Does CPC use the R-efresh Z80A register?

[McArti0]

You can also check the schematics to see that the RFSH line of the CPU is not used anywhere in the CPC (except for the expansion bus).

Our memory not need RFSH line because they are "RAS-only" refresh. They only need ROW ADDRESS and RAS edge. thats all.

[McArti0]

So if you are running aloop over a few bytes (lets say 10) you will already hit 10 rows in the CPC. If your loop is running over 127 bytes - you probably hit all rows.

I took care of that. the loop is tight. Moreover, it is not 127 bytes but 256+126 because CPC has addresses connected to ROW A0-A6 in the order A2, A1, A4, A3, A6, A5, A8. Without A0 and A7, there is A8.

Refreshing works for me at R6=0. So what's wrong?

[Bryce]

ETO win this competition. Do not get excited. Write next post tomorrow ok?

Winner text:

Quote from: eto on 12.03.2024, 16:39:51
If you now turn off the GateArray access it doesn't necessarily mean that the RAM will no longer be refreshed as also CPU access to the RAM will also refresh the RAM. Again as long as the CPU reads from 128 continuous addresses (within the refresh period of 2ms) all RAM rows will be accessed - and refreshed. If I am not mistaken this does even work if the CPU reads from ROM as the address will be put on the RAM IC address pins during the RAS sequence - just the CAS is not executed - but that doesn't matter as only RAS is required to do the RAM refresh.

So what you are actually saying is that your aim, right from the start, was to ignore all the evidence presented before you by multiple people and documented in books until you found someone who vaguely confirmed your incorrect initial assumptions? You have a great future in politics ahead of you!

So now explain to us all what R157 and R158 are there for?

Bryce.

[andycadley]

One thing I've often wondered but not entirely understood is this comment in the Arnold V documentation about the screen spli:

Note that care should be taken with programming this facility such that the screen split does not alter the function of address bits A1-A8 and the dynamic memory refresh is not upset.

Has anyone got an example of what you could do that would cause this issue? Or maybe @McArti0 can explain why it doesn't matter if the Z80 refresh mechanism is used.

[McArti0]

I have code that returns even though CRTC is disabled and does not produce artifacts.
I showed code that produces artifacts when avoiding R increment.
I don't know what r157,158 are for, CPC also works without them.

[eto]

I hope I (at least vaguely) disproved the initial assumption...

That this was seen as proof/confirmation is quite surprising to me.

[SerErris]

Ah no, the 0 byte does not count 

[McArti0]

And yet it doesn't work. I thought I had an ace up my sleeve and I didn't. 

When i set R6=0, screen has one scan line and refresh something.

[SerErris]

You can also check the schematics to see that the RFSH line of the CPU is not used anywhere in the CPC (except for the expansion bus).

Our memory not need RFSH line because they are "RAS-only" refresh. They only need ROW ADDRESS and RAS edge. thats all.

Yes, but the CPU cannot strobe RAS. The GateArray does. And the GA does it based on /RD and /MREQ or on its own reads. /RFSH has no impact - is not connected to the GateArray and to anything else inside the CPC.

/RD is disabled during /RFSH.

you can see it in the timing diagram of the CPU but as well as the real operation of the gatearray:
You cannot view this attachment.

The blue part is where the gatearray is accessing the RAM, and where it is actually reading the screen data.

You can see the following: GA sets RAS (one time) and then two times CAS. The reason for that is, that the CRTC has generated two addresses and only the lowest bit, so the next byte in RAM from the same column is retrieved. That is one of the features of the RAM, that it can burst read. So you only need to have a single RAS and can then read up to 512 bytes (256 bytes depending on the memory). This is unused in CPC other for the aspect of the Gatearray reading screen data.

You can also see NRD high (not active) at the same time - that is the CPU signal to read stuff which active low. So in this particular section it is not active or disabled.
What you also can see is that during the blue time, the NMREQ is going down (active). That is the actual time when the CPU wants to refresh. NRFSH is not captured  unfortunately, but would be active at the same time, as you can see in the CPU documentation.
So the logic is actually RD and MREQ active = RAS/CAS. But only if that is coming in in a specific time window (Sequencer).

But here, we actually do not have RD and MREQ active, but only MREQ, so it is getting ignrored by the GateArray.

So all in all, there is no technical way for the CPC to use the RFSH Line of the CPU and even the normal RD and MREQ lines are not directly connected to the RAM, but instead to the GateArray. And it will not use it to create the RAS signal here.

Your conclusion out of what you overserve, is just not correct and you need to alter the conclusion.

[McArti0]

Here there is no M1 cycle, then the nCPU comes first and then refresh at the same time as the screen reading. Classic NOP. but of course the Z80 refresh is a competitor to reading RAM for the screen

[SerErris]

NCPU_ADDR is high - means it is not active (active low signal). Which means during the blue part, the CPU cannot access the ram, however during the red part it can access the RAM. 

