Um was kümmert man sich denn als nächstes? Beim VIC II und der CPU gibt es noch diverse Bugs!
CPU
(8g/M1) there exists some timing bug when an IRQ occurs during one of SEI/CLI/PHP/PLP and/or sprite DMA is active (irqdma/test6.prg irqdma/test6b.prg)
TODO: make small specific tests that can run as cbm80 cart
(8g/M1) SHA abs,y ($9f) is broken (Lorenz-2.15/Disk2.d64 shaay.prg, trap(1-6,9-12,16-17).prg)
shaay.prg only tests the basic behaviour (data=A&X&H+1) on a single address with no page crossing, all in border area (under these conditions the opcode is supposed to be stable). it does NOT depend on timing. the way it fails hints that the address calculation is wrong (instable although it shouldnt be?)
(8g) value written to $00/$01 will end up in RAM. (ram0001/quicktest.prg)
instead the last value fetched by the VIC should go to RAM, as the CPU does only generate a write signal, but does not put the value on the bus.
TODO: write deterministic testprogram
VIC (bus interface)
(8g/M1) DMA delay by DEN switching is broken (off by one cycle) (dmadelay/test3.prg) causing errors on the VIC screen
(8g/M1) some DMA delay artefacts are emulated incorrectly (dmadelay/test4.prg) causing errors on the VIC screen (WARNING: this test does not work in VICE either!)
(8h/M1) some problem with sprite DMA (spritedma/d017-54.prg spritedma/d017-57.prg) causing errors on the VIC screen
(8h/M1) some problem with gfx data fetches (split-tests/fetchsplit/fetchsplit.prg) causing errors on the VIC screen
the lightpen irq delay is always like "old" VIC, even if there is a new VIC in the C64 - This should not be a problem however (the difference is one *pixel* only).
Wenn sich da was tun würde, fände ich das so richtig Klasse! ![]()