Z180 - How to set clock multiplier in SC126?

[MogensB]

I have just built the fantastic SC126 kit. I have read about the Z180 clock multiplier feature, which should be able to "overclock" the CPU to 36 MHz (gaining double speed I would expect)?

However, I am having problems enabling it. I have read articles and posts about the different Z180 revisions. 

On reset ROMWBW reports: SC126 Z8S180-N @ 18.432MHz IO=0xC0, which to my understanding is capable of setting the double clock multiplier?

I use the following code to set the multiplier (using inline hex machine code in a Turbo Pascal CP/M program):

  LD A,$80

  OUT0 ($1E),A

  OUT0 ($1F),A

(HEX: 3E80 ED391E ED391F)

But apparently the speed of the CPU does not change? I have a test program with some counter loops, which runs in the same time before and after.

Can anyone confirm if this is the right instruction sequence?

Are there any other requirements or restrictions to setting the clock multiplier that I have missed?

Regards, 

MogensB

[Steve Cousins]

Hi MogensB

RomWBW sets the base address for the Z180's registers to 0xC0 (note the "IO=0xC0" in "SC126 Z8S180-N @ 18.432MHz IO=0xC0, ")

As a result the correct addresses are:

0x1E + 0xC0 = 0xDE

0x1F + 0xC0 = 0xDF

Steve

[Eric Dittman]

I built an sc126 last night and thought I'd give it a try. It
does work.

On 7/6/20 5:46 PM, Steve Cousins wrote:
> Hi MogensB
>
> RomWBW sets the base address for the Z180's registers to 0xC0 (note the

> "IO=0xC0" in "SC126 *Z8S180-N* @ 18.432MHz IO=0xC0, ")

>
> As a result the correct addresses are:
> 0x1E + 0xC0 = 0xDE
> 0x1F + 0xC0 = 0xDF
>
> Steve
>
>
>
> On Monday, 6 July 2020 20:32:17 UTC+1, MogensB wrote:
>
>
> I have just built the fantastic SC126 kit. I have read about the
> Z180 clock multiplier feature, which should be able to "overclock"
> the CPU to 36 MHz (gaining double speed I would expect)?
>
> However, I am having problems enabling it. I have read articles and
> posts about the different Z180 revisions.

> On reset ROMWBW reports: SC126 *Z8S180-N* @ 18.432MHz IO=0xC0, which

> to my understanding is capable of setting the double clock multiplier?
>
> I use the following code to set the multiplier (using inline hex
> machine code in a Turbo Pascal CP/M program):
>
>   LD A,$80
>   OUT0 ($1E),A
>   OUT0 ($1F),A
>
> (HEX: 3E80 ED391E ED391F)
>
> But apparently the speed of the CPU does not change? I have a test
> program with some counter loops, which runs in the same time before
> and after.
>
> Can anyone confirm if this is the right instruction sequence?
> Are there any other requirements or restrictions to setting the
> clock multiplier that I have missed?
>
> Regards,
> MogensB
>

> --
> You received this message because you are subscribed to the Google
> Groups "retro-comp" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to retro-comp+...@googlegroups.com
> <mailto:retro-comp+...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/retro-comp/cabac17e-2eba-4482-8cc8-c793226ae8b6o%40googlegroups.com
> <https://groups.google.com/d/msgid/retro-comp/cabac17e-2eba-4482-8cc8-c793226ae8b6o%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
Eric Dittman

[Phillip Stevens]

 MogensB wrote:

I have just built the fantastic SC126 kit. I have read about the Z180 clock multiplier feature, which should be able to "overclock" the CPU to 36 MHz (gaining double speed I would expect)?

Steve Cousins wrote:

RomWBW sets the base address for the Z180's registers to 0xC0 (note the "IO=0xC0" in "SC126 Z8S180-N @ 18.432MHz IO=0xC0, ")

As a result the correct addresses are:

0x1E + 0xC0 = 0xDE

0x1F + 0xC0 = 0xDF

Just to add that the RAM needs to have one wait state to be within specification at 36MHz.

You should "expect problems" if you run it with 0 memory waits, but if it works then great.

You can configure your RomWBW to work at 36MHz on the SC126 all the time,  by setting this line to "2" and the next line to "1". And then rebuilding the binaries.

Phillip

[MogensB]

Thank you!!

It works perfectly now. I had completely missed the fact that the IO addresses for the control registers are relocatable in the Z180...
And, as suggested, I had to bump the memory wait state to 1, to get it running.

Regards,
MogensB

[Nick Brok]

The I/O waitstate must also be increased by one.
The original settings in ROMWBW are for 20 MHz

Op dinsdag 7 juli 2020 07:35:40 UTC+2 schreef MogensB:

[Phillip Stevens]

Nick Brok wrote:

The I/O waitstate must also be increased by one.

The original settings in ROMWBW are for 20 MHz.

