Page 1 of 2

Re: Introduction

Posted: Mon Aug 03, 2020 12:38 pm
by hlide
Hi psmart!

see you have a Z80@20MHz (I have plenty of those). Any plan to add a turbo frequence?

I'm trying to picture out how to make one:

Code: Select all

LD r,r'
                M1R:T1              M1R:T2              M1R:T3             M1R:T4
        |_________          |_________          |_________          |_________
PHI x 1 /         \_________/         \_________/         \_________/         \_________/
        |_________          |                   |_________          |          _________
/MREQ             \_____________________________/         \___________________/         \
        |_________          |                   |________________________________________
/RD               \_____________________________/
        |____     |_________          |____     |____     : 
PHI x 2 /    \____/         \_________/    \____/    \____/
        |____     |                   |____     |_________
/MREQ        \________________________/    \____/         \
        |____     |                   |____________________
/RD          \________________________/
        |__   |_________          |__   |__   : 
PHI x 4 /  \__/         \_________/  \__/  \__/
        |__   |                   |__   |_____
/MREQ      \______________________/  \__/     \
        |__   |                   |____________
/RD        \______________________/
        |_  |_________          |_  |_  : 
PHI x 5 / \_/         \_________/ \_/ \_/
        |_  |                   |_  |___
/MREQ     \_____________________/ \_/   \
        |_  |                   |________
/RD       \_____________________/
Idealistically, The idea is to switch between two frequencies, the normal CPU clock or the multiplied one. X5 is for PAL MZ-700 and x4 for NTSC MZ-700. Soon, I have some ICS501M which allow to multiply a frequency. The way to switch frequency may also be using the multiplied one on the CPU and issue several /WAIT signals when necessary (memory and I/O port access).

But for MZ-700, I see some complications: when accessing ROM ($0000-$0FFF), there is an extra /WAIT signal inserted in the normal CPU timing by the LSI so the /WAIT = 0 may indeed occur too late with the multiplied frequency. So it looks there is a need for an arbiter to generate those /WAIT signals smartly.

Re: Introduction

Posted: Mon Aug 03, 2020 2:17 pm
by psmart
Hi Hlide,

Good to hear from you. Back in the days, I overclocked my MZ-80A to 4MHz (cant remember quite how I did it, but it involved cutting tracks!!!).

Fast forward to today, my tranZPUter SW v1.1 board uses a variable 2nd frequency and will reliably run at 11MHz (the limit is on the decoder I use, a Flash RAM!!) and on my newer design v2.1 where I use a CPLD I get full 20MHz reliably. Given that Im intercepting the Clock from the Z80 pin 6 I cannot change the mainboard frequency so the circuit slows down to the system frequency (2MHz) whenever the mainboard is accessed and then runs at the higher frequency at all other times (when enabled). A board that Im working on at the moment, the Video module will be generating the mainboard system clock so I will be able to overclock the mainboard as well. The tranZPUter works flawlessly at 4MHz on the MZ80B and 3.58MHz on the MZ700 so I should be able to get at least 4Mhz on the MZ80A mainboard with a 20MHz CPU clock. The CPLD design should clock at 33MHz but then would have to change the CPU for an eZ80 or Z180.

CPM at 20MHz flies, PLI CHESS which normally takes many minutes to compile runs in less than a minute!!!

