... can this be the solution?
https://en.wikipedia.org/wiki/R800_(CPU)
It needs less cycles per opcode. So running at 4 MHz would be like running at 16 Mhz because all opcodes are done more quick.
But it needs to be soldered on a little PCB to replace the regular Z80.
Can it be done?
There are much faster Z80 processors which are still available new. Take a look at the Agon project: https://www.thebyteattic.com/p/agon.html
No and no. :)
They do not support undocumented Z80 features.
Quote from: GUNHED on 16:43, 06 July 22Can it be done?
Besides that I don't expect that you can buy the CPU, I doubt that the R800 could make use of its advantages in the CPC.
Although some commands maybe benefit from it, with the gate array activating the WAIT signal so much, I guess that most commands would still be stretched to the same length. The 4x faster would probably shrink to 1.2x faster or so.
Quote from: eto on 18:18, 07 July 22Although some commands maybe benefit from it, with the gate array activating the WAIT signal so much, I guess that most commands would still be stretched to the same length. The 4x faster would probably shrink to 1.2x faster or so.
Indeed. The limit in the CPC is mainly the RAM. Upgrade that to modern SRAM and you have a lot more potential for speed-ups.
The tick of the Z80 replacements is not to access the RAM more quick. They are more quick because their opcodes need less time. So a 2 us command will be done in 1 us for example.
The availability of undocumented opcodes is a valid point. However we would mostly need only the undocumented opcode, but not the illegal opcodes.
Undocumented opcodes are not documented (like LD A,Xlow or so)
Illegal opcodes are opcodes which have some kind of function, but by accident.
What we would need for the CPC is a small PCB bearing the faster Z80-replacement. So we can very easy switch the CPU. Maybe even by adding a switch to the computer. :)
Quote from: GUNHED on 10:29, 08 July 22The tick of the Z80 replacements is not to access the RAM more quick. They are more quick because their opcodes need less time. So a 2 us command will be done in 1 us for example.
If I understood correctly, this will not work in the CPC. I might be wrong, but this is my understanding of how this works:
Let's take LD a,(BC) as an example. This takes 7 T-states. For the Z80, the opcode will be read in the first 4 clock cycles, and then in the next 3 cycles it will read from (BC) and add it to A. In the CPC, the CPU will now wait for another clock cycle, as the gate array makes sure the CPU does not access the bus while gate array is using it.
Now I don't know exactly how many states LD a,(BC) will take on the R800, but the absolute best it can do is 2 T-states, as it still has to fetch the opcode and after that access the RAM. So let's use this.
If the R800 would be in a system without a gate array, you would be right, it would simply be faster. But not in the CPC:
The R800 reads the opcode during the first clock cycle, 4x faster than the Z80. But then it stops, as the gate array sets the CPU to wait. So for the next 3 cycles, although the CPU could do something, it has to wait until gate array has released WAIT.
Once this happens the R800 can perform the next part, read from RAM and add the value to A - again much faster than the Z80, in a single cycle - just to then again having to wait for another 3 cycles until the gate array is finished.
As a result, LD a,(BC) is exactly as fast as with a Z80: 8 clock cycles or 2us. The only difference is, that the Z80 is working during 7 clock cycles and waiting for one cycle. while the R800 is working during 2 cycles and waiting for 6 clock cycles.
Ok, the new CPU will in your example not need 7 T-states, it only needs 2 T-states. Round it up to 4 = 1 us. And there you go. :) (I don't know it the numbers are connect, but it shall serve as example). Instead of 2 us, it takes only 1 us.
The GA does align at 1 us boundaries, equals 4 T-States.
Well, yes. Only 2 times faster, but. YEAH!
I suspect you wouldn't get much of a speedup without redesigning how the gate array manages contention on the bus, but any speed increase you do get will likely break everything like tape loading etc.
Would be interesting to see if anyone fancies trying it out I guess though.
It's my understanding that you can't fetch the RAM while in wait. The R800 also has to fetch the opcode first, and then perform e.g. a RAM read.
What I really don't like is that people tell me what can't be done. :) :) :)
Let's focus on what CAN be done. ;D Well, and in this case all theory is grey, because obviously we start from different 'data' regarding CPU alternatives - just to say it friendly, because you're a great CPC user.
Whatever... Now it's really time to be be positive and give new ideas a try. :) :) :) :) :) :) :)
Quote from: GUNHED on 11:38, 08 July 22What I really don't like is that people tell me what can't be done. :) :) :)
But...
Quote from: GUNHED on 16:43, 06 July 22... can this be the solution?
Can it be done?
But I'll do as requested, will now sit back and watch the solutions popping up.
I'm not sure it's being "unfriendly" to the idea, more just an acceptance that the way the Gate Array is wired up pretty much precludes speeding up the processor by much. It might go a smidge faster in cases that are mostly register based, but even then there is a hard limit on how many read operations the Z80 can execute that will limit the rate of instruction fetches (and even Z80 block instructions require at least an instruction read per iteration).
Of course if you could replace the Gate Array with something that didn't need to stall the bus so often (perhaps something with it's own internal shadow of video RAM) then you could run the CPC faster even with a stock Z80. At which point putting in a faster CPU might well be viable...
Quote from: eto on 12:53, 08 July 22Quote from: GUNHED on 11:38, 08 July 22What I really don't like is that people tell me what can't be done. :) :) :)
But...
Quote from: GUNHED on 16:43, 06 July 22... can this be the solution?
Can it be done?
But I'll do as requested, will now sit back and watch the solutions popping up.
Like you? ;D :) :) :)
Quote from: andycadley on 13:51, 08 July 22I'm not sure it's being "unfriendly" to the idea, more just an acceptance that the way the Gate Array is wired up pretty much precludes speeding up the processor by much. It might go a smidge faster in cases that are mostly register based, but even then there is a hard limit on how many read operations the Z80 can execute that will limit the rate of instruction fetches (and even Z80 block instructions require at least an instruction read per iteration).
Of course if you could replace the Gate Array with something that didn't need to stall the bus so often (perhaps something with it's own internal shadow of video RAM) then you could run the CPC faster even with a stock Z80. At which point putting in a faster CPU might well be viable...
You got the point there. The solution would be to have fewer T-States in fewer us cycles.
Quote from: eto on 10:52, 08 July 22As a result, LD a,(BC) is exactly as fast as with a Z80: 8 clock cycles or 2us. The only difference is, that the Z80 is working during 7 clock cycles and waiting for one cycle. while the R800 is working during 2 cycles and waiting for 6 clock cycles.
You are correct.
In fact the CPU has access to a 1MHz RAM (as "the other 1MHz" of the total 2MHz is used by the gate array).
So if a command like LD A,(BC) or ADD (HL), which accesses a total of 2 bytes always will take 2us. It makes no difference how fast the CPU is working internally.
Most Z80 commands are limited by this RAM access, as they mostly do M1, RD or WR internally. All these M1,RD,WR will always take at least 1us, so a CPU, which is internally faster, won't be noticeable faster in the CPC environment.
There are a few exceptions like 16bit arithmetics (ADD HL,dd etc.) which are doing internal stuff, and these will be indeed 2-3 times faster with an R800.
Other commands like LD r,(IX+n) will be a little bit faster, but not so much.
So as long as you have this limited RAM speed in the CPC a faster CPU won't help that much.
The MSX TurboR, which is using the R800 CPU, has a much faster internal RAM, so it can use its full power and behave like a 28MHz Z80 (as it is running at 7MHz). That is also the reason, why they always try to use the internal RAM, no external memory expansions on the TurboR - the expansion bus still uses the normal clock - as that would slow down the CPU again.
Quote from: Prodatron on 09:56, 09 July 22There are a few exceptions like 16bit arithmetics (ADD HL,dd etc.) which are doing internal stuff, and these will be indeed 2-3 times faster with an R800.
Other commands like LD r,(IX+n) will be a little bit faster, but not so much.
Right, that's how I came to my initial guess, that we could maybe see an increase of 20%. With the additional information now, I guess it's with normal, unoptimised use cases even less. On the Atari ST we have a very similar situation where pure CPU upgrades do not help much. Even a 32MHZ CPU will just give you 10-20% advantage over a 8MHz CPU as long as no cache or fast-ram/rom is used.
Quick question: Could a dk'tronics compatible RAM extension be possible, that is just directly hooked to the CPU and not to the normal bus? As only CPU can access it anyway, might this be an option to implement fast ram? If yes, a much faster Z80 version combined with fast ram might work. As long as the CPU is accessing the additional RAM only it would not have to wait for the gate array. This could also be decoupled from the bus, so the gate array can work on the normal RAM. As soon as the CPU requires access to standard RAM, it will slow down to normal speed, as it has to sync with the wait signal, so e.g. screen updates will not benefit, but all computations in the background could. On the ST this allowed to roughly double the perceived speed, even in games that could benefit from it (Elite 2 frontier with a 28MHZ CPU inc. cache was about twice as fast).
It is a recurrent question on cpcwiki.
The best answer is to make faster programs. ;D
When the Z80 use an external RAM expansion, there is no bus arbitrer to allow to be faster.
Anyway, you will always require to write the video RAM to display something.
No way to make old games running faster w/o patching or reprogram them. But there are many way to make the CPC usage faster by using ROM or mass storage instead of tape or floppy disk.
Quote from: GUNHED on 11:38, 08 July 22What I really don't like is that people tell me what can't be done. :) :) :)
Well, it's not so much that it can't be done. It's just that you'd need to replace the processor, RAM and gate array. And by that point it would be easier to draw up an entirely new motherboard.
BTW if you cache video RAM in the gate array, as somebody suggested, then all you need is: processor, gate array, SRAM (single chip), ROM, AY and some glue logic. Which feels like a pretty simple machine.
But I feel as though the real question is how much software would actually benefit from a faster machine? Productivity software of course, but most game are glued to the frame flyback and won't notice any affect.
IMHO it would be enough to replace the Z80 (which is in a socket anyway).
A CPC can be run with 6 MHz (replace 16 Mhz crystal by a 24 Mhz one). But that's of course a different topic (somewhere in this forum)
If a Z80 replacement let say... uses 3 cycles for an opcode the new Z80 replacements only need 2 or one. That's the way to save time, because there's no need to alter anything else than the CPU. An example command could be ADD HL,BC.
Any kind of software would benefit. And games scrolling could be more smooth.
As PDT told, "It won't help that much". However, it would be of great interest to try it out and see what we get from it. Since only the CPU get's replaced it would harm anything.
Fascinating how one can fail to grasp what others explain to them at length and come back to some utterly marginal aspect just to circumvent accepting that someones "idea" was something better be kept to oneself :laugh:
Peoples wanting a CPC 4x faster with 16 colours MODE 1, have bought an Atari ST. :D
Never ever. ;D
I'd say, try it and see what happens.
Worst case scenario, you get little to no improvement. Best case scenario, you'll be getting some noticeable improvement.
Quote from: TotO on 11:19, 09 July 22When the Z80 use an external RAM expansion, there is no bus arbitrer to allow to be faster.
Anyway, you will always require to write the video RAM to display something.
What 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. A "Super Z80" similar to the R800 could run at e.g. 16Mhz and execute most M-cycles in just a single clock cycle.
Maybe even a compatibility mode could be implemented, so that the "Super Z80" always behaves like a normal Z80.
I know that this is still not easy to do and there is no such "Super Z80", and it's still the question if anybody wants that, but just from a general perspective, would that potentially work? Or am I missing something in that logic?
Here a quick diagram, what I mean, of course probably lacking lots of details...Screenshot 2022-07-09 at 20.50.37.jpg
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.
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.
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
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.
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.
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"?
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)
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.
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.
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 (https://github.com/hoglet67/AtomBusMon) 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.
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.
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. ;)
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
The 3rd X-CPC version improve the CPU and display capabilities. Not in compatibility mode.
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
It doesn't looks to run at this clock speed.
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.
Just FYI, another fast Z80 replacement:
https://www.msx.org/forum/msx-talk/hardware/mclz8-project-fast-z80-replacement
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).
Yes, this is actually very interesting... need to have a closer look.
Quote from: eto on 10:03, 21 January 23Quote 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
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.
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.
There are further updates to this project it seems.
https://www.msx.org/forum/msx-talk/hardware/mclz8-project-fast-z80-replacement?page=0
Does anyone know what the fastest Z80 currently on sale is?
20Mhz. !!! 5 Times faster.
II'm currently designing an extension for the 6128 in the onebyte cache for write concept.
Quote from: McArti0 on 19:15, 15 April 24Does anyone know what the fastest Z80 currently on sale is?
20Mhz. !!! 5 Times faster.
II'm currently designing an extension for the 6128 in the onebyte cache for write concept.
The eZ80 runs at 50MHz, but the architecture has been optimised, so compared to a standard Z80 it would be equivalent a Z80 at 150MHz.
Bryce.
Quote from: Bryce on 08:43, 17 April 24eZ80 runs at 50MHz,
Bryce.
But.
Z84C0020PEG is real Zilog, pinout compatibility and protocol. I think it is a good replacement even just for reducing the power supply.
Building an Amstrad with an eZ80 would be fun. A couple of challenges with it though:
* The on device hardware uses I/O addresses starting at $80 (the high byte is ignored). You might have to patch software to avoid those addresses. Most software probably loads those bits high, which would be safe, but writes to the gate array have the register data on those bits. Register 2 could be problematic here. Although I think just setting bit 5 high should solve any issues.
* The eZ80 has no memory manager on board. That means you'll need to use external RAM and ROM. At 50MHz the clock cycle time is 20ns[0]. The fastest parallel RAM chips available appear to be about 10ns. The fastest ROMs about 55ns. Once you add in gate delays for whatever you're using for the memory manager (CPLD, FPGA) you're unlikely to be able to run at full 50MHz clock speed even reading from RAM.
But those issues aside, it's certainly do-able and, as I said, would be fun <g>.
A 20MHz Z80 on the other hand would be far easier. You'll need to replace the DRAM with faster modern SRAM and rejig the gate array timings. But neither of those overly complicated.
- I'm assuming here that the read cycle is a single clock cycle. It certainly is for internal memory. Either way you'll need that single cycle read for the best performance.
Just curious, the Terasic T-Rex can run the CPC at 24Mhz and it seems pretty reliable - I know it's an FPGA core, but from a timing point of view in relation to a real CPC, timing seems to always come up as an issue - what exactly are the parts of the real CPC that the timings have issues with and which can be overcome on real hardware somehow - i.e. raster RAM chips? faster ROM chip? (I'm guessing)... and why don't such FPGA cores have timing issues even if internally?
Quote from: zhulien on 11:23, 17 April 24what exactly are the parts of the real CPC that the timings have issues with and which can be overcome on real hardware somehow - i.e. raster RAM chips? faster ROM chip? (I'm guessing)
1us Divided into z80 1/4 time GA 3/4 time to read 2 bytes. A simple speed 2x increase results in too much data to display. Either 100Hz frame and 600Hz interrupt, or change GA to only download 1byte for 1 nop. ROM you can replace FRAM.
Quote from: McArti0 on 12:36, 17 April 24Quote from: zhulien on 11:23, 17 April 24what exactly are the parts of the real CPC that the timings have issues with and which can be overcome on real hardware somehow - i.e. raster RAM chips? faster ROM chip? (I'm guessing)
1us Divided into z80 1/4 time GA 3/4 time to read 2 bytes. A simple speed 2x increase results in too much data to display. Either 100Hz frame and 600Hz interrupt, or change GA to only download 1byte for 1 nop. ROM you can replace FRAM.
Does that mean if a replacement GA was made with a microcontroller then that could fix the timing issues with the GA?
YES. New CPC with new GA sponsored by microcontroller
Quote from: zhulien on 13:48, 17 April 24Quote from: McArti0 on 12:36, 17 April 24Quote from: zhulien on 11:23, 17 April 24what exactly are the parts of the real CPC that the timings have issues with and which can be overcome on real hardware somehow - i.e. raster RAM chips? faster ROM chip? (I'm guessing)
1us Divided into z80 1/4 time GA 3/4 time to read 2 bytes. A simple speed 2x increase results in too much data to display. Either 100Hz frame and 600Hz interrupt, or change GA to only download 1byte for 1 nop. ROM you can replace FRAM.
Does that mean if a replacement GA was made with a microcontroller then that could fix the timing issues with the GA?
Well if you change the CPU, change the Gate Array, possibly change the RAM speed, possibly change the motherboard because various electrical interference issues might arise at higher speeds then yes, you could theoretically run a faster CPC.
Quote from: McArti0 on 15:05, 17 April 24YES. New CPC with new GA sponsored by microcontroller
Is it not easily possible with existing cpc and new GA?
You answered this question while I was typing it
Quote from: andycadley on 15:17, 17 April 24Well if you change the CPU, change the Gate Array, possibly change the RAM speed, possibly change the motherboard because various electrical interference issues might arise at higher speeds then yes
Or maybe we can do it with FPGA? ;)
OK, the T-Rex is ready. 8)
Quote from: McArti0 on 16:52, 17 April 24Or maybe we can do it with FPGA? ;)
OK, the T-Rex is ready. 8)
I just recognized that I still have the T-REX Quartus Snapshot by Tobiflex here on the site:
http://www.symbos.org/download/cpctrex-quartussnapshot10.zip
Feel free to use it, it's only 18 years ago :D (I have no idea about this VHDL and whatever stuff at all)
eZ80 does not support forbidden commands, so it will hang in CPC. R800 would be better. But overclocking the clock is asking for trouble. Image out of sync, FDD is physically spinning too slowly, etc.
Quote from: McArti0 on 16:52, 17 April 24Quote from: andycadley on 15:17, 17 April 24Well if you change the CPU, change the Gate Array, possibly change the RAM speed, possibly change the motherboard because various electrical interference issues might arise at higher speeds then yes
Or maybe we can do it with FPGA? ;)
OK, the T-Rex is ready. 8)
Well yes, if you just build a "CPC on a chip" inside an FPGA that will also work,but it isn't really "upgrading a real CPC" at that point, is it?
The moment real, 1980s hardware is involved, you have to start considering the actual physical limitations of what already exists. It may just not be possible to run something faster without actually redesigning everything.
It's interesting that this was different for several system:
- CPC: In general it's impossible to increase the clockrate; RAM is 2MHz, so because of the video it limits the Z80 to 1MHz memory access; everything else is connected to the same clock inside the CPC as well
- MSX: Why not? :) Until today you can double the clockrate from 3,57 to 7,1 MHz with a standard set of parts, which you can still buy
- Enterprise 64/128: You can even choose between original 4,6,8 or 10MHz Z80 speed; works great!
- C64: You could attach a CMD SuperCPU (MOS 65816) running at 20MHz with own memory; yes, not a C64 anymore, turning the original hardware into a zombie system, but some people liked it
I think the MSX and Enterprise designs put more effort into decoupling the hardware from the CPU. It had the advantage of making it easier to swap out components and change the performance of various bits without causing as much hassle. The downside is that it's harder to exploit the raw performance of the system because you can't really "hit the metal" in quite the same way (or if you do compatibility strikes hard).
The C64 wasn't really like that but the SuperCPU is a weird beast that treats the host machine more like a kind of slave - a bit like Tube processors on the BBC. You could probably do something like that on a CPC, run everything externally and use the "Z80" cycle to allow the external system to write to video RAM but it would feel like a very different kind of machine.
TThe vampire method for cpc should be possible which is likely somewhat similar for the turbo chameleon right? That is put another cpu in it (fpga or not) and use whatever cpc hardware can be used. Cpm could be patched to run really fast, basic perhaps to a degree but most other software wouldn't benefit. The turbo chameleon and vampire seem to further to emulate almost the entire system, like putting a trex into a cpc and running the software on the trex but with some type of trex to floppy layer and keyboard layer.
If you insert 41256-60/70ns, you could reduce the screen data reading time from 3/4 us to 1/4 us or 3/16 us. Then you could read the screen data every 4 cycles with a clock of 16Mhz .
Quote from: McArti0 on 09:34, 18 April 24If you insert 41256-60/70ns, you could reduce the screen data reading time from 3/4 us to 1/4 us or 3/16 us. Then you could read the screen data every 4 cycles with a clock of 16Mhz .
Theoretically, maybe. But you're making the classic mistake that people who focus on the digital aspect always make: you're ignoring the analogue aspects.
There always well be numerous other issues that need resolving as you increase speeds. The bus was designed to tolerate the speeds it was intended to run at, capacitors were chosen for various points of the board because they feel within required tolerances etc. It doesn't necessarily follow that just putting in faster digital components that all the rest of the circuitry will just work (and even less that it will work reliably).
When I made an ISA 8MHz card with 8255, ADC and etc., I ignored the capacitors and it worked. ;D
You can bargain down to 12MHz or even 8MHz. :P
I think SymbOS would be happy. ;)
Has anyone actually tried massively overlooking the cpc. I am thinking the most compatible solution would be some type of cpu accelerator inside the cpu socket with its own ram and potentially its own alternative bus and the ability to programmatically switch between standard cpc mode/ram/speed and its own, but... even in thinking along this method, I think the cplink card is currently the best option. It allows you to run stuff on the pi, subroutines and use the pi hardware indirectly. Absolutely not a lot of software yet that uses it, but I am having fun with it.
And MiSTeR is not a ready-made product?
IMHO a hardware-clone/CPCnext/ ... should at least provide the 50 pin expansion port or (maybe even better) some MX4 slots for expansions with MX4 plug.
BTW: I have a CPC6128 running at 6 MHz stable. Just replaced the 16 MHz crystal by a 24 MHz one.
Quote from: GUNHED on 18:07, 18 April 24I have a CPC6128 running at 6 MHz stable.
what RAM do you have 150ns?, mux LS153? what CRTC, what 8255.
Take a photo of the mainboard that RUN.
and check the temperature of all chips, especially 765
It might be possible to replace the Z80 by a Raspberry Pico (or better RP2040) based Z80 implementation. This could have several speed modes which make sure, the CPC stays fully compatible.
1) By default, just a Z80 replacement with 4Mhz. Pico internal RAM acts as 128 or maybe even 256 K RAM expansion, depending on how much RAM is needed for the Z80 simulation
2) Full speed mode - maybe similar to a R800 CPU - all CPU internal operations finish within 1 CPU cycle - and while only Pico internal RAM expansion is accessed it can even execute a command per clock cycle (or how fast the Pico can handle it)
3) Fast (compatible) mode - CPU works like a normal Z80 when accessing base RAM but works full speed, when accessing the Pico internal enhanced RAM
Mode 1 will ensure 100% compatibility
Mode 2 will probably require new software or adapting existing software
Mode 3 might work with many existing applications that use the enhanced RAM (CP/M plus?)
on top of it, it could implement something like the Blitter in the Atari ST which can copy data from/to RAM with maximum speed, e.g. Sprites data in enhanced RAM is copied directly to screen RAM - RAM address calculation is done by the "Blitter"
Quote from: GUNHED on 18:07, 18 April 24BTW: I have a CPC6128 running at 6 MHz stable. Just replaced the 16 MHz crystal by a 24 MHz one.
Yes, your old story.
But "stable" is a very relative description.
It is useless/not compatible regarding video, FDC and probably more.
Unfortunately I forgot it, but what was the CPC meeting, where you presented this 6MHz machine to the public?
The SuperZ80 expansion card, disabling the internal Z80, writing speed to internal RAM 20kB per frame 1us per byte.
SuperCPU could have a larger than I design (one address, one byte =24 bit) write buffer to CPC RAM. Each write to the buffer is fast. Wait states appear when the buffer does not have time to empty. When buffer is full during nCPU is Hi, SuperZ80 can execute several non-write instructions or wait for write byte to buffer.
I was also thinking about a 9-bit clone ROM, which it would download while executing the code and write the 9th bit that this byte is already cached inside.
Quote from: Prodatron on 20:32, 18 April 24regarding video, FDC and probably more.
VGA monitor welcomes this with open arms.
Does Gotek also have a problem?
Quote from: McArti0 on 20:42, 18 April 24Quote from: Prodatron on 20:32, 18 April 24regarding video, FDC and probably more.
VGA monitor welcomes this with open arms.
Does Gotek also have a problem?
The Gotek would have to listen to a 1,5times faster FDC. All sectors will have a 1,5times higher density, which was the problem of a 6MHz CPC. Because of this you werent' able to exchange discs between a 4 and a 6MHz CPC. A 6MHz CPC could save about 6,7KB/track instead of 4,5KB.
Quote from: Prodatron on 20:47, 18 April 24The Gotek would have to listen to a 1,5times faster FDC
and all disk drives are equally fast? 3,5" too?
Quote from: Prodatron on 20:32, 18 April 24Quote from: GUNHED on 18:07, 18 April 24BTW: I have a CPC6128 running at 6 MHz stable. Just replaced the 16 MHz crystal by a 24 MHz one.
Yes, your old story.
But "stable" is a very relative description.
It is useless/not compatible regarding video, FDC and probably more.
Unfortunately I forgot it, but what was the CPC meeting, where you presented this 6MHz machine to the public?
Yeah, and now that's your old story too. Like usually you want to tell people what's 'useless' for them. But what you mean is just, that something is useless for you / SymbOS. Try to be a bit less Narciss. ;) Come on, allow us to live our CPC hobby our way! :) :) :)
BTW: IIRC the meeting was either one of the CPC-Only meetings or some XzentriX, but it's something like 18-21 years ago. And the CPC still runs like a charm. I love the enhances = horizontally squeezed screen and also to be able to put 50% more data on an disc. :)
Anything else... It's 3 the morning. Read you later the day...
Quote from: GUNHED on 02:15, 19 April 24And the CPC still runs like a charm.
Have you ever tried to speed up the motor that spins a floppy disk? Is this controlled by the device software?
Quote from: GUNHED on 02:15, 19 April 24and also to be able to put 50% more data on an disc.
Ho wdo you exchange data with this CPC? Are other expansions compatible and can be used, like the M4 or Symbiface?
Quote from: McArti0 on 06:40, 19 April 24Quote from: GUNHED on 02:15, 19 April 24And the CPC still runs like a charm.
Have you ever tried to speed up the motor that spins a floppy disk? Is this controlled by the device software?
No, and I wouldn't know how to do this actually. In case of the 6 MHz CPC the FDC just writes/reads with 50% more speed. So up to nearly 300 KB can be put on one disc side. And for 80 track (ds) formats up to roughly 1,2 MB can be stored on disc.
Not all the discs work that way error free, but most of them. Just tested a 3" disc from 1997 which still contains the same data error-free since 27 years. (Written with the 6 MHz CPC). :)
Quote from: eto on 10:38, 19 April 24Quote from: GUNHED on 02:15, 19 April 24and also to be able to put 50% more data on an disc.
Ho wdo you exchange data with this CPC? Are other expansions compatible and can be used, like the M4 or Symbiface?
My preferred way to exchange data back the day was to use the Inicron RAM expansion (accu buffered) and the RDOS ROM to have the 444 KB RAM disc C. Today I would probably use a serial connection of SD card.
I tested quite some hardware expansions: Some work, few not.
(And for very few expansions you probably need to adjust software a bit.)
I wonder how much 50% more Sectors per track is compared to 9 :P
Quote from: McArti0 on 15:03, 19 April 24I wonder how much 50% more Sectors per track is compared to 9 :P
Well, the FDC765 supports different sector sizes. According to the maxium number of bytes per track it may be befeficial to use 0.5, 1.0 or even 2 KB sectors. 8)
Quote from: McArti0 on 18:40, 18 April 24what RAM do you have 150ns?, mux LS153? what CRTC, what 8255.
Take a photo of the mainboard that RUN.
and check the temperature of all chips, especially 765
Say something about the components or take a photo. And confirm that gotek does not work.
Quote from: GUNHED on 02:15, 19 April 24also to be able to put 50% more data on an disc.
but that then also requires AMSDOS to use more sectors per track, right? What settings do you use then, that it can write a full track?
Quote from: McArti0 on 15:10, 19 April 24Quote from: McArti0 on 18:40, 18 April 24what RAM do you have 150ns?, mux LS153? what CRTC, what 8255.
Take a photo of the mainboard that RUN.
and check the temperature of all chips, especially 765
Say something about the components or take a photo. And confirm that gotek does not work.
As told, just the crystal got exchanged (in my case I added a 2nd one at 24 MHz and a switch to be able to switch crystals - Switching shall happen ONLY when the CPC is OFF!).
Anything else remains the same. No heat, no problems - it's a CPC not a stupid PC thanks god! :) :) :)
Well, yes, I put a Z80B instead of the Z80A. RAM works fine anyway.
The critical component it the GA. Seems that other 6 MHz CPCs had problems with some GAs.
Quote from: eto on 15:27, 19 April 24Quote from: GUNHED on 02:15, 19 April 24also to be able to put 50% more data on an disc.
but that then also requires AMSDOS to use more sectors per track, right? What settings do you use then, that it can write a full track?
No, other DOS or OS can be used. (Of course using the native software will not change a thing to the better.) :) :) :)
If you want to stay with the native OS then I would suggest to use ParaDOS and change format parameters in that.
Also CP/M allows to adapt disc formats in an easy way.
Quote from: GUNHED on 15:30, 19 April 24As told, just the crystal got exchanged
what original components do you have? RAM 200ns, 150, 120? what crtc, what 8255.?
Just found out about this https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf (https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf) today .. Zilog is retiring the Z80 after 48 years.. so if you wanna make that Amstrad CPC accelerator, better get on with it pronto :D
6mhz is better than 4mhz, but it only makes sense as a $20 upgrade of changing the cpu. Ideally something faster. I know other ways that can be done but to be true to the hardware I am not sure...
Another way could be to actually run a cpc emulator in the Pi side that communicates with the cpc for certain services like real floppy access and keyboard or perhaps some I/O... but then its just a more cool way of running an emulator rather than really a faster cpc.
I'm not abandoning CPLink as I really think it has some great potential and besides the M4 card I think everyone should have one.
Quote from: GUNHED on 15:33, 19 April 24If you want to stay with the native OS then I would suggest to use ParaDOS and change format parameters in that.
Also CP/M allows to adapt disc formats in an easy way.
okay... will try. What parameters do you use for Parados to get the floppy properly filled?
How do you start CP/M? The system disk obviously won't be able to boot.
Quote from: eto on 14:14, 20 April 24Quote from: GUNHED on 15:33, 19 April 24If you want to stay with the native OS then I would suggest to use ParaDOS and change format parameters in that.
Also CP/M allows to adapt disc formats in an easy way.
okay... will try. What parameters do you use for Parados to get the floppy properly filled?
How do you start CP/M? The system disk obviously won't be able to boot.
Sorry, I use another OS most of the time. For CP/M: Copy tracks, store content on RAM disc, switch to 6 MHz (CPC off/6 MHz crystal active/CPC on), finally copy data back to tracks.
Quote from: McArti0 on 18:00, 19 April 24Quote from: GUNHED on 15:30, 19 April 24As told, just the crystal got exchanged
what original components do you have? RAM 200ns, 150, 120? what crtc, what 8255.?
Doesn't matter, the GA is the critical component. (Z80 in 6 MHz of course!).
Quote from: GUNHED on 20:55, 21 April 24ry, I use another OS most of the time. For CP/M: Copy tracks, store content on RAM disc, switch to 6 MHz (CPC off/6 MHz crystal active/CPC on), finally copy data back to tracks.
I think we should update the Wiki article with all the relevant aspects.
At the current level of documentation, anyone who tries it will end up with a machine that is fast but can't access any software. And the way to make software work on it requires not only additional, special hardware - it also requires specific knowledge about stuff like running CP/M from ROM, copying data to a battery backed up RAM disk and figuring out the drive parameters in CP/M and PARADOS.
Does Dandanator work at 6MHz?
Ps. DDI 5?
Give it a try. In any case it's needed to update come CRTC registers before usage. Or use a multiscan monitor.