Problems with 4 MB RAM expansion - may happen to you too - please read!

[GUNHED]

Dear CPC / Plus and 4 MB users,

I've been using the 4 MB RAM expansion from Zaxon for quite some time now.
Now I noticed that there is an annoying error:

If an expansion RAM block from &CC to &FE is banked in and you then switch to block &FF, then the byte &FF (or sometimes another) is written into the source block at the RAM location addressed by BC.
In other words, the memory gets corrupted by an OUT command e.g. OUT (C),A.

This is a nasty thing, but it only occurs on the CPC6128 (664/464 not tested).
The malfunction does not occur on the 6128plus though!

Does any one of you have the 4 MB extension from Zaxon?
Then please run the BASIC test program from the attached .DSK and post a photo here (or just report).

Asking kindly for your help.

(Different power supplies, keyboards and monitors were used in my testing)

[McArti0]

Hmm..

https://www.cpcwiki.eu/index.php/Standard_Memory_Expansions#Extended_1M-4M_Expansions_.28RAM7.2FYarek-style.29

OUT [01111aaaxxxxxxxx],11bbbccc
 aaa  = upper bits of 64K bank selection (512K-step) (A8,A9,A10 bits)
 bbb  = lower bits of 64K bank selection (64K-step)  (D3,D4,D5 bits)
 ccc = configuration (as in CPC6128)
 xxxxxxxx = should be set so that it doesn't conflict with other ports (*)

Your aaa is always 111 and xxxx xxxx is full Range 00-FF. Maybe You use random property?

[GUNHED]

Random? No!

