RE: [stella] Emulator test program

Subject: RE: [stella] Emulator test program
From: "Fred Quimby" <c9r@xxxxxxxxxxx>
Date: Thu, 28 Jul 2005 01:48:09 -0400
I don't know of one... But I did discover something that is not emulated 
correctly a while ago, regarding spurious writes for read-modify-write 
instructions.  I had the idea that doing an INC WSYNC should give two 
scanlines, but on a real 2600 it didn't appear to work - I could only see 

I found out that the READY line on the 6507 only halts it during read 
cycles.  Therefore the second WSYNC gets executed before the CPU halts, thus 
you only get one scanline.

Similar incorrect behavior would probably occur if you set the SP to $02 and 
did a BRK or a JSR.  The emus would probably freeze after the write to $02 
and do the next 1-2 writes after the scanline was complete, but a real 2600 
would run through all of the writes before halting the processor.

I haven't verified that the above is 100% true, but it does fit in with my 
observation about INC WSYNC.  So while this isn't a torture test in itself, 
such a thing would be a good part of one...

>Does anyone know of a 'torture test' for 650x emulators that
>might be available for download? This would be a really
>handy addition to the literature. Programmers familiar with
>floating point routines can find a program called 'paranoia'
>which is often used to confirm the behavior of floating
>point routines. Something similar for emulators would
>identify specific problems quickly and aid in debugging
>Perhaps someone could suggest a strategy for constructing
>such a test and classifying the result. For example, an
>emulator may just be 'functionally' equivalent to the CPU
>without necessarily being cycle exact. (That would be OK for
>just running many 650x programs.) It may also be
>cycle-exact, but not supporting unofficial opcodes. It may
>also be cycle-exact, with support for unofficial opcodes,
>but without support for some of the page-crossing anomalies
>of the 650x. It may even get all these right, but without
>the spurious reads and writes which the processor actually
>does in normal operation.
>A report card issued after checking and confirming all these
>possibilities would allow emulator writers to set the bar
>where they want and confirm their progress at achieving it.
>Democracy: The triumph of popularity over principle.
>Archives (includes files) at
>Unsub & more at

Archives (includes files) at
Unsub & more at

Current Thread