HBlank Timings

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Mar 15, 2009 2:10 pm

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

Jorge Nuno · Post by **Jorge Nuno** » Sun Mar 15, 2009 2:27 pm

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...

HardWareMan · Post by **HardWareMan** » Sun Mar 15, 2009 4:46 pm

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.

Jorge Nuno · Post by **Jorge Nuno** » Sun Mar 15, 2009 5:05 pm

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.

HardWareMan · Post by **HardWareMan** » Sun Mar 15, 2009 6:26 pm

Jorge Nuno wrote:How many bits? 12 (CMOS 4040) ?

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.
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).

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.

You can use sequence of move.w opcodes. For example:

Code: Select all

move.w Counter,d0
move.w HVCounter,d1
move.w Counter,d2

So, you will know 2 time stamps and our reading will be exactly between two this values (becouse all of this instructions have same execute time in ticks and timings for control signals). And if use all 8 data registers we can made more reading to more accurate measurement, for example:

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

And see what happened with our counter.
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.

Jorge Nuno · Post by **Jorge Nuno** » Sun Mar 15, 2009 7:11 pm

Anyway, I'm lost... What was this for? About the /TIME memory accesses, and VDP ones, the read/write cycle timing can be visualized on a scope, to see if it is different or not...

Eke · Post by **Eke** » Sun Mar 15, 2009 7:18 pm

wow

Nemesis · Post by **Nemesis** » Sun Mar 15, 2009 9:26 pm

Bah there is almost no way to make a relation between [VDPstatus/HVcounter <-> Output signals
maybe by reading Hcounter value as soon as the system is powered ON
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)

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.

Nemesis · Post by **Nemesis** » Mon Mar 16, 2009 6:59 am

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.

mickagame · Post by **mickagame** » Mon Mar 16, 2009 7:23 am

WOW !!!

Eke · Post by **Eke** » Mon Mar 16, 2009 9:49 am

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.

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...

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.

damn... this is smart

mickagame · Post by **mickagame** » Mon Mar 16, 2009 9:56 am

Yes I'm agree with you.

HardWareMan · Post by **HardWareMan** » Mon Mar 16, 2009 11:01 am

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...

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.
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.

Nemesis · Post by **Nemesis** » Mon Mar 16, 2009 11:27 am

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.

Eke · Post by **Eke** » Mon Mar 16, 2009 1:13 pm

@HardwareMan: thanks for the clarification, I wish I had more hardware experience"

@Nemesis: what about sampling with VCLK and ZCLK as well ? the problem with EDCLK is that Jorge showed it was not constant during blanking