Please have a look at the BASIC program (it's the common way for banking) and report your result with your 4 MB expansion. This will help the community. Thank you all. 

[McArti0]

For lowbyte=0 to &FF

OUT &7F00+lowbyte,&FF

What Do You SET?

xxxx xxxx = 00 to FF

[zhulien]

Dear CPC / Plus and 4 MB users,

I've been using the 4 MB RAM expansion from Zaxon for quite some time now.
Now I noticed that there is an annoying error:

If an expansion RAM block from &CC to &FE is banked in and you then switch to block &FF, then the byte &FF (or sometimes another) is written into the source block at the RAM location addressed by BC.
In other words, the memory gets corrupted by an OUT command e.g. OUT (C),A.

This is a nasty thing, but it only occurs on the CPC6128 (664/464 not tested).
The malfunction does not occur on the 6128plus though!

Does any one of you have the 4 MB extension from Zaxon?
Then please run the BASIC test program from the attached .DSK and post a photo here (or just report).

Asking kindly for your help.

(Different power supplies, keyboards and monitors were used in my testing)

yes, i *was* using it on a 6128 Plus, but i do have a 464, 664 and 6128 I can test it on if you need.  I am now using the 2mb RAM expansion with the plus bug fix now.

[GUNHED]

yes, i *was* using it on a 6128 Plus, but i do have a 464, 664 and 6128 I can test it on if you need.  I am now using the 2mb RAM expansion with the plus bug fix now.

Yes, it would be great if you could run the test program (especially on a CPC), because it seems you're the only one being able / willing to help. 

The result of this is important for the community.

BTW: Now I'm using the 4 MB on the Plus and the great 2 MB PulkoMandy expansion on the CPC. And it *should* be the other way around. So a temporary solution, but it works.

[GUNHED]

For lowbyte=0 to &FF

OUT &7F00+lowbyte,&FF

What Do You SET?

xxxx xxxx = 00 to FF

Please have a look at the simple BASIC program it's self-explaining. Just give it a try and you see.

[zhulien]

I will get back to you in a day or two... 

[GUNHED]

Meanwhile I an provide some information from Markus' German CPC Forum: Manno tested his two 4 MB expansions. One worked with the CPC6128, but not the other one.

More results would be beneficial. I guess I have to inform Zaxon, since this is not a problem of my setup.

However, any kind of testing-results would be great to be posted here. 

[zhulien]

hi GunHed, I am a little lost as to what the expected outcome is...  

I tested the following so far:

- 6128 plus with your tester, it gives 7 and a half lines of smiley faces regardless of gemini or zaxon, regardless of the switch positions

what is it supposed to show for 

standard 64kb:
standard 128kb:
additional 128kb:
additional 256kb:
additional 512kb:
additional 2mb:
additional 4mb:

I will try also on 464, 664 and 6128 now...

[zhulien]

I just tried my 664 and 464 with the same Mx4 and M4, RAM etc... and it says incompatible BASIC - I haven't seen that before?  I have reverted my switchable 6128/664 ROMs from the 664 to make it 'almost' as original as a standard system, that never did that.  My CPC6128 when it boots isn't showing the M4 - so I am guessing it is because of the ROM socket 7 not being movable.

[Kris]

Just give it a try on my 6128 Plus, 4Mo RAM (nothing else connected): same result than @zhulien.

[GUNHED]

Yes, it seems to work fine on the 6128plus (showing only smiley faces).
But the problems do occur on the CPC (values instead of smiling faces).
So the test system shall be the CPC and the 4 MB expansion.

Thank you all for testing. Is Zaxon reading here too?

[zhulien]

How many smiley faces should it have when it works and what should it look like when it doesn't work?

[zhulien]

Why does 512kb, 2mb and 4mb all have the same number of smiley faces on 6128plus?

[McArti0]

Where is the documentation that shows that the RAM bank number is passed as the lower byte of the IO address?

[GUNHED]

To answer your questions please look at the very simple BASIC program. It's self explaining. More information can be found in the CPC's manual and in the CPC-Wiki pages about RAM Banking.
Sorry, but this thread is about the 4 MB expansion and not a general one.

[zhulien]

The way you should be testing memory is writing to main memory and then within a loop of all the memory you want to check, write to the extra memory, then check if the main memory is overwritten.  This can take a lot of time if you want to check all so there are some optimisation that technically could be wrong but suffice, such as checking the presence of each 64kb block is faster than each 16kb... but only because we don't currently have expansions other than in 64kb increments.  Technically you should track the memory found for use later... e.g. if you have the 2nd 256kb but not the first, use it... don't discuss it because you need 256kb but it wasn't the first 256kb.  Alternatively let a user configure how they want to use their extra ram so it doesn't get trashed all the time... e.g. maybe I am using a debugger in the first 256, ramdisc in the 2nd 256, then expect my game if it was nicely coded to use space following... but that seems too difficult for some game coders, and because again nobody on cpc agrees on standards.  Pitty the cpc didn't have the msx community.  We have the better machine imho with the worst standards.

[GUNHED]

Before we get completely derailed...

This thread is specifically about the 4 MB RAM expansion working at the CPC (not the 6128plus where it runs just fine).

There are problems in that particular combination with the particular RAM &7FFF. That's the topic here please. 

[zhulien]

Hi, it took a while but here are my findings.

From your test program, it appears to have no issues on any of my CPCs with the Zaxon 4mb expansions that I have - however...here is a switch on my Zaxon 4mb expansion that I have no idea what it does - it appears to do nothing and I get 4mb pass every time.

The issue with the smily test program I found on different RAM configuration is... it is successfully passing where there is no RAM.  Because of this i went back to my own RAM logic to do some tests and found some oddities as described below.  

Here is RAMSLOW.BAS - it reports how many 16kb RAMs you have and it has not failed for me yet with any memory configuration.  

It works with 3 passes:

pass 1, it initialises a few bytes in every possible RAM block
pass 2, initialises the main RAM, 
pass 3, it checkes each possiblew RAM block to ensure it reads what was initialised and not the main RAM also

I do this for each of the 256 16kb blocks and it can report which blocks are available correctly so 'good' software should be able to use the RAM it requires no matter where it might be.  note: i am not checking for 64kb memory blocks.

Code Select Expand

10 blocks%=0:m$="":GOSUB 60
20 '
30 PRINT:PRINT blocks%;"x 16KB blocks of extra RAM totalling ";:PRINT ram%;"KB"
40 END
50 '
60 REM RAM Test
70 '
80 OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
90 '
100 t=TIME:ram%=0
110 FOR pass%=1 TO 3
120   PRINT"pass ";:PRINT pass%;:PRINT"..."
130   counter%=0
140   FOR high%=&78 TO &7F
150     port = high%*256
160     RESTORE
170     FOR i%=1 TO 32
180       READ low%
190       IF pass%=1 THEN ELSE 210
200         OUT port,low%:POKE &4000,low%:POKE &4001,high%:POKE &4002,counter%
210       REM end if
220       '
230       IF pass%=2 THEN ELSE 250
240         OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
250       REM endif
260       '
270       IF pass%=3 THEN ELSE 390
280         OUT &7F00,&C0:main%=PEEK(&4000)
290         OUT port,low%:lowtest%=PEEK(&4000):hightest%=PEEK(&4001):countertest%=PEEK(&4002)
300         IF hightest%=high% AND lowtest%=low% AND countertest%=counter% AND main%=&EE THEN ELSE 360
310           ram%=ram%+16:blocks%=blocks%+1
320           REM m$=m$+"Y"
330           IF blocks%=1 THEN PRINT
340           PRINT HEX$(high%)+HEX$(low%)+" ";
350           GOTO 380
360         REM else
370           REM m$=m$+"N"
380         REM endif
390       REM endif
400       counter%=counter%+1
410     NEXT
420   NEXT
430 NEXT
440 RETURN
450 DATA &C4,&C5,&C6,&C7
460 DATA &CC,&CD,&CE,&CF
470 DATA &D4,&D5,&D6,&D7
480 DATA &DC,&DD,&DE,&DF
490 DATA &E4,&E5,&E6,&E7
500 DATA &EC,&ED,&EE,&EF
510 DATA &F4,&F5,&F6,&F7
520 DATA &FC,&FD,&FE,&FF

Here is RAMMED.BAS - the same as above but makes the assumption that there are no missing 16kb blocks within each 64kb block - for existing memory expansions this is fair enough, for future ones, you could argue the same with 16kb blocks why we dont check for 8kb, so it's not an issue in my view. It is 4 times faster but just as reliable.

Code Select Expand

10 blocks%=0:m$="":GOSUB 60
20 '
30 PRINT:PRINT blocks%;"x 16KB blocks of extra RAM totalling ";:PRINT ram%;"KB"
40 END
50 '
60 REM RAM Test
70 '
80 OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
90 '
100 t=TIME:ram%=0
110 FOR pass%=1 TO 3
120   PRINT"pass ";:PRINT pass%;:PRINT"..."
130   counter%=0
140   FOR high%=&78 TO &7F
150     port = high%*256
160     RESTORE
170     FOR i%=1 TO 32 STEP 4
180       READ low%,low2%,low3%,low4%
190       IF pass%=1 THEN ELSE 210
200         OUT port,low%:POKE &4000,low%:POKE &4001,high%:POKE &4002,counter%
210       REM end if
220       '
230       IF pass%=2 THEN ELSE 250
240         OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
250       REM endif
260       '
270       IF pass%=3 THEN ELSE 420
280         OUT &7F00,&C0:main%=PEEK(&4000)
290         OUT port,low%:lowtest%=PEEK(&4000):hightest%=PEEK(&4001):countertest%=PEEK(&4002)
300         IF hightest%=high% AND lowtest%=low% AND countertest%=counter% AND main%=&EE THEN ELSE 390
310           ram%=ram%+64:blocks%=blocks%+4
320           REM m$=m$+"Y"
330           IF blocks%=1 THEN PRINT
340           PRINT HEX$(high%)+HEX$(low%)+" ";
350           PRINT HEX$(high%)+HEX$(low2%)+" ";
360           PRINT HEX$(high%)+HEX$(low3%)+" ";
370           PRINT HEX$(high%)+HEX$(low4%)+" ";
380           GOTO 410
390         REM else
400           REM m$=m$+"N"
410         REM endif
420       REM endif
430       counter%=counter%+1
440     NEXT
450   NEXT
460 NEXT
470 RETURN
480 DATA &C4,&C5,&C6,&C7
490 DATA &CC,&CD,&CE,&CF
500 DATA &D4,&D5,&D6,&D7
510 DATA &DC,&DD,&DE,&DF
520 DATA &E4,&E5,&E6,&E7
530 DATA &EC,&ED,&EE,&EF
540 DATA &F4,&F5,&F6,&F7
550 DATA &FC,&FD,&FE,&FF
Here is RAMFAST.BAS - it reports also how many 16kb RAMs you have but sometimes it fails.  It is similar to RAMMED.BAS but... it skips writing and checking of main memory.  This seems to be the flaw I guess and I believe it is a similar flaw to your 4mb memory tester with the smilies.

Code Select Expand

10 blocks%=0:m$="":GOSUB 60
20 '
30 PRINT:PRINT blocks%;"x 16KB blocks of extra RAM totalling ";:PRINT ram%;"KB"
40 END
50 '
60 REM RAM Test
70 '
80 t=TIME:ram%=0
90 FOR pass%=1 TO 2
100   PRINT"pass ";:PRINT pass%;:PRINT"..."
110   counter%=0
120   FOR high%=&78 TO &7F
130     port = high%*256
140     RESTORE
150     FOR i%=1 TO 32 STEP 4
160       READ low%,low2%,low3%,low4%
170       IF pass%=1 THEN ELSE 190
180         OUT port,low%:POKE &4000,low%:POKE &4001,high%:POKE &4002,counter%
190       REM end if
200       '
210       IF pass%=2 THEN ELSE 350
220         OUT port,low%:lowtest%=PEEK(&4000):hightest%=PEEK(&4001):countertest%=PEEK(&4002)
230         IF hightest%=high% AND lowtest%=low% AND countertest%=counter% THEN ELSE 320
240           ram%=ram%+64:blocks%=blocks%+4
250           REM m$=m$+"Y"
260           IF blocks%=1 THEN PRINT
270           PRINT HEX$(high%)+HEX$(low%)+" ";
280           PRINT HEX$(high%)+HEX$(low2%)+" ";
290           PRINT HEX$(high%)+HEX$(low3%)+" ";
300           PRINT HEX$(high%)+HEX$(low4%)+" ";
310           GOTO 340
320         REM else
330           REM m$=m$+"N"
340         REM endif
350       REM endif
360       counter%=counter%+1
370     NEXT
380   NEXT
390 NEXT
400 RETURN
410 DATA &C4,&C5,&C6,&C7
420 DATA &CC,&CD,&CE,&CF
430 DATA &D4,&D5,&D6,&D7
440 DATA &DC,&DD,&DE,&DF
450 DATA &E4,&E5,&E6,&E7
460 DATA &EC,&ED,&EE,&EF
470 DATA &F4,&F5,&F6,&F7
480 DATA &FC,&FD,&FE,&FF
If you were to rewrite RAMMED as an RSX, it should come back instantly - ideally you'd return to BASIC a pointer to a table of blocks, or a list of blocks.

[zhulien]

btw, we can make pass2 in RAMMED.BAS a bit faster also by not looping, splitting the 3 passes to be sequential - that will remove about 255 iterations.  The code above is very very loosely based on the Gemini memory checking code.

[zhulien]

RAMMED2.BAS - reliable + 4x faster

Code Select Expand

10 blocks%=0:m$="":GOSUB 60
20 '
30 PRINT:PRINT blocks%;"x 16KB blocks of extra RAM totalling ";:PRINT ram%;"KB"
40 END
50 '
60 REM RAM Test
70 '
80 OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
90 '
100 t=TIME:ram%=0
110 PRINT"pass 1";:PRINT"..."
120 counter%=0
130 FOR high%=&78 TO &7F
140   port = high%*256
150   RESTORE
160   FOR i%=1 TO 32 STEP 4
170     READ low%,low2%,low3%,low4%
180     OUT port,low%:POKE &4000,low%:POKE &4001,high%:POKE &4002,counter%
190     counter%=counter%+1
200   NEXT
210 NEXT
220 '
230 OUT &7F00,&C0:POKE &4000,&EE:POKE &4001,&EE:POKE &4002,&EE
240 '
250 PRINT"pass 2";:PRINT"..."
260 counter%=0
270 FOR high%=&78 TO &7F
280   port = high%*256
290   RESTORE
300   FOR i%=1 TO 32 STEP 4
310     READ low%, low2%, low3%, low4%
320     OUT &7F00,&C0:main%=PEEK(&4000)
330     OUT port,low%:lowtest%=PEEK(&4000):hightest%=PEEK(&4001):countertest%=PEEK(&4002)
340     IF hightest%=high% AND lowtest%=low% AND countertest%=counter% AND main%=&EE THEN ELSE 430
350       ram%=ram%+64:blocks%=blocks%+4
360     REM m$=m$+"Y"
370     IF blocks%=1 THEN PRINT
380       PRINT HEX$(high%)+HEX$(low%)+" ";
390       PRINT HEX$(high%)+HEX$(low2%)+" ";
400       PRINT HEX$(high%)+HEX$(low3%)+" ";
410       PRINT HEX$(high%)+HEX$(low4%)+" ";
420       GOTO 450
430     REM else
440       REM m$=m$+"N"
450     REM endif
460     counter%=counter%+1
470   NEXT
480 NEXT
490 RETURN
500 DATA &C4,&C5,&C6,&C7
510 DATA &CC,&CD,&CE,&CF
520 DATA &D4,&D5,&D6,&D7
530 DATA &DC,&DD,&DE,&DF
540 DATA &E4,&E5,&E6,&E7
550 DATA &EC,&ED,&EE,&EF
560 DATA &F4,&F5,&F6,&F7
570 DATA &FC,&FD,&FE,&FF

[GUNHED]

Recently I did write an Email to Zaxon, I hope that he will find time to investigate the issue and hopefully create an update for the logic on the 4 MB expansion. 

BTW: The switch on the RAM expansion is for the 464 vs. 6128. It enables proper mode &C3 for the 6128

[zhulien]

Semi-offtopic, but RAM related while testing I discovered the following oddity... not about Zaxon RAM though (seems to work fine for me here)

Columns as follows: 
- port
- 6 WinApe configurations, note the oddity in the 3rd WinAPE (320k RAM, not 320K Silicon Disc) - 4 missing blocks
- 5 of my CPC664 configurations with a real DkTronics Memory and Silicon Disc, both are switchable, so R for RAM, S for Silicon Disc, R>S RAM switched to Silicon Disc, S>R Silicon Disc switched to RAM, it's very consistent and no holes in the memory like the WinAPE one.  

When I got my CPC, I got a Silicon Disc cheaply for my 664 then years later a Memory expansion - so for 99% of my CPC life I had 576K RAM and therefore never noticed any holes.

Code Select Expand

<-------WINAPE-------->                         <------CPC664----->
64 128 320 320 384 576 320 320 320 320 576
R S R R>S S S>R R+S

#7fc4 - - Y - - Y Y - - Y Y
#7fc5 - - Y - - Y Y - - Y Y
#7fc6 - - Y - - Y Y - - Y Y
#7fc7 - - Y - - Y Y - - Y Y
#7fcc - - Y - - Y Y - - Y Y
#7fcd - - Y - - Y Y - - Y Y
#7fce - - Y - - Y Y - - Y Y
#7fcf - - Y - - Y Y - - Y Y
#7fd4 - - Y - - Y Y - - Y Y
#7fd5 - - Y - - Y Y - - Y Y
#7fd6 - - Y - - Y Y - - Y Y
#7fd7 - - Y - - Y Y - - Y Y
#7fdc - - - - Y Y Y - - Y Y
#7fdd - - - - Y Y Y - - Y Y
#7fde - - - - Y Y Y - - Y Y
#7fdf - - - - Y Y Y - - Y Y
#7fe4 - - - Y Y Y - Y Y - Y
#7fe5 - - - Y Y Y - Y Y - Y
#7fe6 - - - Y Y Y - Y Y - Y
#7fe7 - - - Y Y Y - Y Y - Y
#7fec - - - Y Y Y - Y Y - Y
#7fed - - - Y Y Y - Y Y - Y
#7fee - - - Y Y Y - Y Y - Y
#7fef - - - Y Y Y - Y Y - Y
#7ff4 - - - Y Y Y - Y Y - Y
#7ff5 - - - Y Y Y - Y Y - Y
#7ff6 - - - Y Y Y - Y Y - Y
#7ff7 - - - Y Y Y - Y Y - Y
#7ffc - Y Y Y Y Y - Y Y - Y
#7ffd - Y Y Y Y Y - Y Y - Y
#7ffe - Y Y Y Y Y - Y Y - Y
#7fff - Y Y Y Y Y - Y Y - Y

Is there some special circuitry in some 256K RAM expansions that moves fc, fd, fe, ff up to dc, dd, de, df if a 256k silicon disc is present?
A bug in WinApe?  Some other voodoo magic?

[zhulien]

Unfortunately I don't have a real 64k DkTronics RAM expansion to test.  Gemini works flawlessly in my tests and Symbiface does too.