Megadrive1 overclocking using EDClk
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Megadrive1 overclocking using EDClk
A little detail about the EDClk:
It's not a pure clock signal - during horizontal synchronization it's frequency is MasterClk/5 (~10.6MHz), but in active-video it's MasterClk/4 (~13.3MHz), I think it's an input to the VDP, after coming from a low-passfilter, which means that during active-video the clock amplitude is smaller. Before the filter the signal is good (constant amplitude), and that includes the B15 pin from the cartslot.
Now some info about the DTAck signal; probably most of the megadrive hardware lovers know this:
Each active device "responding" to the CPU drives the signal low (VDP/BUScontroller/Extra hardware at the cartridge port) but it's never driven high, (to avoid short-circuit) so a pull-up resistor is required (and there is one of 2.2k).
The problem: This signal has a huge capacitance, so DTAck will quickly go low, but the rise is slooowwww... (sometimes it doesn't reach Vcc/2 using EDClk as a CPU clk and sinks again )
This means that:
CPU accesses ROM -> DTAck activated (low);
CPU accesses IO, DTAck is still low (or below trigger level);
CPU continues to run, but the R/W probably missed!
Solution: make DTAck rising edge faster... How? Replacing 2.2K with a 910Ohm resistor or leave the 2.2K resistor and connect one in parallel with 1.8K. (Average current flow when DTAck is forced-low is 5.5mA).
In normal occasions DTAck is activated one cycle (~130nanoseconds) after AS, never less so don't worry about using slow-motion-memories as long as they are faster than that, it's safe. (actually the address is already set-up before AS, so maybe 150ns are accepted).
MD1 CPU sucessfully overclocked to... errr.. EDClk MHz, fully stable and with sound of course. No shitty halt switches, just hardwire the CPU with EDClk before the filter, and it's fine.
Remember that the memory accesses aren't affected with the overclock, unless you snap in some modern/faster memories and sink DTAck before 130ns yourself.
Coming in near future is a picture of new/old DTAck waveform.
[speculation]
Also I beleive that EDClk is always MasterClk/5 in 256 pixel mode...
[/speculation]
It's not a pure clock signal - during horizontal synchronization it's frequency is MasterClk/5 (~10.6MHz), but in active-video it's MasterClk/4 (~13.3MHz), I think it's an input to the VDP, after coming from a low-passfilter, which means that during active-video the clock amplitude is smaller. Before the filter the signal is good (constant amplitude), and that includes the B15 pin from the cartslot.
Now some info about the DTAck signal; probably most of the megadrive hardware lovers know this:
Each active device "responding" to the CPU drives the signal low (VDP/BUScontroller/Extra hardware at the cartridge port) but it's never driven high, (to avoid short-circuit) so a pull-up resistor is required (and there is one of 2.2k).
The problem: This signal has a huge capacitance, so DTAck will quickly go low, but the rise is slooowwww... (sometimes it doesn't reach Vcc/2 using EDClk as a CPU clk and sinks again )
This means that:
CPU accesses ROM -> DTAck activated (low);
CPU accesses IO, DTAck is still low (or below trigger level);
CPU continues to run, but the R/W probably missed!
Solution: make DTAck rising edge faster... How? Replacing 2.2K with a 910Ohm resistor or leave the 2.2K resistor and connect one in parallel with 1.8K. (Average current flow when DTAck is forced-low is 5.5mA).
In normal occasions DTAck is activated one cycle (~130nanoseconds) after AS, never less so don't worry about using slow-motion-memories as long as they are faster than that, it's safe. (actually the address is already set-up before AS, so maybe 150ns are accepted).
MD1 CPU sucessfully overclocked to... errr.. EDClk MHz, fully stable and with sound of course. No shitty halt switches, just hardwire the CPU with EDClk before the filter, and it's fine.
Remember that the memory accesses aren't affected with the overclock, unless you snap in some modern/faster memories and sink DTAck before 130ns yourself.
Coming in near future is a picture of new/old DTAck waveform.
[speculation]
Also I beleive that EDClk is always MasterClk/5 in 256 pixel mode...
[/speculation]
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
You said that EDCLK=MCLK/5. So, in my case it must be 53.2034MHz/5=10.64Mhz But, when I try to meassure B15 pin (EDCLK on cartslot) device shows me 13.06MHz (~53.2034Mhz/4). So, where is the truth?
And when I look at EDCLK in oscilloscope, I see solid 50% duty wave (almost square, but it almost reaches to limits of my oscilloscope frequency). Without changes or something else.
PS If whe get PAL mode, then active scan line takes 48mks. When enabled 320 pixel width mode, it will be: 1/(48/320)=6.66MHz. It looks like EDCLK/2: 13.06MHz/2=6.53MHz. All calculating errors is in measurement errors, I guess.
And when I look at EDCLK in oscilloscope, I see solid 50% duty wave (almost square, but it almost reaches to limits of my oscilloscope frequency). Without changes or something else.
PS If whe get PAL mode, then active scan line takes 48mks. When enabled 320 pixel width mode, it will be: 1/(48/320)=6.66MHz. It looks like EDCLK/2: 13.06MHz/2=6.53MHz. All calculating errors is in measurement errors, I guess.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
I said that the frequency of EDClk is MasterClk/5 only on Hsync region.
The signal is clean in the cart slot pin, I've said that too, it's filtered when it passes through the filter.
Correction: The signal is made by the VDP.
Correction2: No it isn't
The signal is clean in the cart slot pin, I've said that too, it's filtered when it passes through the filter.
Correction: The signal is made by the VDP.
Correction2: No it isn't
Last edited by Jorge Nuno on Sun Feb 08, 2009 2:16 am, edited 1 time in total.
I thought EDCLK corresponded to twice of the internal VDP dot clock
in H32 mode, dot clock = MCLK/10
in H40 mode, dot clock = MCLK/8
this could be useful to calculate the exact amount of pixels in H40 mode
in H32 mode, dot clock = MCLK/10
in H40 mode, dot clock = MCLK/8
could it be that during HSYNC, the dot clock is changed to always use MCLK/10 ?I said that the frequency of EDClk is MasterClk/5 only on Hsync region.
this could be useful to calculate the exact amount of pixels in H40 mode
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Probably. The HSync pin, according to Charles is able to output the pixel clock itself, setting one undocumented bit in a VDP register (don't remeber).Eke wrote: could it be that during HSYNC, the dot clock is changed to always use MCLK/10 ?
this could be useful to calculate the exact amount of pixels in H40 mode
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
I heard what you said. But if we take this:Jorge Nuno wrote:I said that the frequency of EDClk is MasterClk/5 only on Hsync region.
Then, I must get:Eke wrote:in H32 mode, dot clock = MCLK/10
in H40 mode, dot clock = MCLK/8
53.20MHz/10=5.32MHz
53.20MHZ/8=6.65MHz
And that is very noticeable changing of frequency. But I saw nothing at oscilloscope. Maybe, I must use 32H mode - I'll check this out. But looks like you are right: Hblank period not changes, and VDP must take all sprites to build new scanline in all available resolutions.
Thinking in same thing.Eke wrote:I thought EDCLK corresponded to twice of the internal VDP dot clock
HardWareMan wrote:It looks like EDCLK/2: 13.06MHz/2=6.53MHz.
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
In fact it is the Vsync pin that outputs the pixel clock when Register 0C is | 0x40 (bit6 is set)Jorge Nuno wrote: Probably. The HSync pin, according to Charles is able to output the pixel clock itself, setting one undocumented bit in a VDP register (don't remeber).
The Hsync has an unknown alternate function (Charles says it's always 1, but I think it's dumb to make a dual function pin that the alternate function is '1' )
Anyone with a scope and a writable cart can do this little test...
http://cgfm2.emuviews.com/txt/vdppin.txt
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Mmm... I see. It's change cycle duty. "1" stays same and "0" is stretched. I think, when MCLK/4 it has 1100 and when MCLK/5 it has 11000. That is interesting. Thanks.Jorge Nuno wrote:Bump!
HWMan, look:
EDClk frequency changes to MClk/5 on HSync '0' state and returns back to MClk/4 on the '1' state. I forgot to check on the vertical blanking period (next week)
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
Umm... Let's see how it looks like in Vsync period:
It chages frequency to Mclk/5 when Csync falls (Hsync rises)... Weird (should be the opposite)
But! After 15 pulses of Mclk/5 it changes back to Mclk/4 (in the middle), but only for 2 pulses (what the fu..!?):
And then, more 15 pulses of Mclk/5. After that, it stays on Mclk/4 until the next Csync falling edge:
The Edclk is generated on the 315-5433 on VA6 boards, it passes through a ferrite bead (FB7) then goes to the cart slot and the VDP (yellow)
(so it's not made by the VDP):
Blue is what my 315-5433 outputs on pin #158 (much cleaner and ready to go to the 68k )
____
BTW here is my DTACK after changing the pullup resistor to 910 Ohm (yellow):
(blue is the cart CE)
It chages frequency to Mclk/5 when Csync falls (Hsync rises)... Weird (should be the opposite)
But! After 15 pulses of Mclk/5 it changes back to Mclk/4 (in the middle), but only for 2 pulses (what the fu..!?):
And then, more 15 pulses of Mclk/5. After that, it stays on Mclk/4 until the next Csync falling edge:
The Edclk is generated on the 315-5433 on VA6 boards, it passes through a ferrite bead (FB7) then goes to the cart slot and the VDP (yellow)
(so it's not made by the VDP):
Blue is what my 315-5433 outputs on pin #158 (much cleaner and ready to go to the 68k )
____
BTW here is my DTACK after changing the pullup resistor to 910 Ohm (yellow):
(blue is the cart CE)
-
- Very interested
- Posts: 256
- Joined: Tue Sep 11, 2007 9:10 pm
hey, this looks interesting
could it mean the VDP internal pixel clock is not "constantly" MCLK/5 in H40 mode ?
also, could you do similar tests as Charles McDonald did for the SMS:
http://www.smspower.org/forums/viewtopic.php?t=8161
could it mean the VDP internal pixel clock is not "constantly" MCLK/5 in H40 mode ?
also, could you do similar tests as Charles McDonald did for the SMS:
http://www.smspower.org/forums/viewtopic.php?t=8161
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
I could do that, in Edclk's units, though I will mention the exact moment the frequency changes, so that the exact period can be calculated.
It's just that counting manually in terms of Mclks it's difficult and I could get lost, and do the count again. Don't worry about half or third cycles because Hsync and Vsync seem to change always on the same phase of Edclk...
I can show the "2xresolution" interlaced, but not the progressive one...
It's just that counting manually in terms of Mclks it's difficult and I could get lost, and do the count again. Don't worry about half or third cycles because Hsync and Vsync seem to change always on the same phase of Edclk...
I can show the "2xresolution" interlaced, but not the progressive one...
-
- Very interested
- Posts: 374
- Joined: Mon Jun 11, 2007 3:09 am
- Location: Azeitão, PT
bump
There's 1 more serious issue, when overclocking the CPU, this:
Yellow is /AS signal, Blu is /DTACK. (using Edclk for the 68k), wave persistence is 5 seconds.
As it can be seen, the access times vary between 125ns and ~25ns, due to the fact the AS signal is asserted at random, regarding the original clock, because EDclk and Vclk are assynchrounous each other. Which means that all signals that use /AS to generate themselves, must be based from the clk that is suplied to the 68k, like this:
steady ~75ns from /AS to /DTACK, again using EDclk
So the 68k clk network must be interconnected, but there is a problem:
- the VDP outputs Mclk/7 on the Vclk pin, and a lot of memory access signals are based from it.
Luckily there is a VDP pin that stops the VDP from making the Mclk/7 signal and chagnes the Vclk pin to an input, so any clk can be supplied to it and the mem signals will be based from whatever clk is there (like pic2).
That pin is SEL1, it has to be tied to 5V. Thats pin #48 on the discrete VDP.
But this will lead to another issue:
- the YM2612 will be without clk. Mclk/7 has to be obtained from an external divider, using a shift register connected to the onboard 53MHz osc.
For the LULZ:
42ns acess times
It is the same thing as before but not using EDclk, that was with an external 24MHz metal can oscillator, and this gives theese results using Tmee bench prog:
There's 1 more serious issue, when overclocking the CPU, this:
Yellow is /AS signal, Blu is /DTACK. (using Edclk for the 68k), wave persistence is 5 seconds.
As it can be seen, the access times vary between 125ns and ~25ns, due to the fact the AS signal is asserted at random, regarding the original clock, because EDclk and Vclk are assynchrounous each other. Which means that all signals that use /AS to generate themselves, must be based from the clk that is suplied to the 68k, like this:
steady ~75ns from /AS to /DTACK, again using EDclk
So the 68k clk network must be interconnected, but there is a problem:
- the VDP outputs Mclk/7 on the Vclk pin, and a lot of memory access signals are based from it.
Luckily there is a VDP pin that stops the VDP from making the Mclk/7 signal and chagnes the Vclk pin to an input, so any clk can be supplied to it and the mem signals will be based from whatever clk is there (like pic2).
That pin is SEL1, it has to be tied to 5V. Thats pin #48 on the discrete VDP.
But this will lead to another issue:
- the YM2612 will be without clk. Mclk/7 has to be obtained from an external divider, using a shift register connected to the onboard 53MHz osc.
For the LULZ:
42ns acess times
It is the same thing as before but not using EDclk, that was with an external 24MHz metal can oscillator, and this gives theese results using Tmee bench prog: