Memory Maps

Memory maps for the various systems supported in 8bit-Unity are shown here, together with detailed information of the location and quantity of memory available for game code and assets. Some of the memory ranges can be modified by editing the “.cfg” files in /unity/ sub-folders. In any case, blocks should not overlap grey areas of the maps, as they are used for System/ROM (the computer will crash).

Apple //e

The APPLE has two memory blocks for code, and single blocks for sprite and music (DUET) data. The Double-HiRes (DHR) graphic mode used in 8bit-Unity has a fixed memory location at $2000 both in MAIN and AUX memory (80 columns card).

  • Game code: blocks $0803-$1fff / $4000-$a7ff (22,784+2,048+7,156 = 31,988 bytes)
    (1st block defined as STARTADDRESS and LOW in apple2-hgr.cfg)
    (2nd block defined as __HIMEM__ and HIGH in apple2-hgr.cfg)
  • Sprite data: block $a800-$bbff is available (5,120 bytes)
    (defined as SPRITERAM in unity.h)
  • DUET data: block $bc00-$beff is available (768 bytes)
    (defined as MUSICRAM in unity.h)
  • Bitmap data: automatically loaded to 2 memory block (8,192 bytes in MAIN memory)
    (defined as BITMAPRAM in unity.h)

Hints: Up-to 768 bytes of memory can be recovered for sprites by using a small (or no) DUET file. To do this, edit the first 2 bytes of address in the M music file and increase the value of MUSICRAM accordingly. If more memory is required for code, offset the location of SPRITERAM and MUSICRAM, then increase __HIMEM__ accordingly.

Atari XL/XE

The ATARI has several memory blocks for code, RMT and sprite data. Bitmap data is automatically loaded to 2 separate blocks by the function LoadBitmap(filename). Each block contains a single 4 color frame. A DLI routine (see DLI.a65) switches between these frames every screen refresh, producing a virtual palette of 9 blended colors. The DLI also handles 5th sprite flicker, while a VBI routine handles RMT music playback (see RMT.a65).

  • Game code: blocks $0c00-$65ff / $d800-$dfff / $e400-$fff4 (22,784+2,048+7,156 = 31,988 bytes)
    (1st block defined as STARTADDRESS and __HIMEM__ in atarixl.cfg)
    (2nd and 3rd blocks defined as HIDDEN_RAM2 and HIDDEN_RAM in atarixl.cfg)
  • Sprite data: block $9000-$93ff is available (1,024 bytes)
    (defined as SPRITERAM in unity.h)
  • RMT data: block $9400-$9aff is available (1,792 bytes)
    (defined as MUSICRAM in unity.h)
  • Bitmap data: automatically loaded to 2 memory block (16,384 bytes)
    (defined as BITMAPRAM1 and BITMAPRAM2 in unity.h)
  • DLI/RMT routines: block $6600-$6fff (2,816 bytes)
    (see DLI.a65 and RMT.a65)

Hints: In your C files, insert #pragma code-name(“SHADOW_RAM2”) or #pragma code-name(“SHADOW_RAM”) to load code in the 2nd and 3rd memory blocks. If more memory is required for sprite data, offset the location of MUSICRAM and keep your RMT file small enough to not overlap the upper boundary.

Commodore 64/128

The C64 conveniently has contiguous memory blocks for code, SID and sprite data. The bitmap data is automatically loaded to 3 separate blocks by the function LoadBitmap(filename).

  • Game code: block $1800-$afff is available (43,008 bytes)
    (defined as STARTADDRESS and __HIMEM__ definitions in c64.cfg)
  • Sprite data: block $c700-$cfff is available (2,304 bytes)
    (defined as SPRITERAM in unity.h)
  • SID data: block $0800-$17ff is available (4,096 bytes)
    (defined as MUSICRAM in unity.h)
  • Bitmap data: automatically loaded to 3 memory block (10,240 bytes)
    (defined as SCREENRAM, COLORRAM, BITMAPRAM in unity.h)

Hints: Up-to 4KB memory can be recovered for game code by using a small (or no) SID file. In such case, increase the value of __HIMEM__ and offset the value of STARTADDRESS accordingly. If more data is required for sprite data, try swapping the locations of SPRITERAM and MUSICRAM (and keep your SID file smaller than 2KB).

Atari Lynx

Oric 1/Atmos