CPC TURBO First Level - project

[McArti0]

I have a dream ...

The Second Level of TRUBO is within the reach of Mr. Bread80.
In his GA RP2350 you can press the 8MHz CPU mode.

In this thread I wanted to address the possibility of the First Level of CPC TURBO, i.e. faster execution of some z80 instructions via CMOS with a higher clock.

All we need is to change the shape of the WAIT signal for a faster processor or locally change the clock (small speedstep)

How to do it? ...  

[McArti0]

Linkt to emulation TURBO CPC First Level.

It work (or not work) 

Project v0.00⅜

[GUNHED]

Would be nice to see that running.

However, please do consider that a CMOS Z80 has different opcodes (f.e. OUT (C),0 vs OUT (C),&FF ). So not all software will work.

[McArti0]

please do consider that a CMOS Z80 has different opcodes (f.e. OUT (C),0 vs OUT (C),&FF ).

This problem is now a thing of the past.

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/zilog-z84c0020peg-in-my-cpc-not-all-works/msg239050/#msg239050

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/zilog-z84c0020peg-in-my-cpc-not-all-works/msg239772/#msg239772

Nothing will stop us!

[GUNHED]

You got an great kind of attitude! Go on!! Software will support your new hardware!!! 

[zhulien]

i wonder if something like this could work.

imagine a very fast z80 with fast cpc ram.  in normal mode they are not enabled like upon boot.  they could be enabled either like 6128 plus features or via a port. 

when enabled, the fast ram takes place of the standard cpc ram, and the fast cpu is 'available'. the fasts cpu is not automatic, but... maybe it can either be running in slow crippled mode, but software switchable to fast mode, then back to slow mode.The reason for this is... an application when wanting to perform any type of timing sensitive I/O or floppy access would switch to slow mode, but then when wanting to do something fast, would switch to fast mode.

we already have hardware that can use an external CPU instead of internal, and we already have hardware that can use external RAM instead of internal - so likely it could bepossible to do something like this.

timing with the crtc wouldn't be affected i suspect as it will always be looking at the original slow cpc ram.

[andycadley]

I don't think the RAM speed would have to matter. You could have "fast RAM" all the time and there would be no change to the system unless you actually sped the CPU (or gate array) up.

Whether you could do that without redesigning most of the motherboard and essentially building a new machine is a whole other matter.

[zhulien]

my understanding is the CRTC can only see the internal RAM without modifying the CPC - but as mentioned we already have cards that can have external CPU (you can buy unpopulated ones on ebay) and also external RAM (UliFAC), maybe they can work together

[Benedikt]

If I am not mistaken, it should be possible to effectively replace the internal RAM with fast SRAM by sandwiching an expansion board between the system board and the socketed Z80, GA and PAL.
With the RAS and CAS lines interrupted, the DRAM on the system board would effectively be disabled.
Since 55ns SRAM can happily run at 16MHz, appropriate glue logic for access interleaving could then enable zero wait state RAM access even with an 8MHz Z80.
Well, at least in my head. I have no idea whether it would actually work.

[McArti0]

Switching between 4/16MHz will be via command ED 00/ ED 01 which are free in Z80.
All write/read cycles to internal ram will be the same with Z80 4MHz (Until @Bread80 decides  to make an 8MHz GA version)
All external RAM can work as FAST with 94ns access time for opcodes.
It is enough to mask the low READY signal for fast z80 while accessing external RAM/ROM.

[McArti0]

Well, at least in my head. I have no idea whether it would actually work.

It will work but you have to disable CRTC and include it in the extension.

[zhulien]

Well, at least in my head. I have no idea whether it would actually work.

It will work but you have to disable CRTC and include it in the extension.

Why disable crtc? Why not shadow it as alifac does?

[Benedikt]

Well, at least in my head. I have no idea whether it would actually work.

It will work but you have to disable CRTC and include it in the extension.

Why disable crtc? Why not shadow it as alifac does?

I don't quite get why the CRTC would have to be disabled or bypassed, at all.
With appropriate address and data latches and careful timing, the CRTC and Gate Array could freely access the 16MHz SRAM in every other 16MHz cycle.
The Gate Array would not have to wait for the value from RAM any longer than with the CPC's slow native RAM.
The 8MHz Z80 would then get exclusive (buffered) access during the other half of the 16MHz cycles. Wait states would only be necessary for I/O.

[McArti0]

I don't quite get why the CRTC would have to be disabled or bypassed, at all.