Nick, TBH, I'm pretty sure for the SC126 that it would be unnecessary, to change or set the I/O wait state.

The I/O wait state setting is ignored for all internal z180 peripherals, and the sc126 has no external peripherals.

(But, I don't have one to say for sure. It isn't necessary for the sc130, or sc131 that I do have).

If you wanted to add a PPIDE interface, (like your Scrumpel or my yaz180) then yes, you're right of course.

Cheers, Phillip

[J.B. Langston]

I have some example code here: https://github.com/jblang/TMS9918A/blob/master/examples/z180.asm. You can see how the functions are called from my mandelbrot generator: https://github.com/jblang/TMS9918A/blob/master/examples/mandel.asm#L53-L72. Phillip is probably right that the I/O wait doesn't need to be set in general but since I am using my TMS9918A video card in this program, I did increase I/O wait to 3 wait states.

[Nick Tate]

Hello everyone... In the past few days I have been working on a utility to overclock the CPU for CP/M... It alters CPU settings, WAIT states, and the  UART settings to set the baud rate for 115K. Feel free to play around with the code. 

https://github.com/ntate6630/SC126-running-CP-M-at-36864-MHz

If anyone can give my advice as to what I could improve on I would be very greatfull thanks! 

Its not 100% reliable and every now and again the system will do something strange like freeze up ocasionally or after running a CP/M application it will not return to the command prompt, or sometimes  cause a CP/M panic!  sometimes the system will stop reading the SD card so no files can be accessed.

All this is temporary and the system can be reboot and your'e back in to 18MHz again.

[Alan Cox]

If my maths is right you need faster ROM than the standard 512/512K
card to run at 36MHz. In practice that might mean doing the 1MB RAM
mod and copying ROMWBW into the other RAM first as I don't see many
sources of 5v flash fast enough. Even the RAM is a bit tight.

[Bill McMullen]

I've successfully built and tested a lot of Z8S180's at 33.333 & 36.864MHz with zero wait states.  In my experience, the CMR must be set to XTAL*2 before the CCR is set to XTAL/1, otherwise PHI is simply XTAL/1.  That's opposite of your sequence and you might want to check that with an oscilloscope or frequency counter.

Adding two wait states will effectively reduce PHI to about 2/3 of what you've programmed it to be, or about 25MHz.

To be fully within specifications, zero wait state RAM needs to be about 15ns or less and while SST39SF040-45's can use one wait state, they're getting expensive and hard to find.  SST39SF040-55's or -70's need 2 wait states.

[Phillip Stevens]

Nick wrote:

Hello everyone... In the past few days I have been working on a utility to overclock the CPU for CP/M... It alters CPU settings, WAIT states, and the  UART settings to set the baud rate for 115K. Feel free to play around with the code. 

https://github.com/ntate6630/SC126-running-CP-M-at-36864-MHz

If anyone can give my advice as to what I could improve on I would be very greatfull thanks! 

Its not 100% reliable and every now and again the system will do something strange like freeze up ocasionally or after running a CP/M application it will not return to the command prompt, or sometimes  cause a CP/M panic!  sometimes the system will stop reading the SD card so no files can be accessed.

Hi Nick,

You’re going to want to store the stack in a DEFW, otherwise using EQU is just defining a value (rather than allocating storage). Having it set to 0 is just going to overwrite what’s in 0xFFFE/F (I can’t remember offhand what RomWBW stores there).

Also Alan’s right. You can’t do 0 Memory wait state with any Flash devices I’m aware of. You need to change to 1 Memory wait state before changing the multiplier registers, if you’re going to stay in specification. But YMMV if your Flash is good enough it might work most of the time.

Cheers,  Phillip

[Wayne Warthen]

I'm not sure if the system is running RomWBW or not.  If it is, note that RomWBW has a utility app called SETCPU which allows you to change the clock speed and I/O and Memory wait states of a running system.  It handles all of the fixup of the system timer interrupt and baud rate when the speed is changed.  It does not prevent you from setting the speed/wait states to a value that does not work.  In this case, the system will just crash and a reboot will restore functionality.

This utility has no bearing on the ability of a system to actually run with increased clock speed and/or reduced wait states.  Just wanted to make sure folks are aware of it.  It is only included in the dev branch of RomWBW.

Thanks,

Wayne

[Phillip Stevens]

On Tuesday, 4 October 2022 at 07:39:09 UTC+11 Phillip Stevens wrote:

Nick wrote:

Hello everyone... In the past few days I have been working on a utility to overclock the CPU for CP/M... It alters CPU settings, WAIT states, and the  UART settings to set the baud rate for 115K. Feel free to play around with the code. 

https://github.com/ntate6630/SC126-running-CP-M-at-36864-MHz

If anyone can give my advice as to what I could improve on I would be very greatfull thanks! 

