HBlank Timings
Moderators: BigEvilCorporation, Mask of Destiny
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Time to show your TV whose the boss
http://www.angelfire.com/80s/sixmhz/tvscope.html
now I need a suitable TV to mess with
I guess its enough of offtopic for now
http://www.angelfire.com/80s/sixmhz/tvscope.html
now I need a suitable TV to mess with
I guess its enough of offtopic for now
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
Umm playing with deflection coils huh?
I think the MD approach is more useful: multichannel, grid, signal measurements, does not limit bandwidth by itself (limited by the ADCs and FIFOs), trigger options, signal operations (+/-/Avg/FFT),software updates to add features, dumping options, and of course no risk of being fulminated with some kVolts... (And still playing games), but a lot harder to acomplish (the next level!)
The offtopic is never enough, becuase there are always loose things to be said... This should be split...
I think the MD approach is more useful: multichannel, grid, signal measurements, does not limit bandwidth by itself (limited by the ADCs and FIFOs), trigger options, signal operations (+/-/Avg/FFT),software updates to add features, dumping options, and of course no risk of being fulminated with some kVolts... (And still playing games), but a lot harder to acomplish (the next level!)
The offtopic is never enough, becuase there are always loose things to be said... This should be split...
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
First, I add some offtopic. It is not clever use TV tube for oscilloscope. It is use electromagnetic deflection system, so you hardly limited by frequency and can get distortion of signal. You need tube with electrostatic deflection system. Or, you can use digital emulation with output in TV standard. For example, look at device, described in russian "Radio" magazine for 1991 year, #4 and #5. It use fast ADC direct transform with speed of 10M samples per second. 6 or 8 bit. Some of people make such oscilloscope with TV output on fast microcontroller - you can ask the Google.
Second, we can made some big counter wich will count M68K clocks and will reset with M68K. Outputs of this counter can be passed thru 74x245 bus former to data line at some address. So, software always can get number of ticks goes from start of program (reset). I think it is more easy. And I can make this, if you can't.
Second, we can made some big counter wich will count M68K clocks and will reset with M68K. Outputs of this counter can be passed thru 74x245 bus former to data line at some address. So, software always can get number of ticks goes from start of program (reset). I think it is more easy. And I can make this, if you can't.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
HardWareMan wrote: Second, we can made some big counter wich will count M68K clocks and will reset with M68K. Outputs of this counter can be passed thru 74x245 bus former to data line at some address. So, software always can get number of ticks goes from start of program (reset). I think it is more easy. And I can make this, if you can't.
A counter whose value is availble to the CPU as an arbitrary memory location, sounds like a challenge... How many bits? 12 (CMOS 4040) ?
It could be mapped to $A12000, (/Time as an output enable to the 2 state-buffers HC244, /DTACK already solved)
It shall be a wire mess , and yet, there is no guarantee that the HVcounter starts at the same time as this one, and you can't just read HVcouter and this counter simultaneously.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
I think, we must have some reserve of counter capacity, say 1 second will be enough. So, if CPU CLK=7,6MHz our counter must be 24 bit to fit that number. Or, you can use divider to divide VCLK by some constant.Jorge Nuno wrote:How many bits? 12 (CMOS 4040) ?
I must notice some correction. We cannot use simple bus former, becouse while CPU reading data from counter, counter can change his state, wich can cause wrong data interpretation. So, use latch register like 74x373/74x573 will eliminate this problem. Need simple connect LE register input to OE register input and it will be lock value while reading at time when reading signal will active (at ~2 clock of machine cycle of M68K).
You can use sequence of move.w opcodes. For example:Jorge Nuno wrote:It shall be a wire mess , and yet, there is no guarantee that the HVcounter starts at the same time as this one, and you can't just read HVcouter and this counter simultaneously.
Code: Select all
move.w Counter,d0
move.w HVCounter,d1
move.w Counter,d2
Code: Select all
move.w Counter,d0
move.w Counter,d1
move.w Counter,d2
move.w Counter,d3
move.w HVCounter,d3
move.w Counter,d5
move.w Counter,d6
move.w Counter,d7
But there can be one thing, wich can spoil this all. We don't know for sure: differs VDP access and memory (at !TIME signal) access or not.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
My tests indicate that when the VDP powers on, it starts pretty much anywhere within the frame. It certainly doesn't begin from a fixed point, IE, the beginning of a new frame. I'm running on a base MD1 with no TMSS, and every time I ran my ROM to capture data (which starts capturing a handful of cycles in), the HV counter data began from a completely different point in the frame.maybe by reading Hcounter value as soon as the system is powered ONBah there is almost no way to make a relation between [VDPstatus/HVcounter <-> Output signals
and measuring VDP reset signal in relation with video signals (this would also gives us the effective line number where VDP starts)
most probably, Hcounter is *always* reseted with the same value when the VDP resets also, it appears to be reloaded with 0xe4 (0xe9) each time it reaches 0xb6 (0x93)
I'm making some progress:
The yellow line is HSYNC. The general region in which you see the green line asserted represents the area in which the HBLANK flag in the status register is set.
I've constructed a test ROM which runs an active loop reading from the VDP status register, using machine code opcodes which leave various "target" bits of the 16-bit word region unset. This means those data lines are only asserted when transferring data from the VDP status register, so I can easily sample any of these lines with an oscilloscope, and know what I'm always looking at is the state of that bit in the status register of the VDP. Using this technique, it's possible to accurately match up readings from the status register to the various output signals from the VDP.
Obviously this technique wouldn't work for complex values like the H/V counter, but that doesn't matter. We only need one point of reference (eg, the HBLANK flag) to relate the data we already have about the status register and H/V counter, back to the other output signals.
I'll keep on running tests and sampling data. That screenshot I've just posted obviously doesn't give a lot of useful data by itself, it's just a "proof of concept" screencap really. I'll see if I can tie in a clock signal so we can get a useful measurement.
The yellow line is HSYNC. The general region in which you see the green line asserted represents the area in which the HBLANK flag in the status register is set.
I've constructed a test ROM which runs an active loop reading from the VDP status register, using machine code opcodes which leave various "target" bits of the 16-bit word region unset. This means those data lines are only asserted when transferring data from the VDP status register, so I can easily sample any of these lines with an oscilloscope, and know what I'm always looking at is the state of that bit in the status register of the VDP. Using this technique, it's possible to accurately match up readings from the status register to the various output signals from the VDP.
Obviously this technique wouldn't work for complex values like the H/V counter, but that doesn't matter. We only need one point of reference (eg, the HBLANK flag) to relate the data we already have about the status register and H/V counter, back to the other output signals.
I'll keep on running tests and sampling data. That screenshot I've just posted obviously doesn't give a lot of useful data by itself, it's just a "proof of concept" screencap really. I'll see if I can tie in a clock signal so we can get a useful measurement.
how is that possible ?It certainly doesn't begin from a fixed point, IE, the beginning of a new frame. I'm running on a base MD1 with no TMSS, and every time I ran my ROM to capture data (which starts capturing a handful of cycles in), the HV counter data began from a completely different point in the frame.
I mean, the VDP is logic hardware, and like any logic it *should* have a fixed reset state.. which includes internal counter registers as well
I don't see how possible it is to initialize registers with "random" values ? Maybe it's all matter of latency between the first read and the moment the VDP effectively started.
Also, the counters *have* to run at the same time the VDP generates the video signal so they should start running as soon as the /RESET line is disactivated.
What could be possibly done is to install a 3-position switch on this RESET line, first position connected to default (ie Master RESET line), others connected to ground/+5V (or whatever it is in a genny) ?
This way you could have code running and trigger some random VDP reset...
damn... this is smartI've constructed a test ROM which runs an active loop reading from the VDP status register, using machine code opcodes which leave various "target" bits of the 16-bit word region unset. This means those data lines are only asserted when transferring data from the VDP status register, so I can easily sample any of these lines with an oscilloscope, and know what I'm always looking at is the state of that bit in the status register of the VDP. Using this technique, it's possible to accurately match up readings from the status register to the various output signals from the VDP.
Last edited by Eke on Mon Mar 16, 2009 10:00 am, edited 1 time in total.
-
- Very interested
- Posts: 745
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
I had big expirience with build schemas that make raster TV signals. I can say that to implement additional reseting logic is not justified. Just make simple reset logic on needed condition. So, when you power up it, random state achieved. Then it will be count step by step at source clock and very soon all logic set to normal planned state. Usually it takes one-two frames to stabilize.Eke wrote:how is that possible ?
I mean, the VDP is logic hardware, and like any logic it *should* have a fixed reset state.. which includes internal counter registers as well
I don't see how possible it is to initialize registers with "random" values ? Maybe it's all matter of latency between the first read and the moment the VDP effectively started.
Also, the counters *have* to run at the same time the VDP generates the video signal so they should start running as soon as the /RESET line is disactivated.
What could be possibly done is to install a 3-position switch on this RESET line, first position connected to default (ie Master RESET line), others connected to ground/+5V (or whatever it is in a genny) ?
This way you could have code running and trigger some random VDP reset...
VDP must have RESET input becouse all bus arbitrate logic in it. So, sure we can make some register at some address (say, use TIME# signal) and control RESET# signal by software. But, nobody know what will happen with M68K bus. And sure VDP security system will lock up again.
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.
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.