NTSC raster problem

[a1bert]

I have big problems with NTSC raster changing in the middle of the screen on Atalantis in my emulator

VICE is accurate with the raster timing in NTSC. 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. In normal circumstances you are very well able to develop everything in VICE and it will work with the real NTSC machine.

If you do heavy VIC-I manipulation you should test the result with the real machine when you are done. 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.

[TBCVIC]

Thanks for you insight. For now I haven't planned to change the scrollregisters to scroll anything, so I hope I'm safe then. I'll just code for a few years until I finished and then ask someone to test it for me

[nojoopa]

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

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.

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

[a1bert]

...but this (sort of) contradicts the first statement.

Well, the color register and matrix/font register timing is accurate (compared to screen refresh).

If I only had infinite time, I could get a test prog out that would demostrate one of the "features" I run into (having a NTSC-converted VIC20 in my closet to take out when needed helps test things).