Question about available memory

[H4plo]

Hi all,

 

I read somewhere that the available RAM is from $2000 to $A000. My game (.XEX) uses $2000-$B3FF, however, it works fine on the emulator (Altirra) on all the configurations I have tried. Is it OK to leave it like this, or some additional steps are required? Just want to make sure that the emulator is not playing nice and giving me RAM where there is none.

 

Thanks.

[+Eyvind Bernhardsen]

You’re fine as long as no cartridge is inserted. 8KB cartridges use $A000-$BFFF, 16KB carts (or 800 “right” carts) additionally use $8000-$9FFF.

That’s why a lot of games used to tell you to “REMOVE CARTRIDGE”; they needed that RAM to be available. 

[Rybags]

$2000 lower limit is a general figure for when a DOS is present.

Without Dos you can assume $600 though up to $680 can potentially be overwritten by the input buffer in some cases.

If no language processor is present and certain other conditions you can potentially use memory from $400.

[H4plo]

Thanks. So if I understand correctly there is RAM available at $A000-$BFFF, but if a cartridge gets inserted it will be bank-switched to ROM. 

[+Eyvind Bernhardsen]

36 minutes ago, H4plo said:

Thanks. So if I understand correctly there is RAM available at $A000-$BFFF, but if a cartridge gets inserted it will be bank-switched to ROM. 

That’s correct. Note that older 800s and 400s might have less than 48KB of RAM, in which case there’s no RAM to be switched in. Those machines won’t be able to run your program. 

[H4plo]

8 minutes ago, Eyvind Bernhardsen said:

That’s correct. Note that older 800s and 400s might have less than 48KB of RAM, in which case there’s no RAM to be switched in. Those machines won’t be able to run your program. 

Thanks. Should I worry about this? Or is it normal/accepted for games not to run on those old variants?

[baktra]

3 hours ago, H4plo said:

Thanks. Should I worry about this? Or is it normal/accepted for games not to run on those old variants?

Your game requires around 37 KB of RAM, which means you are targetting 48 KB original machines and 64 KB  XL/XE machines. That is mainstream.

The only machines left behind are Atari 400 and Atari 600XL without memory upgrades. And these are rare configurations, because I would bet that whoever owns the 400 or 600XL for practical use, has them upgraded to either 48 KB or 64 KB.

 

When it comes to cartridge presence, it depends how nice you want to be to the users.

It is generally considered acceptable not to be that nice and just hang/crash when a cartridge or XL/XE internal BASIC is present. Especially if your accompanying documentation clearly states what are the system requirements and that cartridges must be disabled.

 

You can be nicer, detect a cartridge and display a friendly message. Even more nice is to detect BASIC on XL/XE models and disable it automatically.

Will cost you a piece of code executed using the INITAD vector.

 

So rather than focusing at RAM requirements, I would recommend focusing at the following:

 

1. Compatibility with PAL and NTSC machines (if the intention is to run on both)

2. Compatibility with both original 400/800 OS ROM and XL/XE OS ROM. Altirra's debugger can detect illegal OS jumps and help you with this.

3. Checking if the game (if shipped just as a binary load file) can be loaded by popular DOSes (DOS 2.5) or binary loaders (MyPicoDOS and similar). Given the memory areas used, it is likely to be loadable by many DOSes.

 

If the last address is $B3FF, then it doesn't interfere with display RAM and display list used by the screen editor on >=48 KB machines, so you do not have to take extra measures.

 

Edited November 24, 2023 by baktra

[Rybags]

It's pretty well accepted that cartridges need to be removed before running most games or application software.

In any case, it's only really language carts that allow a disk boot.

[+Eyvind Bernhardsen]

5 hours ago, baktra said:

Will cost you a piece of code executed using the INITAD vector.

I _think_ it’s okay to just write 3 to PORTB as a segment of the load file (start address PORTB, end address PORTB, 3), which most assemblers can generate.

[baktra]

30 minutes ago, Eyvind Bernhardsen said:

I _think_ it’s okay to just write 3 to PORTB as a segment of the load file (start address PORTB, end address PORTB, 3), which most assemblers can generate.

 

I don't believe that is the best solution.

 

Firstly, forcing a specific value in PORTB can interfere with binary loaders that use buffers in the RAM under ROM, or extended RAM.

Secondly, disabling BASIC requires updating some system vectors, like RAMSIZ and RAMTOP.

Thirdly, the E: device at IOCB#0 needs to be closed and opened (or at least closed and the screen disabled), otherwise your binary load file would load into the display list and screen RAM (when BASIC is enabled, it is around $A000) causing screen glitches.

 

I am using the following sequence. I just disable the screen and close the E: device, but I have another INIT code that establishes a loading screen. Instead of that other INIT code, you can simply re-open the E: device for IOCB#0.

        lda #0               ;No screen
        sta SDMCTL

        ldx 20               ;Vertical sync
@w1:    cpx 20
        beq @w1	

        ldx #0               ;Close E: device
        lda #CLOSE
        sta ICCOM,X
        jsr CIOV

        lda PORTB            ;Disable BASIC ROM
        ora #2
        sta PORTB
        lda #1               ;Set basic flag
        sta BASICF
        lda #192             ;Set new RAMTOP and RAMSIZ
        sta RAMTOP
        sta RAMSIZ 
        sta MEMTOP+1
        lda #0
        sta MEMTOP
        rts

 

Again, up to you, if you want to bother with this or not. And this will obviously not work with pre-XL/XE machines.

Edited November 24, 2023 by baktra

[baktra]

Full solution here:

 

[H4plo]

Thanks everyone. With some optimisations I was able to bring the end address back to $9E99. This is a port of one of my C64 games; I had a couple of big loops unrolled in the light rendering path for performance reasons, but Atari runs almost twice as fast as C64 and there was no need to keep those loops unrolled (actually it turned out it wasn't even necessary on C64, but I kept it that way anyway).

 

I'll keep your advice in mind for my next game.