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)
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?
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. :) :) :)
For lowbyte=0 to &FF
OUT &7F00+lowbyte,&FF
What Do You SET?
xxxx xxxx = 00 to FF
Quote from: GUNHED on 14:52, 29 September 23Dear 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.
Quote from: zhulien on 18:16, 29 September 23yes, 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.
Quote from: McArti0 on 18:00, 29 September 23For 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.
I will get back to you in a day or two...
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. :)
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...
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.
Just give it a try on my 6128 Plus, 4Mo RAM (nothing else connected): same result than
@zhulien.
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?
How many smiley faces should it have when it works and what should it look like when it doesn't work?
Why does 512kb, 2mb and 4mb all have the same number of smiley faces on 6128plus?
Where is the documentation that shows that the RAM bank number is passed as the lower byte of the IO address?
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.
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.
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. :)
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.
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.
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.
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.
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.
RAMMED2.BAS - reliable + 4x faster
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
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
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.
<-------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?
Unfortunately I don't have a real 64k DkTronics RAM expansion to test. Gemini works flawlessly in my tests and Symbiface does too.
According to https://www.cpcwiki.eu/index.php/Dk%27tronics_memory_expansion the DKtronics memory expansion would detect a 6128 and move 64K of it's memory so as not to conflict with the extra 64K in the 6128. Presumably the goal was to ensure 464/664 owners could play 128K games which assumed the banking scheme with getting a slew of complaints from 128K owners who didn't get the full 256K they paid for.
I doubt all memory expansions bothered though, with many just taking the machine up to 320K regardless. WinAPE is presumably allowing you to mimic either with a 320K and 384K option.
no matter what i try, in winape, i cannot detect in 6128 configuration blocks at c4, c5, c6, and c7 - for some reason they are at fc, fd, fe, ff. Yet 128k software runs. hmm, seems something in my memory test logic that breaks WinAPE but not a real CPC.