News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Memory refresh plus

Started by arnoldemu, 19:27, 06 April 14

Previous topic - Next topic

roudoudou, McArti0 and 1 Guest are viewing this topic.

arnoldemu

I assume that the memory refresh on a plus is refreshed purely by the video fetching from ram.
If I wanted to disturb that process from code and stop it reading particular memory addresses how would this be done?

I am more asking how a read/write of a particular memory address is translated into accesses for the RAM chips.
e.g. If the video read from &c000, which memory addresses would be refreshed by this?

I want to make a test to verify this.

EDIT: I believe the CPC memory refresh is also done by the video hardware. Am I correct that it is less of a problem because of the 8 chips for the base 64k? So would a cost down with 4 chips for the base 64k have the same memory refresh problems of a Plus?

If I wanted to disturb the memory refresh on the CPC how could I change that too?






My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

rpalmer

arnoldemu,

The refresh is handled by the Z80 itself. It uses the R-register to provide the 8-bit Row address and uses Z80 memory control signals to do the job.

rpalmer

Bryce

The splitting of the RAM between 8x 64Kx1bit or 2x 64Kx4bit wouldn't have any effect on the refresh requirements or speed.

Bryce.

TFM

As I know, this is not the case in the CPC.


The Plus uses imho the ASIC for memory refresh.


Dunno how to disturb that though.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

gerald


Quote from: arnoldemu on 19:27, 06 April 14
I am more asking how a read/write of a particular memory address is translated into accesses for the RAM chips.
e.g. If the video read from &c000, which memory addresses would be refreshed by this?
I have no info the the plus range, but for the CPC range ROW addresses is made of the following addresses :


      GA    Z80
RA0   MA1    A2
RA1   MA0    A1
RA2   MA3    A4
RA3   MA2    A3
RA4   MA5    A6
RA5   MA4    A5
RA6   MA7    A8
RA7   MA6    A7


However, refresh is done on each selected row, be it done by the GA or the Z80. That is, each RAS access will refresh the corresponding row.

Z80 address to Physical addresses is :

A15    CA6
A14    CA7
A13    CA4
A12    CA5
A11    CA2
A10    CA3
A9    CA0
A8    RA6
A7    RA7
A6    RA4
A5    RA5
A4    RA2
A3    RA3
A2    RA0
A1    RA1
A0    CA1


So making a code that do not refresh a part of the ram mean avoiding fetching in the corresponding row from either the GA (video) or the Z80.


Quote from: arnoldemu on 19:27, 06 April 14
EDIT: I believe the CPC memory refresh is also done by the video hardware. Am I correct that it is less of a problem because of the 8 chips for the base 64k? So would a cost down with 4 chips for the base 64k have the same memory refresh problems of a Plus?
As bryce said, this does not make a difference. The 4bit RAM in the plus range are equivalent to 4 1bit RAM in parallel in the same package. They both have 256 rows.
Refresh issue in the plus may just result from a poor assignment of row addresses.

Quote from: rpalmer on 20:20, 06 April 14
The refresh is handled by the Z80 itself. It uses the R-register to provide the 8-bit Row address and uses Z80 memory control signals to do the job.
The Z80 provide a way to refresh DRAM using the R register, however, it is not used on the amstrad CPC. The refresh cycle at end of M1 cycle is just ignored by the GA.

Bryce

The 6845 does the refreshing as far as I knew, not the Z80. The 6845 has refresh functionality built in, I assume it's being used.

Bryce.

gerald

Quote from: Bryce on 20:49, 06 April 14
The 6845 does the refreshing as far as I knew, not the Z80. The 6845 has refresh functionality built in, I assume it's being used.
The 6845 has no refresh capability as such.
The way the CPC is designed makes the video ram fetch refresh all the dram rows. It is the way amstrad assigned the crtc generated addresses to the row addresses that make the proper refresh.
If the crtc adresses where wired linearly to the DRAM (MSB as row, LSB as col), the video stream would only read the 16k upper ram, which would correspond to the 64 upper rows. Put the Z80 in a less than 256 byte loop, and most of you RAM get lost.


Bryce

That's what I meant actually. Not a deliberate feature, more of a by-product that can be used.

Bryce.

TFM

Quote from: Bryce on 20:49, 06 April 14
The 6845 does the refreshing as far as I knew, not the Z80. The 6845 has refresh functionality built in, I assume it's being used.

Bryce.


No, the CRTC can only access the first 64 KB. So how do the second 64 KB of the CPC6128 get refreshed? As I told it's the GA / ASIC doing the refresh.

TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

gerald

Quote from: TFM on 21:11, 06 April 14
No, the CRTC can only access the first 64 KB. So how do the second 64 KB of the CPC6128 get refreshed? As I told it's the GA / ASIC doing the refresh.
The banks are refreshed in parallel. They share addresses/data/RAS signals, only the CAS signal is different. A refresh is done each time  RAS is going low.

DRAM access are done this way :
set the address bus with row address, take RAS low => this precharge the row, and refresh all cells on this row.
set the address bus with col address, take CAS low => read or write the selected cell in the previously charged row.

So you can refresh multiple devices while only accessing one.

arnoldemu

Thankyou to everyone for your help with this. I will do some tests and try and work out how I can choose addresses so that the ram refresh is disturbed.

I was aware that the 6845 generated an address, the gate-array then accessed the ram which then causes the ram to refresh. I was also aware the 2 banks of the 6128 were refreshed in parallel. I also know the refresh feature of the z80 is ignored.

What I didn't know exactly was how the addresses, generated by the crtc, were then applied to the ram chips, and what rows/columns would be refreshed for a particular address.

