Were there any games/software that used memory beyond what was advertised available to BASIC on the machine?

Question

Were there any games/software that used memory beyond what was advertised as available to BASIC on the machine ?

• On home / personal computers any time up to 1984 .
• Without needing to plug in any additional hardware .

How common was it on home / personal computers of this era that assembly-code or BASIC could access more memory than what was advertised as available to BASIC on the machine (e.g. like storing non-video data on video-memory)?

Was there any other type of RAM that was normally not accessible to BASIC?

Added To Question
If a machine had 24k RAM, and only 18k of that available to BASIC, was that 8k empty, or, on any existing machines, was anything ( other than assembly-code which could use all of the 24k ) stored on there, if anything was stored on there, exactly why was it stored there .

An example, may be for the Bally Astrocade, using video memory, although I don't know any details / games / software .

Answer 1

The Commodore 64 advertises 38911 bytes free for BASIC upon startup. It's a 64kb machine. Non-BASIC programs could use the full 64kb rather than the ~38kb. Therefore using more memory than is available to BASIC was routine.

The difference was primarily that BASIC and the rest of the kernel don't need to be present, so if you're not using them then you can have some RAM instead.

Answer 2

Answers for the Apple II:

(Please have a look at this answer to understand the memory layout, and where the areas used by BASIC are placed).

1) Were there any games/software that used memory beyond what was advertised as available to BASIC on the machine?

Assuming that "advertised as available to BASIC" means "between $801 and DOS", then yes, machine code programs (games) would regularly use other free areas. In some cases they'd even overwrite DOS, making a reboot after the end of the program necessary. There were even BASIC programs which manipulated the memory layout of the BASIC areas themselves, for various reasons (for example, to have machine code subroutines as BASIC extensions).

2) How common was it on home / personal computers of this era that assembly-code or BASIC could access more memory than what was advertised as available to BASIC on the machine

See above, very common.

(e.g. like storing non-video data on video-memory)?

Actually, just having a lot of BASIC program code could already put BASIC code into video-memory, prohibiting the use of graphics (and it happened in practice).

3) Was there any other type of RAM that was normally not accessible to BASIC?

Yes, RAM in the so-called "language card", which was in the same place as ROM. A few games used that (e.g. Zork and other Infocom games), as well as non-DOS systems (UCSD Pascal).

Answer 3

For nearly all machines with BASIC, I would expect any non-BASIC programs to use BASIC's workspace. Also, people (inc me) would not allow the OS to get a look-in and use its memory too ;)

Answer 4

on ZX Spectrum 48K BASIC there are the PEEK and POKE commands which allow access to whole RAM/ROM. So any BASIC game can use the additional RAM. The memory map was this:

0000h ROM
4000h VRAM screen 
5800h VRAM attr 
5B00h buffer LP
5C00h  system variables
5CB6h  microdrive maps
CHANS  channels info
       00h
PROG   BASIC source code
VARS   BASIC variables
       00h
ELINE  editation line
       NL
       00h
WORKSP input data
       NL
       temp workspace
STKBOT calculator stack
STKEND free space
SP     stack
       GOSUB stack
       ???
RAMTOP 3Eh
UDG    user defined graphics
P-RAMT end of physical memory

where all the addresses defined with name instead of hex number are in system variables. As you can see the space after BASIC code is not empty. However you can use some parts if you carefull not to corrupt the BASIC system.

The most usual stuff that was used from BASIC outside its standard memory range was the UDG. It was few characters in the BASIC font that could be redefined to any graphics. So instead of printing text you could also print sprites or national characters instead however there where just few such characters IIRC 8.

It was also common to combine asm and BASIC so BASIC puts some user assembly code into free memory above BASIC (be POKE or by loading from tape,floppy,microdrive) and tehn call it time to time using RANDOMIZE USR addr...

If you want concrete example of BASIC game using RAM above BASIC the first that comes in mind was (CZ): Zedník má žízen in translation builder has thirst where you are Builder building a wall and your goal was to collect as many bears along the way as you could before your thirst got you (it gives you energy) but they where not for free so you need to build a wall to earn money too.

here screenshot from game the beers and builder are UDG characters printed by PRINT...

Answer 5

On the Amstrad CPC machines, the bottom and top of the address space was taken up by the firmware and the Basic ROMs respectively, each taking 16Kb from the 64kb, leaving 32kb for the programs and OS data. However they each shadowed 16KB of RAM. Each ROM could be paged in or out to allow full use of the memory. The setup allowed all writes to RAM, but reads were from ROM or RAM according to the selection. Thus you could read from Basic but write to screen memory at the same time, even though the addresses overlapped.

I should clarify that this was all specified in the firmware reference from Amstrad (Soft 968) and was standard for programmer not using BASIC: see section 2:

The upper and lower ROMs may be enabled and disabled separately. When the
upper ROM is enabled data read from addresses between #C000 and #FFFF is
fetched from the ROM. Similarly, when the lower ROM is enabled data read from
addresses between #0000 and #3FFF is fetched from the ROM. When the ROMs
are disabled data is fetched from RAM.
Note that the ROM state does not affect writing which always changes the contents
of RAM.

