This changes the register read semantics of the IRQLINE_L register and IRQLINE bit in the IEN register to return the y_counter from the composer. Since 9 bits is not quite enough to count up to 524, the value will stick at 9'b1_1111_1111 from lines 511-524.
Originally this was intended to be a light weight top-level only change, however after reviewing some demo programs it was realized that using line_idx would return the "effective" scan line, not the true scan line. After weighing options, it was determined that software would be able to make much more use of this if the true scan line were returned instead, thus y_counter is now routed out of the composer module up to the top.
The behavior of SCANLINE during interlaced display modes generated a lot of discussion, and the pro's and con's of several options were considered, but ultimately the decision to go with a simpler interface was decided as being the better option. SCANLINE will contain only even values during even fields and only odd values during odd fields. This has the side effect of making SCANLINE[0] a copy of Current Field (Bit 7 of DC_VIDEO) during interlaced modes.
It was discovered that these new read/write semantics have the potential to introduce a new bug into existing software: if the software does a read-modify-write of the IEN register, there is a chance that the value of SCANLINE[8] will not match IRQLINE[8] and the line irq value will end up happening 256 lines earlier or later than intended. After further discussion, it was decided that the substantial benefits that this feature provides outweighs the relatively minor inconvenience of keeping track of what IRQLINE[8] should be. This new behavior will need to be communicated to software developers. Read-modify-write instructions, like W65C02's TSB or TRB, should not be used to enable or disable interrupts unless SCANLINE[8] is restored immediately afterwards.
This changes the register read semantics of the IRQLINE_L register and IRQLINE bit in the IEN register to return the y_counter from the composer. Since 9 bits is not quite enough to count up to 524, the value will stick at 9'b1_1111_1111 from lines 511-524.
Originally this was intended to be a light weight top-level only change, however after reviewing some demo programs it was realized that using line_idx would return the "effective" scan line, not the true scan line. After weighing options, it was determined that software would be able to make much more use of this if the true scan line were returned instead, thus y_counter is now routed out of the composer module up to the top.
The behavior of SCANLINE during interlaced display modes generated a lot of discussion, and the pro's and con's of several options were considered, but ultimately the decision to go with a simpler interface was decided as being the better option. SCANLINE will contain only even values during even fields and only odd values during odd fields. This has the side effect of making SCANLINE[0] a copy of Current Field (Bit 7 of DC_VIDEO) during interlaced modes.
It was discovered that these new read/write semantics have the potential to introduce a new bug into existing software: if the software does a read-modify-write of the IEN register, there is a chance that the value of SCANLINE[8] will not match IRQLINE[8] and the line irq value will end up happening 256 lines earlier or later than intended. After further discussion, it was decided that the substantial benefits that this feature provides outweighs the relatively minor inconvenience of keeping track of what IRQLINE[8] should be. This new behavior will need to be communicated to software developers. Read-modify-write instructions, like W65C02's
TSBorTRB, should not be used to enable or disable interrupts unless SCANLINE[8] is restored immediately afterwards.