|
Post by dshadoff on Feb 2, 2020 19:29:04 GMT
I'd like to understand the timing of VSYNC/HSYNC/VBLANK interrupt at the end of the frame.
I would take oscilloscope measurements myself, but the IRQ1 line is not exposed on the bus, so I would need to open up a console to take the measurement - and I thought that somebody here might already have this information, or might be in a better position to take the measurement.
What I would like to know is: - at the time of the VSYNC assertion, is the HSYNC pulse (a) non-existent, or (b) a delay of the VSYNC signal going low ? - at what point in this timeline is IRQ1 asserted ? At the precise moment of VSYNC transition, or approximately 5uS later (which may or may not be the moment when the signal goes low) ? Or is it earlier ?
I ask this question because the timing of VBLANK IRQ seems like it could be slightly different on a real machine versus Mednafen and MiSTer (by about the width of a HSYNC signal).
Chris' CPUtest program has a vertical line cycle-timed from VBLANK, and it shows slightly to the left on a real machine as compared to Mednafen and MiSTer, implying that these emulations have a delayed IRQ or some other small CPU wait which doesn't exist on a real system.
|
|
|
Post by elmer on Feb 2, 2020 20:26:38 GMT
I'd like to understand the timing of VSYNC/HSYNC/VBLANK interrupt at the end of the frame. ... What I would like to know is: - at the time of the VSYNC assertion, is the HSYNC pulse (a) non-existent, or (b) a delay of the VSYNC signal going low ? - at what point in this timeline is IRQ1 asserted ? At the precise moment of VSYNC transition, or approximately 5uS later (which may or may not be the moment when the signal goes low) ? Or is it earlier ? I ask this question because the timing of VBLANK IRQ seems like it could be slightly different on a real machine versus Mednafen and MiSTer (by about the width of a HSYNC signal). Gods yes, it would be wonderful to get some cycle-accurate information about the PCE's video timings, and especially the relationship between the video signals, the VDC settings, and the interrupts! The old Ki's Research Room website that disappeared when geocities died, has this to say about a couple of your questions ... <Oct.07 2008> /HBLANK and /VBLANK
The /HBLANK and /VBLANK signal outputs of VCE are observed on every 21.47727MHz "master cycles." D0, D1, ..., D7 means data bit 0, 1, ..., 7.
/VBLANK becomes "L" or "H" 30 x master cycles after /HBLANK becomes "L" (1)(2)
/HBLANK-L-PERIOD = 237 x master cycles (1)(2) /HBLANK-H-PERIOD = 1128 x master cycles (1)(2) --> Total /HBLANK-PERIOD = 237 + 1128 = 1365 x master cycles (1)(2) /VBLANK-L-PERIOD = 4095 x master cycles (1)(2)
[When VCE $400.D2 = 0] /VBLANK-H-PERIOD = 353535 x master cycles (1) --> Total /VBLANK-PERIOD = 4095 + 353535 = 357630 x master cycles (1) [When VCE $400.D2 = 1] /VBLANK-H-PERIOD = 354900 x master cycles (i.e. 353535 + 1365) (1) --> Total /VBLANK-PERIOD = 4095 + 354900 = 358995 x master cycles (1)
(1) Not affected by any values written to VCE $400 D0-D1 throughout the test. (2) Not affected by any values written to VCE $400 D2 throughout the test.
|
|
|
Post by dshadoff on Feb 2, 2020 22:07:34 GMT
Hmm... this is all good information, but is missing a few variables. For instance, it doesn't seem to indicate how HDS, HDW, etc. are treated, nor when exactly IRQ1 is triggered... This all started when I was looking at why MiSTer FPGA places Chris Covell's CPU Test's vertical line in the wrong spot on the screen. Since it is positioned by a CPU-wait loop, and since the CPU on MiSTer is now in good shape (except CSL opcode), this means that the starting point of the counting was wrong... in exactly the same way that it is wrong in Mednafen. So, the hunt... which is explored in this thread on the MiSTer forums, starting about here: www.atari-forum.com/viewtopic.php?f=117&t=32496&start=275#p392498Chris did some oscilloscope captures of the VSYNC/HSYNC signals and timings, and came out with roughly what Ki's log had. But still, it wasn't clear when IRQ is triggered... moreover, the VSYNC/HSYNC signals are different on MiSTer. As indicated within that thread, this article explains a lot of details why the MiSTer signal is good, and the PC Engine signal is OK - but that it depends on where in the PC Engine that you grab the signal from !! www.hdretrovision.com/blog/2019/10/10/engineering-csync-part-2-falling-shortAll this to say that I can now trust both of the VSYNC signal patterns as being OK (even though they are different)... but still no IRQ, and it isn't on the bus. I've been tinkering in the VHDL code, and it *appears* that the correct spot for the IRQ to be triggered is actually "at the beginning of the display area on the first non-display line"... but I don't have a graphic output to demonstrate yet, nor a confirmational scope trace from a real system. Next up, I also want to confirm the same timing on the RCR interrupt... Mednafen seems to have that correct, but MiSTer seems a bit late.
|
|
|
Post by elmer on Feb 2, 2020 23:45:04 GMT
Hmm... this is all good information, but is missing a few variables. For instance, it doesn't seem to indicate how HDS, HDW, etc. are treated, nor when exactly IRQ1 is triggered... As I posted in this thread ... pcengine.proboards.com/post/7633/threadMy tests with Chris's Screen Dimension Test program, together with the test program that I made when punch was asking about RCR interrupts, shows that HDE, HSW and HDS basically seem to have no actual effect on the RCR timings. The RCR interrupt seems to occur at the end of the VDC's HDW period (a few cycles before, likely just after the final character's pixel data has been read from VRAM). It looks like the rising edge of the VCE's HSYNC pin causes the VDC to transition from whatever-it-was-doing into starting the HDS period. The VDC's HDE, HSW & HDS settings have no effect on when the interrupt is triggered, and they don't seem to effect when the BXR & BYR registers are shadowed/locked for the next line's display (i.e. the shadowing doesn't *appear* to be related to the start of the HDS period, which rather surprised me). I kinda assume (with little evidence) that the VDC's VBLANK interrupt is similarly only loosely coupled to the VCE's VSYNC pin state, and that it has more to do with the VDW counter. Didn't turboxray post some split-screen stuff years ago that showed that you could get 2-or-more VDC vblank-interrupts in a single frame if you set up some short screen heights? Perhaps I'm just remembering that wrong.
|
|
|
Post by elmer on Feb 3, 2020 4:10:08 GMT
Didn't turboxray post some split-screen stuff years ago that showed that you could get 2-or-more VDC vblank-interrupts in a single frame if you set up some short screen heights? Perhaps I'm just remembering that wrong. A quick test shows that the VDC's VBLANK interrupt occurs shortly after the end of the last line of the display (i.e. the VDW), it has absolutely *nothing* to do with the timing of the VCE's vsync signal.
|
|
|
Post by dshadoff on Feb 3, 2020 5:55:50 GMT
Hmmm.... that makes sense.
But my empirical measurement has "shortly after" meaning: - on the line immediately after the last displayable line - at the transition point between HDS and HDW
...But that's from tinkering with MiSTer code.
According to Mednafen, the RCR interrupt happens 4 cycles (not sure if that's pixels or partial-pixels) prior to the end of HDW... I'm just getting ready to test this out. Of course, if I had a machine open, I could take measurements...
|
|
|
Post by elmer on Feb 3, 2020 7:10:46 GMT
Hmmm.... that makes sense. But my empirical measurement has "shortly after" meaning: - on the line immediately after the last displayable line - at the transition point between HDS and HDW ...But that's from tinkering with MiSTer code. I've put an RCR interrupt on the last line of a 200-line display so that I can do some timing tests. The VDC's vblank interrupt is definitely coming after RCR interrupt, sometime around/just after the beginning of the HDW period of the first non-display line. I'll do some more tests, but first I had to figure out *exactly* (or as close as I can get) to when the RCR interrupt is triggered. According to Mednafen, the RCR interrupt happens 4 cycles (not sure if that's pixels or partial-pixels) prior to the end of HDW... I'm just getting ready to test this out. Hmmm ... my test is showing that Mednafen is triggering the interrupt a little late. IIRC, mednafen's internal VDC timing numbers are calculated in VDC clocks, not 21MHz clocks ... but I could be wrong, my head is in a different space right now. Anyway, I'm doing my testing at medium resolution so that the VDC and CPU are running on the same clock frequency. I'm attaching a test that shows the delay from the RCR interrupt to the start of the next HDW period (by aligning a change in the border color). This test aligns a white/pink partial line that is underneath the main 320-wide screen display. It shows that to align the change in VCE border color, there are 147 cycles between the IRQ being triggered and writing the border color. With 455 cycles on a line, and 320 cycles of display, that puts the RCR interrupt as being triggered 12 VDC cycles before the end of the line +/- 1. Running the same code on Mednafen shows the line being displayed approx 8-10 cycles/pixels to the right. Can you run the test and see if it lines up on one of your machines? testvdc-rcr-to-start-of-next.pce (16 KB) EDIT: The 147 cycle figure includes the 8 cycles for the CPU to respond to the interrupt, and excludes the last cycle of the write to the VCE color register.
|
|
|
Post by ccovell on Feb 3, 2020 8:21:17 GMT
I can add my 2 cents here with a newer Screen Dimension Test that tightens up the interrupt timing a little, and lets you adjust the HSync interrupt. Scanline int will hit at the same line as Sprite 4's leg, so you can adjust it with Sprite 4 pos.
I also put HSync in higher priority, with VSync lower, in the ISR.
|
|
|
Post by dshadoff on Feb 3, 2020 17:59:34 GMT
Wow, this is great stuff guys ! I took a quick peek this morning before I left for work, but I’ll review it in detail tonight.
From what I saw, the code I added (based on Mednafen) is close, but still slightly late, just as elmer had thought. It’s only a couple of clock cycles, but I’ll put in the effort to adjust properly.
|
|
|
Post by dshadoff on Feb 4, 2020 4:57:55 GMT
So after running a bunch of tests (recompiling the core takes about 15 minutes each time), I have come to the same conclusion - 12-13 VDC cycles is the correct amount. Both tests gave effectively the same results.
Unfortunately, it revealed a few more deficiencies in the MiSTer core: 1) in elmer's test, the left edge of the RCR interrupt was visible, but on MiSTer, the right edge never occurred: the pinkish line became the background color. 2) While running tests, most games with deficiencies showed an improvement with the VSYNC and RCR IRQ timing changes... however, the intro section on Bomberman'94 looked a bit worse than before. This may be related to either #1 above, or the number of available CPU-read-write cycles available to VRAM, or DMA speed, or possibly something else in the video.
|
|
|
Post by elmer on Feb 4, 2020 10:43:45 GMT
Just to add some more confusion to the mix ... Here's anbother test program. Once again, there's an RCR at the end of the last displayed line, just as before. This time, the RCR code just sits doing a bunch of nop instructions, and then finally exits. The VBLANK code takes a look at the PC value stored on the stack, and figures out just how many nop instructions have been executed, and then uses that to calculate the delay between the RCR and VBLANK interrupts. Once again, it looks like Medanfen and my Turbo Duo don't quite agree on the timings. For a 320-wide screen, I'm seeing 123 cycles between the RCR and VBLANK interrupts. Mednafen gives something like 138 or 139 cycles. HOWEVER ... this is a value that changes depending upon the HDW setting. For a 336-wide screen, I'm seeing 107 cycles between the RCR and VBLANK interrupts. Once again, changing the HDS, HDE and HSW settings doesn't seem to make any difference. The only thing that changes the timing is the HDW value. This is the same as I was finding with the delay between the RCR interrupt and when the VDC shadows/locks the BYR/BXR/CR/etc registers for the next line. testvblank-rcr-to-vblank.pce (16 KB)
|
|
|
Post by dshadoff on Feb 4, 2020 15:36:53 GMT
OK, this is very helpful... but it exposes that I have more work to do.
To recap: MiSTer had placed the VSYNC and RCR interrupts at incorrect points along the scanline (though roughly correct points along the y-axis).
Originally: - the RCR interrupt on the trailing edge of the HSYNC pulse - the VSYNC interrupt was Complicating matters, they basically ignore the HDS setting, and aim to centre the display based on the HDW setting within a fixed aperture
What we have found: - VSYNC actually occurs at the transition between HDS and HDW on the first non-display line - RCR is slightly before the end of the HDW period (i.e. as the render engine does its calculations related to the last pixels of the line)
Using your newest test, the original number was: 91
After adjusting VSYNC, before RCR: 69
After RCR adjust: Seemingly random numbers, but occurring in groups, centred on key numbers - for example, 460, 1500, 3551, 7696, 16040, 32694 (but not in this order) I think this is related to the issue I noted earlier about the RCR scanline starting but not ending.
|
|
|
Post by spenoza on Feb 4, 2020 15:47:14 GMT
Would you settle for a pinball wizard?
|
|
|
Post by ccovell on Feb 4, 2020 23:47:22 GMT
Would you settle for a pinball wizard?
No, there has to be a twist.
|
|
|
Post by turboxray on Feb 8, 2020 14:28:23 GMT
It's been quite a while, so I don't remember all the things I tested for in relation to RCR. One thing to note though, if you're using video output of the VCE and the cpu to align for testing, that the video output is delayed by 8 pixels in relation to the cpu's perspective (I believe it's 8 pixels.. Charles Macdonald is the person who tested this; I never verified it though).
I want to say RCR is generated at the end of HDW, but I can't remember for sure (I do have a WIP I was making that says this.. so at one point I believed this to be true). I do know that things that trigger the VDC to generate an RCR for the processor; one is the normal window (transition out of HDW or HDE area), and the other (I believe) is when VCE asserts hsync pulse and the VDC is *not* in HSW mode. HSW is just a timeout window. But if the RCR is generated somewhere between HDW->HDE and HSW, then the transition from HSW->HDS (with or without hsync from the VCE) does not generate an RCR (as well as related fetching functions from VDC register buffers). But if the VCE generates hsync and the VDC isn't in the HSW window of timing, the VDC will still snap to HDS (regardless of where it is in any mode). Again, it's been a while but I'm almost positive in the second scenario you'll get another RCR interrupt (but slightly different way).
Why do I know this? Because my trick of having the VDC skip every other sprite pixel line (i.e. shows only odd or even lines of sprites.. 16x16 is shown as 16x8, etc), relies on having the VDC slightly shorter than the VCE frame, giving two frames per VDC line (on being full, the other being like 50 cpu cycles).. and since BG and Sprite calculates are not done at the same time.. BG behaves normal while sprites already calculated for the line. Hopefully that makes sense.
Though since it's been so long, probably shouldn't take my word for it on the RCR stuff. Best to test some of these scenarios haha. And of course if what I remember is true of the second scenario, I don't think any game relies on this? So it's not terribly important.
|
|