I have fixed bugs with the read-modify-write instructions, PLP, PHW, the $nn,Y addressing mode (it had a copy and paste error and was acting like $nn,X), the MAP instruction was no inhibiting interrupts and numerous others.
I also finally got around to making the dummy write in read-modify-write instructions only happen if the target address is $D019, i.e., to acknowledge VIC-II interrupts, thus avoiding an extra cycle in those instructions.
The CPU now passes the Lorenz 6502 tests for all the legal opcodes, and C64 and C65 mode BASIC both work, as does the DOS for the internal drive, making it easier to test a wider variety of software again. The Lorenz test suite takes about half an hour on a real C64, but all the official 6502 opcodes can be tested on the C65GS in under a minute. This really is a fast 8-bit computer.
However, not everything is right, since Bouldermark crashes for a reason I have yet to discover. Synthmark64 runs fine, however, and the speed is almost unchanged from the last test. The slight slow-down is due to putting back a necessary wait-state when reading from colour RAM.
|Obligatory screen shot of Synthmark64 running very fast indeed.|
I also put some effort into tracking down some bugs in the newly added parts, including the emulated stereo SIDs (although they both come out the same mono audio jack right now). Apart from some speed issues, which is just as likely due to the 60Hz screen refresh rate as anything, sound is now working, as tested in Bouldermark and Lemmings.
The VIC-IV reimplementation is not yet complete, with multi-colour and bitmap graphics modes still having a few bugs to shake out. I did manage to get extended colour mode and bitmap modes working to some degree, although multi-colour mode and bitmap modes both have some problems to work out, which I have yet to fully explore.
Along the way I also added support for the DMAgic DMA controller to DMA memory from outside the 1MB C65 address range. This is used to copy the disk chooser program from the Kickstart ROM to $C000 at start up. Similarly, chained DMA lists are now supported, and one chained DMA list does the copy as well as clear the screen and colour RAM. Clearing 4KB RAM and copying another 4KB RAM all takes about 13,000 cycles, about the equivalent of five rasters on a real C64.
The next steps will probably be to debug the multi-colour graphics problems to figure out what is going on there, so that graphics looks right. Then I might finally get started on implementing writing to SD card and implementing sprites, at which point all core functionality will exist, however flawed and imperfect it may be.
My plan for sprites is to have the 8 normal C64 sprites, plus another 8 (or 16 if I can manage it) 64x64 256-colour sprites. These will each require up to 4KB of data. I am thinking about how I can make the sprite data fetching character based, so that the sprites can be made up from 8x8 pixel character tiles, making for much more efficient use of memory. In principle I could re-use the character generator machinery