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 .

  • there was something I heard about reading unpopulated memory locations on an Apple II to ascertain composite video sync state, but those are known unknowns (if the process even works at all)
    – scruss
    Commented Nov 16, 2019 at 18:52
  • Back then I read a diary by the paradroid developer in a magazine where he described how he would use the ram under the rom in the C64 to get more memory for his game. I was very impressed. Commented Nov 16, 2019 at 19:14
  • 4
    @Thorbjørn Sure, but that couldn't be considered anything unknown to developers; this exact technique was documented by Commodore themselves on page 261 of the Commodore 64 Programmers Reference Guide.
    – cjs
    Commented Nov 16, 2019 at 19:51
  • 1
    @scruss that's vapour lock — reading an address with nothing mapped to it, to obtain whatever was on the data bus in the previous half-cycle, to sniff the current position of the video beam (assuming you've put something sufficiently recognisable into video memory). I think that empirically it works on all the 8-bit Apple IIs; there are a few recent programs that use it, e.g. deater.net/weave/vmwprod/space_bars which mixes graphics modes and low-res pages based on raster racing.
    – Tommy
    Commented Nov 18, 2019 at 16:54
  • Not adding this as an answer because it's not strictly 'on the machine' but there are C64 demos and disk copiers that use the RAM and CPU on the 1541 disk drive for performing certain work.
    – Alan B
    Commented Mar 8 at 14:59

10 Answers 10


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.


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).

  • 1
    One aspect of Apple II's memory layout that made it quasi mandatory to change the basic addresses was the fact that the graphic memory was in the middle of address space $2000-3FFF for HGR and $4000-$5FFF for HGR2. If you let the basic start at $800 you would only have 6 Kbyte for basic+vars. If you put basic start at $4000 or $6000 you would still have more than 20 Kbyte depending on DOS. Commented Jun 11, 2020 at 14:02
  • @PatrickSchlüter: I wonder if there would have been any difficulty with putting 5K of the code for DOS code between $0C00 and $2000, and allowing four 256-byte buffers to be placed at either $800 or high memory depending upon whether code needs the second text/lores page.
    – supercat
    Commented Jun 13, 2020 at 19:58

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 ;)


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
PROG   BASIC source code
VARS   BASIC variables
ELINE  editation line
WORKSP input data
       temp workspace
STKBOT calculator stack
STKEND free space
SP     stack
       GOSUB stack
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 then 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 beers 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.

Zednik ma zizen

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

Zednik ma zizen

btw. that game was really stretching the RAM limits as it was really huge BASIC code (biggest BASIC program I ever saw on ZX)


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.


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.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.

  • 1
    While correct, the question asks about machines at "any time before 1984". The CPC 464 was released in 1984, the 664 and 6128 in 1985. Commented Jun 11, 2020 at 13:54
  • Shall I just edit the question to make my answer correct? 😉 Commented Jun 11, 2020 at 19:20
  • 1
    I'm kind of new here myself, but I think that's frowned upon. ;-) On the other hand, this question has seen so much editing that I guess it can't do any harm. Commented Jun 11, 2020 at 21:54
  • 2
    The original question text was hard to interpret but the 1984 could have been intended as inclusive. The word "before" was added by @wizzwizz4 during a rewrite for clarity. I've suggested editing the question to "up to 1984", which seems more true to the original intent to me, but my edit needs reviewing as this account is new.
    – occipita
    Commented Jun 13, 2020 at 8:19

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).


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 127,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.

  • I had self made small simplistic (few lines of BASIC) utility that preserved asm IDE and source code (Prometeus) so whenever I did something wrong After RESET I just wrote the few BASIC lines and restored original state (so I did not need to load the IDE and write the code again ...)
    – Spektre
    Commented Sep 22, 2022 at 9:51
  • The UK magazine "Your Spectrum" published plans for modifying a standard 48K spectrum in the same way -- the standard 48K spectrum put a 32K bank of RAM at 0x8000, but in many models used 64K chips to achieve this (the 32K chips the Spectrum was designed to use were 64K chips with half of the memory disabled due to faults, but AIUI there weren't enough faulty chips to meet demand, so many Spectrums ended up with fully working 64K chips instead), so the modification was very simple and didn't even need new memory chips in most cases.
    – occipita
    Commented Mar 24 at 12:46

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.


On the Radio Shack Color Computer tricks to utilize memory not traditionally available to BASIC programs were common after Radio Shack released the 32K and 64K RAM variants of the machine. Interestingly, most models of the computer sold as having 32K of RAM actually used 64K RAM chips, although the manufacturer of the chips apparently didn't guarantee the upper 32K of RAM would all work. In reality, the upper 32K of RAM was almost always fine, however the early variants of the 32K Coco didn't have the top (8th) address line connected to the RAM chips. Fortunately, it was a fairly simple modification to bend out the pin of that address line on each of the RAM chips and solder a wire to it. This mod was published in Coco magazines and very popular with users.

Soon after, Radio Shack released a new revision of the Coco's motherboard that did connect all the address lines so they would have the option of selling a 64K RAM machine when the chips came down in price.

Whether your Coco was a 32K model that came out of the box 64K-capable, required a mod to enable the extra 32K or was sold as a 64K machine, the same bit in memory toggled the BASIC ROMS out of the upper half of the memory map leaving a contiguous 64K of RAM that could be used by non-BASIC programs.

A popular trick for BASIC users was to input a BASIC program that would POKE the bytes of a short machine code program into memory and then jump to that code as a subroutine. This code would simply copy the BASIC interpreter from ROM into the same addresses of the underlying RAM and then return control to the BASIC program. From this point all kinds of useful modifications could be POKEd into the BASIC interpreter including adding entire new commands to the BASIC along with some quite extensive expanded capabilities. This was all pretty remarkable stuff for the early 80s and was quite popular with users not only because it was very useful but also because it was super fun to play around with.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .