There are many kinds of C64 games and there's no way to really tell from the program data what system it's supposed to be playing on, which kernal you are supposed to be using, and even which CIA chip (older C64s, really old ones, used 6526A which didn't have some of the bugs the standard 6526 did; I'm not really sure why they went with the buggier ones.. maybe oversupply?)
The best we can do is put the Kernal, Basic, Charrom, and any peripheral firmware checksums (the 1541 for example) and also the C64 type which can be selected by the TASer. Almost all games designed for NTSC setups will play okay on the PAL setups (since most of the time the interrupts are driven by scanline index) but going the other way tends to be sketchy (mostly because the NTSC setup has 263 scanlines while PAL has 315.) Some games autodetect this and compensate for it. Ultimately, it's not up to the game to decide what region it's for, but the user to make sure that they are using a machine that is compatible.
I anticipate there will be instances where a specific kernal/basic firmware are chosen due to exploitable bugs, and C64 type. Games written in BASIC probably won't care, and others that have a lot of idle will also probably have no difference between machine type execution-wise (other than the fact that frame-driven games will run faster on NTSC than PAL, but would otherwise be unaffected unless it needed or assigned the video chip to interrupt on the extra scanlines.)
There is a large number of setups you could have as a result of the number of peripherals you can use. But because software houses didn't always know what kind of setup a user might be using (other than taking a really good guess at PAL vs NTSC due to geographic location) they had to be more flexible.
Another issue is the availability of original media. Some games saved their high scores to the program disk. So even if you own the original game and dump it yourself, you can still end up with a different image.
It would be preferable to use the original disks from the DISKS folder in GameBase64 Extras in order to settle any sort of dispute, as these are maintained in large part by Pete Rittwage (among others at c64preservation.com) with the sole mission to preserve original disks in a way they can be archived and reproduced.
Anyway.. enough with that rant. Right now, things need to "just work". I'm consulting with a number of people who are working on a variety of MOS chips at the transistor level, translating them into logic gates which I can more readily work with. Items of interest are the 6510 (which is the 6502 with tri-state bus to make it play nice in a multi-chip system), 6522 (VIA, how the bugs work), 6526 (CIA, this timer chip is also quite buggy but more progress has been made here), 6581 (SID, virtually everything about this chip is now known), 6567/6569 (VIC, these video chips are essentially identical except for some constants for NTSC/PAL), and they are doing some more stuff with the 6502 as well.
But we already have a solid 6502 core, used for other things. The C64 emulation is currently lacking the ability to halt the 6502 processor properly when the video chip demands the bus on both ph1 and ph2.
Here's why:
BA With this signal, the VIC indicated that the bus is available to
the processor during the second clock phase (ø2 high). BA is
normally high as the VIC accesses the bus mostly during the first
phase. But for the character pointer and sprite data accesses, the
VIC also needs the bus sometimes during the second phase. In this
case, BA goes low three cycles before the VIC access. After that,
AEC remains low during the second phase and the VIC performs the
accesses. Why three cycles? BA is connected to the RDY line of the
processor as mentioned, but this line is ignored on write accesses
(the CPU can only be interrupted on reads), and the 6510 never does
more than three writes in sequence (see [5]).
I couldn't figure out how to buffer reads for the 6502 core. The way it's configured, this value is needed immediately when read and there's no way for me to predict what the CPU wants to do until I actually execute its code. Suppose it was reading a timer chip value that decrements by 1 every cycle. The value will be incorrect by however many cycles the CPU needed to be delayed. Since a "badline" happens (usually) every 8 scanlines, and the VIC has to "stun" the processor for 40 cycles (not counting the additional cycles needed for sprite access if they are used) the likelihood of the wrong timer value being read is extremely high if the game is counting cycles (this technique is often used for "stable rasterlines", a graphics trick.) Some timing-sensitive games, when they get consistently incorrect timer values, will have a cascading effect: they could cause some very obvious graphics anomalies or perhaps not even run at all.
I didn't want to muck about with the 6502 core. Any ideas would be greatly appreciated.
This isn't going to tell us anything about 100% accurate emulation- only that the vital parts aren't obviously failing. Pretty much everything in the right column is handled by the timer chips (the interrupts that are failing are definitely the 6526 timers) so there's much work to be done there. These chips are pretty buggy to begin with.
The 6581 sound chip failure is due to the lack of filters, I imagine.
What blows my mind is that it passed the 6567 (video) chip test. I'm convinced it doesn't check much other than the register I/O works. I know for a fact it needs a lot of work, especially for sprites (sometimes the bottom sprite line is missing.) And even if it checks those, it's the PAL 6569 chip that's actually emulated so the scanlines aren't even the same in number of lines and length in cycles. I do know for a fact that it checks video interrupts and it'd let me know if those failed, so when it claims that interrupts failed, it's not this chip.
It's no surprise everything in the left side passed- that's all 6502 core, ROM and RAM. There are more comprehensive tests that I need to compile into cartridge form to find out in depth if there's anything truly off.
