WinAPE RAM expansion behaviour / Bug?

[Prodatron]

Here are some SyMon (this app is included in SymbOS 4.0) screenshots, which show, which memory is available with different types of memory expansions. Just check the N/A areas.

This is in fact the same like we had with exactly these expansions in the 80ies/early 90ies.

CPC6128 with 128K:

You cannot view this attachment.

CPC 464/664 with additional 256K:

You cannot view this attachment.

CPC6128 with additional 256K:

You cannot view this attachment.

(now you can see some unavailable banks/gaps, which are not existing resulting in gaps, but mirrored and still detected as not existing)

Any CPC (464/664/6128) with additional 512K:

You cannot view this attachment.

Any CPC with 1MB (or more):

You cannot view this attachment.

[zhulien]

The images didn't show, does symbos work on e.g. 664 with silicon disc?

[Prodatron]

no idea, why the images are gone, next try...

CPC6128 with 128K:

You cannot view this attachment.

CPC 464/664 with additional 256K:

You cannot view this attachment.


CPC6128 with additional 256K:

You cannot view this attachment.


(now you can see some unavailable banks/gaps, which are not existing resulting in gaps, but mirrored and still detected as not existing)

Any CPC (464/664/6128) with additional 512K:

You cannot view this attachment.

Any CPC with 1MB (or more): 

You cannot view this attachment.

[Prodatron]

The images didn't show, does symbos work on e.g. 664 with silicon disc?

The second screen shows this configuration, but I don't know, if the original silicon disc supports #C1 and #C2 on a 464/664?

I made another test with real hardware, and indeed it may happen, that non-existing banks are not mirrored but return random bytes. I guess this depends on the ram expansion hardware.

As an original unexpanded 6128 will mirror its second 64K to all non-existing banks, it is always the best way to consider, that banks may be either mirrored or return broken bytes.
WinApe is always mirroring banks. You may be right, when saying, that for special memory expansions this is not the correct behaviour. But a detection routine should always consider both behaviours, as both may happen on real hardware as well.

[Prodatron]

Its interesting the different detection logics we all have. Please continue posting them.

Eto already posted a good one, here is another variant:

10 memory &3fff
20 for x=&fc to &c4 step -8
30 out &7f00,x:poke &4000,x
40 next
50 for x=0 to 7
60 out &7f00,&c4+x*8
70 print"Bank";x+1;"- ";
80 if peek(&4000)=&c4+x*8 then print"Available" else print"Not existing"
90 next
100 out &7f00,&c0

You may extend it for more 512K areas using &7exx, &7dxx etc.
The principle is always the same, start writing the test values to the most upper bank and walk down to the lowest, if you don't want to be confused by mirrored banks.

[zhulien]

Eto's one uses a similar method to the Gemini one and the one I posted which was based on the Gemini one. It can detect exactly which blocks are available and not.  I guess if its shadowed it doesn't matter which we use as long as it isn't assumed to be fixed always.  I had seen some very simple 128 checks that do not much more than check for c4 and if present assume a 6128, I guess it is ok in reality as there isn't any real less than 64k expansions or expansions that aren't contiguous. 

Now to think of how to check using this method but not permanently corrupt the ram... 256 byes maybe pushed to the stack...or in smaller groups that would never be shadowed to reduce stack usage... perhaps temporarily use video ram.