VIC-II/m6569 emulation issues (and fixes)

[c1570]

While working on https://github.com/c1570/Connomore64 I found some VIC-II emulation issues in chips. On the real VIC-II...

• writing to D011/D012 can trigger a raster IRQ immediately (if no raster IRQ has been triggered for the current line already)
• G/C data doesn't feed into the gunit directly - there's a one cycle delay instead (you can see that in https://www.c64-wiki.de/wiki/Raster-Timing#K.C3.BCnstliche_Badline_.28exakt.29 and https://www.c64-wiki.de/wiki/VIC#Arbeitsweise ).
  • After fixing that you'll have to move the bunit checks one cycle, which will also fix opening the left/right border.
• There'll be a DMA delay/VSP offset of 1 already if triggering a badline in cycle 15 (even though incrementing VC only happens in the G access in cycle 16). VICE etc. do the badline check after G accesses. I fixed this by introducing next_vc = vc + 1 in C accesses, then doing vc = next_vc at the end of G accesses, which is a bit of a hack, but it avoids doing badline checks every single cycle. - See https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VICII/dmadelay/ for tests.
• XSCROLL can get updated in any cycle (and will be visible with one cycle delay). At the moment, m6569.h latches XSCROLL in cycle 16.
• Sprite Crunch support is missing/inaccurate (see VICE code).

If you want some more test programs, let me know. I recommend testing with Mayhem in Monsterland as its title screen has pretty tight timing.

[PatrickvL]

Please share a link to your fixes, curious what you've done here...

[floooh]

Very cool, thanks for the investigations @c1570, I don't know yet when I'll get around to work on the C64 emulation again, but when I do I'll try to implement your findings.

PS: your RP2040 project is frigging amazing!