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

[DragWx]

I don't have a way to test composite mode on my hardware, but I think the scanline register in the emulator is wrong when in NTSC mode, as you've discovered. There's an issue already open because someone agreed with you that it smelled fishy, and I've added some info there.

[doslogo]

I was thinking about what can be the problem with waiting too long on a scanline, and wonder if the acknowledgement of the IRQ LINE must happen before or after the NOPs? What if a new IRQ LINE is generated while still processing the interrupt, even if the scanline number was changed (doesn't make any sense). Then we have this annoying 9th bit of the scanline number which is different on read and write, and who knows if there is a sync issue when the hardware or emulator fetches those.

My game is much more complex compared to the test I made for this thread, with the game and interrupts not corrupting VERA state etc. But my knowledge of 6502 interrupt logic is in its infancy, with less than a year of learning a whole new CPU architecture.

in the emulator is wrong when in NTSC mode

It's basically wrong with timings and even interlaced vs. progressive. But, the VGA is also wrongly timed when compared to the real hardware so I don't think one fix would solve all problems. The emulator will probably be fixed once people like me write games that will show up differently compared to real hardware... At least that is my hope.

[DragWx]

1) Any interrupts you don't acknowledge will immediately cause another IRQ the moment you return from your ISR.

2) If another IRQ happens during your ISR, it won't trigger another IRQ as long as you didn't touch the CPU's "I" flag, but it will still set the appropriate bit in $9F27. Ideally, you'd structure your code such that you don't unexpectedly run into another line IRQ while you're already in your line ISR, but if you need to, the way you'd check for this is by acknowledging the line IRQ at the beginning, then checking $9F27 at the end to see if the bit is set again.

3) I see that your ISR always acknowledges both LINE and VBLANK IRQs regardless of which one actually hit. If your LINE ISR stretches past the time where the VBLANK IRQ happens, then your ISR will accidentally acknowledge the VBLANK IRQ and skip it entirely, so be sure not to acknowledge the VBLANK IRQ until the VBLANK path in your ISR runs.

4) If you know your line ISR will always be at risk of overlapping VBLANK IRQs, you can check for the VBLANK flag in $9F27 at the end of your line ISR and jump straight to your VBLANK ISR and save yourself the round-trip of POP/RTI/AnotherIRQ/PUSH.

[Wavicle]

I made an experimental change this weekend that moved the timing of the line interrupt to the end of active display. I ran it using the test program here. While it did move the location where the background color changes earlier, it was still in the visible area of the display. I did not expect this; it should have given roughly 12 microseconds between the end of active display of one line and the beginning of another. I'll continue digging in.

Regardless, the experimental change negatively affected some existing software. If this change were to go into VERA, it would have to be done as a special type of line interrupt to prevent breaking existing software.

[doslogo]

I made an experimental change...
While it did move the location where the background color changes earlier, it was still in the visible area of the display. I did not expect this; it should have given...

It has been known for some time that there is no time to make it to our own interrupt code, but we should have had a chance by placing the interrupt at the end of the visual scanline instead of at the beginning, but we can still do something with the current setup, like waiting in the interrupt until the end of the active area (which works in VGA but not in NTSC for some odd reason)!

My first entry of this thread talks about the scroll registers before even going into the more visual backdrop color change. There is a hidden timing per scanline where the scroll registers latch (for future rendering of a scanline), and that is not fully set in stone (emulators guess this quite badly, I am afraid). With the current problems of the NTSC (that is both Composite and S-video) timings, those scroll registers are also latched at some other hidden time compared to the VGA.
The priority should be to find the NTSC problem (if there is one), and then work our way to find a safe way to set the scroll registers per scanline (only in 240p at the moment), so that current software can still work, but newer ones will benefit from adding parallax scrolling and other raster effects commonly used by other consoles and 8-bit computers.

Also thank you for testing things! I will write a new test right now that will move the sprite (mouse cursor) to whatever the scanline counter is (cache the counter, then write that to the sprite's Y coordinate), to hope find something odd. Since we can't print the value or pause the machine to read the registers, I am hoping that a visual sprite can indicate if something is bad about the counter itself. I'll post my findings later as well as respond to DragWx's post.

[doslogo]

I see that your ISR always acknowledges both LINE and VBLANK IRQs regardless of which one actually hit

Yes, but when I did just acknowledge vblank by itself, no matter if I had set the scanline to go off at 436 (before leaving vblank isr), IRQ LINE triggered directly at scanline 481 instead (in the official emulator with VGA).

save yourself the round-trip of POP/RTI/AnotherIRQ/PUSH.

As mush as I hate the round-trip, my game have quite many cycles to squeeze in between 2 scanlines (remember, 240p). Not many cycles, but enough to warrant using the raster effect in the first place.


So I did a test with the mouse cursor following the interrupted scanline, and using those 169 NOPs required by NTSC and it actually looks like it worked (at double scanline 118, do one black, then one red, and so on for 22 double scanlines; set sprite Y to scanline counter):

nops169_spr.JPG (144.81 KiB) Viewed 163 times

I have no idea if there are actually cycles left inbetween those scanlines, but I really hope so.
So this test proves the (read only) scanline counter works on the real hardware.

Does NTSC work then? Possibly. I need a way to test some game logic outside of interrupt time, like another sprite moving a distance. Also I need to find when the scroll registers are latched for a particular scanline.


Attachment includes the source and program for this test, which can probably help making the emulators better (they completely fail all NTSC but also VGA timings)

LINETIM2.zip

(3.88 KiB) Downloaded 4 times

[Wavicle]

I made an experimental change...
While it did move the location where the background color changes earlier, it was still in the visible area of the display. I did not expect this; it should have given...

It has been known for some time that there is no time to make it to our own interrupt code, but we should have had a chance by placing the interrupt at the end of the visual scanline instead of at the beginning, but we can still do something with the current setup, like waiting in the interrupt until the end of the active area (which works in VGA but not in NTSC for some odd reason)!

My first entry of this thread talks about the scroll registers before even going into the more visual backdrop color change. There is a hidden timing per scanline where the scroll registers latch (for future rendering of a scanline), and that is not fully set in stone (emulators guess this quite badly, I am afraid). With the current problems of the NTSC (that is both Composite and S-video) timings, those scroll registers are also latched at some other hidden time compared to the VGA.
The priority should be to find the NTSC problem (if there is one), and then work our way to find a safe way to set the scroll registers per scanline (only in 240p at the moment), so that current software can still work, but newer ones will benefit from adding parallax scrolling and other raster effects commonly used by other consoles and 8-bit computers.

Also thank you for testing things! I will write a new test right now that will move the sprite (mouse cursor) to whatever the scanline counter is (cache the counter, then write that to the sprite's Y coordinate), to hope find something odd. Since we can't print the value or pause the machine to read the registers, I am hoping that a visual sprite can indicate if something is bad about the counter itself. I'll post my findings later as well as respond to DragWx's post.

There are a few things that affect timing. One of the most significant is that each line is rendered into an 8-bit line buffer before scanout. Because of this, changes to the palette will take place immediately, but changes to line rendering (e.g. scaling) will not be visible until the line is scanned out. The change to scaling takes place close to immediately (worst case by the time the next block of data is pulled from memory) but it is not immediately visible.

It should be possible to wait until the end of active display in composite mode, but one must remember that individual lines scanout at roughly half the speed in composite mode compared to VGA.