Count your RAM banks

[Screech]

Thanks for that update. I looked for about an hour and couldn't find how to read the Acculumator from BASIC. I knew it was a zero page location but couldn't find it.

[mortarm]

How does doing the same thing in 12 lines make it more elegant than doing it in six?

[DragWx]

How does doing the same thing in 12 lines make it more elegant than doing it in six?

The first method relies on non-existent RAM reading back as $A0 due to bus capacitance when reading from address $A000, while also being vulnerable to RAM actually existing but "accidentally" being set to $A0, which will cause a false positive.**

The second method uses the built-in Kernal routine for detecting how much RAM is present, no BASIC reimplementation required, and since it's a Kernal routine, we're allowed to assume it'll always return the right answer.



** I'd try reading $A000, rewriting the result XOR $FF, rereading $A000 to see if it worked, then rewriting the original value back to $A000. This would remove both the reliance on bus capacitance (which I would never trust, no matter how reliable it appears to be), and the false positive.

[ahenry3068]

How does doing the same thing in 12 lines make it more elegant than doing it in six?

The first 5 lines was some nice setup to make the code readable and understandable
(also part of elegance). Also setting up the Alias's for the register Cache's could be useful
further down the line in program code.

I could have done it in ** !! 1 !! ** Line of code.
REM GET BANKED RAM. 60 POKE $30F,1: SYS $FF99:BC=PEEK($30C):IF BC=0 THEN BC=256 110 PRINT "TOTAL BANKS";BC 115 PRINT "HIGHEST BANK #";BC-1 120 PRINT BC*8192;" BYTES OF HIRAM"

[mortarm]

The first method relies on non-existent RAM reading back as $A0 due to bus capacitance

I'm not familiar with that.

[DragWx]

The first method relies on non-existent RAM reading back as $A0 due to bus capacitance

I'm not familiar with that.

"Bus capacitance" is like if you shouted into an alleyway, heard your own voice echo back at you, and mistook that for being another person responding to you.


When the CPU encounters the opcode LDA $A000, it's encoded as the bytes AD 00 A0 in the program.

After reading that last A0 byte from memory, the CPU will actually make a fetch to the address $A000. If there's nothing there to actually put data on the bus (like a missing RAM chip), then the bus will still have a faint "echo" of the A0 byte from before, which is what gets read back by the CPU.

Reading $A100 will give you $A1, reading $BCDE will give you $BC, and so on.


This behavior can seem reliable, but since it's technically interference and not an intentional feature, there's a billion random things that can affect it, and an unrelated board revision can eliminate it entirely, which is why I said I wouldn't trust it.