More technically it means, during NCPU_ADDR active (low) the address lines of the CPU are multiplexed to the RAM  (ram) and all other times the CRTC address lines are connected to RAM.

The CPU can only read or write during the short period of time when the gate array puts NCPU_ADDR low. Which starts at second half of the image and ends 3/4 to the right of the image.

The Gatearray actually need to force the CPU to be in that slot, so that it does not write to the RAM (e.g. wants to write), but the address lines are currently connected to the CRTC and also NMWE is disabled (so nothing the CPU will do will get ever written into CPU). It does it with wait states, so that it always falls into the 4 clock cycle boundry and the CPU will ever read or write from Memory at this particular fixed window.

That is actually T2 of the CPU M cycle and after that the address lines are disconnected - so the address output of the refresh address genereated by the R register between T3 and T4 cannot reach the RAM. 

In CPC the CPU can not compete with screen reading and can not use its refresh technology for any task.

[Bread80]

One more thing to chew on: The R register is only a seven bit counter (bit 7 never updates). The 4164 DRAM requires 16-bit addresses. To quote from the datasheet (https://www.farnell.com/datasheets/1905614.pdf):

"Refresh A refresh operation must be performed at least every four milliseconds to retain data. Since the output buffer is in the high−impedance state unless CAS is applied, the RAS only refresh sequence avoids any output during refresh. Strobing each of the 256 row addresses (A0 through A7) with RAS causes all bits in each row to be refreshed. CAS can remain high (inactive) for this refresh sequence to conserve power."

The memory chips require an 8-bit refresh counter. The Z80 only provides a 7-bit refresh counter. Therefore the Z80 can't be the one driving the refresh.

(And to recap what's already been said: The CRTC and GA already provide a 14 bit counter, and this is already driving RAS of the RAMs. Why would the designers of the Amstrad ignore this and add extra circuitry to get the refresh from the Z80 (and they'd need to find extra time in the video cycle to do so?).)

[eto]

each of the 256 row addresses

quite many (most?) 4164 chips use only 7 bits for the rows, e.g. the Samsung KM4164B.

[SerErris]

The 4164 ICs are organized as a matrix of 128 rows and 512 columns of cells(bits). These cells need to be refreshed every 2ms at least. Each 512 cells in a row are refreshed, when the respective row is accessed (RAS signal + address lines). So what a computer needs to ensure is that within 2ms all 128 RAM

Just out of interest, I looked the datasheet of the 4164 up, and was wondering about this as well.
According to this datasheet https://www.silicon-ark.co.uk/datasheets/TMS4164-datasheet-texas-instruments.pdf
it is actually a 256 rows by 256 columns chip. 

So the chips build into the 464s (at least) would need full 8 bit for refresh.

