From: Tony Duell <ard_at_p850ug1.demon.co.uk>
>> the add-on A-400 oscillator, used to tune your Moog back up as it
drifted
>> off pitch, which they all did more or less constantly. The
documentation
>> mentions retaining this feature even though the emulation no longer
>> drifts.
>>
>> But: why not? Shouldn't it drift, actually?
>
>Hmm... This is a difficult problem.
It was extreamly annoying trying to cut a track and keep pitch over time.
>But as regards undesirable behaviour (computers that suffer from logic
>problems in the design, synthesisers that drift), well, IMHO the
>simulator should be _able_ to exhibit that behaviour as well. A
processor
>designed with a race hazard so that 1 cycle in 10^11 (or so) it does the
>wrong thing should be emulated as having that problem. Maybe there
should
>be an option to turn it off (on the emulator) though.
The bset examples is the 8085 and z80 undocumented instructions that
all the vendors faithfully reproduced for that exact reason.
>It's not going to be trivial to implement that. Not only do you have to
>be able to emulate the machine when some components aren't working
>properly (how many people know what (say) a PDP8/e would do if a given
>gate was stuck at 0 or stuck at 1, what would happen if one input on a
>multi-input gate stopped working), you also have to allow for idiots
like
>me who want to 'cut tracks', inject arbitrary signals, etc. Are you
going
>to allow me to 'desolder' components and test them separately. I am
>thinking about gates that 'go slow' -- I've had 74S TTL that tests fine
>at slow speeds (switches and LEDs on a breadboard) but which fails when
>run at full speed. This sort of fault is painful to find because often
>the machine works correctly when single-stepped as well.
Yes emulating N^X error states is not a lot of fun for something as
simple as
PDP-8 and it gets worse for more complex systems.
Not many would want that save for those training in repair methods.
Allison
Received on Mon Jan 08 2001 - 21:00:42 GMT