20 Jun
2009
20 Jun
'09
12:45 p.m.
Andy Holt wrote:
I've spent time writing an emulator for a machine I don't own and for
which I have a certain amount of documentation.
<<<<
I've written a couple of emulators a long time ago.
The more memorable one being for the F8 microprocessor that ran on the ICL
1900, was written in
assembler (probably GIN5, might have been PLAN) and whose execution speed on
the mainframe was
almost the same as for a real hardware F8.
The difficult decision was whether to follow the documentation or the real
hardware in a very
common situation.
I ended up hitting the same sort of decision while writing my PERQ
emulator (or rather, the decision was forced on me at a later point) --
the PERQ's CPU contains an "expression stack" which is 16 levels deep.
According to the official microcode documentation, the behavior of this
stack on overflow/underflow is "undefined." I coded the emulator to log
a warning when this occurred and to clip the value into the range
[0,16], under the (naive) thinking that the only times this clipping
code would be hit would be when an emulation error occurred, and I'd
want to know about it.
Well, that caused a very subtle bug that took me a long time to track
down. There is some microcode (notably, a RNG loaded by the game
PERQMan) that accidentally "leaks" a pop on every invocation and it's
only the fact that the _real_ hardware wraps the eStack pointer around
that allows it to run on the real hardware without destroying the
stack. (It's still dumb luck that it manages to work at all.) This was
crashing horribly on my emulator with really odd results. After doing a
lot of debugging, I tracked it to the RNG microcode and made a very
simple change to the eStack code. Now I can play Pac-Man on PERQemu,
and all is well with the world...
Josh
Andy