News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_m_dr_m

Ultra-fast and **non-destructive** RAM detection

Started by m_dr_m, 09:48, 15 April 20

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

m_dr_m

'joir. I'm quite bothered by Parados or YANCC corrupting all the memory just to measure how much RAM there is.
Granted, Orgams is also trashing some banks, yet only the ones it uses, and for the good cause: persistence across resets!

It's quite easy to detect RAM without corrupting it.

       
       
  • Connect reference bank (e.g. C4)
  • Pick reference byte (any address 4000-47FF)
  • Connect candidate bank (e.g. CC)
  • Compare byte at said address. If distinct -> Done for this bank, that's additional memory
  • If same, it can be a coïncidence, so:
  • Change byte (e.g. inc (hl))
  • Reconnect ref bank
  • Compare
  • Reconnect candidate bank
  • **Restore Byte**
  • If didn't compare as equal -> that's additional memory.
On top of that:

       
  • If assuming all RAM extensions are multiple of 64 KiB, we only have to test CC, D4, DC, ...
  • If assuming all RAM extensions are powers of 2, the reference bank can remain C4.

GUNHED

Using FutureOS there is a probably more quick and of course non-destructive way:

1. Bank in all expansion RAM (E-RAM) one after another, save bytes from &4000 / &4001 and then write to &4000/1 the physical RAM select (this is &78C4 up to &7FFF using 4 MB E-RAM space)
2. Assessing the bytes at &4000/1 (each E-RAM) and comparing them to the actual E-RAM configuration in BC, setting status bits for each E-RAM
3. Restoring the data in all E-RAMs at &4000/1

Why is it important to keep E-RAMs intact? Well, lots of users love RDOS and the 444 KB RAM disc it provides. Also supported by native OS and CP/M 2.2, CP/M Plus and so on...  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

That's slightly less reset-proof (: I.e. if a reset occurs before you have restored the bytes, all banks traversed are corrupted. With an incremental approach, you have to be very unlucky to trash just one bank!


BTW, why do you store 2 bytes for each?

SOS

Quote from: m_dr_m on 09:48, 15 April 20
'joir. I'm quite bothered by Parados or YANCC corrupting all the memory just to measure how much RAM there is.

You can easily give a tip in the YACC thread for improvement ;)

I need only one 16KB-Bank, so it should be enough to test against bank C4 if it exist or not?!
(is there any RAM-Extension available for the CPC464(Plus), which are not using C4-Bank?)

roudoudou

Quote from: m_dr_m on 17:50, 15 April 20
BTW, why do you store 2 bytes for each?
easier and faster to store BC switching value in the memory
My pronouns are RASM and ACE

roudoudou

Quote from: m_dr_m on 17:50, 15 April 20
That's slightly less reset-proof (: I.e. if a reset occurs before you have restored the bytes, all banks traversed are corrupted. With an incremental approach, you have to be very unlucky to trash just one bank!


BTW, why do you store 2 bytes for each?
Plus you cannot use incremental approach with moar than 512K due to decoding IO right?
My pronouns are RASM and ACE

GUNHED

Quote from: m_dr_m on 17:50, 15 April 20
That's slightly less reset-proof (: I.e. if a reset occurs before you have restored the bytes, all banks traversed are corrupted. With an incremental approach, you have to be very unlucky to trash just one bank!


BTW, why do you store 2 bytes for each?
Chances for a reset in about 0,001 seconds? I don't care.
Yes, two bytes. RAM select as indicated before. Checking for 4 MB RAM needs two bytes.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

Quote from: SOS on 18:02, 15 April 20
You can easily give a tip in the YACC thread for improvement ;)


I thought I already complained at one point, that's why i chose this more constructive approach!

I don't consider 7FC4 to 7FC7 as persistent memory, they can be trashed at will. By the way there is also 7CC4 to 7CC7 available from the CPC RAM (when a X-Mem is plugged).
So, yes, if your test just pokes C4, it would be perfect.



QuotePlus you cannot use incremental approach with moar than 512K due to decoding IO right?


Why not?


SOS

Quote from: m_dr_m on 19:46, 16 April 20
I thought I already complained at one point

Öhh, nooo, not to me :blank:
I will change the RAM-Detection to the fixed question "Is 7FC4 as an RAM-Bank available - or not?".
Keeps the Code short & simple  :D
(but cost time, i must first release the next CubeMDOS-Version)

roudoudou

Quote from: m_dr_m on 19:46, 16 April 20
I don't consider 7FC4 to 7FC7 as persistent memory, they can be trashed at will. By the way there is also 7CC4 to 7CC7 available from the CPC RAM (when a X-Mem is plugged).
So, yes, if your test just pokes C4, it would be perfect.

Why not?
#7CC4 is not CPC RAM with 2M memory expansion, you will experience confusion between 512K slots, like you just did
My pronouns are RASM and ACE

Powered by SMFPacks Menu Editor Mod