Z80 to X80/R800 ?

[fano]

After an interesting thread about comparaison between various CPU (fr lang only : Meilleurs algo d'un test par bouding box), i was thinking about the gameboy CPU that is a custom Z80 (Sharp X80)
It owns some powerfull instructions (like post increment/decrement and zero page addressing) and i was wondering if it was possible to test it on a CPC.
The software part is not a problem for me but i am unable to find datasheet about this CPU , especially pinout, and if it is possible to source one.
Maybe someone here have an idea about this , thanks 

[TotO]

Yes. And the Gameboy Pocket offered the same as twice the clock speed.
But, understand that is not possible to exchange them easily...

GAMEBOY :



GAMEBOY POCKET:

[fano]

Thanks , i've a bit too fast 
Out opcodes have been removed for this CPU so there is no way to try this on a CPC 


But, everything is not lost , the MSX Turbo R CPU (Ascii R800) is too a Z80 clone and seems to be more compatible with vanilla Z80.Maybe , i may try to find some datasheet about this one so the question remains the same , but with R800 

[Bryce]

Here's a few tips that might help your search:

1 - The X80 was officially called the Sharp LR35902 - This might help with you datasheet search (although I don't think I've ever seen a datasheet for it either).

2 - This file will tell you everything you need to know about the op-codes it has / hasn't: http://marc.rawer.de/Gameboy/Docs/GBCPUman.pdf

3 - For any further information on the GB code / hardware, just do a search for "Jeff Frohwein", he is the king when it comes to GB info.

4 - Unfortunately the X80 didn't just have extra op-codes, it also deleted some, so even if you matched the pins to a 40 pin DIL socket, the CPC Firmware wouldn't work until you'd removed / replaced all the code the X80 doesn't understand.

Bryce.

Edit: The X80 pinout can be taken from this schematic: http://fms.komkon.org/GameBoy/Tech/SuperGameBoy.gif

[Badstarr]

If all the OpCodes are known why not create an FPGA emulation but keep all the compatible OpCodes in there too?

[The Last Bandit]

You could mess around witha Capcom Kabuki, its a 40 pin DIL Z80 clone running at MHz with some encryption features added.

[fano]

Thanks Bryce , sorry for asking too quickly, sadly x80 i/o instructions seems to have been stripped.
Another solution could be the R800 but i am afraid the CPC would not accept it as fetch cycle have been stripped (no more wait and refresh) and RAM or other components may be not able to support this.I have not a lot of illusions about this but i'd be curious to see if CPC hardware could be able to support it.This makes me dream as R800 is a super Z80 nearly binary compatible with vanilla Z80.1 byte instructions can be executed in 1 cycle, it owns a 16bits ALU that allows fast 16bits operations and have multiplication instructions.


About firmware , this is not a big problem as it is easy to run my own bootstrap instead of firmware to make tests.

If all the OpCodes are known why not create an FPGA emulation but keep all the compatible OpCodes in there too?

i am just a programmer , i may be able to learn FPGA programming but am far to be able to do electronic part stuff.I am very interested in FGPA/CPLD programming but i am not sure to have sufficient knowledge in electronics itself to interface it with a real machine.

You could mess around witha Capcom Kabuki, its a 40 pin DIL Z80 clone running at MHz with some encryption features added.

Sounds fun, but does theses extensions could be usefull ?

[Sykobee (Briggsy)]

If all the OpCodes are known why not create an FPGA emulation but keep all the compatible OpCodes in there too?

That depends on whether they re-used the opcodes they removed for the new instructions they added.


The R800 is an interesting chip indeed.

[Badstarr]

I suppose you could create within an FPGA, something to catch the OpCodes and translate them. Most likely far more time consuming than editing the firmware. I've tried a few things on my two FPGA dev boards but it's all new territory and things didn't really do what I thought they would do. Practice practice I suppose.

My main goal is (someday when I have the time) to make an FPGA based RAM and FDC upgrade. My thinking is basically you can get a FPGA dev board with enough IO and download the code to it and have an *almost*instant FDC and RAM addon. Sort of like a more straight forward DIY project for those not comfortable doing lots of soldering. I also like the idea that it should be possible to make an ASIC replacement too though it would involve some serious surgery to install it.

[fano]

I must say about FGPA, the most interesting thing would be to have a replacement board that cover CPU and GA sockets to replace them for faster classic programs and add new features for future games , but that's a dream a nice dream i make in my bed 
Instead of that , i am trying to find a way to get a bit of speed (overclocking Z80->fail overcloking full CPC->weirdo and incompatible)
Maybe , we'll never find , that's not a big problem , i'll still love my CPC 

[TFM]

After an interesting thread about comparaison between various CPU (fr lang only : Meilleurs algo d'un test par bouding box), i was thinking about the gameboy CPU that is a custom Z80 (Sharp X80)
It owns some powerfull instructions (like post increment/decrement and zero page addressing) and i was wondering if it was possible to test it on a CPC.
The software part is not a problem for me but i am unable to find datasheet about this CPU , especially pinout, and if it is possible to source one.
Maybe someone here have an idea about this , thanks 

IMHO that CPU suxxx, because it has no second register set. That would slow down my routines by 30-40%. 

[TFM]

Thanks , i've a bit too fast 
Out opcodes have been removed for this CPU so there is no way to try this on a CPC 


But, everything is not lost , the MSX Turbo R CPU (Ascii R800) is too a Z80 clone and seems to be more compatible with vanilla Z80.Maybe , i may try to find some datasheet about this one so the question remains the same , but with R800 

In this case I would suggest to switch either to the Z280 / Z380 or even better the eZ80 CPU. That would be really a gain. (HD64180 and Z180 lack IMHO important opcodes, so forget about them),

[fano]

We still need to investigate on this way but there is a little problem, we are not sure theses CPU could be accepted by CPC because of the GA arbitration scheme and if other circuits can support them.I'll take a look to datasheet.
We found a CPU 100% Z80 compatible (in binary and machine cycles) , it may give 20% extra speed in theory (as i understood the optimisation is made during instruction fetch) but we need to test it in real condition to be sure (again because GA arbitration)

[TFM]

There was a CPU replacement card for CP/M computers, it used the Z280 with own memory (fast) and accessed the remaining system at standard speed.


The 6 MHz patch speeds up the whole CPC by 50%.


(Also there is the HD64180 card for the CPC, but the used CPU is connected via expansion port, so not what you want).

[dragon]

A fpga z80 compatible with ez80 opcodes.

Projects :: OpenCores,y80e

[fano]

Thx Dragon , i am waiting account validating , i'll download this to take a look.After all maybe that could be solution to fork this to make an extended version of Z80 compatible with CPC.

The 6 MHz patch speeds up the whole CPC by 50%.

Yep, i already tried this (look at cpcwiki article) but it needs modifications inside CPC and the result is odd and not compatible.I tried to use overclocked Z80 using GA 16mhz clock and to divide it by 3 (CPC can not support faster) but the result is not so interesting.The Plus accepts 8mhz clocked Z80 but have stability problems.Finaly , overclocking CPU/system seems to not be the solution, that's why i am trying to find a compatible CPU (binary and cycle) with better performance at same frequency (and without CPC modification except removing Z80 and putting new on Z80 socket)
For sure , theses Z80 µcontrolers are very interesting as they own their internal ram that does not have the same constraints than CPC ram and are binary compatible with Z80.I am just afraid they can not be supported by CPC.


I think that could be interesting to understand how to get something compatible to have a diagram about various CPC signals like M1 /wait and so on in order to understand perfectly CPU/GA/RAM interaction.

[gerald]

I think that could be interesting to understand how to get something compatible to have a diagram about various CPC signals like M1 /wait and so on in order to understand perfectly CPU/GA/RAM interaction.

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).

[fano]

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).

