News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_fano

Z80 to X80/R800 ?

Started by fano, 10:08, 04 February 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

TFM

Did you replace the Z80A by the Z80H?

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

fano

Used a Z84C0008PEC  :)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

RockRiver

Quote from: TFM on 17:50, 05 February 14
You did overclock ? Did you exchange the crystal on board? How did it work?
MSX cousins did that years ago: MSX1 at 7 Mhz:
7 mhz kit | MSX Resource Center (Page 1/2)
http://msx.hansotten.com/index.php?page=clock-upgrades



MacDeath

QuoteMSX1 at 7 Mhz
wasn't it called the TurboR ?
:laugh:

Kris

Quote from: MacDeath on 19:30, 13 June 14
wasn't it called the TurboR ?
:laugh:


No, MSX Turbo R is a "MSX 3" even if it has never been called like this ;)


MacDeath

Nope as well...
True MSX3 is MSX 2+... TurboR is more like MSX4.


TotO

The MSX3 was planed to be released with the V9990 VDP... (and was canceled)
So, no MSX3, no MSX4... Only MSX and MSX 2 boosted.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

SyX

Well, i don't know if it's an urban legend, but i read at the beginning of the millenium that ASCII Corp. (the owner of the MSX standard) was trying to get Sega for making an MSX 3 based in the Dreamcast (it was a big retro moment in Japan with great meetings, the fpga msx, a new magazine by ASCII, ...), but the negotiations never went well thanks to Kazuhiki Nishi (the boss in Ascii).

TotO

If they said, with exclusive Shenmue 3... It was a legend.  ;D
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

zhulien

this is an interesting topic almost resurrected by the newer similar ones - i guess there are more than one person wanting such a solution... I am now investigating the possbilities of a Z80 pin-compatible FPGA replacement board - of course timing is paramount for the GA and the Z80 cores seem to be widely available, perhaps one even adaptable.  Performance increase by such... addition of new instructions and internal memory to the FPGA that can run in full speed within constrained external clock cycles - such as moving 64kb RAM within the FPGA in a single instruction clockcycle externally... then the FPGA can be considered to have co-processor instructions, memory movement, matrix transformations, graphics pre-processing, rendering even... 

ThomH

Quote from: gerald on 09:15, 05 February 14
One limiting factor for a compatible enhanced Z80 is the GA that deals with the DRAM access for the Z80. There is only one RAM access slot available every microsecond, and since RAS/CAS are managed by the GA, we can only do 1 read/write to the base RAM every 1µs.
Since most instruction are using the bus all time, all access to original RAM (BASE and EXP) will be limited, and overall code speed will be limited by memory access. New instruction will only add marginal improvement.
A solution is to have 'fast' ram only accessible by the CPU (or a cache, but we lose all determinism in the code).
Very late, but: surely there are actually two RAM access slots every microsecond, it's just that a vanilla Z80 will use only one of them. A hypothetical CPC-specific processor could wait until WAIT is no longer asserted and then use both that cycle and the one after before needing to get out of the way. So if your imaginary Z80 replacement turned all machine cycles into a single clock cycle, it would likely run twice as fast as the stock Z80 without requiring any further base hardware modification?

gerald

Quote from: ThomH on 21:22, 08 September 17
Very late, but: surely there are actually two RAM access slots every microsecond, it's just that a vanilla Z80 will use only one of them. A hypothetical CPC-specific processor could wait until WAIT is no longer asserted and then use both that cycle and the one after before needing to get out of the way. So if your imaginary Z80 replacement turned all machine cycles into a single clock cycle, it would likely run twice as fast as the stock Z80 without requiring any further base hardware modification?
There is only one cycle allowed per microsecond, whatever your microprocessor is, and it had to conform with the 'vanilla' Z80 timing. That's something dictated by the fixed timing of the gate array which does the interface to the DRAM.



ThomH

Quote from: gerald on 07:24, 09 September 17
There is only one cycle allowed per microsecond, whatever your microprocessor is, and it had to conform with the 'vanilla' Z80 timing. That's something dictated by the fixed timing of the gate array which does the interface to the DRAM.
There's only one cycle during which WAIT is not asserted but per its published timing diagrams the Z80 has two different kinds of access cycle. An oppose read will access memory during the first cycle on which WAIT is not asserted. A regular read or write will access in the cycle afterwards.

Therefore any machine, including the CPC, that uses the wait line, must be able to service a memory access during the first cycle that WAIT is asserted. In the CPC's case it's two contiguous cycles of video access followed by a two cycle window for the Z80, which will use only one of them.

