RE: [stella] Emulator test program

Subject: RE: [stella] Emulator test program
From: "Fred Quimby" <c9r@xxxxxxxxxxx>
Date: Thu, 28 Jul 2005 05:27:49 -0400
I just proved the theory in my last post by writing some code that will run 
on a real 2600 but will crash emulators:

lda #$FF
sta TIM1T
bpl .1

Get to work! :)

>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, 
>you only get one scanline.
>Similar incorrect behavior would probably occur if you set the SP to $02 
>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
> >them.
> >
> >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

Archives (includes files) at
Unsub & more at

Current Thread