Quote from: gerald on 20:46, 06 April 14
Refresh issue in the plus may just result from a poor assignment of row addresses.
Interesting. So they have re-ordered the address lines that go to the RAM chips themselves?

I noticed something about this when looking at the uninitialised second bank of ram in the 6128.

I will do more investigations.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

gerald

I've done some test on a plus and cost down cpc and the result are :
  ASIC and preASIC DRAM address mapping is not the same as the regular CPC.
  ASIC and preASIC uses the same DRAM address remapping.

The following table show the mapping for the Z80/CRTC address space to dram address space for regular CPC and (pre)ASIC
MA/RA are CTRC generated adresses
RAx are row addresses
CAx are column addresses
CCLK is the 1MHz clock used to clock the CRTC. It is used for selecting word 2n and 2n+1 during video fetch.

So bit 0 of Z80 address is drives Column bit 1 on regular CPC and Column bit 0 on (pre)ASIC


Z80 CRTC  CPC  Asic
A15 MA13  CA6  CA7
A14 MA12  CA7  CA6
A13 RA2   CA4  CA5
A12 RA1   CA5  CA4
A11 RA0   CA2  CA3
A10 MA9   CA3  CA2
A9  MA8   CA0  CA1
A8  MA7   RA6  RA7
A7  MA6   RA7  RA6
A6  MA5   RA4  RA5
A5  MA4   RA5  RA4
A4  MA3   RA2  RA3
A3  MA2   RA3  RA2
A2  MA1   RA0  RA1
A1  MA0   RA1  RA0
A0  CCLK  CA1  CA0


The differences between the two mapping are not that big : the ASIC mapping is linear but still map the lsb to the row adresses. CPC mapping seems to have beed selected for layout reason.


arnoldemu

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Bryce

Very interesting, well researched Gerald.

Bryce.

Executioner

As far as I know, the way to cause the RAM refresh to fail in both a Plus or normal CPC is simply to stop a few bits of the CRTC address changing (ie. never refresh the selected area). Generally, only the Row address needs to be cycled, so stopping MA0 through MA7 from changing, and stopping the CPU from reading those rows, will cause data to be lost, quite quickly (generally around 4ms). Assuming memory chips that require the full 8 bit rows address, you probably can't stop any one of the bits from changing. You would think that setting CRTC register 1 to a particularly low value while the CPU is halted would cause the loss of data quite quickly. In pratice, I've only noticed it happen a couple of times.

djaybee

Reviving an ancient thread, because I was curious about the same thing. I suspect that the CRTC 6845 keeps generating MA addresses throughout the line (and probably the whole frame), and merely resets them at character 0. This is based on the Motorola 6845 manual, figure 12, which shows MA addresses on the address bus even when DISPEN is off.

Combining that with the layout of R and C lines to the DRAM, that implies that the CRTC needs to hit 512 consecutive words (256 CRTC characters) within 2ms (the max allowed refresh period for the 4164B-15 DRAM, from the datasheet). 2ms is about 31 lines at 64us.

A standard display with 40 CRTC characters actually needs 41 lines to hit that many characters (64 characters per line, which increments by 40 every 8 lines). That slightly off-spec, but not by much.

Reduced-width displays might be worse. A 32-character-wide "speccy" display will need 49 lines, i.e. about 50% longer than spec. Narrower screens get worse, e.g. a 24-character display takes 65 lines, more than double the specified time, and so on.

Note that some interrupt code runs every 52 lines, which also causes some refresh.

From there, I'll guess that preventing some of the RAM from getting refreshed might require to use a very narrow display to reduce the address increment from character row to character row. Things might get worse if the display is very tall (it's hard to guess what happens during the top/bottom borders), and you can worsen things by a few DRAM rows if you use very tall CRTC characters. Obviously, your Z80 has to stay within the DRAM rows that get hit by the CRTC on each line, so that it doesn't cause the other rows to get refreshed. That requires that interrupts be disabled.

Not knowing for sure what addresses get generated during the top/bottom border, you might not be able to disable refreshes in some areas for more than about 296 lines, i.e. not forever, though it'd be interesting to investigate what happens if you make the display 312 lines tall (R6 = 39 with the default R9).

I don't have an actual CPC to test that on. Nor do I have an appropriate oscilloscope or logic analyzer to investigate the pin-level details if I had a CPC (an oscilloscope on the CRTC's MA7 pin might be enough).

McArti0

Exactly this month, I embarrassed myself on the forum regarding this issue.   :laugh:

CRTC is not refreshing CPC only when R0=0. if R0<>0 then CRTC counters always work and refreshing (at border too)
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

roudoudou

Quote from: djaybee on Today at 11:09Note that some interrupt code runs every 52 lines, which also causes some refresh.

Quasar CPC was talking about the refresh bug on the Plus, mixing line-per-line split and PRI (you set a raster line interrupt which never occurs). i didn't digged that part but it's a lead

My pronouns are RASM and ACE

andycadley

Yeah, I've always been curious about this. The Plus documentation warns about it but doesn't really go into detail. I don't think it's a "bug" as such, it's just an unfortunate side effect of (ab)using the hardware in ways never intended.

Would be neat to get it properly documented though (and emulated even).

McArti0

Quote from: McArti0 on Today at 12:41CRTC is not refreshing CPC only when R0=0. if R0<>0
errata: CRTC is not refreshing CPC only when R1=0. if R1<>0
CPC 6128, Whole 6128 and Only 6128, with .....
NewPAL v3 for use all 128kB RAM by CRTC as VRAM
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

Powered by SMFPacks Menu Editor Mod