HBlank Timings
Moderators: BigEvilCorporation, Mask of Destiny
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
On semi related note, emulators should fill all RAMs with grabage (as RAM state is undefined on powerup). One thing I have noticed when I tested a friend's ROM on real HW is that Vscroll RAM first 2 entries is random on powerup, but the rest seem to be fixed to 0...
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Remember that there is the pixel clock at ~6MHz... Every video signal is synchronous with it's rising edges, but for some reason everyone forget it. In H40 it's nothing more than Edclk/2, which means that during H pulses it changes rate.
My MD has TMSS, and I'm not sure if bypassing it, the VDP is still acessible.Nemesis wrote:Unfortunately, my current oscilloscope doesn't have the bandwidth to sample MCLK, so I can't get a precise reading. I estimate that on a PAL system running in H32/V28, the HBLANK flag is asserted around 85 MCLK cycles before HSYNC enters the blanking phase, and that the HBLANK flag remains asserted for around 590-600 MCLK cycles.
Here's the ROM I used to perform this test:
http://nemesis.hacking-cult.org/MegaDri ... gister.bin
And here's the source:
http://nemesis.hacking-cult.org/MegaDri ... gister.asm
Jorge, you might have better luck sampling the output. You seem to have access to a pretty good CRO.
EDIT: I should mention, all the bits of the VDP status register can be sampled with this ROM, except bit 9 (FIFO Empty flag) and bit 4 (Odd interlace field flag). Just hook the corresponding data line from the 68K bus matching the bit you want to sample.
EDIT2: It just occurred to me, I should be able to get an accurate sampling if I compare the data to EDCLK, then convert the EDCLK values back to MCLK. I think I'll try that tomorrow.
Last edited by Jorge Nuno on Mon Mar 16, 2009 7:17 pm, edited 1 time in total.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
you will still have to write "SEGA" but you won't be having the TMSS ROM ran.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Have you possibility to do the same test in H40 to know approximatively how many MCLK paste between HBlank flag set to 1 and HSync period?Nemesis wrote:Unfortunately, my current oscilloscope doesn't have the bandwidth to sample MCLK, so I can't get a precise reading. I estimate that on a PAL system running in H32/V28, the HBLANK flag is asserted around 85 MCLK cycles before HSYNC enters the blanking phase, and that the HBLANK flag remains asserted for around 590-600 MCLK cycles.
Here's the ROM I used to perform this test:
http://nemesis.hacking-cult.org/MegaDri ... gister.bin
And here's the source:
http://nemesis.hacking-cult.org/MegaDri ... gister.asm
Jorge, you might have better luck sampling the output. You seem to have access to a pretty good CRO.
EDIT: I should mention, all the bits of the VDP status register can be sampled with this ROM, except bit 9 (FIFO Empty flag) and bit 4 (Odd interlace field flag). Just hook the corresponding data line from the 68K bus matching the bit you want to sample.
EDIT2: It just occurred to me, I should be able to get an accurate sampling if I compare the data to EDCLK, then convert the EDCLK values back to MCLK. I think I'll try that tomorrow.
It will help to complete eke schema ...
Do you have same results for H40 mode?Nemesis wrote:Well, the logic analyser thing didn't go so well. I'll have another go at it later.
What I did instead was create a test ROM which is actively polling the status register and HV counter in tandem as fast as possible, and writing that sampled data to RAM. I ran the ROM multiple times over, under a variety of conditions, both with an without interrupt handler routines, dumping the contents of RAM out to my PC to generate around 1MB of sampled data.
The only tests I've done so far have been in V28/H32 mode on a PAL system, but the data I've compiled suggest the following:
-The HBLANK flag in the status register is set when the HCOUNTER value "jumps" from what appears to be 93 to E9. I assume in other display modes, the HBLANK flag will also be set when the HCOUNTER value jumps ahead, regardless of what the actual values are under that mode.
-The HBLANK flag is cleared at what appears to be a HCOUNTER value of 06.
-HINT is triggered at the exact same time as the HBLANK flag in the status register is set, and the HCOUNTER value jumps. In other words, the HCOUNTER jump, HINT, and HBLANK flag being set, all occur at the same time.
-The VCOUNTER is incremented slightly before HBLANK is set, at an apparent HCOUNTER value of 85. IE, if the VCOUNTER was 14 when HCOUNTER was 84, when HCOUNTER is 85, VCOUNTER will now be 15.
-On the last line, the VBLANK flag is set when the VCOUNTER value is incremented to E0.
-The VBLANK flag is cleared when the VCOUNTER value is incremented from FE to FF the second time. As per the info from Charles MacDonald, and my own tests, the VCOUNTER in this PAL mode counts in the following sequence: 00-FF, 00-02, CA-FF. VBLANK is set when VCOUNTER hits E0, during the 00-FF block. When VCOUNTER hits FF in the CA-FF block, VBLANK is cleared.
-VINT is triggered when the HCOUNTER resets from FF to 00, well after the VCOUNTER has been incremented to E0 and the VBLANK flag has been set.
-The VINT occurrance flag is set as soon as VINT is asserted. It only reads as set when the interrupt has not yet been taken. Reading the status register immediately after entering the VINT routine for example registers this bit as unset.
These readings I took mostly line up with this timing info Eke posted:
http://img10.imageshack.us/img10/8066/vdptimingsh32.gif
With the exception of the VCOUNTER increment, which I read as happening when HCOUNTER reaches 85, not when it reaches 86. The additional info I've provided, such as interrupt timing and vblank flag timing, fit into this diagram as I've described above.
This is preliminary info. I need to do a lot more analysis and sampling, and in particular test under different screen modes such as H40, V30, and on NTSC systems, but I can be pretty confident about what I've posted. Regarding the interrupt timing, note that I sampled those times by determining the last sample I was able to capture before the interrupt was taken, so interrupt execution times haven't affected my readings. Due to the volume of sample data I've captured, I'm reasonably confident the info I've given is accurate, but I do need to carry out more tests.
Old post, I haven't been around much lately...Eke wrote:oh well, something like this ?mickagame wrote:I thought to read hvcounter in a loop and write to ram only in interrupt routine, not each time you read itI don't know if this is possible with the 68k but it would be damn precise yesCode: Select all
Main: LEA $C00004,A6 Loop: MOVE.w (a6), D0 ;Get HVcounter BRA Loop; Hint: MOVE.w D0 $E01000 // DISPLAY STORED VALUE ON SCREEN RTE;
But, no, this won't be very precise. The move and bra in the main loop are fairly long instructions and they will affect when the interrupt comes in. What you really need to do is read it in the interrupt, and have the main loop doing as little as possible.
Logically it seems that doing STOP #$2300 in main is the best way to achieve this - but it appears not to be either, it seems to take quite a while to wake up.
Best way is to fill a block of ROM with about 80000 NOP instructions, no loops - and execute that. That should take over 2 frames to execute, which will be enough time for any interrupts to happen. This way, the most the interrupt will get delayed is 3 cycles.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
The manual says STOP is always 4 clock cycles, but maybe it always executes the following instruction on waking before the interrupt is processed. The manual isn't clear on that. The only thing they say occurs before the next instruction is a trace exception if tracing was enabled. So maybe
STOP #$2300
NOP
is the way to handle it.
STOP #$2300
NOP
is the way to handle it.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I was thinking of another method recently: what if we used the /HL input ability to freeze the Horizontal Counter ?
This would involve minor hardware modifications (but nothing more complicated than a 50/60Hz switch) and the ability to access required pins (maybe only possible on earlier model 1 revisions ?
By connecting /HL input to /IPL2 output and masking interrupts on 68k side, horizontal counter would be latched (and remain latched as long as interrupt remains pending) at the exact moment when interrupt level 4 or level 6 is triggered.
As long as you wait enough time for this to occur (wait for VCounter specific value, wait for Hblank flag to be set then cleared in teh case of HINT, wait for VINT flag in the case of VINT), you could then read the Hcounter and retrieve the latched value
This could be used for both interrupts... and even used with other signals such as /YS, /HSYNC or /VSYNC to measure other events but it might not be so easy to read HCounter before it is unlatched
This would involve minor hardware modifications (but nothing more complicated than a 50/60Hz switch) and the ability to access required pins (maybe only possible on earlier model 1 revisions ?
By connecting /HL input to /IPL2 output and masking interrupts on 68k side, horizontal counter would be latched (and remain latched as long as interrupt remains pending) at the exact moment when interrupt level 4 or level 6 is triggered.
As long as you wait enough time for this to occur (wait for VCounter specific value, wait for Hblank flag to be set then cleared in teh case of HINT, wait for VINT flag in the case of VINT), you could then read the Hcounter and retrieve the latched value
This could be used for both interrupts... and even used with other signals such as /YS, /HSYNC or /VSYNC to measure other events but it might not be so easy to read HCounter before it is unlatched
Last edited by Eke on Fri Apr 03, 2009 10:02 am, edited 2 times in total.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
you can nicely do that on MD2, all of them have a discrete 68K... no, VA4 does not... so you can nicely do the level2 int trick
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen