Howto get banked RAM size

Ender · Post by **Ender** » Wed Oct 07, 2020 1:44 am

2 hours ago, TomXP411 said:

I don't think anyone has explained why that would be... if the chips aren't populated on the board, then the lines will float and either have random values, be all zero, or be all one. There's no mechanism I can think of for reads and writes to "mirror" lower banks. To actually write to a chip, the CS line must be set for that socket, and the CS for the first RAM chip would not be set if you're writing to bank 64.

If the emulator is doing that now, I'm going to pin that down as an emulator bug, rather than the correct behavior of the final board.

Of course, if all 256 banks are populated, the test does not actually write to 0. It falls past the JNZ MEMTEST1 and sets the top bank to $FF.

as to using MEMTOP... @SlithyMatt explained above that it doesn't always work.

The behavior of ramtas, which is what initializes memory and detects the number of banks and reports the total memory at bootup, seems to rely on it working this way. If it doesn't work on actual hardware, wouldn't they have seen it in their testing?

Stefan · Post by **Stefan** » Sat Oct 17, 2020 4:07 am

On 10/7/2020 at 1:43 AM, TomXP411 said:

I don't think anyone has explained why that would be... if the chips aren't populated on the board, then the lines will float and either have random values, be all zero, or be all one. There's no mechanism I can think of for reads and writes to "mirror" lower banks. To actually write to a chip, the CS line must be set for that socket, and the CS for the first RAM chip would not be set if you're writing to bank 64.

If the emulator is doing that now, I'm going to pin that down as an emulator bug, rather than the correct behavior of the final board.

Of course, if all 256 banks are populated, the test does not actually write to 0. It falls past the JNZ MEMTEST1 and sets the top bank to $FF.

as to using MEMTOP... @SlithyMatt explained above that it doesn't always work.

I agree that it's unlikely that the hardware chip select wraps around to skip unpopulated memory. At the beginning of this thread, I also assumed that we would see random, ff or 0 on the data bus when reading unpopulated memory. I guess we just have to wait and see when the board is done. Reading a recent post by @Lorin Millsap elsewhere on this site, it is a work in progress. Maybe the Board works in mysterious ways ?

Lorin Millsap · Post by **Lorin Millsap** » Sat Oct 17, 2020 4:12 am

On that, the RAM works perfectly.

For unpopulated chips there is no wrap around or skip. Reads from unpopulated chips will give erratic results, mostly random residual values.

To check how much ram is present you need to write a non-random sequence then attempt to read that sequence back. If the sequence returned matches the sequence written that RAM is populated. Otherwise it is either unpopulated or there is a fault.

Sent from my iPhone using Tapatalk

m00dawg · Post by **m00dawg** » Mon Jan 04, 2021 5:32 am

I wonder, it's not for me to say given my level of programming skills here, but that's something that might be convenient to do at boot-up and store the results somewhere in the BASIC RAM space (or somewhere) so applications can easily reference that without having to write similar memory detection routines? It would be neat to see the X16, while paying homage to the Commodore 8-bit machines, counting RAM at boot like a PC ? Or if not at boot maybe having something in ROM that can be called so as not to consume any program space to do this?

Apologies for a "gosh it would sure be nice if..." sort of post I'm not qualified to implement myself but thought I'd toss that out there just the same since I'd imagine there would be several potential applications that might want to know how much RAM there is to work with including several apps being discussed outside of this one (such as trackers, games, etc.).

Lorin Millsap · Post by **Lorin Millsap** » Mon Jan 04, 2021 5:37 am

I’m sure we can do that. I think it should be an official feature request.

Sent from my iPhone using Tapatalk

Cyber · Post by **Cyber** » Mon Jan 04, 2021 7:08 am

On 10/17/2020 at 7:12 AM, Lorin Millsap said:

For unpopulated chips there is no wrap around or skip. Reads from unpopulated chips will give erratic results, mostly random residual values.

To check how much ram is present you need to write a non-random sequence then attempt to read that sequence back. If the sequence returned matches the sequence written that RAM is populated. Otherwise it is either unpopulated or there is a fault.

Sounds logical and simple, but a bit weird to me. ) May be just because a never needed to check ram presence in my programming experience.

Since I heard about such technique for the first time, now I'm curious: is this a common approach in many different systems?

As far as I understand, this is a thing for early and simple chips. If I'm not mistaken, modern more complicated chips contain small fixed info in them, so you can just try read this info, and not only check the chip presence, but also immediately identify its capacity and other parameters. And in most modern systems this is done by BIOS and not by the user. Am I understanding this correctly?

Ender · Post by **Ender** » Mon Jan 04, 2021 8:38 am

2 hours ago, m00dawg said:

I wonder, it's not for me to say given my level of programming skills here, but that's something that might be convenient to do at boot-up and store the results somewhere in the BASIC RAM space (or somewhere) so applications can easily reference that without having to write similar memory detection routines? It would be neat to see the X16, while paying homage to the Commodore 8-bit machines, counting RAM at boot like a PC ? Or if not at boot maybe having something in ROM that can be called so as not to consume any program space to do this?

Apologies for a "gosh it would sure be nice if..." sort of post I'm not qualified to implement myself but thought I'd toss that out there just the same since I'd imagine there would be several potential applications that might want to know how much RAM there is to work with including several apps being discussed outside of this one (such as trackers, games, etc.).

Well, as @SlithyMatt pointed out above, you can get it by peeking $25B, at least until the ROM is changed and things are shuffled around. That shouldn't be an issue in the future when things are solidified.

m00dawg · Post by **m00dawg** » Mon Jan 04, 2021 2:47 pm

I was up too late as it was yesterday so didn't log the feature request until today, though I put it here. Hopefully that's the right place for it!

JimmyDansbo · Post by **JimmyDansbo** » Mon Jan 04, 2021 5:39 pm

I was playing around with the -ram option for the emulator. It seems that it can only be used with the following values: 8, 16, 32, 64, 128, 256, 512, 1024, 2048

I dived into debugging a call to to RAMTAS and found that one of the functions it performs is to figure out how much memory is available. It does this by "walking" a bit through RAM BANK selector i.e. VIA#1 Port A.

It checks memory like this:

Quote

Set RAMbank = $00

Store $00 to address $A000

Set RAMbank = $01

Loop:

Load value from $A000 and save it.

Write $01 to address $A000

Set RAMbank = $00

Compare $A000 with $01

If it is equal, the number of RAMbanks has been found

Restore value to $A000

Return with the RAMbank number

else

Shift value in RAMbank left ; $01->$02, $02->$04, $04->$08, $08->$10, $10->$20, $20->$40, $40->$80

Jump back to Loop.

As can be seen from above, the function tests if a RAM bank is mirrored in order to figure out how many RAM banks are available.

On 10/17/2020 at 6:12 AM, Lorin Millsap said:

For unpopulated chips there is no wrap around or skip. Reads from unpopulated chips will give erratic results, mostly random residual values.

It seems the RAMTAS function needs to be re-written in order to be able to handle that memory is not mirrored. As RAMTAS is a function from the C64 KERNAL, I expect it to be rewritten to handle the fact that missing memory is not mirrored.

Since MEMTOP relies on the values provided by RAMTAS, do we need anything else to tell us how much memory is in the system?

When a physical system arrives, it might be good to have some software that can actually test the banked memory, but for that I have submitted a fast RAM tester here:

Lorin Millsap · Post by **Lorin Millsap** » Mon Jan 04, 2021 6:30 pm

I was playing around with the -ram option for the emulator. It seems that it can only be used with the following values: 8, 16, 32, 64, 128, 256, 512, 1024, 2048
I dived into debugging a call to to RAMTAS and found that one of the functions it performs is to figure out how much memory is available. It does this by "walking" a bit through RAM BANK selector i.e. VIA#1 Port A.
It checks memory like this:
Set RAMbank = $00
Store $00 to address $A000
Set RAMbank = $01
Loop:
Load value from $A000 and save it.
Write $01 to address $A000
Set RAMbank = $00
Compare $A000 with $01
If it is equal, the number of RAMbanks has been found
Restore value to $A000
Return with the RAMbank number
else
Shift value in RAMbank left ; $01->$02, $02->$04, $04->$08, $08->$10, $10->$20, $20->$40, $40->$80
Jump back to Loop.

As can be seen from above, the function tests if a RAM bank is mirrored in order to figure out how many RAM banks are available.
It seems the RAMTAS function needs to be re-written in order to be able to handle that memory is not mirrored. As RAMTAS is a function from the C64 KERNAL, I expect it to be rewritten to handle the fact that missing memory is not mirrored.
Since MEMTOP relies on the values provided by RAMTAS, do we need anything else to tell us how much memory is in the system?
When a physical system arrives, it might be good to have some software that can actually test the banked memory, but for that I have submitted a fast RAM tester here:

A bunch of things in this need to be fixed. So firstly the banking is not handled by the vias. Banking is handled by ZP locations $00 and $01. The emulator does not currently reflect this. The next revision will fix this.

And yes missing memory does not mirror so that is incorrect behavior by the emulator.

Sent from my iPhone using Tapatalk