Answer 6

On the BBC Micro, the operating system has the explicit concept of "language ROMs", of which BASIC was the most obvious example. Other "language ROMs" available included word processors and other business software, as well as other programming languages. Some parts of the memory map were explicitly reserved "for the active language", while others could be allocated dynamically, and still others were reserved to support operating system functions. It was a very sophisticated system for an 8-bit micro.

Typically, the area from &1900 (PAGE) to &7C00 (HIMEM) exclusive was available to BASIC programs, assuming a machine with floppy drives fitted and in the most frugal display mode. Switching to the tape filing system allowed reducing PAGE to &E00; selecting a graphics display mode would however reduce HIMEM automatically, perhaps as low as &3000.

On the 6502, zero-page memory is also important; normally &70-&8F was available to user assembly code without affecting BASIC or other system functions. This was technically part of the "reserved for language" area, but BASIC guaranteed that it would not use that area, limiting itself to &00-&6F inclusive.

A game requiring a lot of RAM could easily supplant BASIC, and thereby use all of the "reserved for language" space as well as all the RAM that BASIC normally allocated (dynamically) to itself. After the load was complete, the game could also overwrite RAM allocated for the filing system. Such games would need to reinitialise both the filing system and BASIC on exit; most simply didn't provide this function, and expected the user to reset the machine by pressing BREAK.

Obviously these options were not available to a game written in BASIC. But most games that needed a lot of RAM were already written in assembler for speed reasons.

A few later games took advantage of the expanded capabilities of the BBC Master or even the Master Turbo - but these machines didn't appear until 1986. On the Master Turbo, the game itself would run in the Second Processor with 62KB RAM available, and also load part of itself into the "host" which was the Master itself. The best known of the games which could do this was Elite.

Answer 7

The TI-99/4 and /4A computers had a rather unique arrangement where their BASIC interpreters used the 16KiB of memory attached to the system throuh the video adapter as their store both for program code and data, ignoring the memory attached to the main bus. Admittedly on an unexpanded system there was only 256 bytes of that, and most of it would have been used as temporary storage (the processor registers were mapped into it, and the machine code call stack used it too), but some of it would likely not be used by BASIC. Machine code programs (ie game cartridges - there was no way to execute machine code via BASIC) could have used that in addition to the video memory.

Another potentially usable memory location would be the section of video memory used for storing character bitmaps. BASIC provided a way to modify this memory but not read it, but other programs running on the system could have read it when necessary. If the character wasn't used on screen the bitmap could obviously be changed without consequence. Memory was reserved for 128 character bitmaps (112 if the Extended BASIC cartrige was used), so most non-graphical programs didn't use all of them.

Of course, most end-user non-BASIC programs didn't need to resort to this, as the only available options to load and execute such a program required a memory expansion (eiher the 32KiB memory expansion card or the 4KiB "mini-memory" cartridge-based RAM expansion), and the built-in BASIC wouldn't use either (Extended BASIC used the 32KiB card if present but couldn't be used withthe mini-memory cartridge).

Answer 8

The Oric Atmos 48k advertises 37361 bytes free at startup, and PRINT FRE(0) prints 37628 which is pretty much the same value.

But there was a GRAB command that allowed to use "hires" video memory and then FRE(0) went up to 44796 bytes so 7 kb more. This corresponds to the area $9800..$B400 that is no longer used by hires mode plus relocated text bitmap data.

So programs using only text mode could use 44kb of BASIC memory (assembly could use that memory too of course, but that was already the case even without GRAB as long as hires mode wasn't activated, GRAB offers extra safety, preventing the mode to be switched to hires to avoid destruction of this memory).

This command also works for 16Kb Oric 1 & Atmos. The amount of total memory is of course much lower.

Answer 9

ZX Spectrum clone Didaktik Gama has 80KB RAM, there are two top 32KB banks. The BASIC is an almost exact copy of ZX Spectrum 48K BASIC, without any direct possibility to use the other bank.

The banks could be switched by OUT 123,0 or OUT 127,1. There are however some subtle differences between the first model and the following ones:

• Didaktik Gama '87 BASIC did not care. If the RAMTOP is above #7FFF and you switch the bank, it will crash, because you yanked the stack away.
• Later models patched the OUT BASIC command and if the port is 127, the ROM routine will copy the original bank to the one being switched into, up to RAMTOP (took a fraction of a second). Thus the banks were "mirrored" and the RAM was not usable.

Though, technically speaking, if you set the RAMTOP to be less than #8000 (the first model) or less than the default (later models), you can use POKE, PEEK and OUT to access the memory. While true, this is not in the spirit of the original question.

Very little widespread software was using the second bank (unless written individually, e.g. since the second bank survived RESET, I put a fast tape loading routine there and then it was a matter of CLEAR & OUT & PRINT USR to initialize it). In fact, I am aware only of GAMA COPY 80, a tape copying program.