Commander X16

Hello Everyone,

I've another update on the VERA design, and this one is important if you are working with VERA interrupts. Please read if you write games, demos, or any program that uses line interrupts.

The IRQLINE register now has different read and write semantics. Writing the IRQLINE register (IRQLINE_L / $9F28 and IEN / $9F26 bit 7) still works the same, however reading the IRQLINE register now returns the new SCANLINE register. This is a 9 bit raster line counter that starts at 0 and counts up 511. It will sit at 511 for scan lines 511-524. 511-524 are "scan lines" that happen during VSYNC. In progressive scan mode, 479 is the last visible line.

In interlace mode, SCANLINE counts even numbers on even fields and odd numbers on odd fields. This means that bit 0 of the SCANLINE register reports nearly the same thing as bit 7 of the DC_VIDEO register.

There is one "trap" here that developers need to be on the lookout for here: it is not safe to set bits in the IEN register using a read-modify-write. Performing a code sequence such as LDA $9F26 / ORA $02 / STA $9F26 or using the W65C02 bit set/clear opcodes has a chance to flip the value of IRQLINE bit 8 depending on the line being drawn when that code executes. Any code writing the IEN register will need to know what the value of IRQLINE[8] should be because it is no longer accessible through the register interface.

This was discussed at some length on Discord and the feedback from those present was that the drawbacks from having to take a few extra steps when writing the IEN register was outweighed by the benefits to some types of software being able to poll for a particular line. If anyone feels that we reached the wrong conclusion, please make your case (constructively and with civility!) in this thread so that we know where to find it.

More details can be found in the PR implementing this change here: https://github.com/fvdhoef/vera-module/pull/21

Here is sample output from a demo program written by @MooingLemur that changes the background color every scanline.

So, we should poll IRQLINE(8) and then write to IEN?

My 4096 color demo would probably be affected.

I'll update it to R41 this weekend. @Wavicle could you then test this on hardware with the latest Vera?

 

On 9/23/2022 at 10:04 AM, Ed Minchau said:

So, we should poll IRQLINE(8) and then write to IEN?

The assumption is that if you are enabling interrupts, you already know what IRQLINE should be. You need to mask off bit 7 and set it to whatever it should be before writing it back out.

Hello again, everyone. As we've had a chance to test this change out on more software, I think that I underestimated the impact of the "trap" above.

@ZeroByte suggested moving bit 8 of the SCANLINE from IEN[7] to IEN[6] which will re-enable read-modify-write operations to IEN. (E.g. you can enable a single interrupt by doing IEN |= 0x20 without knowing what bit 8 of the line IRQ should be).

Let me know of any problem/issue you see with this modification to the new (and as yet unsupported in the emulator) scanline feature.

On 9/28/2022 at 12:10 AM, Wavicle said:

moving bit 8 of the SCANLINE from IEN[7] to IEN[6] which will re-enable read-modify-write operations to IEN. (E.g. you can enable a single interrupt by doing IEN |= 0x20 without knowing what bit 8 of the line IRQ should be).

I like that a lot more ?.