I'm writing a PCE emulator and while it runs a lot of games I'm having trouble with a few glitches.
1) When exactly does the RCR check happen? Is it at the beginning of the scanline (cycle 0), or after the scanline has been drawn (cycle 1127), or somewhere during the hblank (between 1128-1364)?
2) Does the RCR check against the current scanline, or the next one? As in does it fire an interrupt as it starts to draw the matched scanline, or does it give you time to change things like BYR before it starts drawing?
3) When does the BYR latch increment? It seems that when you write to BYR it doesn't take effect until the next line so there's a latch involved, but some games seem to be off by a line if I don't pre-increment BYR before drawing with it. I can only assume this means I'm incrementing at the wrong time and some games set BYR at different times expecting the correct behavior.
RCR, IIRC, happens when HDW ends(pretty sure it's the end of HDW and not the end of HDE). The VCE signals to the VDC when hblank starts. HSW is pretty much just stall time for the VDC, so it can sync with outside driving device (like the VCE). Having too large a HSW has no effect since it causes the VDC to go to the next phase (HDS), but too small can cause a double interrupt if it's missing the sync signal window. If the VDC is setup in a manner in which the 'scanline" is too small, the VDC will start drawing the next scanline on the same scanline (since it's just feeding the digital pixel bus to the VCE). So the VDC will trigger an interrupt once(when HDW ends), and then again when the VCE asserts hsync to the VCE (which automatically causes the current HDW to end, thus getting another interrupt if RCR is set for the next scanline).
I haven't tested it, but I remember Exophase saying he tested BYR and BXR being latched some cycles apart, but relatively close to the width of the scanline. IIRC, BYR and BXR are latched when sometime during HDS (and obviously before HDW starts).
I'm super busy at the moment, but I could test some stuff on the real system for you next week, if you need.
Thanks, I'll give these settings a try. I wasn't thinking of it in terms of HDS+HDW+HDE+HSW, which I should have been doing. I figured it had to be on a boundary of some sort but I was only thinking of hblank+vblank from the VCE.
I'd love to see the results of testing on real hardware, but I should be able to manage without in the meantime if you're too busy.
If you already have some tests specifically for this I can run them on a PAL TurboGrafx.
mic_ wrote:
If you already have some tests specifically for this I can run them on a PAL TurboGrafx.
I wish I had a PAL TG. The hack they did is pretty advanced (the VCE isn't outputting a PAL timing frame). Lots of tests I'd run on that thing. Maybe someday I'll get one.
tomaitheous wrote:
mic_ wrote:
If you already have some tests specifically for this I can run them on a PAL TurboGrafx.
I wish I had a PAL TG. The hack they did is pretty advanced (the VCE isn't outputting a PAL timing frame). Lots of tests I'd run on that thing. Maybe someday I'll get one.
Consolegoods sells PAL units new/boxed for about $80. Or about $110 if you want it modded for RGB output.
Keep in mind that they are shipped from the UK, and come with 230V power supplies.
Incrementing after BYR when hblank starts and latching it when hblank ends cleared up a lot of problems for me.
As for RCR, I think it increments the scanline counter first at the end of HDW then triggers the interrupt if RCR matches the counter. This causes the least amount of problems for games on my emulator but it isn't perfect so it may not be entirely correct.