Memory Map for Atari ST,STE,TT and Falcon

The memory map has to be split into parts due to its sheer size.

• Exception vectors and basic RAM & ROM locations
• System variables and low RAM
• IDE, Memory control & video
• DMA & SCSI
• YM, DSP & DMA Sound
• MFP, RTC & anything else
• The Cookie Jar

Or view all sections combined on a single page: Complete memory map listing

Datasheets, pinouts and reference documents: Reference documents and datasheets

Sources

These pages were checked against the following, in this order of preference. Where sources disagreed the entry is marked CONFLICT or CHECK on the page itself, with the reasoning given there.

Hatari — https://github.com/hatari/hatari
Cycle-accurate emulator, actively maintained. As an emulator it has to implement every bit correctly or software breaks, which makes its source the best available description of what the hardware actually does. Several of its chip implementations carry detailed comment blocks, and some of the blitter accuracy derives from reverse engineering and Verilog work by Jorge Cwik (ijor). Checked against commit e77819f, July 2026.

EmuTOS — https://github.com/emutos/emutos
Free TOS replacement, actively maintained, boots on real ST, STE, Mega ST, Mega STE, TT and Falcon hardware. Its headers define what a working OS needs to touch, and its .c files show how those registers are used in practice, which settles polarity questions that headers alone leave open. Also the only source here that knows about several add-on boards. Checked against commit bc34e0b, June 2026.

Atari TOS sources — https://github.com/th-otto/tos1x and https://github.com/th-otto/tos3x
Atari's own operating system sources, reconstructed by Thorsten Otto to rebuild the original ROMs. tos1x covers TOS 1.04, 1.06 and 1.62; tos3x covers 2.06, 2.08 and 3.06. This is Atari's own code rather than anyone's interpretation of it, so where it writes a value that value is correct by definition. Note that tos3x also contains one file of genuine TOS 4.04 Falcon code (bios/vsetmode.c), which is the only TOS 4.04 source known to exist. Checked against commits 7c6680d and c84ed76.

The Atari Compendium — Scott Sanders, SDS Publishing, Appendix B
http://cd.textfiles.com/ataricompendium/BOOK/PDF/APPENDB.PDF
The published reference, and the broadest single document: 500 addressed entries covering the whole address space, with bit level detail for around 170 of them. Careful and well organised, but it is a static document from the mid 1990s and does contain errors of its own.

Western Digital WD1772 data sheet — Western Digital, preliminary combined WD1770/1772 datasheet
Used for the floppy controller command set, alongside two other sources: DrCoolZic's edited datasheet (https://info-coach.fr/atari/documents/_mydoc/WD1772-JLG.pdf and his companion https://info-coach.fr/atari/documents/_mydoc/FD-HD_Programming.pdf) and the Acorn/BBC Micro "WD1770/2/3 data" reference file (http://bbc.nvg.org/doc/wd1770.txt). None of the three is reliable alone; each has errors the other two catch, including the WD original's own step-rate and settling-time tables. See Reference documents and datasheets for the full breakdown and the consolidated register reference.

Secondary documents

These were cross-checked against the four primary sources above rather than trusted on their own. Where one of them is the ONLY source for something, the entry on the page says so explicitly.

Atari STE ASIC schematics — https://www.keli.dk/old-asic/
Keli Hlodversson's trace of Atari's original hand-drawn GLUE/MMU (GST MCU) schematics, recovered and converted to PDF by Christian Zietz. This is the source for the undocumented GAMECART register at $FFFF9000, which appears in no emulator, no version of TOS and no published reference, along with the unused /ROM0, /ROM1, /ROM5 and /ROM6 chip select decodes. Schematic evidence rather than tested behaviour, and flagged as such on the pages.

FreeMiNT TOS documentation — https://freemint.github.io/tos.hyp/en/bios_cookiejar.html
The maintained cookie and XBRA registry, and the reference for the cookie jar's own rules. Treated as the current known cookie list; see The Cookie Jar. Note it is a combined cookie and XBRA list, so not every identifier on it is a cookie, and registration means somebody claimed the tag, not that the value layout has been verified.

The authoritative guide to the Falcon video hardware — Aura, on this wiki
Measured VIDEL timing documentation, and the source of the standard mode register value tables and the FS and EE register behaviour.

VIDEL document — https://mikro.naprvyraz.sk/docs/mikro/videl.html
Programmer's description of the VIDEL registers. Note that Hatari's source comments on several video registers are copied verbatim from this document, so the two are not independent where wording is concerned; Hatari's code is.

Atari Falcon hardware registers — Aeon and Chris of Aura, 1993, and the related FALREG listing
Early Falcon register documentation, useful for registers the later sources skip, but with several entries the maintained sources contradict. Treated as a lead to verify rather than an authority. No stable public URL known; the source text is what The authoritative guide to the Falcon video hardware and the audited memory map pages were checked against.

Alive issue 9, "Cookies for the Beast" — https://alive.atari.org/alive9/cookies.php
Worked survey of the hardware cookies with example jars dumped from real machines, including a CT60 Falcon, a Medusa T40 and a Milan. The source for the CT60 cookie structure. A magazine article rather than a specification, so its values are treated as reports to verify.

The Atari A to Z — Mark S Baines, 1998
General reference with a memory map chapter. Used as a further independent opinion on ranges rather than for bit detail.

A note on accuracy

Some of these listings have carried the same errors for thirty years, copied from one document to the next. Several were found and corrected during this pass, including an inverted status bit, a wrong base address, and five wrongly named registers in one block. Where a value rests on a single unconfirmed source it is marked UNVERIFIED.

Where the sources disagree, the disagreement is written into the entry for that register rather than resolved silently, naming which source says what. Some of these are genuinely open questions, and a reader with real hardware is better placed to settle them than any document is. The same applies to registers where only part of the bit layout is known: the unknown bits are listed as unknown rather than left out.

If you find something wrong, please say so, ideally with a source reference. Corrections are welcome, and are worth reporting even when you are not certain: a "this does not match my hardware" is useful on its own.