Its not 100% reliable and every now and again the system will do something strange like freeze up ocasionally or after running a CP/M application it will not return to the command prompt, or sometimes  cause a CP/M panic!  sometimes the system will stop reading the SD card so no files can be accessed.

Hi Nick,

You’re going to want to store the stack in a DEFW, otherwise using EQU is just defining a value (rather than allocating storage). Having it set to 0 is just going to overwrite what’s in 0xFFFE/F (I can’t remember offhand what RomWBW stores there).

I’d also add that you need to allocate a new stack location rather than 0xFFFE-F. I’m sure that’s a bad location if you’re running any CP/M BIOS and or CBIOS from RomWBW.

Typically you can create some stack space within your program, or you can use the BDOS address as the starting location within CP/M. Depends on how certain you are about your stack usage requirement.

You can create stack by reading the 0x0006-7 location. This is the address of BDOS, and anything below this address can be used as TPA (for your program), and the stack can grow down into TPA.

Or you can just allocate a number of bytes for the job.

   defs $40        ;z80 stack grows down
.stack

Remember to put the label AFTER the space, as the stack grows down.

Cheers, Phillip

[Wayne Warthen]

On Monday, October 3, 2022 at 3:22:18 PM UTC-7 Wayne Warthen wrote:

... note that RomWBW has a utility app called SETCPU ...

Oops, the name of the app is CPUSPD, not SETCPU.  Sorry.

-Wayne 

[Nick Tate]

Hello everyone,

I have made changes to the code from your advice and now everything is running perfectly.

I swapped round CMR and CCR so that CMR is first.

I made changes to the label 'stksav', changing it from EQU to DEFW and the stack size label is set to  'stksiz  EQU  40h'  I set label 'stack EQU  01C4h'  adding 64 bytes above the code space. More than enough stack space.

 This completely stopped all the random crashes, Lost SD card files and CP/M panics etc.  Before I set the  stack to '0000h' and this will go down through FFFFh... into the BIOS area.

I have set MEMORY WAIT states = 1, and I/O WAIT states = 0, and its giving me NO problems at all. My thinking is that the internal CPU clock is divided by 4 so the bus speed is really 9.216Mhz when running at 36.864Mhz PHI clock,  so I'm confident it will be fine like this.

I ran my benchmark test again and it finished in 1 min 17 seconds. The previous time with 2 Memory wait states was 1.34 seconds. The stock speed at 18.432 MHz is 2 mins.

The Github file is available here...

https://github.com/ntate6630/SC126-running-CP-M-at-36864-MHz

Thanks.   

Nick

[Alan Cox]

> I have set MEMORY WAIT states = 1, and I/O WAIT states = 0, and its giving me NO problems at all. My thinking is that the internal CPU clock is divided by 4 so the bus speed is really 9.216Mhz when running at 36.864Mhz PHI clock,

It's not a simple bus clock like a Motorola 8bit bus - the bus cycles
are variable numbers of system clocks. The worst case is the M1 cycle
if you look at the timing diagrams in the Z180 manual. You do have
more than one clock per bus cycle.

The timings on the memory are also voltage, capacitance, temperature
and silicon worst cases so you have some slack for overclocking if you
take the risk of silent corruption, and providing you pick the top bin
part (ie the fastest version available) often quite a bit of slack.
The slower ones usually have less because they are parts that didn't
make the top bin in test, whereas the top bin is anything that met the
top bin or faster.

Alan

[Phillip Stevens]

Nick wrote:

I have made changes to the code from your advice and now everything is running perfectly.

Good news.

 

My thinking is that the internal CPU clock is divided by 4 so the bus speed is really 9.216Mhz when running at 36.864Mhz PHI clock,  so I'm confident it will be fine like this.

Just to point out that there is no “clock divider” or multiplier in the Z180, as applies in more modern CPUs.

It perhaps is better thought of as crystal divider or multiplier, as only the ratio is between the crystal attached to the CPU pins and the system clock is being affected by the register settings.

The CPU and memory are always running at 1:1 ratio of cycles per second, based on the result of the “crystal multiply” settings. It is easy to get the wrong end of the stick on this, as it is totally unclear in the datasheets.

P.

[Mark T]

Would the Z180 benefit from adding half clock cycle to the M1 fetch cycles?

I have a 74act163 clock stretcher which divides a 54 MHz clock to 27MHz and extends M1 RD cycle to 71 ns, which is similar to other RD cycles. Its also similar to the M1 RD cycle on a standard 20MHz Z80. I haven’t had chance to test it with RomWBW yet

Is this likely to work on a Z180? Probably going to make a mess of the serial interfaces, but should be OK with FT245.

[7alken]

hi, I first tried to find in docs the ranges for mem (0-3) and io (1-4) wait states (sure it is in datasheet, but ...) and there is NO mention of it;
it may be confusing for a while ))