In terms of your switching, have a look at the schematic below, (top right, IC's U9A, U4B, U9B, U14A/B, U9C, U9D, U1B), the two clocks go into dual D-Type flip flops, each clocked on their own clock and linked to the D input of the other. When the control signal (output of U4A) for Hi/Low speed changes, then both clocks have to be High before the actual flip occurs so the CPU never sees a glitch. You can do the same with NAND gates to flip on the low level. This circuit means you don't need to bother with the WAIT state. If the ICS501M is programmable and is the second clock source, then you could change the frequency programmatically. Also have a look at the DS1077 - I'm adding this to the newest cut of my board as you can program it via I2C. The 2nd frequency is generated by the I/O processor when installed but when not installed their is no 2nd frequency, so to correct this shortfall I'm adding the DS1077. It just needs 2xCapacitors (decoupling, 100nf + 10nf) and 2 resistors (4K7) on the I2C lines and offers 2 seperate clock outputs, so maybe useful for your PAL/NTSC circuitry.

Re: Introduction

Posted: Mon Aug 03, 2020 2:19 pm
by psmart
My MZ-700 running the with the tranZPUter SW v1.1 board, the software needs some tweaks which Im working on and also will soon make a board which fits in the MZ-700.

[MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 2:55 pm
by hlide
Subject regarding overclocking can be posted here.

Re: [MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 3:52 pm
by hlide
The overclocking part of the schematic reminds me of MZ-80 K overclocking. I need to see the timing drawing to figure out how it will behave. I'm in the extremely case when there is no fast memory storage (no SRAM, no FLASH):

- SLOW = (/MREQ = 0 OR /IORQ = 0) AND (/RD = 0 OR /WR = 0) [AND (/CLK = 0->1) for case (2)] --> slow down /CLK to original clock immediately.
- otherwise speed up /CLK to N times back.

Now let us see the frequency switching:

First, the normal CPU timing:

Code: Select all

        :<      M1R:T1      |       M1R:T2      |       M1R:T3      |      M1R:T4      >:
	<                                    LD r,r'                                   >:
        :_________          |_________          |_________          |_________          :
PHI x 1 /         \_________/         \_________/         \_________/         \_________/
        :_________          |                   |_________          |          _________:
/MREQ   :         \_____________________________/         \___________________/         \
        :_________          |                   |_______________________________________:
/RD     :         \_____________________________/                                       :
1) What I fear with a clock switching aligned to the slower clock:

Code: Select all

        :<        T1        |         T2        |T3 |T4>:<    T1    |         T2        |T3 |T4>:        
        :<                LD r,r'                      >:<              LD r,r'                >:
        :_                  |_________          |_  |_  :_          |_________          |_  |_  : 
PHI x 5 / \_________________/         \_________/ \_/ \_/ \_________/         \_________/ \_/ \_/
        :_                  |                   |_  |___:_          |                   |_  |___:
/MREQ   : \_____________________________________/ \_/   : \_____________________________/       :
        :_                  |                   |_________                              |_______:
/RD     : \_____________________________________/       : \_____________________________/       :
2) What I want to have through a clock switching aligned to the faster clock:

Code: Select all

        :<T1|         T2        |T3 |T4>:<T1|         T2        |T3 |T4>:        
        :<          LD r,r'            >:<          LD r,r'            >:
        :_  |_________          |_  |_  :_  |_________          |_  |_  : 
PHI x 5 / \_/         \_________/ \_/ \_/ \_/         \_________/ \_/ \_/
        :_  |                   |_  |___:_  |                   |_  |___:
/MREQ   : \_____________________/ \_/   : \_____________________/ \_/   :
        :_  |                   |_______:_  |                   |_______:
/RD     : \_____________________/       : \_____________________/       :
Case (1) will align each opcode to the slower clock making the cycle count hard to determine. But I guess /WAIT states insertions are okay in that case.

case (2) will run each opcode to the faster clock making the cycle count easy to determine and has the best ratio of instructions per second. But still able to dialog with slow devices (with no inserted /WAIT states though).

So which case is the two-clock source doing in the schematic?

Re: Introduction

Posted: Mon Aug 03, 2020 4:08 pm
by hlide
psmart wrote: Mon Aug 03, 2020 2:17 pmIn terms of your switching, have a look at the schematic below, (top right, IC's U9A, U4B, U9B, U14A/B, U9C, U9D, U1B), the two clocks go into dual D-Type flip flops, each clocked on their own clock and linked to the D input of the other. When the control signal (output of U4A) for Hi/Low speed changes, then both clocks have to be High before the actual flip occurs so the CPU never sees a glitch.
So it is almost the case (1).

Re: [MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 4:30 pm
by hlide
Oh yeah, the ICS501M takes a CLK signal (so the CPU one in my case) and will multiply it by N (x5 in my case). There is some input pins to select N (0 or 1 or N.C). Note that CLKout(t) == CLKin(t) when t % N = 0. So basically, I could reuse your trick with the original CLK and the 5 x CLK.

I still have issue to understand how the switching occurs because in my case it should happen at each T2 of a M-cycle being a M1R, MRD, MWR, IOR or IOW. Obviously, if I could have a fast SRAM/FLASH then the switching won't happen and the CPU will be hell fast.

In fact, the cycles count of instruction of the case (1) while not optimal may still be determined as it is seems to be auto-alignable in a similar way as Amstrad NOP cycles. You could say a NOP instruction is taking 2 cycles on consecutive 1 NOP instructions instead of 4 cycles because T2 and T3 are absorved by the next instruction.

Re: [MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 10:17 pm
by psmart

I've attached below two photographs from my scope, the ground wasn't good as I used the frame rather than the actual 0V connection but it shows the frequency switch.

The top yellow trace is the MZ700 3.58MHz clock, the blue trace is the 8MHz 2nd frequency, the purple trace is the actual Z80 Clock and the green trace in the 2nd photo is M1.

The Z80 doesn't work in the time domain rather clock edge and only the time between edges is critical (at least in my dealings with the CPU), the CMOS parts can go to zero clock but the NMOS parts cant, basically were only concerned with the edge-edge of the max frequency clocking the CPU.
In the circuit, on power up, U14A and U14B have Q=0 as Im not using the set/reset inputs. This allows the CTL_CLK (2nd clock) to go through to the AND gate U1B as well as the SYSCLK, so the output of U1B AND gate at start up is either low if either of the clocks are low or high if they are both high. The first clock pulse will be potentially as short as clock 2 but it isnt really important. Assuming U9A pin 1 input is low, U9B input 5 will be high, U9A pin 2 will be high, U9B pin 4 will be high, U14A Q = low, U14B Q = high. On the first rising edge of either clock, say CTL_CLK in this example, the D input pin 12 will be high because of the high input to pin 4 and 5 of U9B. On the rising edge, U14B Q = high (transfer of D) which will set U9D pin 12 high therefore blocking CTL_CLK as the driver of the Z80 CLK pin. U14B Q~ pin 8 will be low, so low on pin 1 and 2 of U9A will set U14A D input pin 2 to low and on the first rising edge of SYSCLK will transfer low to Q pin 5. This puts a low on pin 10 of U9C which allows SYSCLK to act as the Z80 driving clock (U1B will have pin 5 high as U9D is driven high and the output pin 6 will follow the input pin 4). U14A Q~ pin 6 is high so this drives U9B pin 4 high and sets a stable state of 1 on U14B D pin 12, the circuit follows SYSCLK. If U9A pin high input no goes high, U14A D pin 2 is driven high and on the first rising edge of SYSCLK disables SYSCLK as the Z80 driving clock. The Z80 clock remains in a high state. As U9A pin high is high, U9B pin 5 is low. As U14A Q = high, Q~ = low, so U9B transmits a low to U14B D pin 12. On the rising edge of CTL_CLK, 0 is transferred through to Q and U9D now allows CTL_CLK to act as the Z80 driving clock. As U14B Q~ is now high, it ensures a high is present on U14A D pin 2 and we are again stable.

The crossover always takes place by holding of the Z80 clock at high, the MARK period in the mark space ratio is not important as can be seen in the traces below. The maximum MARK period will be 1/CLK1 + 1/CLK2 + relevant propagation delay of gates. As mentioned though, only the edges and the period between edges is relevant. A glitch would appear as an edge and crash the CPU as the edge-edge would exceed its design parameters hence this circuit holding at the MARK level until both CLK1 and CLK2 are at the MARK level.

For my design, the Z80 is operating independently of the MZ-700 and has its own memory hence can run at 20MHz. If my board was running out of MZ-700 memory then it would always be limited to 3.58MHz. To overclock the base MZ-700 would require Phi to be increased and that then will be limited by the gate array which generates the timing signals and strobes and the propagation delays of all the MZ-700 components. Easiest way to find the max overclock frequency is to increase the frequency output by 5A clock generator as this would adjust all other timing parameters albeit COLR would change on the modulator so you couldn't use a TV or video out, use RGB.

As you have been analysing though, if you want to increase Phi-0 only then you may need to adjust WAIT to add compensation to the signals generated by IC 7A gate array. In my experience on the MZ80A, Sharp use the clock edge in combination with the Z80 signals to generate things like Chip Select for ROM and the Video wait, typically MREQ. On the I/O processor I use on my board, it is imperative that for a write to the mainboard that I delayed WR after setting MREQ by 1 clock signal to meet the rising edge otherwise the write failed.

Will be interesting to see if you can overclock the mainboard by a significant margin.

Re: [MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 10:18 pm
by psmart
Second photo, for some reason attaching two photos the second one doesnt show!

The green trace on this picture is M1 in relation to the clocks.

If you need a trace of any other signals let me know and will see if I can snapshot them.

Re: [MZ series] Overclocking Z80

Posted: Mon Aug 03, 2020 10:24 pm
by psmart
BTW. The below image is the new board Im making for the MZ-700, still being worked on as it depends on information I gain from the MZ80A Video Module which Im currently assembling, but basically it combines the tranZPUter SW v2.1 and the Video Module 2.0 into one board which fits into the tight space of the MZ700. I intercept the MZ-700 video signals and superimpose/replace them so that I can generate 80char screen output and bitmap graphics. Still a work in progress, probably another few weeks before I get a board made, but slowly getting there!