Commander X16

Per this post, it could be very convenient to have a standard routine, say in ROM, that folks can call in their program that will report the available amount of RAM on the system. This avoids folks having to program this into their own programs and provides a standard method for reporting the RAM usage. Many types of programs could use this feature. In the case of the linked post, it was for a text edit / word processor; but games, trackers, really many apps that are using banked RAM.

The perk of the routine in ROM is it only has to be used if needed; but another thought was to have the system scan the available RAM at boot and report this as a variable within the BASIC RAM area. Then programs, upon startup, can look at this address and know the amount. And it could be a fun start-up sequence that is much like older PC BIOS startups, in a small twist of irony given the X16 is a VIC-20 spiritual successor ?

One or both methods would allow programs to have less duplication and more standardization. Certainly a nice to have, but not a need to have though would certainly add creature comforts, particularly given how much ROM space is available.

Exhaustively checking all RAM like in that 'pc bios startup' adds a significant startup delay that should not be there for a machine that was meant to be instantly ready after poweron.

But just probing a single address in all 64 possible banks is a really fast way I think to determine how many banks are available... (and just assume the ram isn't bad)

7 minutes ago, desertfish said:

Exhaustively checking all RAM like in that 'pc bios startup' adds a significant startup delay that should not be there for a machine that was meant to be instantly ready after poweron.



But just probing a single address in all 64 possible banks is a really fast way I think to determine how many banks are available... (and just assume the ram isn't bad)

There's a few methods outlined in the other post. There's certainly a few tricks, though that said, given the speed of the system, I did some quick math and I don't think it'd take more than a handful of seconds. It would also verify the RAM is in a known good state. Time permitting, I might write a quick program to see how fast it takes to scan all of memory.

But that said, a kernel routine could be useful to do either an exhaustive or probe check that programs can use if the instant-on was highly desirable (I personally don't have a problem if it takes a few extra seconds on a cold power on but also don't have strong opinions there).

Ramtas currently does as desertfish says at bootup to probe all 64 possible banks to get the number of RAM banks.  Taken from the ROM source, in kernal/drivers/x16/memory.s:

Quote

 ; detect number of RAM banks

 ;

     stz d1pra

     ldx $a000

     inx

     lda #1

 :   sta d1pra

     ldy $a000

     stx $a000

     stz d1pra

     cpx $a000

     sta d1pra

     sty $a000

     beq :+

     asl

     bne :-

 :   tay

     stz d1pra

     dex

     stx $a000

 

     tya ; number of RAM banks

Unfortunately, this routine also does a bunch of initialization stuff that you wouldn't want to call outside of bootup.  However, the value gotten in the routine above is ultimately stored in $25B.  As my post in the thread you linked says, memtop ($ff99) returns the RAM banks available in A by retrieving $25B, as long as you set the carry flag first.  So, you can currently get the number of RAM banks by calling memtop, which is the safe way since its address is always guaranteed to be $ff99, or you can look at $25B directly, but this is less safe since kernal development is not over so this address could change. However, this is an easy way to do it in BASIC, and once development is over the address won't change.

Sorry if this isn't what you're asking for. I'm a little confused, since memtop seems to fit your request.

Ah admittedly the back and forth in the other post got me a little confused, since there may also be a bug / issue with it being after boot? But yeah it sounds like this is already implemented if I understood you correctly, which is aces!

But that does confuse me in the other post - correct me if I'm wrong, there wouldn't then be a need to do any work to figure this out within an app? If my app needs to know how much memory is available, I just use memtop as you suggest (by calling $ff99) or optionally looking at $25B (or whatever the final address will be) and I'm good to go?

53 minutes ago, m00dawg said:

I just use memtop as you suggest (by calling $ff99) or optionally looking at $25B (or whatever the final address will be) and I'm good to go?

That should do it ?

2 hours ago, m00dawg said:

Ah admittedly the back and forth in the other post got me a little confused, since there may also be a bug / issue with it being after boot? But yeah it sounds like this is already implemented if I understood you correctly, which is aces!



But that does confuse me in the other post - correct me if I'm wrong, there wouldn't then be a need to do any work to figure this out within an app? If my app needs to know how much memory is available, I just use memtop as you suggest (by calling $ff99) or optionally looking at $25B (or whatever the final address will be) and I'm good to go?

Yup, you'd just set the carry flag, call $ff99, and it sets A, X, and Y. A contains the number of banks, and X and Y contain the address of the end of lower memory (which is currently $9F00).  Or if you're in BASIC, you can just do "PRINT PEEK($25B)".  The confusion in the other thread arose because Slithymatt hadn't set the carry flag first (if you don't set the carry flag before calling it, it sets the RAM bank number and address of the end of lower RAM to the passed in A, X, and Y instead of getting it).

5 hours ago, m00dawg said:

Ah admittedly the back and forth in the other post got me a little confused, since there may also be a bug / issue with it being after boot?

It got me confused as well, which is why I mistakenly labeled it a bug. I was not aware of the carry bit behavior, which messes things up. If you call MEMTOP with the carry bit cleared, it will erase the value at $25B, so you just have to make sure it was last called with C set first.