Thanks to visit codestin.com
Credit goes to github.com

Skip to content

VIC-II/m6569 emulation issues (and fixes) #99

@c1570

Description

@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.

Metadata

Metadata

Assignees

Labels

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions