News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_GUNHED

CPC four times faster...

Started by GUNHED, 16:43, 06 July 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

andycadley

I suspect that's functionally equivalent to replacing the GA with one that shadows the standard 64K internally and thus doesn't need to put wait states on the bus, letting the CPU run at full speed. It would probably work and have several benefits, but it doesn't actually exist, which is something of a down side.

MaV

My solution (close to eto's) would be to use dual-ported RAM for the first 64k, the CPU accesses the memory from one port, the GA reads from the other. All further RAM is completely on the side of the CPU creating kind of the "CPU bus". The other CPC peripheral chips would comprise a second bus (peripheral bus) on the other side (GA, FDC, CRTC, AY, etc.). When you think about it, no other peripheral except the GA needs direct RAM access, and the GA has access to read the RAM via the one port of the dual-ported RAM.

The peripherals need only to be addressed via the IO access of the CPU, thus a bus transceiver (A0-15, D0-7 thus 24 lines) links both busses just for the INs and OUTs. Add some glue logic to guarantee that the fast CPU accesses the IO bus only when the peripheral bus allows it (because it is much slower for the fast CPU) which shouldn't be a problem since the INs/OUTs can be lengthened with wait states anyway.

But I'm pretty sure the devil is in the details, and something might crop up that makes the solution infeasible.

So fast RAM with the CPU, and slow (or rather normal) access to the peripherals. The GA need not be changed.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

rpalmer

Mav,

Your proposed solution would still have a problem for the RAM above 64K as that RAM can be accessed by the GA when configured to do so. You would need dual port ram for any expansion RAM as well which is unlikely for what is available today.

The only way to the CPC to run faster is either install a 20Mhz crystal which makes the CPC run a 5MHz (with a 6MHz Z80 chip) or you somehow replicate the GA with a FPGC to manage the system and just let the GA do the video processing only (time sliced with the FPGA to get a slight delay for the fastest CPC you could setup).

rpalmer

MaV

I was led to believe (until now) that only the lower 64k can be adressed by the GA.
Sure, if that is the case, then all RAM would have to be dual-ported, no problem, since it's a theoretical exercise anyway. :D

GUNHED's R800 solution would not require any higher frequencies since the chip seems to run more efficient at the same 4MHz than a stock Z80, we just need to use RAM that can be adressed at every clock cycle, so it needs to be twice as fast as the current.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

TotO

Quote from: MaV on 20:52, 09 July 22My solution (close to eto's) would be to use dual-ported RAM for the first 64k, the CPU accesses the memory from one port, the GA reads from the other. All further RAM is completely on the side of the CPU creating kind of the "CPU bus". The other CPC peripheral chips would comprise a second bus (peripheral bus) on the other side (GA, FDC, CRTC, AY, etc.). When you think about it, no other peripheral except the GA needs direct RAM access, and the GA has access to read the RAM via the one port of the dual-ported RAM.
My first version of the X-CPC used a 64KB IDT dual port RAM (84-pins plcc) to expect to not have data and address bus conflict as you describe and use the expansion RAM only on the CPU bus. But, I was not able to make it working properly and 2 weeks later the IC came obsolete and the price grown from 25€ to 60€, making the solution not viable so I have stopped to try into this direction around five years ago. Next I have tried some Z80 clones/evolutions that can be interfaced on a 4MHz bus but will internal PLL to have a fastest computing... Sadly, not all the instructions are available, making them unusable for the CPC usage.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Axel

Hey guys. 

Do you think there are still "undetected" tricks left to improve scrolling and sprites for better action-games on the CPC without Hardware-Expansions or is the "field grazed"?

TotO

Quote from: Axel on 11:10, 10 July 22Hey guys.

Do you think there are still "undetected" tricks left to improve scrolling and sprites for better action-games on the CPC without Hardware-Expansions or is the "field grazed"?
If you have read my first post. ;) (just try Alcon 2020)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Prodatron

Quote from: eto on 20:14, 09 July 22What about "internal" FAST-RAM that is not connected to the bus?

If we would have a Z80 compatible CPU, that can run at 8 or 16MHz or/and could execute commands much faster internally: if we now add the RAM directly to the CPU instead of to the normal bus and decouple the CPU and FAST-RAM from the internal bus, we could let it run at full speed as long as no access to the bus is required. As soon as we need to access the normal bus, we would slow down the clock to 4MHz and pass through the WAIT signal to the CPU. Of course screen updates would be slow but everything that is computed while accessing fast ram would be a lot faster.
This is probably similiar to how it is working on the Enterprise 64/128.
The first 64K ram are shared with the video chip, so the CPU is decelerated in this area, while it can run at full speed on any other part (>64K) of the RAM.
I think it is the same principle like the "chip ram" (can be accessed by any hardware) and the "fast ram" (can only be accessed by the CPU) of the Amiga.

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

eto

Quote from: Prodatron on 14:49, 10 July 22The first 64K ram are shared with the video chip, so the CPU is decelerated in this area, while it can run at full speed on any other part (>64K) of the RAM.
I think it is the same principle like the "chip ram" (can be accessed by any hardware) and the "fast ram" (can only be accessed by the CPU) of the Amiga.
Yes, I had in mind what I have seen on the Atari ST and the Amiga. Before this thread was started I didn't think about a similar concept being feasible on the CPC, but since except for the CPU nothing can access the additional ram banks anyway, if we move additional ram closer to the CPU without the gate array being involved, it could work like fast-ram on the Amiga.

But as long as there is no feasible (= fully compatible, existing and available) Z80 replacement, being it true hardware or even a simulated Z80, it's just a nice idea. 

revaldinho

Quote from: eto on 19:33, 10 July 22But as long as there is no feasible (= fully compatible, existing and available) Z80 replacement, being it true hardware or even a simulated Z80, it's just a nice idea.

There are FPGA cores which are suitable CPU replacements  - all of the CPC FPGA systems must have a compatible CPU model.

I have successfully run the T80 core included in this project as an in-socket replacement for the CPC's CPU. It booted and ran BASIC, and the Batman Forever and Phortem demos also ran fine. This would be a good place to start for a CPC accelerator.

TotO

Exactly. Because the CPC must use a NMOS Z80 CPU the only way to do a compatible accelerated system is to embbed a 100% compatible core into an FPGA with at less the Gate Array and 64K memory. So, all the technical aspects to handle the acceletated feature and remove the limitations are into the new circuit.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Well, to exchange to CPU by a better solution (even an quick FPGA, actually didn't Dr. Zed work on that?) is only thing.

But instead to exchange even more on the CPCs keyboard, imo it would be better to think about something like Tot0's X-CPC. 

But first steps first.  ;)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

GUNHED

A quicker CPC can be emulated on hardware level too. 
One great example is the upcoming XiAleste.
Another one is Tot0's X-CPC (any updates?)

An there can be this project here...

https://stardot.org.uk/forums/viewtopic.php?p=371537#p371537
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

TotO

The 3rd X-CPC version improve the CPU and display capabilities. Not in compatibility mode.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

Prodatron

Quote from: GUNHED on 13:27, 13 January 23A quicker CPC can be emulated on hardware level too.
One great example is the upcoming XiAleste.
Another one is Tot0's X-CPC (any updates?)

An there can be this project here...

https://stardot.org.uk/forums/viewtopic.php?p=371537#p371537
The CPC TREX already had a 12MHz mode:

https://www.youtube.com/watch?v=lUsDSNtRkTk
Shit, that's 17 years ago now :o

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

TotO

It doesn't looks to run at this clock speed.
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

GUNHED

Yes, the Trex was nice, but it can't be bought any longer. Same with C-One and others.

My hope are on Tot0's X-CPC and everything else we can see at the horizont.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Prodatron


GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

eto

Quote from: Prodatron on 02:24, 21 January 23Just FYI, another fast Z80 replacement:

https://www.msx.org/forum/msx-talk/hardware/mclz8-project-fast-z80-replacement
THIS is interesting. 

It offers ROM and RAM and e.g. while working only in ROM and expanded RAM, it could work full speed, which being cycle accurate, once it accesses the 64K core RAM or any other components. This could be fully compatible with existing software while new software could leverage the full speed mode (but would still work with normal CPCs, just slower). 

GUNHED

Yes, this is actually very interesting... need to have a closer look.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

WacKEDmaN

#45
Quote from: eto on 10:03, 21 January 23
Quote from: Prodatron on 02:24, 21 January 23Just FYI, another fast Z80 replacement:

https://www.msx.org/forum/msx-talk/hardware/mclz8-project-fast-z80-replacement
THIS is interesting.

It offers ROM and RAM and e.g. while working only in ROM and expanded RAM, it could work full speed, which being cycle accurate, once it accesses the 64K core RAM or any other components. This could be fully compatible with existing software while new software could leverage the full speed mode (but would still work with normal CPCs, just slower).
damn... i think that might just work... i mean if its working in nabu and trs-80 i dont see why it couldnt work as a drop in replacement for out CPCs...video memory maybe an issue still..but im sure the Teensy could be setup for the correct mode tho..

maybe the GA could even be emultated inside the Teensy!.. either as a replacement chip..or inside this z80 emulator...its all Arduino IDE code.. and nice at that!.. im thinking it could be ported to other mcus easily enough too..
https://github.com/MicroCoreLabs/Projects/blob/master/MCLZ8/Code/Standard_Z80/MCLZ8.ino

zhulien

Quote from: TotO on 17:21, 07 July 22No and no. :)

They do not support undocumented Z80 features.

I wonder... although it doesn't support z80 undocumented features (I guess that means instructions), perhaps a way to put both the z80 and similar CPU switchable in the machine and alternate ROMs could address this - or alternatively make a faster CPC which isn't 100% compatible, the current CPCs are all not 100% compatible with eachother anyway.

zhulien

#47
this thread is cool and I'd love to see the CPC accelerated. 

Thinking of some alternatives... we have for example CPLINK with Raspberry Pi - this could work running CPC stuff really fast emulated with HDMI out and a host of other benefits, utilising the CPC itself for the keyboard and perhaps floppy access - the CPC could be able to launch a program locally (with access to all local peripherals) or on the Pi (which simulated peripherals - or... indirect access to some CPC peripherals).  Sort of like a Vampire in an Amiga.  Or the Pi stuck directly to the bus which could remove the need for the CPLINK?

Such a solution could be extended to let us run NES, SNES and other arcade games on CPC too if those emulators had a way to redirect input from the CPC keyboard and/or joysticks.  Not exactly a CPC - but it will still *look* like one which is still cool.

Powered by SMFPacks Menu Editor Mod