A i understand (i am far to be a specialist so correct me if i'm wrong) , Z80 works on 4 (m1/io) or 3 clock cycles (memory) , the GA activates /wait on the third Z80 cycle (or close) to access on RAM so all machine cycles becomes 4 clock cycles.A replacement CPU needs to respect this scheme to avoid conflicts so there is no interest to overclock CPU or to get Z80 clone that have reduced cycles (like R800).I was wondering too what happens when Z80 have a M1 cycle that is more than 4 clock cycles.


A Z80 clone (Kawasaki KL5C8400) seems to use a workaround, it respects the original Z80 cycles (4/3) but reduces cycles need for longer instructions (like ADD HL,dd , INC dd etc)  with shorter M1 cycles.Sadly, it does not seem to theses have optimisation when branching fails (e.g JP cc,xxxx/JR cc,xx does not need memory reading when cc is not meet, just increment PC).


About RAM cache, there is already an existing solution for PCW, i'd be curious if this could be adapted to CPC with its memory banking scheme.

[arnoldemu]

What is stopping putting a faster CPU, linking up some way it can access the memory, but when a GA access comes along it respects it and halts?
The idea being it can fit more than 1 operation in the same time a standard z80 would, ga stays happy because it can continue to access at it's own pace?

I also think the idea of decoupling the reading of external ram/rom from the delay mechanism and giving fast rom/ram would be nice.

[arnoldemu]

I think that could be interesting to understand how to get something compatible to have a diagram about various CPC signals like M1 /wait and so on in order to understand perfectly CPU/GA/RAM interaction.

I would like to see these too.

[fano]

Yep, i think this is the key to understand exactly the memory arbitration behaviour and to add a CPU solution to speed up the CPC a bit (not only for new programs but for some CPC gems that would need a little speed boost to become amazing  )

What is stopping putting a faster CPU, linking up some way it can access the memory, but when a GA access comes along it respects it and halts?
The idea being it can fit more than 1 operation in the same time a standard z80 would, ga stays happy because it can continue to access at it's own pace?

As i understood , GA forces Z80 to add wait clock cycles (4mhz , not the GA 16mhz clock) at the end of CPU cycles (M1,read,write,ect...) to get a multiple of 4 clock cycles to stay synchrone as GA needs to read 2 bytes every 4 clock cycles to produce dislay (and to do the dram refresh too?).If CPU and GA are not synchrone , there is a risk of conflict.

An idea to get a bit of speed and remain compatible with CPC hardware could be to reduce needed cycles for complex instructions that fits on 1 byte (inc rr,add HL,xx,etc...) and remove uneeded memory read for some instructions (branching fail, ldir,etc...)
Kawasaki KL5C8400 takes partially this way , i think we'll make some test with this one to see if this is an interesting way.

[gerald]

As i understood , GA forces Z80 to add wait clock cycles (4mhz , not the GA 16mhz clock) at the end of CPU cycles (M1,read,write,ect...) to get a multiple of 4 clock cycles to stay synchrone as GA needs to read 2 bytes every 4 clock cycles to produce dislay (and to do the dram refresh too?).If CPU and GA are not synchrone , there is a risk of conflict.

The GA behaviour is fixed and does not care about what the Z80 is doing (read/write/M1/IO ...)
For GA cycle used to access DRAM, look there : CRTC help

An idea to get a bit of speed and remain compatible with CPC hardware could be to reduce needed cycles for complex instructions that fits on 1 byte (inc rr,add HL,xx,etc...) and remove uneeded memory read for some instructions (branching fail, ldir,etc...)
Kawasaki KL5C8400 takes partially this way , i think we'll make some test with this one to see if this is an interesting way.

The KL5C8400 looks interesting, but we may have to stick to Z80 compatible bus mode to support M2 interrupt mode and also ensure we do not try more than one access to RAM between two wait.

[fano]

Sure , that's because it owns a Z80 cycles mode i noticed this one.

Thanks , i missed this very interesting post, that explains the details i wasn't able to found.

]Basically, each microsecond is cut in three memory access.   One single access for the Z80. It takes 6 16MHz clock cycles, where the two first are with WAITn low.   Two paged access for the GA. It takes 10 16MHz clock cycle, all where WAITn is low.In all these accesses, CAS signal to the DRAM are toggled on either rising of falling edge of the 16MHz clock.Also, the Z80 RAM access is always initiated (RAS cycle), whatever the Z80 is doing : IO request or memory access, internal or external. It is only issued (CAS cycle) when a true access is done (ie base/internal expansion ram).

[TFM]

@Fano: You did overclock the Plus with 8 MHz? WoW. How did you do that? Did you exchange the crystal on board? How did it work?


Can you please tell details?

[fano]

nope, i just overclocked the Z80 , if my memory is good , i took 16mhz on SED pin (or somewhere there) and divided it by 2 (or maybe that was directly 8Mhz there, can not remember exactly)


Obviously , that didn't work correctly, CPC booted but that was very unstable.