Commander X16

OK. I will use MEMTOP. It seems to work in emulator r38 on macOS. 

One more question though.

That Kernal function returns the number of banks, for instance $40 (64) with banks 0-$3f populated.

What will it return if all banks are populated? I suppose it might wrap around to zero.

Good question. I just tested it with starting the emulator with "-ram 2048" and yeah, it looks like it returns 0.

5 hours ago, Ender said:

Good question. I just tested it with starting the emulator with "-ram 2048" and yeah, it looks like it returns 0.

Just to try it out, I tested it with 1024 and got $80, and then attempted to run with zero banked RAM, but the emulator didn't allow that. I think it's a safe assumption that nobody is going to entirely de-populate the banked RAM and then expect any software to actually work, including the kernal and BASIC, which depend on bank 0 to be present. So, 0 = 2MB should be a safe assumption for the programmer.

I wasn't aware of the -ram option.

I don't think it's mentioned in the emulator docs. But I can see it's in the emulator -help.

The emulator seems to accept any -ram value dividable by 8 between 8 K and 2048 K.

However, as I understand, the hardware will have four memory IC slots of 512 K each, and the only possible values in real life would then be 512, 1024, 1536 and 2048 K.

Maybe the best solution is to support all memory size options available in the emulator, even though only four of those options will be supported by the hardware.

16 hours ago, Stefan said:

I wasn't aware of the -ram option.



I don't think it's mentioned in the emulator docs. But I can see it's in the emulator -help.



The emulator seems to accept any -ram value dividable by 8 between 8 K and 2048 K.



However, as I understand, the hardware will have four memory IC slots of 512 K each, and the only possible values in real life would then be 512, 1024, 1536 and 2048 K.



Maybe the best solution is to support all memory size options available in the emulator, even though only four of those options will be supported by the hardware.

This *should* do the job... I suppose I should go test it. ?



;

; MEMTEST

; Returns highest upper memory bank in A

; Preserves: None

;

MEMVAL = $AA ; 1010 1010 pattern. 

MEMTEST:

STZ $01   ; Set bank 1. Bank 0 is used by the KERNAL, so don't mess with it.

MEMTEST1:

LDA #MEMVAL  ; 1010 1010 pattern

STA $A000

LDA $A000

CMP #MEMVAL

BNE MEMFAIL

INC $00

JNZ MEMTEST1

LDA #$FF;

RTS  ; The full 2MB is available

; This bank failed. So subtract 1 and return the last bank that succeeded. 

MEMFAIL:

DEC $00 ; Select the previous bank, which passed

LDA $00 ; Get the selected bank

RTS  ; Returns the last available bank











 

 

On 10/4/2020 at 5:26 AM, TomXP411 said:

This *should* do the job... I suppose I should go test it. ?



;

; MEMTEST

; Returns highest upper memory bank in A

; Preserves: None

;

MEMVAL = $AA ; 1010 1010 pattern. 

MEMTEST:

STZ $01   ; Set bank 1. Bank 0 is used by the KERNAL, so don't mess with it.

MEMTEST1:

LDA #MEMVAL  ; 1010 1010 pattern

STA $A000

LDA $A000

CMP #MEMVAL

BNE MEMFAIL

INC $00

JNZ MEMTEST1

LDA #$FF;

RTS  ; The full 2MB is available

; This bank failed. So subtract 1 and return the last bank that succeeded. 

MEMFAIL:

DEC $00 ; Select the previous bank, which passed

LDA $00 ; Get the selected bank

RTS  ; Returns the last available bank











 



 

I think there might be a problem with this solution.

When you go beyond the last bank, it will first mirror bank 0, as @SlithyMatt pointed out above. For instance, if 64 banks are populated (bank 0-63), bank 64 will mirror bank 0.

I think your code will overwrite at least one byte of bank 0 that is used by the Kernal before you know that you have reached end of banked RAM, which is not a safe thing to do.

If you're going down the memory test lane, you might succeed by backing up the value of bank 0 address $A000, and restore it after the memory test is finished.

Or you may go easy on yourself and use the Kernal function ?

On 10/5/2020 at 12:31 PM, Stefan said:

When you go beyond the last bank, it will first mirror bank 0, as @SlithyMatt pointed out above. For instance, if 64 banks are populated (bank 0-63), bank 64 will mirror bank 0.

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. 

 

2 hours ago, TomXP411 said:

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

About that, I figured out what I was doing wrong. If you call MEMTOP with the carry bit clear, it will permanently blow away the values in RAM and replace them with whatever you have in A,X,Y. Just make sure you always do a SEC beforehand, and you should be good. Of course, you can't depend on another program not blowing it away before your program is run, so you may need to do a RAM test in that case or just document your requirement for the X16 to be reset prior to loading your program.

P.S. - This means that calling MEMTOP from BASIC is definitely NOT recommended.

18 minutes ago, SlithyMatt said:

If you call MEMTOP with the carry bit clear, it will permanently blow away the values in RAM and replace them with whatever you have in A,X,Y. 

Right.  MEMTOP doubles as a READ MEMTOP and SET MEMTOP based on CC.  MEMBOT is similar...