8 Jan
2001
8 Jan
'01
9 p.m.
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
It was extreamly annoying trying to cut a track and keep pitch over time.
> 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. 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