A hypothetical Z80 with single clock cycle length machine cycles could implement a policy of only ever starting to obey WAIT a cycle after it has been signalled and thereby double the speed of a CPC (and, likely, be usable for improvements in other micros too, but I'm no expert).

gerald

Quote from: ThomH on 15:13, 09 September 17
There's only one cycle during which WAIT is not asserted but per its published timing diagrams the Z80 has two different kinds of access cycle. An oppose read will access memory during the first cycle on which WAIT is not asserted. A regular read or write will access in the cycle afterwards.

Therefore any machine, including the CPC, that uses the wait line, must be able to service a memory access during the first cycle that WAIT is asserted. In the CPC's case it's two contiguous cycles of video access followed by a two cycle window for the Z80, which will use only one of them.
The Z80 (or whatever) can ask as much as it wants while the wait is not asserted. But in a CPC, the gate array will only serve him one single DRAM access per microsecond.
Here you can see how the DRAM is accessed (look for RAS/CAS).
Row address are latched on falling edge of RASn, column address on falling edge of CASn.
All signals related to memory and video fetch are free running and generated from counter. They are not influenced by the Z80 except for the WE signal for R/W and CAS which stays high when no memory access are done.


If you want to do more than on memory access per microsecond you need to have your CPU isolated from the main CPC bus. Doing so, you end up with an architecture similar to what is found in an Amiga were everything connected to the gate array address/data bus to be considered as chip memory (this includes the expansion port). Everything that you have connected to your local Z80 bus is then fast memory and could run as fast as you design it.

ThomH

Quote from: gerald on 15:59, 09 September 17
The Z80 (or whatever) can ask as much as it wants while the wait is not asserted. But in a CPC, the gate array will only serve him one single DRAM access per microsecond.
Here you can see how the DRAM is accessed (look for RAS/CAS).
Indeed that contradicts what I had read elsewhere — where RAS and CAS were simply strobing once per 4Mhz clock — and unambiguously proves that my proposed hypothetical Z80 would not function in a CPC.

I'm surprised they bothered disabling the extra CAS strobe during the CPU access period.

Rambling aside: do you happen to have a capture with M1 shown? I've had difficulty getting a consistent explanation of its timing versus the refresh cycle and the extended pages. It seems to correlate with R increments, and MSX timing information suggests that the difference between adjacent fetches can be discerned so I suspect it's active during the fetch portion (i.e. the first two cycles) of each four-cycle opcode fetch, but I'm really just guessing. The maximum-of-two rule on R increments (and MSX WAIT cycles) seems to imply that it isn't signalled by any of the three-cycle machine cycles, regardless of whether they're operation fetches.

gerald

Quote from: ThomH on 19:36, 10 September 17
I'm surprised they bothered disabling the extra CAS strobe during the CPU access period.
You mean during IO? That's to avoid conflict between the RAM data and the IO data.
Quote from: ThomH on 19:36, 10 September 17
Rambling aside: do you happen to have a capture with M1 shown? I've had difficulty getting a consistent explanation of its timing versus the refresh cycle and the extended pages. It seems to correlate with R increments, and MSX timing information suggests that the difference between adjacent fetches can be discerned so I suspect it's active during the fetch portion (i.e. the first two cycles) of each four-cycle opcode fetch, but I'm really just guessing. The maximum-of-two rule on R increments (and MSX WAIT cycles) seems to imply that it isn't signalled by any of the three-cycle machine cycles, regardless of whether they're operation fetches.
On the following capture, you have a selection of case (Read/Write, instruction fetch, IO write, Push)
[attach=2]

ThomH

Quote from: gerald on 20:11, 10 September 17
You mean during IO? That's to avoid conflict between the RAM data and the IO data.On the following capture, you have a selection of case (Read/Write, instruction fetch, IO write, Push)
Every microsecond there is one memory access by the Z80 and two by the Gate Array. There are the two cycles that the Z80 might sample (or output) during, albeit that it is bound to only the address it was announcing during the first, then there are the two cycles during which the Gate Array samples, and it does so twice — once with each value of CCLK.

My reading of your graphs is that RAS and CAS are strobed once at the start of the Z80 period, since no matter when the Z80 expects to sample it'll have the proper address available immediately upon entry into that region, and that RAS is strobed once and CAS strobed twice during the Gate Array region. Which works because for each address announced by the CRTC the Gate Array reads two values, with CCLK providing the low bit. So both accesses will be in different columns but on the same row. Therefore the initial row address remains valid.

So: three memory accesses per microsecond, with two RAS strobes and three CAS strobes.

From that understanding I expressed surprise that the designers bothered strobing CAS twice for the Gate Array but only once for the Z80 when strobing it twice shouldn't have any negative side effects and feels like it'd save some logic.

Am I still failing properly to comprehend what I'm being told?

gerald


Quote from: ThomH on 20:41, 10 September 17
From that understanding I expressed surprise that the designers bothered strobing CAS twice for the Gate Array but only once for the Z80 when strobing it twice shouldn't have any negative side effects and feels like it'd save some logic.

Am I still failing properly to comprehend what I'm being told?
The are 2 CAS strobe for the gate array since it need two consecutive bytes  ;)
For the Z80, the only on CAS strobe is done because there is no need (and no time) for more. The WAIT asserted time is merely one Z80 clock cycle, and for a complete access you also need a RAS stobe.

ThomH

Quote from: gerald on 21:20, 10 September 17
The are 2 CAS strobe for the gate array since it need two consecutive bytes  ;)
For the Z80, the only on CAS strobe is done because there is no need (and no time) for more. The WAIT asserted time is merely one Z80 clock cycle, and for a complete access you also need a RAS stobe.
Yes, that's why I said I was surprised there's no second CAS strobe during the Z80's window, since it wouldn't be detrimental and it feels like you'd need extra logic to skip one than just to run it and forget about it.

rpalmer

People,

I find it funny that everyone keeps referring to the Z80 having a relationship with RAS/CAS.

The Z80 has no idea about RAS/CAS constructs, since if it did then the Z80 address bus would be 8 bits wide and not 16 bits.

rpalmer

ThomH

Quote from: rpalmer on 23:19, 10 September 17
People,

I find it funny that everyone keeps referring to the Z80 having a relationship with RAS/CAS.

The Z80 has no idea about RAS/CAS constructs, since if it did then the Z80 address bus would be 8 bits wide and not 16 bits.

rpalmer


I don't think anybody has. I've been talking about "the Z80's window", i.e. the window of RAM access granted to the Z80 by the Gate Array, and gerald has said things like "For the Z80, the only on CAS strobe ..." which explains that a CAS strobe is being done for the Z80's benefit but not asserting that it is being done by the Z80.

Powered by SMFPacks Menu Editor Mod