a1bert wrote:VICE is accurate with the raster timing in NTSC.
This may have been true for 2.1, but I wouldn't trust the upcoming 2.2 on this
a1bert wrote:There are however some very hard-to-point features in the NTSC VIC-I that don't work in the actual machine while working on VICE.
...but this (sort of) contradicts the first statement.
a1bert wrote:Fixing the problems is hard because at least I could not figure out what actually happens in the real machine that could cause the symptoms, but I have so far managed to find workarounds. Mainly rearranging or delaying writes to horizontal scroll and columns registers.
This seems like evidence for a theory I've had since I started the xvic CPU/VIC-I rewrite...
When xvic is in NTSC mode, the raster line number given by $9003/4 is calculated from the current CPU cycle plus an offset of 37 cycles (as seen in the code snippets posted by Mike earlier in the thread). In other words, what the running program sees is not the same as the internal state, and timed writes to (non-color) registers don't happen when expected. I assume that the problem lies here and that the proper fix would be to move that offset to the "calculate color register change location" macro(s) instead.
However... as there are no suitable testprogs [1] available to confirm/deny this (and due to lack of NTSC VIC-20 expertise/hardware in the VICE team to do them), I've left the NTSC code alone; chances are that some bug crept in and 2.1 works better.
The only way to improve the situation is to write NTSC testprogs. Alternatively, just fix the VIC-I emulation code and send a patch, but I'd still like to see a testprog demonstrating the problem and the fix. (Of course, the same applies for any emulation bug...)
[1] Short, to-the-point and (if possible) descriptive program that tests a specific part of HW functionality; current VICE VIC-20 testprog "library" is
here