It's simple. There are no wires with addresses generated by CRTC in the Z80, PAL and GA sockets.

[Benedikt]

I don't quite get why the CRTC would have to be disabled or bypassed, at all.

It's simple. There are no wires with addresses generated by CRTC in the Z80, PAL and GA sockets.

Got it. Well, in that case we need a whole lot of pogo pins.
The basic approach – without pogo pins – would still be interesting for an internal RAM expansion, though.

[McArti0]

Why disable crtc? Why not shadow it as alifac does?

CRTC can be read and depending on the version you can receive different values. collisions with other CRTC should not be allowed. Although in fact the second CRTC can be connected as write only.

[Bread80]

Some thoughts I've had regarding an upgraded CPC design:

Replace the sequencing logic from the gate array. Then the GA only generates video output and is decoupled from the timings of the rest of the system. You'll need to 'listen' to a GA output signal (eg. CPU or CCLK) to get everything in sync but if they're both driven from the same 16MHz crystal everything will stay in sync once started.

Put a latch between the video bus and the GA. The new sequencer logic can load data into it at it's leisure. The GA can strobe it in via CAS or 244EN. This further decouples the GA from the sequencer and memory and permits the use of faster memory (eg SRAM). You just need to be aware of the GAs version of CCLK when reading video bytes so you get the correct ones. (Probably best to to have a pair of latches for the two video bytes in each cycle).

I/O accesses should probably have wait states generated so old school I/O devices can keep up. If you're doing a full new PCB layout generating a 4MHz PHI for the expansion port will help disk drives etc to run at the correct speed.

Reads from ROM and I/O (except I/O to the GA) don't clash with video reads so the CPU doesn't need to slow down when reading from them. The same for expanded memory. And, if you really want maximum performance, don't generate wait states (or read video bytes) during refresh periods.

The latter item will probably work best if you bring the memory manager into the new sequencer logic (ie replacing the HAL). The HAL is probably not terribly fast anyway (given it's age) so a replacement should enable faster memory accesses.

If you're replacing the HAL you might as well upgrade the memory addressing schema. My preference is that of the Enterprise. This has four 8-bit latches, one per 16k memory bank, and enables any physical memory bank to be patched into any Z80 bank. As with enhanced GA performance the system would need to boot into 'standard' memory manager mode and the enhanced mode would be enabled via an I/O port.

BTW I much prefer an I/O port to a 'secret' Z80 opcode. However adding extra registers to the GA ports is messy. I suspect that shadowing unused CRTC registers would be much more practical, but depends on how the CRTC handles the selection of 'illegal' registers? Does if allow such selections and ignore writes to them, or does it map them onto some default/partially decoded register?

[McArti0]

BTW I much prefer an I/O port to a 'secret' Z80 opcode. However adding extra registers to the GA ports is messy. I suspect that shadowing unused CRTC registers would be much more practical, but depends on how the CRTC handles the selection of 'illegal' registers? Does if allow such selections and ignore writes to them, or does it map them onto some default/partially decoded register?

And I prefer Opcodes because they are faster, because they don't need addressing, and no one has ever used them. CMOS Z80 interface will need hardware patch OUT (c),255 to 0 anyway.

I wouldn't want to kill CRTC 5 (HD6345) in the socket and it has 40 registers.
I checked that in CRTC 0. R0, R32, R64 and R128 are the same register.

At PAL/HAL my mouth is watering at the sight of OUT &3CFF,nn , which nicely bypasses CRTC and GA.

(or read video bytes) during refresh periods.

I see DMA here with an automatic refresh register counter. I like it very much.

[McArti0]

For test I will try CPC Turbo Half Level  

Very complicated circuit 

Link to CPC Turbo Half Level

[Bread80]

I wouldn't want to kill CRTC 5 (HD6345) in the socket and it has 40 registers.
I checked that in CRTC 0. R0, R32, R64 and R128 are the same register.

I didn't realise there was a version with extra registers. That's a shame. I'd really like to be able to add extra GA registers. The current scheme is a little ... cramped.

[eto]

Is the hd6345 used in the CPC?

[andycadley]

Is the hd6345 used in the CPC?

No, not in any shipped model. 

[McArti0]

Is the hd6345 used in the CPC?

"Yes" 

https://www.cpcwiki.eu/forum/amstrad-cpc-hardware/would-you-like-to-have-crtc-5-in-your-cpc-about-hd6345/msg240088/#msg240088