How would I reliably detect the amount of RAM, including Fast RAM?

Question

If I was to write an Amiga game, what would be the best/most reliable way to detect how much RAM is actually available?

Looking at Action's Guide to AGA-Fixing!, he mentions Faulty Memory Detection:

   move.l   #0,$0
   move.l   #$aaaaaaaa,$200000  ;Poke in $200000
   cmp.l    #$aaaaaaaa,$200000  ;Re-read to check valid address
   bne      NoFastAt200000
   cmp.l    $0,$200000          ;Test the mirror effect
   beq      NoFastAt200000

I do wonder though if that's a good way to work across all Amigas, from an original A1000 with 256k Chip RAM to an A4000 with 2MB Chip and 4MB Fast RAM. Also, I don't see how that would tell me how much Fast RAM is available.

I saw AvailMem and AllocMem in exec.library, though I wonder: Will that work even if I don't load Workbench? (That is, if my game boots from a Floppy disk directly - though from my understanding, exec.library is always around, since it's part of Kickstart)

For my specific need, I really only care about detecting if I have 512k or 1MB RAM available on a regular Amiga 500 with Kickstart 1.3, but I would like to make sure that the code works on other Amigas, including an A4000 with Kickstart 3.1 and Fast RAM.

Answer 1

If I was to write an Amiga game, what would be the best/most reliable way to detect how much RAM is actually available?

The routine you're quoting is only able to detect chip memory (not fast memory), by hardware banging in certain areas. Games sometimes tried $C00000 (popular slow memory location) in the same fashion. But there are too many fast memory configurations to try to detect them that way. The system doesn't do like that (autoconfig works better, and other non-autoconfig boards have software that declare the available memory areas to the system)

Games sometimes did that on the $200000 address without checking the mirror effect (because they didn't expect chip memory to be more than one megabyte). And that failed.

But even games that end up taking over the system use AllocMem on boot (with MEMF_CHIP or MEMF_FAST) to get a base value, mask it to try to guess the start of the memory (and then destroyed the OS). It worked rather well on boot because no other program is using up any memory at this point.

And games not taking over the system can just use AvailMem with MEMF_LARGEST flag combined to MEMF_CHIP or MEMF_FAST to try to predict if the subsequent allocations that they're going to perform are going to succeed (else they can print an error message and exit). A lot of games don't predict it and if there isn't enough memory the game will fail at a random point of the game...

    move.l 4,A6
    move.l #MEMF_CHIP|MEMF_LARGEST,d1
    jsr  _LVOAvailMem(a6)
    cmp.l #$80000,d0
    bcc.b  .one_meg
    ; 512k only
    ...
.one_meg

MEMF_LARGEST is not absolutely necessary. It just tells that you can allocate that much memory in one go and it will succeed. Useful when you want to manage the memory block yourself after that.

For fast memory, using MEMF_LARGEST will return the biggest contiguous memory block. It means that if there are different fastmem areas (Z2 & Z3, slow), you'll only get the biggest one. Use just MEMF_FAST alone to get the total available fast memory amount.

Unlike some other libraries that need some initialization, the exec library functions are available as soon as the system is running. It works from a disk custom boot sector too.

Another way (maybe cleaner) is to check exec MaxLocMem, which provides top of chipmem ($80000 for 512k, $100000 for 1 meg, ...)

move.l 4,A6
move.l MaxLocMem(a6),d1
cmp.l  #$100000,d1
bcs.b  .not_one_meg

The only drawback is when you configure WinUAE with more than 2MB chip, MaxLocMem doesn't reflect the chipmem size you configured. But that's a corner case among cornercases (the AvailMem method works even in that case)

Answer 2

I do wonder though if that's a good way to work across all Amigas, from an original A1000 with 256k Chip RAM to an A4000 with 2MB Chip and 4MB Fast RAM.

No, it's a very bad way. This code can only be safely used if you have killed the OS and taken over completely - then you have to be aware of all possible differences between machines, including additional memory and I/O cards, different CPUs etc.

I saw AvailMem and AllocMem in exec.library, though I wonder: Will that work even if I don't load Workbench?

Yes (provided you didn't kill the OS by eg. overwriting allocated memory). For greatest compatibility your game should be run from the startup-sequence (if not from an icon on Workbench) rather than from bootblock code, then users can add commands before it if necessary to enable non-autoconfig RAM etc.

You should try to use the OS as much possible in order to support various features of the machine that may have different hardware implementations. Avoid code that accesses absolute memory locations or pokes into memory that doesn't belong to it, and only access I/O ports directly after claiming them for your exclusive use.