However the Hitachi 4864 actually have a 128x512 organisation and can be refreshed in 128 cycles (actually can get refreshed by the R register of the Z80.

I think they just jammed everything in the CPCs, and that was possible because of Refresh is being done by GA/CRTC and they do not care if it needs 256 reads or 128 reads. 

In reality 256 reads are about 3,2 screen lines, which will take about 128 µs only.
And the 4164 already have a refresh time of 4ms ... which is plenty of time. So that is actually never a problem. 

Also the refresh of the CRTC is absolutely stable, vs. the CPU is refreshing only at M1 cycles and that would be very inconsistent depending on the code you actually execute. It would be in average every 3-4µs and so that would mean 256 rows (256 commands) would be about 1ms. Still a lot of air in there.

[andycadley]

I suspect the real reason for using the GA is that the original design was based on the 6502, which needed external RAM refresh. So they'd probably already figured that out before switching the CPU over to the Z80 and why change something that already worked?

[McArti0]

But CRTC does not refresh at all for 7ms per frame.

Have any of you checked if the RAS for CRTC exists under every high nCAS state even when it is border?

[dodogildo]

I think if Roland Perry and William Poel got in a time machine and read this forum, their minds would explode. They would definitely kidnap some of you and take them back to their own time to exploit your talents and intelligence.

[Bread80]

However the Hitachi 4864 actually have a 128x512 organisation and can be refreshed in 128 cycles (actually can get refreshed by the R register of the Z80.

I've read that the 7-bit refresh of the Z80 caused 'challenges' for computer designers when 64kbit DRAMs started to arrive. I'd guess Hitachi found a clever solution - refresh two lines off a single RAS.

BTW, one more thing I'm thinking about: A0 is driven by the GA. It's used to read the two video bytes during a cycle. It updates between the two video CAS cycles. There is no second RAS. If A0 where being used for CAS only bytes at even addresses would get refreshed!

I'm willing to bet that the A0 is sent to the RAMs during a CAS cycle. A RAS cycle is (probably) running off A1 to A8 (although could be other address lines). This would depend on the wiring of the multiplexers. If anyone wants to take a look at the schematics they're welcome.

[eto]

But CRTC does not refresh at all for 7ms per frame.

Have any of you checked if the RAS for CRTC exists under every high nCAS state even when it is border?

See attached a screenshot from the 6845 datasheet: The CRTC address lines continue to run. This actually makes sense as the CRTC was (also) used in graphics cards where no CPU could do the RAM refreshes so the CRTC had to make sure all graphics RAM is always refreshed.

[eto]

I'm willing to bet that the A0 is sent to the RAMs during a CAS cycle. A RAS cycle is (probably) running off A1 to A8 (although could be other address lines). This would depend on the wiring of the multiplexers. If anyone wants to take a look at the schematics they're welcome.

that's exactly what's happening

[Bread80]

But CRTC does not refresh at all for 7ms per frame.

Have any of you checked if the RAS for CRTC exists under every high nCAS state even when it is border?

The GA is still generates all the video related signals during HSYNC, VSYNC and border periods as if nothing has changed.

I'm not an expert on the 6845 but the datasheet appears to show that the addresses (MA0-MA13) continue to count during those periods.
https://www.cpcwiki.eu/imgs/d/da/Mc6845.motorola.pdf

(Up until now I'd assumed the designers had missed a trick my not running the CPU at full speed during those periods. But if the video cycles are still required for memory refresh then they were simply being clever...)

[SerErris]

But CRTC does not refresh at all for 7ms per frame.

Have any of you checked if the RAS for CRTC exists under every high nCAS state even when it is border?

You are now mixing up blank cycles of a frame and CRTC counting. Even during the blank cycle the CRTC keeps counting, because how would it know otherwise if the blank phase needs to end?`

Beneath the counting and the addresses the CRTC is generating three signals.

VSYNC, HSYNC and DISPEN. All three are going into the GA and it is used there to create the correct timing of the video signal.

But the CRTC never stops counting.

Regarding the RAS signal.

Yes it is important that not only the CRTC is counting, but that the GA is continue to create a RAS signal.

And yes it does.

Internally the GA creates a sequence byte, that is pretty much independent of any other value in the CPC (there is one exception regarding interrupts).

The Sequence looks like this:

Code Select Expand

Bits  7654 3210   S7-S0
---------------
FF:   1111 1111
FE:   1111 1110
FC:   1111 1100
FB:   1111 1000
F0:   1111 0000
E0:   1110 0000
C0:   1100 0000
80:   1000 0000
00:   0000 0000
01:   0000 0001
03:   0000 0011
07:   0000 0111
0F:   0000 1111
1F:   0001 1111
3F:   0011 1111
7F:   0111 1111

FF:
.
.
.


The clock is running at 16Mhz. So it runs from one value to the next ever 1/16 µs. That is 4 times faster then the CPU signal.

This sequence is then used to create most of the other signals. That includes the CPU clock, the CRTC clock (and sound chip) the RAS signal and some others.

The RAS signal only depends on this sequence and the clock. The clock is used to trigger a flip-flop to stabilize the RAS output.

The function is S0 AND (NOT S2 OR S6)
So this is true for the following Values:
FF, 01,03, 7F. ... in other order 01-03 (2 clocks) and 7F-FF (2 clocks) the RAS high will be generated (not active) and from 07-3F (4 clocks) and  FE-00 (8 clocks) it will RAS low (active).

So yes. the GateArray is creating the RAS signal whatever happens to the other parts of the systems. It is not even dependent on the HSYNC/VSYNC signals.

CAS however is only created if it GA needs to read something or if there is a MREQ from the CPU. However the MREQ is also conditionally that it is NOT a Refresh (e.g. not during an M1 cycle after it has finished its opcode read). There is a particular piece of logic in the GA that actually filters this specific condition, to not get confused when a CAS signal is needed.

If you want to read the logic of the CAS signal, which is pretty much more complicated than the RAS signal, I can only recommend Gerald's schematics of the GateArray. Most is explained there, and I just described it in more words.


Addition:
CPU signal (which is used to switch from CRTC Address to CPU address is the following logic:
S1 NAND NOT S7
So when S1 = 1 and S7 = 0 CPUN gets low (active)
This is exactly the case during 03-7F, so for exactly 6 GA cycles, or for 6/16 or 0,375 µs each µs. That is the time window (and the only time window) when the CPU address bus is connected to the RAM. All other times, it is disconnected and the CRTC address bus is connected.

Also this logic is not depending on anything else than the internal Sequencer of the GateArray.

[SerErris]

Double post

[SerErris]

BTW: The Toshiba TMM4164AP also has a 7*9 bit matrix. It is just internally taking one bit of the RAS and combining it with the 8 bit of CAS to achieve that.
https://www.datasheetarchive.com/datasheet?id=dccad5d93e48b7d136da4dc4f6d7cf660e1972&type=M&term=tmm4164

They have a very good datasheet showing how they do this internally:
You cannot view this attachment.

[eto]

Gerald's schematics of the GateArray.

oh... were can we find that?