It turned out to be an issue with the interrupts and when the
vertical interrupt was triggered vs when the vertical blanking
bit was set. The interrupt code in sonic 2 tries to read the
status bit after the vint occurs, and if the vblank bit is set,
it runs the Vint_Level function, but the hacky code I wrote
turned the vblanking bit on after 14ms and off when it triggered
the vint, instead of turning it on at 15ms, and off at 1.2ms, with
the int occuring at the *start* of the time the blanking bit is
set. So the code had been waiting for 14ms after the vint until
it actually started processing thing, which didn't complete before
the next vint, so it only ran the main game loop every 33.2ms which
is why doubling the speed of the simulated execution time made it
seem about the right speed
The hscroll table was multiplying by 2 (because scroll a and b values
are next to each other) but it should have multiplied by 4 because
each value is also 2 bytes and the array is of u8.
I added hscroll by-line support by using a different function for the
line scroll vs the cell or whole screen scrolling. There are still
a bunch of glitches in scroll b's scroll values that I need to fix
The TH counter in the genesis controller code was increasing each
time the TH bit changed state instead of only in one direction.
Surprisingly it worked before, and fixing it made it not work in
Sonic 2, but after adding the 1.5ms timer to reset the TH counter,
it worked again. I guess Sonic2 only reads the 3 buttons instead
of all 6. It should now work with both 3 and 6 button games
Previously it would show a dump of whatever device was next scheduled
to step, if it was Debuggable, but now each debuggable device has a
flag for whether that device is being debugging, and a system flag
to disable it entirely. When the system flag is set, it will try
to enable debugging on the device labelled "cpu". I need to also add
a way of setting a breakpoint on a named device, which will enable
debugging of that device
It's better than it was but there are still minor drop outs due to
a buffer underrun I think (could be other timing issues related to
the update loop or something else). Right now, the audio chips
just have some code to produce sine waves for testing.
I've added skeleton devices for the sound chips, and added the bank
register and banked area of ram mapped to the Z80's bus. Sonic1 will
now run (if the ym2612 device's size is set to 0x1000 instead of 0x04)
Previously it was storing data in the registers, which was an array
of u8, but now it's storing eg. full addresses for the scroll tables
so that they don't need to be fetched from the register values and
converted every rendering. I was thinking this would maybe make
DMA debugging easier, in particular.
The controller th count was starting at 1 instead of 0 which caused
inputs to be read incorrectly, as well as the fact that inputs are
inverted.
The sprite fix now draws them in the right order so that ComradeOj's
sprite test renders correctly, but games still render them broken
because of some other bug yet to be found
For systems that legitimately use 0 for black, this causes a
problem, so I instead use 0xFFFFFFFF for the mask colour which
corresponds to transparent white in ARGB format, which minifb
doesn't support anyways
It was previously decrementing addresses if the direction was from
registers to memory, but that's incorrect. It should increment the
address always when using an addressing mode other than the ARecDec
mode. I also added a memory location to the test cases to test the
MOVEM instruction by comparing what memory was read/written (but it's
only one u32 because that's the minimum we need)
