After an interesting thread about comparaison between various CPU (fr lang only : Meilleurs algo d'un test par bouding box (http://www.gamopat-forum.com/t66305-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 :-*
Yes. And the Gameboy Pocket offered the same as twice the clock speed.
But, understand that is not possible to exchange them easily... ;)
GAMEBOY :
(http://www.z80.info/gfx/z80gb.jpg)
GAMEBOY POCKET:
(http://www.chipdb.org/data/media/1212/DSCF0607.jpg)
Thanks , i've a bit too fast ;D
Out opcodes have been removed for this CPU so there is no way to try this on a CPC :-X
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 :laugh:
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 (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 (http://fms.komkon.org/GameBoy/Tech/SuperGameBoy.gif)
If all the OpCodes are known why not create an FPGA emulation but keep all the compatible OpCodes in there too?
You could mess around witha Capcom Kabuki, its a 40 pin DIL Z80 clone running at MHz with some encryption features added.
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.
Quote from: Badstarr on 11:18, 04 February 14
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.
Quote from: The Last Bandit on 11:44, 04 February 14
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 ?
Quote from: Badstarr on 11:18, 04 February 14
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.
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.
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 :laugh:
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 :-*
Quote from: fano on 10:08, 04 February 14
After an interesting thread about comparaison between various CPU (fr lang only : Meilleurs algo d'un test par bouding box (http://www.gamopat-forum.com/t66305-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%. :(
Quote from: fano on 10:29, 04 February 14
Thanks , i've a bit too fast ;D
Out opcodes have been removed for this CPU so there is no way to try this on a CPC :-X
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 :laugh:
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),
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)
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).
A fpga z80 compatible with ez80 opcodes.
Projects :: OpenCores (http://opencores.org/project),y80e
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.
Quote from: TFM on 02:17, 05 February 14The 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.
Quote from: fano on 08:27, 05 February 14
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).
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).
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.
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.
Quote from: fano on 08:27, 05 February 14
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.
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 ;D )
Quote from: arnoldemu on 10:33, 05 February 14
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.
Quote from: fano on 10:51, 05 February 14
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 (http://www.cpcwiki.eu/forum/programming/crtc-help/msg69368/#msg69368)
Quote from: fano on 10:51, 05 February 14
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.
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.
Quote from: gerald on 11:47, 05 February 14]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).
@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?
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.
Did you replace the Z80A by the Z80H?
Used a Z84C0008PEC :)
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://www.msx.org/forum/msx-talk/hardware/7-mhz-kit?page=0)
http://msx.hansotten.com/index.php?page=clock-upgrades (http://msx.hansotten.com/index.php?page=clock-upgrades)
QuoteMSX1 at 7 Mhz
wasn't it called the TurboR ?
:laugh:
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 ;)
Nope as well...
True MSX3 is MSX 2+... TurboR is more like MSX4.
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.
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).
If they said, with exclusive Shenmue 3... It was a legend. ;D
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...
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?
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.
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).
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 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/rom-board-with-a-tiny-dma-engine/?action=dlattach;attach=21540;image) 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.
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 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/rom-board-with-a-tiny-dma-engine/?action=dlattach;attach=21540;image) 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.
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]
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?
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.
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.
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
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.