VGA vs. NTSC timings are not giving the same desired output

[doslogo]

I still don't quite understand what is is that you are saying is wrong.

Scanline register in NTSC mode is not behaving like in the documentation. 240p is not interlaced. Adding +1 to the current scanline register for the next IRQ LINE interrupt shouldn't work since bit 0 is ignored, still every other frame it does work, and the other frame it does just the same as when adding +2 to the scanline register.

The CPU and VERA run asynchronously to one another. If you are attempting to do scanline effects in both VGA and NTSC, you need to understand the timing differences between the two, and you need to understand that some things, like palette changes, happen while the current line is being scanned out, but changes to how the line is rendered will not be seen until the rendered line is being scanned out, which happens one line after the change is made.

I have known this for the last 6 months. I almost got VGA to work like I want. The issue will always be that when you get a chance to touch the VERA scroll registers, the current scanline is already well into the rendering of that scanline, but the next scanline will still have a chance to take effect, ONLY, there is very little time there as well. So many have said you need to make changes that will happen 2 scanlines later, only to realize that some scroll register Y for some layer will be updated the next scanline (+1) while scroll register X of that same layer will be updated the 'next next' scanline (+2).
Once I release my game, I will make sure that every hardware revision and MHz setting of the CPU (and 16-bit or 8-bit variant) will require backward compatibility with the timings I have magically dialed in (we are not talking about a few hours here, weeks of work, first in emulators just to fail on real hardware, then again on real hardware moving SD cards for hours on end). That's what the "compatibility with existing software" is all about, right? But I am giving the hardware team a chance to fix these issues talked about in this thread before committing to almost random undocumented or unproven behavior.

Back to the NTSC problem: I did some further testing by setting the start scanline to an odd value, and then EOR that with 1 every vblank to try to sync with the 60 Hz swapping of fields for 240p (I know, that shouldn't happen, that is interlaced behavior). I was unsuccessful, and it just looked the same as the screenshots above, flickering with one correct output, and one wrong, every frame.

[DragWx]

Are you moving the mouse cursor with a Kernal call, during your ISR? Kernal calls are too slow for that, and can change with updates, so you'd be better off moving the sprite yourself (sprite 0), directly. At least inside your ISR. That could be what was stretching your ISR to two scanlines instead of one.


Edit: To address something you said earlier, yes, if you want a raster effect on every scanline, it will consume 100% of the CPU. When you see fancy scanline effects on the SNES, it's the HDMA doing it. On the Amiga, it's the "Copper" doing it. Those are all automatic "DMA" style features that happen parallel to the CPU executing code.

There's no equivalent hardware on the X16, so we have to do it all manually with a good old-fashioned display kernel (code that is cycle-timed for synchronization). We also need to think about things like, if we're using the VIA to stream data to the FM chip, we have a whole new puzzle to figure out for making sure it doesn't interfere with any scanline IRQs we might also want.

So, you need to identify what you want the scanline IRQ for; if it's to create a 2-player split-screen, that's just one IRQ, and won't affect you very much. If it's to create advanced parallax backgrounds, like Sonic 1, 2, and 3 for Genesis, that's still only happening on a handful of split points, and not every single scanline. If you want something like Pole Position where the road is transformed by shifting every scanline, that's going to be expensive, but a game like Pole Position isn't computationally expensive, and you can limit how much of the screen is the road.

[Wavicle]

Scanline register in NTSC mode is not behaving like in the documentation. 240p is not interlaced. Adding +1 to the current scanline register for the next IRQ LINE interrupt shouldn't work since bit 0 is ignored, still every other frame it does work, and the other frame it does just the same as when adding +2 to the scanline register.

It is still difficult to parse your meaning. Are you saying that if you set the line interrupt to line 150 you expect line interrupts to happen at 60Hz, but in 240P mode they are happening at 30Hz?

I have known this for the last 6 months. I almost got VGA to work like I want. The issue will always be that when you get a chance to touch the VERA scroll registers, the current scanline is already well into the rendering of that scanline, but the next scanline will still have a chance to take effect, ONLY, there is very little time there as well. So many have said you need to make changes that will happen 2 scanlines later, only to realize that some scroll register Y for some layer will be updated the next scanline (+1) while scroll register X of that same layer will be updated the 'next next' scanline (+2).

You seem to be holding context in your head that you aren't expressing here. There are HSCROLL and VSCROLL registers, but you are using language "scroll register Y" and "scroll register X" which creates ambiguity as to whether you are using "scroll register Y" to mean "VSCROLL" or if it means "some arbitrary scroll register other than X". I need a bit more precision to investigate this.

Once I release my game, I will make sure that every hardware revision and MHz setting of the CPU (and 16-bit or 8-bit variant) will require backward compatibility with the timings I have magically dialed in (we are not talking about a few hours here, weeks of work, first in emulators just to fail on real hardware, then again on real hardware moving SD cards for hours on end). That's what the "compatibility with existing software" is all about, right? But I am giving the hardware team a chance to fix these issues talked about in this thread before committing to almost random undocumented or unproven behavior.

If you need a fast path between your dev environment and the X16 hardware, you should consider getting a Calypso. I designed it to ease this exact pain point. If you need to swap CPUs to make sure your game works on both, I have a CPU Switcher for this as well.

I am the one who added 240P mode to VERA and also fixed many issues in composite mode related to timing and interrupts, but I did not write the documentation. If there is a bug in the design here, I'm probably the one who would fix it. I'm not going to be able to do so unless I understand the problem.

[doslogo]

I am the one who added 240P mode to VERA

Just a short reply here, I am sorry for being rude before. I'll respond to the rest later.

I am constantly coming up with new ideas to test VERA, and many of them prove that there might not be a bug.

[MooingLemur]

Could the issue be simply that on VGA, you will get 480 visible lines (525 total lines) in 1 frame, and on NTSC and RGB, you get 525 total lines (or 526 in 240p) in two frames. Therefore, each scanline scans out at (approximately) half the speed?

Therefore 63 NOPs would only consume half a line, as expected.