Erik states:
"That is not "synchronization", that is emulating."

Richard replies,

Well, then these things we use are not microcomputers, they're emulators. I always thought an emulator was a device external to the target system that emulated the performance of the target device. I guess I'm wrong ...

and Erik says,
"You are. An emulator typically uses a bondout version of the identical, very same chip that it emulates."

to which I reply,

Well ... you're discussing what it does, rather than what it IS ... either that or you're all wet, so to speak. The emulator is the stuff that comes when the FedEx guy drops it off after you've send the better part of a K-buck to someone you don't know, hoping to get a useful tool to help with your hardware/firmware development tasks. Emulating is what IT does. Running the code in its ROM is what the target system does. When there's a resident debugger present, it runs that, and, under the supervision of the debugger, it can also run the code in its ROM. How it does that can vary.
*
Erik states:
"...Ceibo can go to 33MHz."
and I wondered,
"Does it execute one instruction per clock tick at that rate?
Feel free to ask them http://www.ceibo.com/, as I said "I do not use Dallas chips"

They can and do, but I don't know how well, how costly, and what "additions" e.g. pods, etc, I'd have to buy before I could get useful work out of their product.
*
Erik states:
"...No simulator will ever be "true"."

to which Richard replied,

There's nothing to prevent it.

to which Erik replied,

"True, but how will you "simulate" things like exact UART timing with Gatesian software involved."

and I say,

This is exactly why I prefer the resident debug monitor. Bill Gates has no effect on how it performs.

Simulators compute the behavior and timing of the target device/system. If you simulate something you don't expect it to simulate at real-time rates, but you do expect the output of the simulator to contain precise timing. How it's presented can vary quite a bit, but a "REAL" simulator rather than some of the toys commonly available, will enable you to schedule inputs from outside the target device quite precisely in a stimulus file, and that, together with the definition of ROM and RAM, plus the clock(s) are fed to the simulator. The output is a complete representation of all the signals, register content, memory content, etc, that results from the stimuli and when they occur. The simulator pretends it's the MCU, with all its peripherals, and the stimulus file is all the inputs including clocks and ROM and when they happen. The output file contains a schedule of events, at whatever resolution you specify, of the computed signals on the CPU, and, if available, the resulting memory and register content. Most modern simulators have a tool for observing the output data graphically.

This is nothing new. I used HILO under UNIX back in '88 or so in exactly this way. PSpice does things in more or less this way, though MCU models for PSpice are scarce. If you put an MCU into FPGA, the device vendor's simulator will probably handle things in this way as well, though you'll have to specify the input stream in VHDL or VERILOG by means of whatever TEXTIO they support. You can specify timing resolution down to picoseconds if you like.
*
Erik said,
"about complaining to KEIL

The case is that if the first that find a problem does not "complain" the next will find it and the next.... I consider it an obligation to make suppliers aware of their problems for the benefit of my fellow developer."

... with which I agree, though I have repeatedly had the experience that their folks have pointed me to reference information discussing the DS80C320, which is not what I wanted when I asked about the DS89C4x0 series. Their sales person was scarcely aware of the DS89C4x0 series and that's been the rule rather than the exception whenever I contacted them. I believe their institutional position is that the DS89C4x0 series must be like the 'C320, hence, deserves no special attention. This couldn't be farther from the truth.

the 'C320 uses four (?) clock ticks to execute a byte of code, while the DS89C4x0 series uses one. The DS89C4x0 series provides a faster external memory/device interface than other 805x-family members, in that they have a couple page modes in addition to the "usual" external memory/device interface. Mode 1 multiplexes low and high byte of the external memory address on P2 while holding data static on P0. This helps with data setup and hold times at external devices. Mode 2 multiplexes data and high address byte on P2, holding the low address byte static on P0. This helps mitigate propagation delays through external decoding logic if it's present.
*
Erik said

"I gather that the Dallas thingies are addressing somewhat similar to the Philips MX and 669 series (linear 23 bit addresses). This addressing is supported by the AX, CX and LX products."
which doesn't happen to be the case, but then I can't keep up with all the enhancements and variations on the market either.

RE