Atari is a registered trademark of Atari, Inc.

1. Introduction

This archive is a documentation of the development of the Operating System for the Atari 8-bit home computers, from the platform’s inception in 1977 till its discontinuation in 1991. If fulfills three goals:

  1. It provides source code of all known versions of the OS developed first by Atari, Inc. and later by Atari Corp., including prototypes and released versions, in the original form, or, in case of sources obtained through disassembly, as close to the original form as possible.

  2. It allows to create ROM binaries of the OS from these source listings with a modern assembler.

  3. It documents the development history of the OS, based on the sources themselves and other available documentation.

The source listings in this archive were obtained from original source files found on tape backups of Atari’s development systems, from publicly available source listings, from assembly printouts archived by Atari employees, and from disassembly of ROMs found in surviving computers.

The OS was developed on PDP, VAX and Data General MV/8000 mainframes using a few different cross-assemblers through the years, namely:

  1. Boston Systems Office’s CA6500 cross-assembler on a PDP-11

  2. A modified IMP-16 assembler - for the Floating Point Package

  3. 6500 cross-assembler 1.0MR (CRASS65) from Microtec Research, Inc.

  4. CAMAC by Atari, Inc.(Dyer)

Modern assemblers available on today’s platforms do not support the syntax of these old utilities. Therefore, this archive includes the sources in two forms: in their original syntax, and adapted for the ca65 assembler (https://cc65.github.io/), to make them usable on modern computers.

2. Contents of this archive

This archive contains three types of artifacts:

  • Digitized assembly listings. These are text files that recreate assembly listings found in various publications or in possession of Atari developers. The files herein are exact copies of the printed documents, and preserve all assembler output as it was in the prints.

  • Source files in original syntax. These are source code files, either downloaded from Atari development system backups, restored from the digitized assembly listings mentioned above, or restored by disassembly of contents of operating system ROM chips from surviving computers. Where original source code was unavailable or incomplete, it was retrieved from other versions of the OS for which source was available, the goal being to approximate the sources' supposed original contents, formatting and comments, as much as possible.

  • Source files in ca65 syntax. These are the same sources as above, adapted to syntax of the ca65 assembler, allowing to create binaries of all known OS revisions on a modern computer.

In more detail:

*ca65-src/ - Source files in ca65 syntax. Read more at Building OS ROM images.

3. Building OS ROM images

The ca65-src/ directory contains source files for all OS revisions, adapted to the syntax of the ca65 assembler. To build ROM images from these, you will need:

  • a Make utility compatible with GNU Make,

  • the ca65 assembler from the cc65 package,

  • a C compiler such as GNU GCC.

Then go to ca65-src/ and enter:

make

This will create the following ROM images:

4. History of the Atari OS

Spring 1977: First talks about Colleen

The discussions at Atari to develop a successor to the Video Computer System console started in Spring of 1977, before the VCS shipped. The new "Colleen" system, as it was codenamed, was envisioned as both a great game machine and a worthwhile competitor in the emerging home computer market (Saunders, "Tape 19" 00:10-00:56). It would need an adequate operating system that would act as an interface between the user and the sophisticated hardware. The OS to fulfill that role was developed in house by Atari.

1978-01-06: Start of OS development

Howard Bornstein was the first person to work on the operating system for the "Candy" and "Colleen" systems, which would ultimately be marketed as the Atari 400 and 800 (Decuir 1).

1978-10: OS development restarted

The first team responsible to develop the OS failed to do so, so a second one was formed in October 1978 (Saunders, "Tape 08" 05:25-06:14; Stilphen) Its core members were David Crane, Larry Kaplan and Alan Miller (who together with Robert Whitehead would be known as the "Gang of Four", and would later co-found Activision), with several others brought in for help with development. The known contributors were:

Although Bob Whitehead has been credited by some of his co-workers ("VCF East 2019" 01:12:36-01:12:41; Kindig et al., "Interview 163" 15:48-16:16), and in the source comments (xl-rev-2-1984.asm lines 26-27) as co-author of the OS, it has been clarified both by Alan Miller (Saunders, "Tape 08" 04:45-05:01) and by Whitehead himself (qtd. in Indrian) that while he may have been involved in development of software for the computer, he did not take part in OS development.

1978-10-30: Keyboard, Editor and Screen Handler

The title line of DISPLC.SRC (800-rev-a-1979/DISPLC.SRC line 1) indicates that the keyboard, editor and screen handler module was ready by 1978-10-30, though probably not in its final form yet.

1978-12: Floating Point Package

More than a week before 28 December 1978, Shepardson Microsystems delivered the first working version of Atari BASIC, including the Floating Point Package (FPP), to Atari (Wilkinson vi; Wilkinson et al. x). Shepardson would be fixing bugs in the code until December 1979 (Wilkinson vi).

Atari decided that the computer’s ROM should also include the FPP. The BASIC was specified to occupy the size of 10 KB (Wilkinson v), but a cartridge of this size could not be built - the system’s architecture restricted the cartridge size to either 8 or 16 KB. So the excessive 2 KB FP package was built in the computers along with the OS, and remained part of the system ever since. It was developed by: (Wilkinson v; Wilkinson et al. ix; Kindig et al., "Interview 22" 01:43-02:02)

  • Bill Wilkinson - design of the floating point scheme used in Atari BASIC

  • Kathleen O’Brien - implemented the floating point routines

  • Fred Ruckdeschel - guidelines for implementing the math library routines

  • Paul Krasno - implemented the transcendental math routines

1979-01-06: Atari 400 and 800 at the Winter CES

The OS group developed the whole system in 12 weeks, while the hardware to run it was still not finalized; the OS reached beta state just in time for the computers' debut at the Winter Consumer Electronics Show on 6-9 January 1979 (Saunders, "Tape 08" 05:25-06:14; Backiel).

The resulting system was quite sophisticated, providing a simple interface to the computer’s hardware but also allowing expandability with peripheral devices connected to the machine’s Serial I/O port. It featured:

  • Ability to boot the system from disk, tape or ROM cartridge; if no bootable medium was present, the system ran a built-in "Memo Pad" that allowed to write text on screen;

  • A "Central Input/Output" subsystem that provided a common interface for communication with external devices. The OS provided built-in handlers for:

    • the keyboard (K:), supporting character input and keyboard auto-repeat;

    • the screen (S:), allowing to "open" the screen in multiple text and graphics modes, print text on it, draw points and straight lines, and supporting a rudimentary "fill to right" operation;

    • the screen editor (E:), combining keyboard input with screen output to allow user interaction such as editing text and entering programs, with support for moving the cursor and clearing the screen;

    • the cassette (C:), supporting loading and saving data from/to tapes via a Program Recorder connected to the SIO port;

    • the printer (P:), supporting printing of text to a printer connected to the SIO port.

    The CIO subsystem was expandable, allowing additional handlers for devices such as disk drives (D:), modems (T:), RS-232 interfaces (R:) and more, to be loaded and installed in the system.

  • A "Serial Bus Input/Output Controller" subsystem that provided common block-based interface to CIO devices, allowing to communicate with the devices via up to 8 simultaneously opened files;

  • A facility to install custom interrupt service routines, supporting various IRQ and NMI interrupts provided by the hardware;

  • A font set of 128 characters, derived from ASCII and called ATASCII;

  • The Floating Point Package, originally part of Atari BASIC.

1979-01 - 1979-04: Bug fixing

After the Winter CES, the OS group spent the next 12 weeks fixing bugs in the code (Saunders, "Tape 08" 05:25-06:14; Backiel).

1979-02-07: Central I/O ready

The title line of CIOL.SRC indicates that the Central Input/Output module was ready by 1979-02-07 (CIO line 1), though not in its final form yet.

1979-03-09: Disk I/O, Monitor, and Printer Handler ready; updates in CIO

The title lines of DISKP.SRC (800-rev-a-1979/DISKP.SRC line 1), MONITP.SRC (800-rev-a-1979/MONITP.SRC line 1) and PRINTP.SRC (800-rev-a-1979/PRINTP.SRC line 1) all point to 1979-03-09 as the date of the development of the Disk Input/Output, Monitor (i.e. initialization) and Printer Handler modules. It is not known if the modules were already in their final form at the time.

Also on 1979-03-09, Al Miller made some unspecified updates to the Central Input/Output module (800-rev-a-1979/CIOL.SRC line 2).

1979-03-12: Cassette Handler ready

The title line of CASCV.SRC indicates that the cassette handler module was ready by 12 March 1979 (800-rev-a-1979/CASCV.SRC line 1), though not in its final form yet.

1979-04-03: Serial I/O ready

The title line of SIOL.SRC indicates that the Serial Input/Output module was ready by 3 April 1979, developed by Al Miller (800-rev-a-1979/SIOL.SRC line 8). It is not known if the module was already in its final version at this time.

1979-04: OS 255 manufactured

In April 1979, after 12 weeks of testing and tweaking following the Winter CES (Backiel), Atari apparently considered the OS ready enough for manufacturing - but they produced only a few thousand ROM chips before deciding to abort it. (All About Cassette Tapes 8) An issue with the cassette handler was discovered.

The cassette handler stores data on a cassette by first outputting a few seconds of "leader tone", followed by actual data bits encoded using two different audio frequencies. When opening a cassette file for writing, this version of the OS starts the tape recorder’s motor and writes 9.6 seconds of leader tone, before accepting data to write from the user program. If the user program does not provide data to write within 15 s, the write operation will signal a time-out error (All About Cassette Tapes 8-9).

When opening cassette for reading, the system starts the tape motor and then ignores 2 s of tape before attempting to detect incoming data - this gives the motor a bit of time to get up to speed. Then, if the first bit of data is not encountered within 15 seconds, the read operation fails with a time-out error (All About Cassette Tapes 8-9).

These timings could made it impossible to save or load files on some cassettes by simply rewinding it to the beginning and starting from there. Inside a cassette, a magnetic tape is connected to the reels by a few centimeters of non-magnetic pre-tape. It amounts to a few seconds - more than 10 s on some cassettes - of non-recordable tape on the beginning of each cassette side. So if the user rewinded the cassette to the beginning and started recording, the computer could finish outputting the leader tone and attempt to write data before the magnetic tape was reached - which would result in some data not being saved. Similarly, when reading from a fully-rewound cassette, the system would start reading incoming signal from the pre-tape, which would be seen on the system’s side as random sequence of 0s and 1s - and that would break the loading process.

Atari decided to fix this issue. But the April OS had already been installed in the earliest NTSC 400/800 demo units and/or production machines (All About Cassette Tapes 8). Atari had to add a supplement page to the Atari 410 Program Recorder’s owner’s manual, that described steps necessary to use cassettes with this OS version (410 Insert). From this supplement the April 1979 OS gained its moniker "Operating System 255". The issue was also described in an article in the December 1981 issue of SoftSide (Zett).

No machine with OS 255 has been discovered yet. Presence of this OS revision can be tested, by entering in BASIC:

PRINT PEEK(65528)

If the result is 255, then you have OS 255 built in. Please consider sharing your find on the AtariAge forums, or contact this package’s author directly.

1979-05-30: Cassette Handler updated

In the OPOUT routine, the length of the mark leader during writing was increased from 9.6 s to 19.2 s (800-rev-a-1979/CASCV.SRC line 100). The user could now save data to a fully-rewound cassette.

In the SIOSB routine, the timeout for reading and writing of the first record was increased from 15 s to 35 s (800-rev-a-1979/CASCV.SRC line 244). (All About Cassette Tapes incorrectly states that the timeout for reading of a record was different (25 s) than for writing, but in reality the same routine SIOSB is used to set the timeout for both reading and writing.)

1979-05-31: Cassette Handler updated

In the OPENC routine, the length of the tape leader being ignored during reading was increased from 2 s to 9.6 s (800-rev-a-1979/CASCV.SRC line 65). The user could now load data from a fully-rewound cassette.

1979-06: NTSC OS Rev. A ready

With the cassette handler’s shortcomings now fixed, the OS was considered ready for general release. Source listings and other references published later by Atari state that the OS was ready in June 1979 (All About Cassette Tapes 8; 800-rev-a-equates.asm line 2; 800-rev-a-1981-02.asm line 2). It would be later called Revision A.

It is not known if there are other differences between the April OS and this one besides the cassette timings.

The Rev. A OS would be produced in the form of three ROM chips marked:

  • C012399B - 2 KB, Floating Point Package

  • C012499A - 4 KB, low OS

  • C014599A - 4 KB, high OS

It would be included in all NTSC 400 and 800 machines produced before November 1981 ("Upgrades").

1979-11: Atari 400 and 800 shipped

The first Atari 400 and 800 computers reached the domestic (American) market in November 1979. These machines contain ROMs of Revision A of the OS, located on the personality board inside the machine.

By this time the "Gang of Four" had already left Atari to form Activision.

1979-11-13: Source listing printed

Atari prepared a 10-part set of specifications and source listings for internal purposes in 1979. Part 2 contained the sources of the Monitor and Display handler modules (MONITOR), while part 5 contained the equates, CIO, Interrupt handler, SIO, Disk I/O, Printer handler and Cassette handler modules. (CIO). The comment at the beginning of CIO dates the whole listing as 13 November 1979 (800-rev-a-1979/NEQUATL.SRC line 1).

Another copy of the same listing has been archived by Kevin Savetz (OS listing 1979). It contains the same modules, plus the Floating Point Package part of the BASIC assembly listing.

Between the two copies, the listing contains the sources of the whole Revision A OS, except for the character set. (Each of the two copies has some parts missing or unreadable, but thankfully not in the same places.)

The sources were apparently written for Boston Systems Office’s CA6500 crossassembler, which Atari is known to have had intalled on their PDP-11 maiframe at that time (Stewart, OS Manual section 13 p. 2; Margolin). Judging from multiple occurrences of "SYMBOL TABLE" sections, the OS modules were located in separate source files - an assembler would output a symbol table at the end of each file being assembled. Each source file starts with a ".TITLE" statement, most of which happen to contain the file’s name such as "DK1:CASCV" (800-rev-a-1979/CASCV.SRC line 1) or "MONITP.SRC" (800-rev-a-1979/MONITP.SRC line 2). Also, all files contain a .BYTE statement at the end, designed to throw an error if the module’s assembled size is too large; this error message also contains the file’s name (e.g. 800-rev-a-1979/INTHV.SRC line 371; 800-rev-a-1979/SIOL.SRC line 1118). This allows to restore the probable names of the original source files.

The one module whose file name is not mentioned anywhere in the sources, is the equate file. However, its name "NEQATL.SRC" is mentioned in Atari’s internal program development guidelines (Stewart, OS Manual section 13 p. 3). Moreover, the guidelines also specify that all file names on the PDP-11 disks "must end with the user’s assigned code letter". This allows to assign each OS module to its original developer, by last letters of each file name:

Compared to the manufactured Rev. A ROM, this source listing is modified for debugging purposes: WARMSV and COLDSV vectors point to page $90 (800-rev-a-1979/MONITP.SRC lines 90-102).

A "JMP (VTIMR4)" opcode in the SYIRQ routine in the Interrupt Handler, just before the SYIRQ6 label, was ignored during assembly because of a spurious character in the source (Scheiman line 73) - there are no bytes output for that opcode in the leftmost column of the listing. This omission caused the POKEY Timer 4 IRQ to be effectively ignored by the manufactured version of OS. Apparently, the assembler was interpreting this line as an illegal opcode (800-rev-a-equates.asm lines 17-19). The line would be commented out in the later Rev. A listing to reflect that fact (800-rev-a-1981-02.asm line 1338).

Comments for LMARGN and RMARGN claim that the screen margins are set to 1 and 38 at power on, which is not true - they are set to 2 and 39 (800-rev-a-1979/NEQUATL.SRC lines 245-246). This may be a remnant from early development stages.

The FPP, being developed separately by Shepardson Microsystems, was written for a cross-assembler on an IMP-16P computer, modified by Shepardson to accept some additional syntax (Wilkinson et al. ix; Wilkinson vi), examples of which are mnemonics such as ASLA and LSRA. This listing is actually a part of an assembly listing of the whole Atari BASIC, as evident from page numbers starting at 250, and the symbol cross-reference table containing various BASIC symbols not present in the FPP listing.

The label "!FNZERO" is mistyped as "!FNZER0". This originally went undetected because the IMP-16 assembler cropped label names to 6 characters and would interpteret that label as "!FNZER", avoiding the typo.

Note

This package contains:

1980-11: Migration to Microtec

Atari published "Personal Computer System Operating System User’s Manual" in November 1980 (OS Manual; Sheppard). It includes a part of the OS source listing, specifically the equate file. The listing is truncated to 72 columns. Notably, all occurrences of the word "Colleen" are pasted over with "Atari 400/800"; font difference indicates it was done by physical cut-&-paste, not in the original source file.

The comments at the beginning of the file explain that the OS sources have been modified for assembly using the Microtec 6500 cross assembler, and then detail all the changes made: (800-rev-a-equates.asm lines 11-30)

;   1.  " CHANGED TO ' ; ALSO, CLOSING ' ADDED WHERE NECESSARY
;   2.  SOME SOURCE SPACING CORRECTIONS MADE (EG., .PAGE
;          NOT IN COLUMN 1)
;   3.  ( ) IN COMPLEX EXPRESSIONS ADDED FOR CORRECT EVALUATION
;   4.  ILLEGAL OPCODE (PAGE 3 OF INTERRUPT HANDLER) MADE
;          INTO A COMMENT TO REFLECT THAT IT DID NOT
;          ASSEMBLE IN THE ORIGINAL ASSEMBLER
;   5.  FORWARD REFERENCES IN EQUATES NOT ALLOWED IN MICROTEC.
;          SYMBOLS MOVED:
;              IN SIO:  JTADRH,JTADRL  FROM P.3 TO PP.14,15
;              IN MON:  TBLLEN         FROM P.3 TO P.3
;   6.  SOME DUPLICATE LABELS CAUSED PROBLEMS.  SUBSTITUTE LABELS
;          CREATED:
;              IN SIO:  CASET  PP. 2,4,15,16
;              IN DSK:  FOMAT  PP. 1,2,2
;          DUPLICATE LABELS WHICH CAUSED NO PROBLEMS TO THE
;          RESULTING OBJECT ARE UNCHANGED (EITHER DUP VALUE
;          SAME OR LABEL NOT REFERENCED).

The mention of duplicate labels means that the migration to Microtec involved joining all modules into one source file. Indeed, the 1979 sources contained labels with the same name but different values in multiple modules (e.g. CASSET, CRNTPC) that would conflict with each other once the modules were assembled as one source file.

In the area of the equate file, the only important change is that the duplicate VCTABL label is commented out. All other changes are in code formatting.

Note

This package contains:

1981-02: Further Microtec changes, Rev. A source listing

Atari prepared the full source listing of Revision A OS for publication in February 1981 (OS Listing 1981-02). The "Atari 400/800 Operating System Source Listing" manual was offered to the general public no later than in May 1981 (Bills). The listing is truncated to 72 columns, and omits the character set and the Floating Point Package. It does not yet contain conditional code to build the PAL version of the OS.

The code underwent further formatting changes for compatibility with the Microtec assembler. The sources have been joined into a single file, with duplicate labels renamed where necessary. The debugging changes in WARMSV and COLDSV were removed, and several unused labels were removed or commented out. Some typos in comments were fixed, some new ones were introduced.

Locations $E40F, $E41F, and $FFF8-$FFF9, used for storing ROM checksums, are filled with correct values here, while they were zeroed in the 1979 sources.

Note

This package contains:

1981-08: Rev. A source listing re-released

Atari updated their "Operating System Source Listing" manual in August 1981 (OS Listing 1981-08). The new version of the manual, except for having a more professional-looking cover, differs only in page 1 of the listing. For unknown reasons, it was composed with a different, narrower typeface, while the rest of the listing remained in the form of a dot-matrix printout. Page 1 also contains minor changes, such as an added "TM" symbol after the "Atari 400/800" name, removed ";" characters before each comment, and one typo fixed. Maybe the typeface change was required to add that "TM" character? Whatever the reason, the rest of the listing remained unchanged. It still does not contain conditional code to build the PAL version of the OS, which would be shipped in PAL computer models introduced the same month.

Note

This package contains:

1981-08: PAL computers shipped

The cassette handler’s timings for reading and writing were dependent on the speed of ANTIC, the computer’s video display processor, which produced 60 screen frames per second, in accordance with the NTSC TV system used in the U.S. In order to release the computers on European markets, which used a different 50 frames-per-second PAL or SECAM system, Atari needed not only to prepare a new version of ANTIC, but also make a new version of the OS.

The PAL version of Rev. A OS, which reached the market in PAL versions of the 400 and 800 computers starting in August 1981 in the United Kingdom (Current section 11.1 at 1981/August 1), had the cassette timings adjusted, so that the lengths of signals saved on tape would remain the same.

This difference was introduced to the source code by means of conditional assembly controlled by the PALFLG label (800-rev-a-1981-08-palflg.asm search for PALFLG). Although not inclued in the OS sources published the same month, PALFLG would be included in the OS Revision B source listing, published later.

Like in NTSC units, the OS is in the form of three ROM chips, the FPP chip being the same as in the NTSC version:

  • C012399B - 2 KB, Floating Point Package

  • C015199 - 4 KB, low OS

  • C015199 - 4 KB, high OS

This OS version would be built into all PAL and SECAM 400/800 units.

Note

This package contains orig-src/800-rev-a-1981-08-palflg.asm - approximation of how Rev. A sources could look with PAL conditional assembly code, to match the Rev. A OS ROM. The PAL code was copied from Rev. B source listing.

1981-08-26: Z800 specified

Development of a next-generation Atari computer commenced in mid-1981. The project was known as A300, then Z800, and finally Sweet-16 (Stewart, Memo 1). The new computer - ultimately marketed as the Atari 1200XL - and its OS were "designed for ease, simplicity and friendliness of setup and use, while offering both the power and sophistication of a home computer." (Stewart, Sweet 16 OS 2) The Z800 product specification was written by 26 August 1981 (Stewart, Sweet 16 OS 4).

1981-09-06: FPP split from BASIC

According to both the source listing of the Floating Point Package from the time of Sweet-16 OS development (sweet-16/FPP.ASM lines 6-9) and to the 21 June 1984 OS sources (xl-rev-3-ver-4/OS.ASM lines 7705-7706), Mike Lorenzen split the FPP sources off the rest of Atari BASIC on 6 September 1981, to allow assembling them independently. He was probably also responsible for converting them from IMP-16P to the Microtec assembler.

1981-09: OS Rev. B ready

As stated in the source listing that would be published in 1982, an updated Revision B of the OS was ready in September, presumably 1981 (800-rev-b.asm line 2).

Developed by Michael P. Mahar and Robert Scott Scheiman (xl-rev-2-1984.asm lines 29-31), Revision B "provide[s] a higher level of system performance by improving the operating system peripheral I/O control routines. OS version B eliminates annoying pauses in disk and printer operations that sometimes occurred with OS version A." This version fixed several problems of Revision A, most importantly a bug that would cause printers to print parts of a printed line twice, and a bug that would pause a disk drive for 30 seconds (Scheiman lines 65, 99)("Upgrades") The detailed changes are:

  • A BRKKY vector was introduced to allow customization of the Break key IRQ service routine (Scheiman lines 75, 101). The OSRAM routine was changed to initialize BRKKY at startup.

  • An unofficial entry point to SETVBL at $E912 was added, $E912 being the location of SETVBL in Revision A. This was done to maintain compatibility with DOS 2, which calls the routine at this address directly instead of using the public vector SETVBV.

  • The IRQ service routine (SYIRQ) was rewritten to both decrease the routine’s size and support the BRKKY vector (Scheiman line 101). It now uses new tables CMPTAB and ADRTAB and a memory location JVECK. The change also fixes Revision A’s POKEY Timer 4 IRQ bug - the IRQ now works as expected and is customizable by the user by means of VTIMR4 (Scheiman line 101).

  • A bug in the BRK IRQ service routine (SYIRQA) was fixed. Previously, the routine attempted to test the state of the B processor flag by saving the status register to stack with PHP and then reading it with PLA; this would not work because PHP always saves the status register with B set to 1. This could cause an IRQ that was not serviced earlier in SYIRQ, to be misitentified as a BRK interrupt. The fixed routine correctly gets the status register from the stack as it was written by the CPU’s interrupt sequence. (The routine first pulls the saved A register from stack and puts it temporarily in to JVECK before pulling the status register.)

  • The VBLANK routine (SYSVBL) was changed: a CLI instruction was moved to after LPENV, LPENH, DLISTH/L, DMACTL and PRIOR are aligned with their shadows; and there is also a minor change to save space. This fixed a bug that could cause occasional screen flashes when an IRQ occured that took too much time (Scheiman lines 89, 101).

  • The "Set Vertical Blank Vectors and Timers" (SETVBL) was rewritten. Previously, the routine would disable the vertical blank interrupt (VBI) for the duration of the changing of a jump vector, then it would check if the interrupt was requested by ANTIC in the meantime, and it would run the interrupt service routine if necessary. The new version ingeniously avoids the VBI by waiting for 20 CPU cycles after WSYNC. This ensures that the changing of a jump vector will never happen during a VBI, and results in shorter code overall (Scheiman lines 79-81, 103-114).

  • The "check if past end of buffer" routines in the Serial Output Ready (ISRODN) and the Serial Input Ready (ISRSIR) interrupt service routines were modified, to fix a bug occuring when a buffer ends on a page boundary: if SIO used such a buffer, it would go into an infinite loop.(Scheiman lines 87, 101).

  • The Cassette Handler’s SETVBX routine was changed. This routine sets the TIMER1 timeout to the value stored in the X and Y registers and sets the appropriate jump vector so that when TIMER1 reaches 0, the timeout flag TIMFLG would be cleared. Previously, the routine would set TIMFLG and then call SETVBL to set the timeout. If a VBI happened at this point, it could clear TIMFLG immediately. As a result, when leaving SETVBX the TIMER1 could be immediately marked as "already happened". After the change, TIMFLG is set to 1 when leaving SETVBX to ensure this is not the case.

  • The "check for special cartridge" routine (SPECL) was changed. It is called during cold start and warm start. Previously, the routine could modify the RAM location $BFFC when no cartridge was present - now it no longer does. The routine was also rewritten to take less space and not use the RAMLO and TSTDAT memory locations.

The NTSC version of Rev. B OS would be produced in the form of three ROM chips, the FPP chip is still the same as before:

  • C012399B - 2 KB, Floating Point Package

  • C012499B - 4 KB, low OS

  • C014599B - 4 KB, high OS

PAL Rev. B apparently never shipped, despite the source listing published later by Atari containing conditional code to assemble different versions of the OS for NTSC and PAL. It was evidently planned for release - the "Atari XL Addendum" supplement contains a procedure for detection of OS revision, which takes PAL Rev. B into account, listing specific checksum values that could only be computed from a ROM binary file assembled from sources (XL Addendum 28). But an internal review of the Addendum dated 10 January 1983, i.e. after the 1200XL’s debut, reveals that PAL rev. B had still not been released (Peck and Stewart 70-71). No unit containing a PAL rev. B OS has surfaced to this day; on the contrary, PAL rev. A ROM chips have been found with production dates of December 1982, and in machines produced as late as mid-1983 - long after NTSC rev. B introduction (Diepenhorst).

1981-10-28: Z800 OS specified

Harry Stewart prepared an initial version of the "Z800 Operating System External Reference Specification" on 28 October 1981 (Stewart, Sweet 16 OS title page). The document would undergo a few revisions through 1982.

The OS was specified to take 16 KB of ROM space including the FPP, split into two 8 KB ROM chips (Stewart, Sweet 16 OS 3). It would be backward-compatible with the 400/800 Revision B OS, and would contain the following changes: (Stewart, Sweet 16 OS 5-18)

  • Removal of support for game controller ports 3 and 4 - the new computer would only contain two. The data base variables associated to these ports (STICK2-3, STRIG2-3, PADDL4-7, PTRIG4-7) would contain duplicate values of ports 0 and 1 (Scheiman line 126).

  • Removal of support for Atari 800’s right cartridge - the new computer would only have one cartridge port (Scheiman line 128).

  • Auto-adjustment of cassette and keyboard timings based on TV system: there is now one universal OS version for all regional variants of the computers (Scheiman line 130).

  • Each of the two ROMs would contain an OS ROM identification block with Revision date, Option byte, Part number, and Revision number (Stewart, Sweet 16 OS 7; XL Addendum 26; Scheiman lines 134, 198-219).

  • Support for the new Help key.

  • Support for F1-F4 keys and console LEDs. The function keys would perform cursor movement and enable or disable various features.

  • Support for redefinition of key functions.

  • User-alterable key repeat rate.

  • Enabling and disabling of screen DMA with Control+F2.

  • Enabling and disabling of key clicking, either with Control+F3 or by a data base variable.

  • Switching between International character set, either with Control+F4 or by a data base variable.

  • Enabling or disabling of the keyboard, either with Control+F1 or by a data base variable.

  • Modification of the Caps key action - it would toggle between upper- and lowercase instead of always switching to lowercase.

  • Detection of cartidge removal or insertion - the system restarts automatically.

  • Testing for three "special" values to determine cold start vs. warm start (Scheiman line 132).

  • ROM/RAM test at power up.

  • Support for option jumpers on the mainboard.

  • Support for split screen in screen mode 0.

  • Support for fine scrolling of the screen editor.

  • A certain area of the data base on page 3 would not be modified during warm start.

  • New screen modes 12-15.

  • Support for variable sector size in the disk handler.

  • Support for the "write sector without verify" operation (PUTSEC, SIO command "P") in the disk handler.

  • Memo Pad would be replaced by an animated logo on power up.

  • Self Test, accessible either by pressing Help on the logo screen, or by shorting the J1 jumper on the mainboard.

  • Relocating Loader, to be used when loading SIO device handlers.

  • SIO bus polling at power on, for automatic loading of device handlers.

  • Change to the printer handler’s CLOSE operation - it would insert an EOL character in the printer buffer if not already present, ensuring that the contents of the buffer are printed immediately (Scheiman line 146).

  • Support for printer device numbers in the printer handler (Scheiman line 144).

  • Change in handling of truncated records in CIO: an EOL character is inserted in the input buffer in case the record being read is longer than the buffer size, or when an end of file is reached (Scheiman lines 95, 148).

  • Change in handling of zero-length buffers in CIO: a buffer length of zero is returned on handler error that would result in an empty buffer (Scheiman line 95).

  • Fix in the screen handler: a clear screen ATASCII code would be accepted by the handler even when the X/Y cursor coordinates are out-of-range (Scheiman lines 93, 150).

  • Fix in the screen/editor’s memory handling: the editor would no longer modify memory above RAMTOP.

  • Fix for logarithm functions in the Floating Point Package - they would produce an error status when computing a logarithm of 0 (Scheiman line 152).

  • New ROM jump vectors at addresses $E480-E48C for power-on display, Self Test, relocating loader and peripheral handler loading facilities.

  • Hard-coded jump vectors to maintain compatibility with programs that used direct calls to OS Rev. B locations instead of published jump vectors.

1981-11: OS Rev. B shipped

All NTSC Atari 400 and 800 machines manufactured since November 1981 contained the new Revision B OS ("Upgrades"). It was also available as an upgrade for machines produced before that date.

1981-12-04: first version of the Z800 OS specification

4 December 1981 marks the date of the first "controlled version" of Harry Sterwart’s Z800 OS specification (Stewart, Sweet 16 OS title page). The signatures in the document show that it was approved by several managers in the following days.

1982: Rev. B source listing

Atari published a second version of "Operating System Source Listing" in 1982, both separately (OS Listing 1982) and as part of "Atari Home Computer System Technical Reference Notes" (Technical Reference). It contains the source listing for the Revision B OS. The listing is again truncated to 72 columns and omits the character set and the Floating Point Package.

Besides the differences in functionality described above, the listing contains a variety of other changes. Specifically:

  • A compile-time flag PALFLG was added, to allow for assembly of both NTSC and PAL variants of the OS from the same sources.

  • An IMASK memory location was added, although it remains unused.

  • The PIRQQ routine was renamed to PIRQ5.

  • The RETURM routine was renamed to RETUR2.

  • The CRNTP8 routine was renamed to CRNTPC.

  • Checksum bytes at $E40F, $E41F, $FFF8 and $FFF9 are left unset instead of being hardcoded.

  • Many changes in comments. Curiously, most comment typos that were fixed in the 1981-08 listing, are coming back in this version.

  • Many minor changes in formatting.

Note

This package contains:

1982-01-25: International character set defined

Harry Stewart prepared a definition of the international character set for the new Atari computer, now renamed from Z800 to Sweet-16, on 25 January 1982 (Stewart, Memo 2).

1982-03-22: First revision of the Sweet-16 OS specification

As the first page of Harry Stewart’s OS specification shows, the document was revised on 22 March 1982 to incorporate "changes requested by marketing" and "engineering changes found to be needed during development" (Stewart, Sweet 16 OS revision page).

1982-03-24: International Character Set specification ready

On 24 March 1982, Amy Chen completed a specification document of the International Character Set she was developing (Chen, Character Set title page). The specification describes the graphical shapes of all 29 new characters, as well as their layout in the character set.

1982-03-26 - 1982-04-01: Sweet-16 OS WIP source listings

Three source listings from the middle of the "Sweet-16" operating system’s development have been archived. They are:

The listings show that the source code has been split into separate modules again. The sources use .XDEF, .XREF and .XREFB directives to export and import symbols between modules. The relocating features of the Microtec assembler are also being put into use: .ASCT and .PSCT directives mark absolute and program sections, respectively, and the address values visible in the Display Handler’s listing in the ADDR column show that the code in the program section was assembled without defining any absolute origin address. The assembled code would be later put into appropriate addresses by a linker program.

The Floating Point Package (FPP.ASM) had its syntax modified to compile with the Microtec assembler. The source file now contains all of the necessary equates needed to assemble the FPP without referencing other OS modules. These equates previously resided in the main OS equate file (800-rev-b.asm lines 556-638). All references to the DBVER assembly option were removed, and the SKBLANK and SKPBLANK labels were replaced with SKPBLK. The only functional change is a bugfix to the logarithm routines: BASIC functions LOG(1) and CLOG(1) now correctly return 0, and LOG(0) and CLOG(0) return an error. The FPP would remain unchanged (except for assembler syntax updates) until the end of the Home Computer System’s lifetime.

The Display Handler (KEYDIS.ASM) has been expanded with all the new features that would end up in the 1200XL computer. It now supports the Help key - the system updates the new HELPFG location when the key is pressed. The F1-F4 function keys are also supported. Pressing them on their own moves the cursor up, down, left and right, respectively. New cursor movement actions are available when pressing the function keys together with Shift: F1 moves the cursor home, i.e. to the top left corner of the screen, F2 - moves the cursor to bottom, i.e. the bottom left corner, F3 - to the left margin, and F4 - to the right margin.

The Control+function key combinations are also implemented. Control+F1 enables or disables the keyboard, and turns the L1 light-emitting diode to indicate this. The current state is reflected in the new KEYDIS data base variable. (The variable is in a temporary location $3F8; it would be moved elsewhere in the final version of the OS.) A program may change KEYDIS to enable or disable the keyboard, though changing the variable does not switch the L1 diode. So, when a program stores $FF in KEYDIS to disable the keyboard, and the user then presses Ctrl+F1 to enable it, L1 lights up, its state now being inverted.

Control+F2 disables the screen. The system stores 0 to the SDMCTL data base variable, thus disabling ANTIC DMA. Before doing so, is saves the previous value in the new DMASAV variable, so that when the user presses any other key, the DMA would be restored to the previous state. Interestingly, pressing Control+F2 also toggles bit 2 of PORTB: the source comments explain that this would control a TV switchbox. It is unknown if it would only disable the computer’s TV signal output, or if it would also control the switchbox to enable television viewing.

Control+F3 enables or disables key click. The current state is reflected in the new NOCLIK data base variable, which can be modified by a program to control key clicks.

Control+F4 switches between the domestic and international character sets. It is done by modifying the CHBAS variable. If it contains the address of the international character set, the variable is switched to the domestic one, and otherwise to the international one. The L2 diode is also enabled to indicate the international character set being enabled, although again, manual modification of CHBAS does not switch the diode, only Control+F4 does. Though unlike in the case of the L1 diode, changing CHBAS manually does not invert the diode’s state - it correctly indicates the international character set being enabled after subsequent Control+F4 keypresses.

The Caps key’s function was modified: Pressing Caps by itself toggles between upper and lower case, instead of always switching to lower case as before. Shift+Caps and Control+Caps work as before, i.e. lock the keyboard in upper case and semigraphics mode, respectively.

A key redefinition functionality has been introduced. The new KEYDEF and FKDEF data base variables point to a 192-byte key definition table and an 8-byte function key redefinition table. Pointing KEYDEF to a custom key definition table allows to modify the functions of all keys including their combinations with Shift and Control (but not with Shift and Control together). The key definition table translates POKEY keyboard codes to ATASCII codes, so e.g. storing a value of $41 at the 39th position of the table would cause the Inverse Video key to output an "A" character (because $41 is ATASCII code for "A" and 39 is the keyboard code of the Inverse Video key).

Pointing FKDEF to a custom table provides a similar behaviour for the function keys - it allows to modify the functions of the F1-F4 keys, with and without Shift (but not with Control).

While most of the codes in the table are interpreted as regular ATASCII codes, the codes between $80 and $92 have a special meaning, and are by default assigned to special keys such as Caps, Inverse video, Control+3 and the function keys. They are:

  • $80 - Ignored. Assigning this code to a key will cause the key to be non-functional.

  • $81 - Inverse video. By default assigned to the Inverse video key.

  • $82 - toggle uppercase/lowercase. By default assigned to the Caps key.

  • $83 - lock uppercase. By default assigned to Shift+Caps.

  • $84 - lock semigraphics. By default assigned to Control+Caps.

  • $85 - End of file. By default assigned to Control+3.

  • $86 - Enable/disable keyboard. By default assigned to Control+F1.

  • $87 - Ignored, see $80.

  • $88 - "Gonzo" function. Referred to as such in both the sources and in the preliminary draft of the 1200XL OS manual (Peck and Stewart 13), this code just locks the processor in an infinite loop.

  • $89 - Toggle key click. By default assigned to Control+F3.

  • $8A - Function 1. Assigning this to a key causes it to perform the function assigned to the F1 key in FKDEF. By default assigned to F1 and Shift+F1.

  • $8B - Function 2. Assigning this to a key causes it to perform the function assigned to the F2 key in FKDEF. By default assigned to F2 and Shift+F2.

  • $8C - Function 3. Assigning this to a key causes it to perform the function assigned to the F3 key in FKDEF. By default assigned to F3 and Shift+F3.

  • $8D - Function 4. Assigning this to a key causes it to perform the function assigned to the F4 key in FKDEF. By default assigned to F4 and Shift+F4.

  • $8E - Cursor to home. By default assigned to Shift+F1.

  • $8F - Cursor to bottom. By default assigned to Shift+F2.

  • $90 - Cursor to the left margin. By default assigned to Shift+F3.

  • $91 - Cursor to the right margin. By default assigned to Shift+F4.

  • $92 - Toggle international/domestic character sets. By default assigned to Control+F4.

There are a few quirks in this functionality:

  • The values $8A-$8D should only be used in the KEYDEF table, not in FKDEF. Assigning a value of $8A to the F1 key in FKDEF, in order to make it "perform its own function", causes the key to perform the Shift+F1 function instead. Assigning $8A to both the F1 and Shift+F1 combinations in FKDEF will cause the editor to enter an infinite loop when F1 is pressed. The same issue exists for F2-F4.

  • Assigning an ATASCII value of a small letter ($61-$7A) to both the Key and Shift+Key combinations for the same key, causes the editor to lock up when that key is pressed, without Shift, when the editor is in the uppercase mode.

  • Similarly, assigning an ATASCII value of a small letter ($61-$7A) to a Key and Control+Key combinations for the same key, causes the editor to lock up when that key is pressed, without Control, when the editor is in the semigraphics mode.

Overall, all keyboard keys except for Start, Select, Option, Reset, Break, Shift, Control, Help, Control+1, and Control+F2 are re-assignable. Help, Control+1 (start/stop paging) and Control+F2 (toggle screen DMA) are not because they are processed during the keyboard interrupt, before the system reaches the keyboard handler. Other three Control+function key combinations are processed by the keyboard handler, which means they perform their function only when the editor or keyboard handler waits for input.

Key auto-repeat rate is now user-alterable with the KRPDEL (auto repeat delay) and KEYREP (auto repeat rate) data base locations. The default repeat delay and rate are adjusted based on the detected TV system, so they remain the same despite the system’s refresh rate differences.

Support for text screen fine scrolling has been added, controlled with the FINE data base location. Setting FINE to $FF and opening the screen or editor enables the fine scrolling mode: the display list is lengthened by one additional text line to facilitate vertical scrolling, and all text lines have their vertical scroll bit enabled. Additionally, the next-to-last text line has Display List Interrupt bit enabled, although the DLI routine is not yet implemented, therefore the interrupt does nothing.

Curiously, setting FINE to a value between $01-$7F still enables the fine-scrolling mode, but it does not enable the aforementioned DLI. Another quirk is that if there is non-zero data immediately following the screen memory, then it will be visible in the additional text line during scrolling. This BASIC program shows the issue (assuming the standard location of the screen memory on a 64 KB system):

FINE=1017:POKE FINE,255:OPEN #1,12,0,"E:":POK.36864,129

The FINE variable and a new VSFLAG variable used during fine scrolling are at temporary locations $3F9 and $3F7, respectively. They would be moved elsewhere in the final version of the OS. The temporary location results in them being not zeroed on warm reset though: pressing Reset does not disable the fine-scrolling mode.

Support for additional hardware screeen modes has been added: opening the screen with the AUX2 byte set to 0-11 works as usual, while the values 12-16 are now assigned to new graphics modes:

  • 12: ANTIC $3 mode, 40*19 characters, or 40*16 + 4 text lines in split-screen mode.

  • 13: ANTIC $4 mode, 40*24 characters, or 40*20 + 4 text lines in split-screen mode.

  • 14: ANTIC $5 mode, 40*12 characters, or 40*10 + 4 text lines in split-screen mode.

  • 15: ANTIC $C mode, 160*192 pixels, or 160*160 + 4 text lines in split-screen mode.

  • 16: ANTIC $E mode, 160*192 pixels, or 160*160 + 4 text lines in split-screen mode.

Unfortunately, since the AUX2 value is trimmed to 15 on the start of the screen open routine, it is not actually possible to open the screen mode 16 - a mode 0 screen without text window gets opened instead.

An ".IF FALSE" block at the beginning of the screen open routine (DOPEN) enables split screen mode for graphics mode 0 - performing GRAPHICS 0 opens the text screen with the separate 4 text lines at the bottom. To open the screen "normally" the user must add 16 to the AUX1 value, just like in the case of all other graphics modes, e.g. by entering GRAPHICS 0+16. This modification would break compatibility with existing software though, so it was likely enabled in the code only for testing.

The screen handler now accepts a screen clear code no matter what value is in the cursor X (COLCRS) and Y (ROWCRS) coordinates. So, a program like:

GRAPHICS 2:FOR Y=0 TO 11:PRINT #6;Y:NEXT Y:PRINT #6;CHR$(125)

now correctly clears the graphics screen instead of failing with ERROR 141.

A bug in the screen clear routine has been fixed. In Revision B and earlier, opening a screen mode or outputting the ATASCII clear screen code (125) would modify the first 64 bytes above RAMTOP, potentially destroying data put there by the user (Chadwick 19; Scheiman line 91). Now this bug is fixed, so the memory above RAMTOP is now safe. Well, it i would be, if the developers hadn’t broken the screen scrolling routine at the same time: outputting the ATASCII delete line code (156) when the cursor is in the last line of the screen, causes the 40 bytes after the end of screen memory to be moved to screen space.

A change in the CLRLIN routine affects the behaviour of the Insert Line editor function with regards to the contents of the margins. In Revision B, pressing Shift+Insert would shift the contents of the screen down starting at the cursor’s current line, including the contents of the margins, although the contents of the left margin on the current line would not be moved. In this version pressing Shift+Insert moves both the left and right margins down, including the left margin at the current line, but it does not clear the margins at the current line - so the contents of the margins at the current line are effectively copied one line down.

The key click routine (CLICK) was modified to wait by observing the VCOUNT counter instead of waiting for WSYNC, to fix a Rev. A bug that caused DLI colour changes to jump by one line when keyboard was used (Scheiman line 77). This change also makes the bell sound (e.g. when pressing Control+2) more "smooth", though only on NTSC systems. It also introduces a new issue: the CLICK routine uses the CONSOL register to generate sound, but it always stores the value in the register with bit 0 set, thus inhibiting detection of the Start key press. The system VBLANK routine would soon reset CONSOL to a proper value, so the window of time to experience the problem is rather narrow, but can be demonstrated by the following program:

OPEN #1,4,0,"K:":GET #1,A:CONSOL=PEEK(53279):CLOSE #1:IF INT(CONSOL/2)*2=CONSOL THEN PRINT "Start pressed"

Entering the above program and pressing the Space key always reports Start as being pressed in this OS version, regardless of the actual state of the key.

There are several other changes in the code to save space: the NOSCRL routine (Do CR without scroll) has been removed, because it had been unused even in Revision A, and a few instructions have been modified here and there to shorten the code by a few bytes. The handler entry points for the Screen, Editor and Keyboard devices, and the keyboard IRQ interrupt vector, have been removed from the display handler’s sources - apparently they have been moved to a separate module.

There are several handwritten annotations on the listing’s pages, describing changes and bugfixes to be made. All of them would be incorporated in the final version of the 1200XL OS.

The Data Base listing (DATBAS.ASM) contains only the memory locations used by the OS on pages 0 to 6. It does not contain all the other equates - they are now stored in a separate file. Looking at the first pages of both the Data Base and the Display Handler listings, their line numbering starts at 421, which means that the equate file would have 420 lines and would be included by an .INCLUDE directive. The titles on the first pages also show that the included equate file was titled "SWEET16 EQUATES".

Although the equate file itself is unavailable, the values defined in it are still visible in the "Symbol Table" and "Cross Reference" sections at the end of the listings. So, despite the sources being incomplete, we can infer a lot about which new features were being in the works - and which weren’t yet - by April 1982, just by looking at the defined equates and data base locations:

  • A variety of equates were moved form their respective modules to the main equate file or to the data base:

    • IOCBSZ, MAXIOC, LEDGE, REDGE, MAXDEV - moved to Equates from Data Base.

    • INIMLL, INIMLH, SEX, CLS, CARTCS, CART, CARTFG, CARTAD - moved to Equates from Monitor (MONITP).

    • TOADR, FRMADR - moved to Data Base from Monitor.

    • EOL - moved to Equates from Central Input/Output (DIOL).

    • CNTL1 - moved to Equates from Display Handler (DISPLC).

    • DISKID, PUTSEC, STATC, FOMAT, NODAT, GETDAT, PUTDAT - moved to Equates from Disk Input/Output (DISKP).

    • NBUFSZ, DBUFSZ, SBUFSZ, PDEVN, SPACE - moved to Equates from Printer Handler (PRINTP).

    • CASET, READ, WRITE, SIDWAY, NORMAL, DOUBLE, PLOT, ACK, NACK, COMPLT, ERROR, B192LO, B192HI, B600LO, B600HI, HITONE, LOTONE, WIRGHI, RIRGHI, NCOMLO, NCOMHI, MOTRGO, MOTRST, CRETRI, DRETRI, CTIMLO, CTIMHI - moved to Equates from Serial Input/Output (SIOL).

    • DTA, DT1, EOT, HDR, TONE1, TONE2 - moved to Equates from Cassette Handler (CASCV).

  • The Module Origin Table equates (CHRORG, VECTBL, VCTABL, CIOORG etc.) have been removed. The various modules are now being assembled to a common program section (.PSCT) and their address origins are instead determined at link time.

  • The device handler origin equates (EDITRV, SCRENV etc.) and the jump vector equates (DISKIV, DSKINV, CIOV etc.) have been removed - apparently moved to a separate module.

  • Several data base variables were moved to new RAM locations:

    • TEMP2 was shifted by one byte so it now shares memory with TEMP1.

    • PTIMOT, PBPNT, PBUFSZ, CRETRY, DRETRY, CKEY, CASSBT, NEWROW, NEWCOL, ROWINC, COLINC were moved to new locations in the Data Base.

  • An equate MODEM and data base locations CSTAT, TMPX1, HOLD5, GLBABS and ADDCOR, which all were unused even in Revision A, have been removed.

  • Definitions of TRUE and FALSE were added to Equates, apparently to be used as values for assembly options (RAMSYS and LNBUG).

  • A new equate RAMSYS suggests that new conditional code for assembling the RAM-based OS was being worked on.

  • New equates PUPVL1, PUPVL2, and PUPVL3 and new data base locations PUPBT1, PUPBT2 and PUPBT3, indicate that the System Reset functionality was modified from being initiated by the ANTIC Reset interrupt, to being initiated by the 6502 CPY reset. For the power up routine to still be able to distinguish a warm start from a cold start, the three "special" values PUPBT1-3 were introduced. The power up routine checks for three specific values in these locations to recognise cold start vs. warm start (Scheiman line 132).

  • A new data base location NGFLAG indicates that the power up routine now tests for errors in RAM and ROM.

  • A new data base location JMPERS indicates that the power up routine now tests the state of on-board configuration jumpers. A shorted jumper would force the system to run Self Test.

  • A new equate CHKLOC = $4000 does not exist in later revisions of the OS, so its purpose is uncertain. But its name suggests it is a starting address used when detecting the amount of RAM during power up (see the ENSPEC routine). In the later versions of the OS, the starting address would be set to $2800 (i.e. 10 KB), but this value suggests that originally the test was meant to start at $4000 (i.e. 16 KB).

  • A new data base location GINTLK (in a temporary location) indicates that the TRIG3 register has already been repurposed as a cartridge indicator and that the VBLANK routine, that reboots the system when a cartridge is inserted or removed, is implemented. But, considering CARTCK is not yet added to the Data Base, the code that tests for the cartridge checksum is probably not done yet.

  • New equates HELP, CNTLF2, INTCHR and DOMCHR, and new data base locations SUPERF, VSFLAG, KEYDIS, DMASAV, KRPDEL, KEYREP, NOCLIK and FINE are used by the updated Display Handler to implement functions described earlier. Though the lack of the CNTLF1, CNTLF3 and CNTLF4 equates indicates that a change in the system VBLANK routine (SYSVBL) that would suppress Control+function key combinations from producing a keyboard code, has not yet been implemented.

  • Removal of the PTEMP data base variable means that the printer handler has been undergone some changes - the support for printer device numbers (Scheiman line 144) might have been implemented at this point.

  • A new equate DSCTSZ and a new data base location DSCTLN, indicate that the disk I/O routines have been modified to support variable disk sector size.

  • New equates PAL, WLEADN, RLEADN, WIRGLN, RIRGLN, WSIRGN, RSIRGN, BEEPNN, BEEPFN, WLEADP, RLEADP, WIRGLP, RIRGLP, WSIRGP, RSIRGP, BEEPNP, and BEEPFP, a new data base location PALNTS, and the removal of the PALFLG equate and the ADDCOR data base entry, indicate that the cassette handler has been reworked to adjust its timings automatically according to the TV system.

  • A new equate STORG = $5000, which is the origin address of the Self Test memory bank, indicates that the Self Test was already in the works.

  • New data base locations LTEMP, LCOUNT, RELADR, RECLEN, HIBYTE, NEWADR, PARMBL, RUNADR, HIUSED, ZHIUSE, OLDPAR, GBYTEA, LOADAD and ZLOADA, indicate the existence of the Relocating Loader.

  • New data base locations ZCHAIN, CHLINK and HNDLOD, indicate the existence of the Peripheral Handler Loading Facility.

  • New equates LNBUG, LNIRQ and LNNMI, and the replacement of LINZBS with LNFLG in the data base, indicate that the modifications to support the new version of LNBUG development system were being implemented. Notably, the LNORG label does not exist yet, and would be added later.

  • A new data base location ENTVEC has been added, although its purpose is unknown. It would remain unused in all future OS revisions.

  • New equates AMVTAD, AMINIT, AMNAME, AMISRA and AMFLAG, and new data base locations ABUFPT, ACMISR, MINTLK (in a temporary location) and ACMVAR, suggest that support for the "Asynchronous Communications Module Interface" was being worked on. Notably, the ACMI assembly option is not introduced yet in this version - it would control whether ACMI support is enabled at assembly time.

This "Asynchronous Communications Module Interface" is a complete mystery - no known documentation mentions it, so the only available information is the OS source code itself. It was a device that when connected, would indicate this fact to the system by asserting TRIG2 low. The IIH (Initialize Interrupt Handler) routine would copy the state of TRIG2 to the MINTLK variable on system startup. TRIG2 would also be monitored in IVNM (Process Immediate VBLANK NMI) the same way as TRIG3 is monitored for cartridge change: if an ACMI module was inserted or removed, the system would reset itself (or wait for the user pressing Reset in later versions).

The ACMI would also expose its hardware memory on page $D7, specifically $D7EA-$D7FF were defined as: (xl-rev-3-ver-4/OS.ASM lines 1070-1076)

  • $D7EA: AMVTAD - vector table

  • $D7F6: AMINIT - initialization address

  • $D7F9: AMNAME - ACMI device code

  • $D7FA: AMISRA - interrupt service routine address

  • $D7FF: AMFLAG - ACMI flags

PRS (Preset Memory) would use these locations to initialize the ACMI. If bit 7 of AMFLAG was set, PRS would:

  • install ACMI’s device handler in HATABS, using AMNAME as the device’s letter and AMVTAD as the address of the handler’s vector table,

  • copy ACMI’s interrupt service routine address from AMISRA to ACMISR,

  • and jump through AMINIT to initialize ACMI.

The ACMI could raise an IRQ, though the physical mechanism is unknown. If it did, the IIR (Process Immediate IRQ) routine would jump through ACMISR to service the IRQ.

An area reverved for ACMI (11 bytes at ACMVAR) is not cleared by the OS during warm start.

Judging from the exposure of memory on page $D7, the ACMI could have something to do with the Parallel Bus Interface. The PBI was being developed as part of the Sweet-16 project before it was ultimately decided not to expose the bus in the 1200XL computer.

Note

This package contains the source listings mentioned above:

This package also contains orig-src/sweet-16/ - a recreation of the source code of the whole Sweet-16 WIP OS. It is based on these listings, with all the missing modules lifted from sources of the later XL OS Rev. 10. The Rev. 10 parts were converted to Microtec syntax and routine names were changed to their OS Rev. B names. The resulting sources are more comparable to Rev. B sources, and allow to build a working binary ROM image of the Sweet-16 WIP OS.

1982-03-29: Relocating Loader specification ready

On 29 March 1982, Amy Chen completed a specification document of the Relocating Loader she was developing (Chen, Relocating Loader title page). The specification fully describes the Relocating Loader’s functionality. It also defines the address $E486 as a public entry point to the Relocating Loader (Chen, Relocating Loader 11), as specified earlier in the Z800 OS specification (Stewart, Sweet 16 OS 17) - a feature that would ultimately be dropped.

1982-04-01: Peripheral Handler and Relocating Loader ready

Comments in the 21 June 1984 OS sources indicate that in April 1982, Robert Scott Scheiman implemented the Peripheral Handler Loading Facility, and Amy Chen implemented the Relocating Loader (xl-rev-3-ver-4/OS.ASM search for "R. S. Scheiman 04/??/82", "Y. M. Chen 04/??/82"). The dates in the comments would be later updated specifically to 04/01/82 in the Rev. 2 sources published in 1984 (xl-rev-2-1984.asm search for "R. S. Scheiman 04/01/82", "Y. M. Chen 04/01/82"), though the change was probably made to hide the fact that the precise dates were not known.

1982-06-01: Fine scrolling DLI implemented

Comments in the XL OS Rev. 2 sources from 1984 indicate that by 1 June 1982 Harry Stewart had implemented the missing DLI routine for the text screen fine scrolling (xl-rev-2-1984.asm lines 14930 and 16945). The routine changes the text color (COLPF1) on the last line of the screen to be equal to the background color (stored at COLOR2). The change hides all characters visible on the last line, fixing the issue of unwanted characters appearing on the last line when the screen is scrolled down, that was present in the Sweet-16 WIP.

Another comment explains that the CONVRT routine (later renamed to CCA) was completed by Lane Winner, also on 1 June (xl-rev-2-1984.asm line 14948). Notably, the dates of Stewart’s and Winner’s contributions were missing from all known OS revisions up to Sept. 1984, and were only added in the 1984 printed version of Rev. 2, so the date of 1 June is probably not correct. Especially considering that Winner’s change in CONVRT had already been implemented in the 1 April sources.

1982-08-31: Handler Loader specification ready

On 31 August 1982, Scott Scheiman completed a specification document of the Handler Loader he was developing (Scheiman, Handler Loader title page). The specification fully describes the functionality of the Peripheral Handler Loading Facility. It also defines the addresses $E489-$E48F as three public entry points to the Handler Loader (Scheiman, Handler Loader 25), as specified earlier in the Z800 OS specification (Stewart, Sweet 16 OS 17). These entry points would be shifted to $E486-$E48C in the finished OS because the Relocating Loader entry point, originally specified at $E486, would ultimately be dropped.

1982-09-17: First revision of the Atari 600 specification

Parallel to the development of the Atari 1200XL computer, Atari was developing a new low-cost machine, internally known under the names Liz, Crazy 8, S-8, and then Atari 600 (Squires 13). The first revision of the specification was created on 17 September 1982 (Squires 12).

1982-09-20: Second revision of the Sweet-16 OS specification

Harry Stewart’s Sweet-16 OS specification has got revised for the second time on 20 September 1982, to incorporate "further changes found to be needed during development and unit testing" (Stewart, Sweet 16 OS revision page).

1982-10-26: Self Test ready

Comments in the 21 June 1984 OS sources indicate that by 26 October 1982 Michael Colburn had implemented the Self Test (xl-rev-3-ver-4/OS.ASM search for "M. W. Colburn 10/26/82").

1982-10-26: XL OS Rev. 10 ready

ROM identifier: Date 1982-10-26, CPU series 1, Part AA000000, Rev. 10

With the Self Test in place, Revision 10 of the OS was complete. It bears the date of 26 October 1982 in the ROM identifier block. It was also called "Rev. A" in a Field Service Manual tech tip ("Tech Tip 18A"). It would eventually ship in the first Atari 1200XL computers.

Developed by Harry B. Stewart, Lane Winner, Robert Scott Scheiman, Y. M. (Amy) Chen and Michael Wayne Colburn (xl-rev-3-ver-4/OS.ASM lines 24-27), this version contains all of the enhancements specified earlier in the Sweet-16 OS specification. The only feature omitted is an entry for the relocating loader routine (RELEAD) in the jump vector table. The developers abandoned the idea of a public entry point for the relocating loader - it would remain an internal routine used only by the new SIO polling routines. Ultimately, the SIO polling and the relocating loader would never be used by any peripheral device produced by Atari.

Compared to the work-in-progress Sweet-16 sources from earlier that year, there are several differences in the Display Handler. All the handwritten annotations in the Sweet-16 listing are now incorporated in the sources. The VSFLAG, KEYDIS and FINE data base variables are now moved to their final locations. The LINBUF line buffer has been removed from the data base - it was already unused in the Sweet-16 sources, because the screen scrolling routines were updated to not use it. Speaking of which, the bug in the "delete line" editor function, introduced in the Sweet-16 sources, is now fixed - the editor now does not modify the memory above RAMTOP.

The split-screen mode in graphics mode 0 is no longer always enabled - it is now controlled by a new data base variable SPLTM0. Setting it to non-zero before opening the screen results in enabling the split-screen mode. Curiously, while SPLTM0 is specified in the Sweet-16 OS specification (Stewart, Sweet 16 OS 14) and mentioned in Harry Stewart’s presentation notes from 1982 (Stewart, Presenting 8), the preliminary version of the Atari 1200 OS Manual Supplement had this data base location excised from the list (Peck and Stewart 74) - a sign that SPLTM0 would be removed in the next OS revision.

The support for ANTIC $3 mode at screen mode number 12 has been removed, and the rest of the new modes have been shifted down by one, to their final locations:

  • 12: ANTIC $4 mode, 40*24 characters, or 40*20 + 4 text lines in mixed mode.

  • 13: ANTIC $5 mode, 40*12 characters, or 40*10 + 4 text lines in mixed mode.

  • 14: ANTIC $C mode, 160*192 pixels, or 160*160 + 4 text lines in mixed mode.

  • 15: ANTIC $E mode, 160*192 pixels, or 160*160 + 4 text lines in mixed mode.

The fine-scrolling functionality has been improved: the Display List interrupt added on 1 June hides visibility of unwanted characters on the last screen row. But the issue with setting FINE to a value between $01-$7F not enabling the DLI remains not fixed. Because of this, the XL Addendum for the OS manual would state that the only values allowed for the FINE location are 0 and $FF (XL Addendum 17).

Another quirky consequence of the added DLI is that the text would disappear during I/O operations. The value of COLPF1 is restored to its original value as usual, i.e. in the deferred VBLANK routine. But if fine-scrolling is enabled and an I/O operation is in progress, the DLI will change the text color to background and it will stay that way for the time of the I/O, because the deferred VBLANK routine is not called during time-critical operations. A quick demonstration of the issue:

FINE=622:POKE FINE,255:GRAPHICS 0
CSAVE:REM Then press any key

CSAVE is an example of a critical operation. The text will disappear when the first data block starts being output.

Related to the above, the screen and editor handlers gained a proper Close function. Previously it did nothing; now it resets the DLI vector VDSLST to a default, thus disabling the color change at the last line, but not disabling the DLI itself. The DLI is not even disabled for the moment of changing VDSLST, which may cause a system lockup if the interrupt happens in the middle of updating the two bytes of VDSLST.

Atari has dropped the idea of Control+F2 controlling the TV switchbox. Bit 2 of PORTB is now unused.

The functionality of Control+F1 and Control+F4 keys has been moved from the keyboard handler’s Get Character routine (KGETCH) to the keyboard IRQ routine (PIRQ5). The system VBLANK routine (SYSVBL) has been modified to suppress Control+F1 and Control+F2 key combinations from producing a keyboard code. This means that the keys now perform their functions (Keyboard disable, Screen DMA disable, Toggle character sets) even when the editor is not waiting for a character, for instance in the Self Test or any other program. The two combinations no longer produce a key click, and additionally the problem of the L1 diode getting inverted when the user changes KEYDIS and then presses Control+F1, has been fixed.

As a consequence, Control+F1 and Control+F4 are no longer re-assignable with the KEYDEF table, and the associated special key codes $86 (Enable/disable keyboard) and $92 (Toggle international/domestic character sets) are no longer supported in the KEYDEF and FKDEF tables. The first one is ignored (same as $80), and the second one produces the ATASCII code $92. The "Gonzo" function (special key code $88) survived these changes though, and remains functional - if we consider system lockup as "functional". The Control+F3 combination remains the only re-assignable one.

The key click routine (CLICK) has been updated to fix the issue with reading the Start key, introduced in the Sweet-16 sources.

The "extend logical line bitmap on insert line" editor routine (EXTEND) has been changed, with the loop counter changed from 23 to 22. The logical line bitmap (LOGMAP, 4 bytes = 32 bits) indicates which lines in the editor span more than one actual line of the screen, one bit for each line. (This allows to enter BASIC program lines longer than 40 characters.) The issue was, when inserting a line, the bits in the logical line bitmap (LOGMAP) would be shifted down including the 24th bit (i.e. 0th bit of LOGMAP+3). This was unnecessary, because an editor screen has only 24 rows, and the 24th bit of LOGMAP represents the 25th row, which does not exist in any screen mode. The change causes the 4th byte of LOGMAP to never be changed. The advantage of this fix was never used though - the 4th byte of LOGMAP would never be repurposed for any other functionality and would remain effectively unused.

A new data base location CARTCK has been added: it stores a checksum of cartridge contents. The monitor module’s reset routine (RESET) uses this checksum to check if a cartridge was changed. If it was, the system performs cold start instead of warm start. There is a bug in that routine though: it computes the checksum from the addresses $BFF0-$C0EF, i.e. only 16 bytes of cartridge contents are used, making the cartridge change detection quite unreliable.

The Self Test contains an easter egg - when running All Tests, during the Keyboard Test the on-screen keyboard types out the developer’s name: "Michael Colburn".

Notably, several source modules access zero-page data base variables using non-zero page addressing modes. This is caused by using .XREF instead of .XREFB when importing a variable in a module. E.g. COLRSH and DRKMSK in the display handler module are imported with .XREF (xl-rev-10/KEYDIS.ASM line 33), which results in the EOR and AND opcodes that access these variables, being assembled as absolute mode instructions. This resulted in subotpimal code, but the Microtec compiler accepted such discrepancies without a hitch, so the issue would remain unnoticed until the OS was migrated to the CAMAC assembler a year later.

Due to the multitude of differences, the new XL OS was not 100% compatible with the earlier versions. Software that made direct calls to OS procedures instead of documented vector tables would cease to function. Atari wisely took that into account, and reserved a few OS ROM locations for such programs, so that if a program jumped to such location, the OS would point the program to the right routine in the new OS. In addition to the $E912 patch added in Revision B, two new patches have been added:

  • At $E959 to the SIO routine, to support VisiCalc (Stewart, Sweet 16 OS 18).

  • At $FCD8 to the CLICK routine.

That was not enough to cover all problematic software, though. Atari later released "The Translator" (DX5063 NTSC version and FK100807 PAL version), a disk-based utility which switched the built-in OS off and replaced it with a (slightly modified) 400/800 rev. B system, allowing those programs to function properly.

The Asynchronous Communications Module Interface support was not included in the OS, as the 1200XL lacked the Parallel Bus Interface needed to connect the device. The code to support ACMI was disabled by introducing a conditional assembly variable ACMI and setting it to FALSE.

The Rev. 10 OS would be produced in the form of two ROM chips, marked:

  • C060616A - 8 KB, low OS

  • C060617A - 8 KB, high OS

It would be included in all 1200XL units leaving the factories.

Note

This package contains:

Why two verions? At one point in time, Atari migrated the OS development from the Microtec 6500 assembler to their own CAMAC. Source comments related to XL OS Rev. 3 (xl-rev-3-ver-4/OS.ASM line 44) indicate that the migration happened before that revision. At that time, all routine names were changed and code formatting was completely modified. This makes it difficult to compare source codes of earlier Microtec-based revisions with later CAMAC-based versions. Therefore, the Rev. 10 sources are available in this package in both syntaxes, to allow to trace the history of changes between older revisions A/B and Sweet-16 WIP, and the later XL/XE revisions. Though it must be noted that in reality this migration from Microtec to CAMAC probably did not happen during Rev. 10 development, but later.

Source codes in both versions match the Rev. 10 ROM.

1982-12-01: Self Test specification ready

On 1 December 1982, Michael Colburn completed a specification document of the Self Test he had developed (Colburn title page). The specification fully describes the Self Test’s functionality, including layout of all its screens. Curiously, the "Audio-Visual Test" screen layout page shows a staff with the famous five-note musical phrase from the film "Close Encounters of the Third Kind", with a handwritten note scribbled over that says "Replace with Pictures from an Exhibition, Promenade - Mussorgsky", the name of the tune actually implemented in Self Test.

1982-12-13: Atari 1200XL introduced

Atari introduced the new 1200XL home computer, around a set of peripheral devices, at a New York City press conference ("Atari introduces").

1982-12-23: XL OS Rev. 11 ready

ROM identifier: Date 1982-12-23, CPU series 1, Part AA000001, Rev. 11

Even before the 1200XL was shipped, the company prepared an updated version of the OS, named Revision 11 (XL Addendum 17). It was developed by Robert Scott Scheiman (xl-rev-3-ver-4/OS.ASM lines 29-31). Its major purpose was to provide compatibility bypasses for badly-programmed Atari Program Exchange cassette releases (Scheiman lines 120, 156), and to fix various issues in features introduced in Revision 10.

The SPLTM0 data base variable has been removed (see the change in SOP). The motives are unknown, but it is probable that the variable was identified as unnecessary - it is possible to open screen mode 0 with a text box by first opening the screen normally, and then putting 4 into the BOTSCR data base location (Brannon).

A new data base location CHSALT has been added - it stores the high byte of the address of the international character set. The behaviour of Control+F4 has been modified - it now swaps the values of CHBAS with CHSALT, allowing the user to specify their own pair of two character sets to switch between. (See the changes in COC and KIR.) This was done to solve a problem of messing up a program’s display when the user presses Control+F4. If a program modified the value of CHBAS for its own purposes, e.g. to use its own character set, the the user pressing Control+F4 would change the character set to the ROM’s international set, and then would be unable to restore the program’s character set, thus permanently breaking the program’s display. Now the user may press Control+F4 again to restore the program’s character set (Scheiman lines 140, 160).

The IVNM (Process Immediate VBLANK NMI) routine was modified to fix the issue found in Rev. 10 which caused on-screen text to disappear during I/O operations if the screen fine-scrolling was enabled. Now the immediate VBLANK routine always restores the text color (COLPF1) from the shadow register COLOR1, which means it will be restored even during time-critical operations (Scheiman line 162).

Another change in IVNM fixes an issue with the Control-F4 (Toggle character sets) key combination. In Rev. 10, if Control+F4 was held for long, the key repeat action would commence and the user would hear the sound of repeated keystrokes, though the character sets would be toggled only once. This change in IVNM ensures that the key repeat action is disabled while holding Control+F4.

A delay was added in the RES (Process RESET) routine, to fix a "customer difficulty with the SYSTEM RESET key" ("Tech Tip 18A"). The delay alleviates the problem with the Reset key’s debounce, that could cause a cold start to launch even when a warm start was expected, losing the user’s data in the process (Woolley). If a key debounce happened after the PUPBT1-3 values are zeroed (see the RES routine) but before they are set to their proper values (also see RES), it would result in an unwanted coldstart. The added 0.1 s delay ensures that any changes of PUPBT1-3 commence after the state of the Reset key had stabilized (Scheiman line 158).

The PRS (Preset Memory) routine was modified to fix a system lock-up that could happen when there was not enough RAM free for a graphics mode change. Consider the following program:

GRAPHICS 2:REM Open screen mode that takes less space
DIM A$(30000):DIM B$(8300): REM Use up almost all RAM
GRAPHICS 0:REM This fails

Opening a screen mode when there is not enough free RAM for that mode, locks up the machine. The issue in Rev. 10 was, resetting the system would not fix the lock up. Since the Reset routines attempt to open a mode 0 screen, they too would fail, leaving the machine unusable (Scheiman line 162).

It was solved in Rev. 11 by introducing a new data base variable DERRF (being set at COC), which holds the status of the last screen open operation. If PRS detects that the last screen open failed, it will zero the APPMHI pointer, thus indicating to the system that all RAM is free. This allows the later mode 0 open to end successfully, even if the user’s data in the RAM gets lost in the process.

The ECL (Perform Editor CLOSE) routine was modified to fix the bug introduced in Rev. 10 with the routine not fully disabling the fine-scrolling mode. Now when the screen device with fine scrolling enabled is closed, the fine-scrolling DLI is disabled and the screen is re-opened in non-scrolling mode 0 with the FINE variable reset to 0 (Scheiman line 162).

The KGB (Perform Keyboard GET-BYTE) routing was modified to remove support for the useless "Gonzo" function (special key code $88).

The CHLEFT, GHRIGT and CHOME routines were removed to save space, since they were merely jumps to actual routines. All references to these routines in DLN and TSFR were replaced.

The KIR (Process Keyboard IRQ) was optimized to be faster and use less ROM space, by using the X and Y CPU registers to store temporary results.

The ATARI rainbow logo routine (PPD0) was modified. It now draws an ® mark on the right of the ATARI logo. It also disables POKEY keyboard interrupts so that pressing keys no longer glitches the moving rainbow. Lastly, it fixes Rev. 10’s bug in that setting RAMTOP to a low enough value would cause the power-up display to lock, as demonstrated by this snippet:

RAMTOP=106:POKE RAMTOP,16:BYE

Now the routine resets RAMTOP to $4000, so the power-up display never fails.

The order of many routines was shuffled a lot, apparently to fit in two new unofficial OS vectors for compatibility with 400/800 OS Revision B:

  • At $EF6B jump to the ICR (Initiate cassette READ) routine,

  • At $F223 jump to the PPD0 (Perform power-up display) routine, which in Rev. B was the Memo Pad, now replaced by the rainbow logo.

OS Revision 11 was produced in the form of two ROM chips:

  • C060616B - 8 KB, low OS

  • C060617B - 8 KB, high OS

Revision 11 was also called "rev. B" in the 1200XL Field Service Manual tech tip 18A ("Tech Tip 18A"). In the APE Warp+ OS 32-in-1 upgrade developed by Steven Tucker, it is mislabeled as "1200XL (REV 5)" (Pace).

Although Revision 11 was released almost immediately after Rev. 10, due to short production span of the 1200XL, far more computers shipped with Rev. 10 than with Rev. 11 (Scheiman line 156) - it has not actually been confirmed if any 1200XL were produced with Rev. 11 factory-installed. Only two examples of a 1200XL with this OS version have been reported so far - one by Bryan Edewaard (Edewaard) and another by Steven Tucker, who again misnamed it as Rev. 5 (Tucker). Rev. 11 would be installed in 1200XL computers by Atari authorized service centers (Scheiman line 156) starting 29 September 1983.

Note

This package contains orig-src/xl-rev-11.asm - approximation of XL OS Rev. 11 sources, derived from the later Rev. 1 sources. Source of the rainbow boot screen is based in part on the sources published by Curt Vendel (Riker) (Curt’s sources are of a later revision of the screen, never included in any OS revision).

The source code matches the Rev. 11 ROM.

1983-01-06: Atari 1200XL at the Winter CES

Atari presented the 1200XL computer at the Winter Consumer Electronics Show in Las Vegas on 6-9 January 1983 (Ahl 46).

1983-01-07: Second revision of the Atari 600 specification

The specification for a new low-cost Atari 600 machine was revised on 7 January 1983 (Squires 12). It specified a new computer with features similar to the 1200XL, but without the F1-F4 function keys and status LEDs and with an added Parallel Bus Interface (Squires 14) to be available in two configurations with 16 and 64 KB of RAM (Squires 15). The computer would use a single 16 KB ROM to store the OS (Squires 16), and contain on-board BASIC (Squires 4). This project would eventually be marketed as the Atari 600XL and the 800XL.

1983-01-19: Works on the 6402 computer

By 19 January 1983 Atari was working on another successor to the 1200XL, codenamed "1251" and later "6402", that would contain a built in disk drive, voice synthesizer and modem (Stewart, Comparison). It would eventually be known as the 1450XLD.

1983-02-18: Parallel I/O ready

The OS had undergone development to support the new Atari 600 features: the Parallel Bus Interface and on-board BASIC. Comments in the XL OS Rev. 2 sources indicate that by 18 February 1983 Amy Chen had implemented the Parallel Input/Output module (xl-rev-2-1984.asm search for "Y. M. Chen 02/18/83").

1983-03-11: XL OS Rev. 1 ready

ROM identifier: Date 1983-03-11, CPU series 2, Part BB000000, Rev. 1

The first complete revision of the new OS for the Atari 600 was ready on 11 March 1983. It was developed by Robert Scott Scheiman, Richard K. Nordin and Y. M. (Amy) Chen (xl-rev-3-ver-4/OS.ASM lines 33-35). It was intended for use in all models from the new line of Atari computers: the 600XL, 800XL, 1400XL, and the 1450XLD (Scheiman line 166).

Compared to Revision 11, it added support for the Parallel Bus Interface and on-board BASIC (Scheiman line 168), along with several bugfixes.

The rainbow logo routine (PPD0) was removed to free ROM space for the new features - it was replaced with SES (Select and Execute Self-test). entering BYE in BASIC or booting the computer with BASIC disabled takes the user straight to Self Test instead of showing the logo.

The new "Parallel Input/Output" module supports devices attached to the Parallel Bus Interface, along with new data base variables: VPIRQ, PDVMSK, SHPDVS, PDIMSK, PPTMPA, PPTMPX. As a consequence, the Relocating Loader’s RELADR data base variable was moved from $0238 (now occupied by VPIRQ) to $024A. IIR (Process Immediate IRQ) was modified to support parallel device IRQs, and ISW (Initialize Software) was modified to initialize the VPIRQ vector. The SIOV jump vector now points to a new PIO (Parallel Input/Output) routine instead of SIO.

PIA PORTB bit 1 now controls whether the built-in BASIC is enabled. A new data base variable BASICF holds the state of built-in BASIC. It occupies the last byte of the area formerly occupied by ACMVAR. Various routines were modified and rearranged to support BASIC, taking into account that while enabling it via PORTB makes it look as if an external cartridge was inserted, the internal BASIC never changes the state of TRIG3 (cartridge interlock) register as an external cartridge would:

  • PRS (Preset Memory) was modified: the routine sets the BASICF flag according to the state of PIA PORTB. Testing of the TRIG3 (cartridge interlock) register was removed. Also, support for the JMPERS variable was removed as the new computer would not have configuration jumpers on the main board.

  • The call to ISW (Initialize Software) was moved a bit later in PRS (Preset Memory), after setting up of HATABS.

  • The call to IHW (Initialize Hardware) was moved from PRS (Preset Memory) to PMI (Perform Miscellaneous Initialization).

  • PMI was modified to support BASIC enabling/disabling based on the state of the Option key.

  • Initialization of the PIA chip was moved from IIH (Initialize Interrupt Handler) to IHW (Initialize Hardware).

A SEI was added at the beginning of PRS (Preset Memory), though it is unknown what error it fixes.

The CEL (Check End of Line) routine was modified to remove a call to CCR (Check Cursor Range) - it was moved to SPB (Screen Put Byte) located immediately above. It fixes a bug existing since Rev. A that only started to manifest itself in Rev. 10. When outputting continuously to the screen, pressing the Break key would sometimes be ignored and would result in one printed character being omitted (Scheiman lines 154, 174). One consequence of this fix is that the user may set the RMARGN variable to a value greater than 39 and it will not be restored to 39 during Editor Get Byte operations (i.e. reading characters) from the Editor, but only when performing Editor Put Byte (e.g. printing). Previously RMARGN would be restored to 39 during Editor Get Byte.

The Rev. 1 OS would be produced in the form of a single ROM chip:

  • C062024 - 16 KB

Although intended for all models of the new XL computer line, Revision 1 ended up installed in most 600XL units, but all known 800XL computers contain the later Revision 2.

Note

This package contains orig-src/xl-rev-1.asm - approximation of XL OS Rev. 1 sources, derived from the later Rev. 2 sources. The source code matches the Rev. 1 ROM.

1983-03: Atari 1200XL shipped

Atari shipped the 1200XL computer in March 1983 (Current section 11.1 at 1983/March). It contained the XL OS Revision 10 ROMs, though early production units contained EPROM chips instead of proper mask ROMs ("Tech Tip 18").

1983-05-10: XL OS Rev. 2 ready

ROM identifier: Date 1983-05-10, CPU series 2, Part BB000001, Rev. 2

After Revision 1, Atari continued refining the system. The next OS revision, bearing the date of 10 May 1983, was developed by Robert Scott Scheiman and fixed a few issues found in Revision 1. It was intended for the 600XL, 800XL, 1400XL, and the 1450XLD (Scheiman line 166).

The CCS (Cartridge Change Coldstart) routine (real name unknown, due to unavailability of original source code) was replaced with WRF (Wait For Reset) - when hot-plugging a cartridge, the system no longer reboots immediately, instead it hangs and waits for pressing Reset.

Order of statements in PRS was changed so that NGFLAG (memory status flag) is reset also during warm start. In Rev. 1, setting NGFLAG to 0 and pressing Reset would confuse the OS to assume that RAM is bad, and launch the Self Test’s memory test. Now NGFLAG is reset to 1 at reset and the issue does no longer occur.

The PPB (Perform Printer PUT-BYTE) routine was modified to fix a bug introduced in Revision 10 when support for printer device numbers was added. The BASIC bypasses CIO for PUT operations, and it could cause a printer PUT operation initiated from BASIC to "inherit" the device number from a previous non-printer I/O operation (Scheiman lines 144, 176).

Apparently someone had noticed Michael Colburn’s easter egg in Self Test. The TKSP table was modified so that the All Test’s keyboard test no longer types the developer’s name, instead it types "Copyright1983Atari".

Revision 2 OS would be produced in the form of one ROM chip:

  • C061598B - 16 KB

It would be included in most Atari 800XL units, including all of the European 800XLF machines. The 600XL parts list also contains this OS revision (600XL Service Manual 5-5), suggesting that later 600XL units also contained - or were meant to contain - rev. 2. There is one report of such unit (Ryan, 600XL).

It would end up included in many 65XE/130XE computers too, despite the newer Revision 3, dedicated for the 130XE, being ready before the 130XE shipped. It is possible that the Tramiels decided to initially mount rev. 2 OS in the XEs in order to liquidate the remaining backstock of parts inherited from Atari, Inc. (which was a company known for greatly overstocking their components), and started installing rev. 3 only after the rev. 2 backstock has drained.

Note

This package contains orig-src/xl-rev-2.asm - approximation of XL OS Rev. 2 sources as they would look like in mid-1983. It is based on the source listing that Atari published in 1984, but taking into account the fact that in mid-1983 the source code had differences in formatting, which would survive up to XL OS Rev. 4 Ver. 0.

The source code matches the Rev. 2 ROM.

1983-06-05: Atari 600XL, 800XL, 1400XL and 1450XLD at the Summer CES

Atari presented a new family of computers at the Summer Consumer Electronics Show on 5-8 June 1983. These were the 600XL, the 800XL, the 1400XL and the 1450XLD (Halfhill). The 600XL and the 800XL would be smaller, cost-reduced replacements of the 1200XL, without the F1-F4 function keys and the indicator LEDs, but with built in BASIC, a new Parallel Bus Interface connector, and an updated OS. The 800XL would contain 64 KB of RAM, while the cheaper 600XL would contain 16 KB, expandable to 64 KB with a separate 1064 Memory module.

The 1400XL and 1450XLD would be the high end machines, containing additional features connected internally via the PBI: a Votrax voice synthesizer, a 300 baud modem, and in the case of the 1450XLD, a disk controller (Vendel, "Atari 1400XL"; Vendel, "Atari 1450XL"). Both models would retain the 1200XL’s function keys., Additionally, the 1450XLD would retain the 1200XL’s indicator LEDs, and would have a larger housing with a built in disk drive and a bay for a second one.

Of the four machines, only the 600XL and the 800XL would reach the market. The 1400XL would be cancelled on 6 Dec. 1983, while the 1450XLD would remain in development until the company’s assets were sold to Jack Tramiel on 1 July 1984.

1983-07: Atari 1200XL production ended

Atari stopped manufacturing the 1200XL computer in July 1983 (Current section 11.1 at 1983/July).

1983-07-07: Kassar steps down

Atari announced on 7 July 1983 that Raymond E. Kassar, the CEO of the company since 1978, has resigned following the fininacial crisis at the company. He was to be replaced by James J. Morgan on 6 September; until then, Warner’s co-COO Emanuel Gerard would serve as an interim CEO (Pollack).

1983-09-06: Morgan takes over

James J. Morgan became the new CEO of Atari, Inc. on 6 September 1983 (Pollack). He immediately began restructuring the company to cut the operating costs down.

1983-09-29: XL OS Rev. 11 shipped

Atari published Tech Tip 18A for the 1200XL Service Manual on 29 September 1983 ("Tech Tip 18A"), advising to replace the Rev. 10 OS in serviced 1200XL units with Rev. 11. (It falsely states that the only difference between the revisions is the correction of a problem with the Reset key.)

1983-10/11: Atari 600XL shipped

Atari shipped the new 600XL computer in North America around October or November 1983 (Current section 11.1 at 1983/October/November). It contained the XL OS Revision 1.

1983-11-01: OS sources brought to Coding Standard

Comments in the 21 June 1984 OS sources indicate that by 1 November 1983 Richard K. Nordin reedited the source code to "bring it closer to the coding standard" (xl-rev-3-ver-4/OS.ASM search for "R. K. Nordin 11/01/83"). He added large blocks of comments describing the OS revision history and program structure, filled in a lot of missing comments in the source code itself, and added header comments to all routines that instruct how to call the routine, its exit parameters, and lists its authors and changelog.

It was all a work-in-progress though - in many places Nordin lacked the necessary knowledge to fill in the missing details, so the comments are full of question marks, to be completed later (xl-rev-3-ver-4/OS.ASM lines 13-14).

1983-11?: Migration to CAMAC

It is plausible that Nordin migrated the OS sources from the Microtec CRASS65 assembler to CAMAC around the same time as he did his Coding Standard changes. As the comments in the XL Rev. 2 source listing show, the migration allowed the developers to discover that in the CRASS65 version some symbols were imported using .XREF instead of .XREFB (previously discussed at 1982-10-26: XL OS Rev. 10 ready, which resulted in some zero-page locations being referred to using absolute mode instructions (xl-rev-2-1984.asm search for "CRASS65"). When converting the cources to CAMAC, the developers needed to replicate this problem, so that the resulting ROM binary would not change. As CAMAC had no facility to force an instruction to use absolute addressing, they solved this by turning instructions into VFD pseudo-ops (xl-rev-2-1984.asm search for "VFD").

The migration to CAMAC certainly did not happen later than 23 March 1984, as the surviving OS ROM from that date already had the VFD directives removed.

Note

It is not known how the XL OS sources looked like before they were edited to conform to the Coding Standard. As a consequence, the sources of XL OS revision 2 and earlier available in this package are historically inaccurate in the sense that while they match the contents of the ROM chips, they are formatted as if the Coding Standard had already been applied to them.

1983-12: Atari 800XL shipped

Atari started shipping small quantities of the new 800XL computer in North America in December 1983 (Current section 11.1 at 1983/December). It contained the XL OS Revision 2.

1983-12-06: Atari 1400XL cancelled

An Atari engineering log sheet from 6 December 1983 notes that "[f]or all practical purposes, the 1400 has been cancelled" (LogSheet 22). The 1450XLD computer would remain in development. In the following months, Atari would continue improving the OS in order to eliminate outstanding bugs and support the advanced PBI features of the 1450XLD. Most of the changes from this period would never reach production.

1983-02-22: PBI changes

While the new internal features of the 1450XLD were meant to function as PBI devices, supplying their own ROM handlers as any external PBI device could, they turned out to require changes in the OS itself. Comments in the 21 June 1984 OS sources show than on 22 February 1984 Olivia Ying-Tzu Jang and Vincent H. Wu made a change the first such change: they modified the PWS (Perform Warmstart) routine to initialize the PDVS (parallel device select) register to 0 on warm start (xl-rev-3-ver-4/OS.ASM lines 2305-2306).

1984-03-23: Bug fixes

Comments in the 21 June 1984 OS sources show than on 23 March 1984 Richard K. Nordin fixed several issues in the OS (xl-rev-3-ver-4/OS.ASM lines 44-49). First things first, Nordin fixed all misuses of absolute mode addressing in place of zero-page, discovered during migration from CRASS65 to CAMAC (see 1983-11?: Migration to CAMAC). He replaced all occurrences of the VFD pseudo-op with proper opcodes. It freed a few ROM bytes because each of these instructions is now shorter by 1 byte.

The first ROM identification block now includes the CPU ID byte (IDCPU), same as the second block. Previously the first block contained 0 at this location.

The number of entries in HATABS was decreased by one (by decreasing MAXDEV by 3, as each HATABS entry takes 3 bytes). This solved the problem of HATABS overlapping PUPBT1, previously noted in Rev. 2 sources (xl-rev-2-1984.asm lines 140-142).

The "Boot Error" message was modified to mixed case (xl-rev-3-ver-4/OS.ASM lines 2904-2905).

RAM size detection in PMI (Perform Miscellaneous Initialization) was modified to start detecting RAM size at 16 KB instead of 10 KB (xl-rev-3-ver-4/OS.ASM lines 2961-2962). As there were no XL machines produced with less than 16 KB of RAM, this was a safe change, and it slightly decreased the system’s startup time.

The cartridge checksum computation in CCE (Check Cartridge Equivalence) was fixed to use last 256 bytes of the cartridge instead of 16 bytes (xl-rev-3-ver-4/OS.ASM lines 3067-3068). This improved reliability of cartridge change detection.

The Self Test keyboard easter egg in All Tests was adjusted to contain the current year ("Copyright1984Atari").

Handling of SIO NAK responses was fixed in WCA (Wait for Completion or ACK) (xl-rev-3-ver-4/OS.ASM lines 13481-13482). Previously the routine would not set the Y register to 0 (to indicate failure).

Order of instructions in SEN (Send) was changed to fix an error in computation of a buffer checksum (xl-rev-3-ver-4/OS.ASM lines 13572-13573). Previously, a SIO Serial Output Ready interrupt could happen before the CHKSUM variable was initialized, causing the checksum to be incorrect and causing a transmission error.

1984-03-23: XL OS Rev. 3 binary

ROM identifier: Date 1984-03-23, CPU series 2, Part BB000002, Rev. 3

A version of OS Revision 3 dated 23 March 1984 has apparently survived on a prototype 1450XLD motherboard, and was distributed on the first CD of "PoolDisk Too" in the late 1990s (Offenga, "Operating Systems 3.3"; Pooldisk Too path TEXT/1450/1540OS3.v0). It can also be found on the Internet with the name 1450R3V0.ROM. It contains all of the Richard K. Nordin’s bugfixes made on that date, but does not contain the PBI changes from 22 February. Apparently Nordin made fixes to the OS independently and in parallel to Jang and Wu’s PBI development.

Note

This package contains orig-src/xl-rev-3-1984-03-23.asm - approximation of XL OS Rev. 3 sources from 23 March. It is derived from the later Rev. 3 sources. The source code matches the PoolDisk Too ROM.

1984-03-27: Voice synthesizer IRQ bug fix

Comments in the 21 June 1984 OS sources show than on 27 March 1984 Richard K. Nordin made another fix in the OS (xl-rev-3-ver-4/OS.ASM lines 44-49). He modified IHW (Initialize Hardware) to set bits 4 and 5 of PORTB low (xl-rev-3-ver-4/OS.ASM lines 3109-3110). Bit 5, previously unused, has been repurposed in the 1450XLD to enable or disable interrupts from the internal voice synthesizer device (Voice Handler 2), so it is now initialized to disable the interrupts on system reset. The purpose of bit 4 is unknown, though.

1984-04-16: XL OS Rev. 3 binary

ROM identifier: Date 1984-03-27, CPU series 2, Part BB000002, Rev. 3

Karl Heller dumped the OS ROM chip from a prototype 1400XL/1450XLD mainboard he owns. The chip was labelled "OS REV3 VER2 4/16" (Heller). Its ROM ID date and features match the description of Revision 3 from 27 March 1984, found in the 21 June 1984 source code (xl-rev-3-ver-4/OS.ASM lines 43-49). It contains all of the Richard K. Nordin’s bugfixes made up to 27 March, but again does not contain the PBI changes from 22 February. The "VER2" text on the label probably means the second iteration of Nordin’s development (the first being from 23 March 1984, and should not be confused with the later Revision 3, Version 2.

Note

This package contains orig-src/xl-rev-3-1984-03-27.asm - approximation of XL OS Rev. 3 sources from 27 March. It is derived from the later Rev. 3 Ver. 4 sources. The source code matches Karl Heller’s ROM.

1984-05-15: Internal PBI device support added

Comments in the 21 June 1984 OS sources show that on 15 May 1984 Olivia Ying-Tzu Jang added support for internal PBI devices (xl-rev-3-ver-4/OS.ASM line 1457). IRQ statuses of external PBI devices were exposed to the OS in the PDVI register, and the OS could be controlled to selectively ignore them by setting the PDIMSK (parallel device IRQ selection mask) data base variable. But in the 1450XLD, the internal voice handler and modem devices would expose their IRQ statuses on the separate IPDVI register. Thus Jang added the definition of IPDVI to the equates, added a new data base variable IPDIMK that would function as a selection mask for the internal interrupts, and modified the IIR (Process Immediate IRQ) routine to support IRQs reported via both PDVI and IPDVI. The routine now uses the first byte of ABUFPT (previously meant for ACMI but not actually used) as a temporary buffer.

1984-05-15?: XL OS Rev. 3, Ver. 2 ready

Comments in the 21 June 1984 OS sources show than all of the changes by Olivia Ying-Tzu Jang and Vincent H. Wu were collectively named "Revision 3, Version 2" in the introductory section (xl-rev-3-ver-4/OS.ASM lines 51-62). The date of 22 February 1984 given in the Rev. 3 Ver. 2 description seems to be incorrect, though, as according to the description itself, this version contained support for internal PBI devices, which was introduced on 15 May. It is plausible that Jang and Wu put the date in the intro section when they initially made their changes on 22 February, but when Jang did her later 15 May changes she simply forgot to update the date in the intro section.

The version’s description is also incorrect in that it describes the 22 February change as "On cold start, initialize PDVI = 0, to avoid potential checksum error" (xl-rev-3-ver-4/OS.ASM lines 60-61). Firstly, the register name is wrong - PDVI is a read only register, and the 22 February change actually initializes PDVS, a write only register located at the same memory address. Secondly, the 22 Feb. change initialized PDVS iduring warm start, not cold start. This is explainable by the fact that initialization of PDVS would be moved to cold start later in June - apparently the next developer simply updated the description of Rev. 3 Ver. 2 to match the new version’s behaviour.

1984-05-28: 600XL production suspended

It was reported on 28 May 1984 that Atari had suspended production of the 600XL computer in its Hong Kong facilities (Halper).

1984-06-08: Reset routine added, PDVS initialization moved

Comments in the 21 June 1984 OS sources show that on 8 June 1984 Michael Barall started the third round of development of Rev. 3 OS (xl-rev-3-ver-4/OS.ASM lines 64-69). Plans to release the Asynchronous Communications Interface Module had apparently been dropped by this point - Barall repurposed the ACMVAR data base area as a place for a "reset routine". The IHW (Initialize Hardware) routine now jumps (via JSR) to ACMVAR on each warm start, immediately after initializing the hardware registers (xl-rev-3-ver-4/OS.ASM lines 3169-3177). A user can now place its own routine at ACMVAR, allowing them to take control of the system at the very early stage of the system’s reset. The PRS (Preset Memory) routine initializes the first byte of ACMVAR to $60, ie. the RTS opcode, so that the initial "reset routine" simply returns immediately (xl-rev-3-ver-4/OS.ASM lines 2521-2524).

At the same date, Barall moved initialization of the PDVS register from PWS (Perform Warmstart) to IHW (Initialize Hardware) (xl-rev-3-ver-4/OS.ASM lines 2307-2308, 3111-3112). Previously initialized only on warm start, now PDVS would be initialized both on cold start and warm start.

1984-06-08: XL OS Rev. 3, Ver. 3 ready

Comments in the 21 June 1984 OS sources show than all of Michael Barall’s changes up to this date were collectively named "Revision 3, Version 3" in the introductory section (xl-rev-3-ver-4/OS.ASM lines 64-69).

1984-06-21: Device number 0 fix

Comments in the 21 June 1984 OS sources show than on 21 June 1984 Michael Barall fixed an error in SHT (Search Handler Table) originally introduced in the XL Rev. 10 OS. He restored support for device number 0, which worked fine in the 400/800 OS.

1984-06-21: XL OS Rev. 3, Ver. 4 binary and sources

ROM identifier: Date 1984-06-21, CPU series 2, Part BB000002, Rev. 3

A ROM image of Revision 3. Version 4 OS, dated 21 June 1984, was shared to the world by Nir Dary back in 1999 (Offenga, "Operating Systems 3.3"), apparently retrieved from a surviving 1450XLD machine. It can be found on the Internet under the filename 1450R3VX.ROM or os1450.128. Years later in 2025, Ken van Mersbergen retrieved an archive of source files, including OS Rev. 3 Ver. 4, on a tape backup from Atari’s Data General MV/8000 mainframes (Mersbergen, OS Rev. 3 Ver. 4). Judging from the name of the archive’s main directory, it came from the home directory of Atari employee Lane Winner. The sources match the earlier ROM dump and contain all of the changes developed by Jang, Wu, Nordin and Barall up to 21 June 1984.

In addition to the changes mentioned in the previous sections, the sources also contain several new equates and data base variables, all related to the internal voice handler, modem, and disk handler of the 1450XLD. The new equates are all on page $D1: VSTB, PBICTL, PMDATA, PMCMD, PMCTL, DISKWR, DISKRD, PMSTAT, VOICE1 and DMST. The new data base variables are DSKCNT, TOPSLT, SPBCTL, NRINGS, VPCTR and VMCTR.

Curiously, the source file is mostly, but not fully, converted from CAMAS to the Boston Systems Office assembler syntax. All "TITLE", "SUBTTL", "SPACE", "ORG" and "LIST" directives have been changed to ".NAM", ".SUBTTL", ".SPACE", ".AORG" and ".MLIST/.CLIST", and EQU and SET pseudo-ops were converted to "=". The archive also contains a second, slightly earlier copy of the sources named "OS.ASM.BU" ("BU" meaning "backup"), that has the "LST" directives not converted to BSO syntax yet. It seems as if a developer had begun converting the code to BSO syntax, but did not finish it. Later OS sources would remain in the CAMAC syntax.

Note

This package contains:

  • orig-src/xl-rev-3-ver-4/OS.ASM - XL OS Rev. 3 Ver. 4 source code from Ken Van Mersbergen, in BSO syntax. The source code matches Nir Dary’s ROM.

  • orig-src/xl-rev-3-ver-4/OS.ASM.BU - A slightly earlier version of XL OS Rev. 3 Ver. 4 sources from the same archive as the above one, with only the assembler’s "LIST" directive being different.

  • orig-src/xl-rev-3-ver-4.asm - approximation of XL OS Rev. 3 Ver. 4 sources converted back to CAMAC syntax, for easy comparison with other versions.

1984-07-01: Tramiel takes over

On 1 July 1984, Jack Tramiel’s Tramel Technology Ltd. acquired Atari, Inc.'s home video game and computer businesses, along with a stock of 100,000 XL computers (Kelly 10).

1984-07-12: Peripheral Handler Loading Facility and Relocating Loader removed

Comments in the 19 July 1984 OS sources show that on 12 July 1984 Michael Barall removed the Peripheral Handler Loading Facility and the Relocating Loader (xl-rev-4-ver-0-1984-07-19.asm lines 10874-10875, 10987-10988).

Both modules had never been used by any device produced by Atari. Barall removed them presumably to free space for the new features he would add on the next day.

Regarding the Relocating Loader, all its routines were removed: RLR, END, GBY, CAL, TEX, FTX, WOR, LOO, HIG and TRPR, along with the DATAER and MEMERR equates. The RUNADR, HIUSED, ZHIUSE, OLDPAR, GBYTEA and LOADAD data base variables were removed - their locations would be later used by the Help Text Viewer. The LCOUNT, RECLEN, RELADR, HIBYTE and PARMBL variables would also be repurposed for the Help Text Viewer, but their names were not changed, for some reason. The LTEMP, NEWADR and ZLOADA variables are now marked as unused.

Regarding the Peripheral Handler Loading Facility, most of its routines also were removed: PHL, CLT, IND, LHO, PPO, PHR, PHP, PHPA, LPH, PHG, GNL, GNLA, SHC, PHW, PHC, PHQ, PHX, PHO and PTL. The ZCHAIN, CHLINK and HNDLOD data base variables are now marked as unused. Calls to Peripheral Handler Loading Facility’s routines were removed from PRS, CIO, XOP and CCO.

Of the three peripheral handler entries in the Jump Vector Table, PHINIV (peripheral handler initialization) and PHUNLV (peripheral handler unlinking) point to an SEC/RTS routine, i.e they immediately return with error. Only PHENTV (peripheral handler entry) remains functional - the PHE routine it points to, was not removed, because it could be used by PBI devices to add their device handler to HATABS.

1984-07-13: SIO fast mode implemented, Help Text Viewer started

Michael Barall added support for SIO fast mode on 13 July 1984 (xl-rev-4-ver-0-1984-07-19.asm lines 12433-12434). The SIO protocol was enhanced to support fast mode, i.e. a transfer rate of 38400 baud (defined by the new B38400 equate) - twice as fast as the normal rate. When a device responds to a command frame with an HSACK code ('H') instead of the usuak ACK ('A'), then it means it wants to continue communication in fast mode. The WCA (Wait for Completion or ACK) routine was modified to set fast mode on a HSACK.

On the same day Barall started implementing the Help Text Viewer (xl-rev-4-ver-0-1984-07-19.asm line 4731). He added a new equate BADHFT, new data base variables HFTYPE, HPTYPE, HCHAR, HNEXT, HROW, HCOL, HFILL, HFIRST, HIMAGE and HCOUNT, and new routines HTV, CHK, IHV, HFILE, HMESAG, HTSMSG, HSMMSG, HMMMSG and HCSMSG. HTV was exposed via a jump vector HTXTVV at $E49F, for use by applications. The LCOUNT, RECLEN, RELADR, HIBYTE and PARMBL variables were repurposed for use by the Help Text Viewer without changing their names.

ISW (Initialize Software) was modified to set the Viewer’s initial state, and KGB (Perform Keyboard GET-BYTE) was enhanced to open the Viewer when the user presses the Help key. Knowing that Keyboard Get Byte is used by both the keyboard and the editor handler, Barall ensured that the Help key is processed only if KGB had been launched in the context of Editor Get Byte (and added a comment in EGB to warn future developers about it).

1984-07-16: Help Text Viewer updated

Michael Barall continued implementing the Help Text Viewer on 16 July 1984 (xl-rev-4-ver-0-1984-07-19.asm line 11932). He added new routines HRO, HRD, HCC, HAB, HRB, HDB, HAF, HTI, and HPT.

He marked 16 July as the starting date of development of Revision 4, Version 0 (xl-rev-4-ver-0-1984-07-19.asm lines 78-83).

1984-07-17: Help Text Viewer updated

Michael Barall continued working on the Help Text Viewer on 17 July 1984 (xl-rev-4-ver-0-1984-07-19.asm line 5030). He added a new routine HCS (Help Viewer Clear Screen).

1984-07-19: XL OS Rev. 4, Ver. 0 sources

ROM identifier: Date 1984-07-17, CPU series 2, Part CC000001, Rev. 4

Source files for Revision 4, Version 0 of the OS, dated 19 July 1984, were found by Ken van Mersbergen on a tape backup from Atari’s Data General MV/8000 mainframes, and published in 2025 (Mersbergen, OS Rev. 4 1984-07-19). It is the first revision dated after Jack Tramiel bought the Consumer division of Atari, Inc. from Warner on 1 July 1984. The source’s date in the header comments (xl-rev-4-ver-0-1984-07-24.asm lines 76-81), and in the ROM Identifier (xl-rev-4-ver-0-1984-07-24.asm lines 162-164) contain the dates 16 July and 17 July 1984, respectively.

This copy of the sources contains all of Michael Barall’s changes up to 17 July, i.e. the Help Text Viewer and SIO fast mode.

Additonally Barall also added a few new "LIST L" and "LIST -L" directives that so that only the Help Text Viewer’s routines would be printed during assembly. He also slightly updated the "FIX" macro to display a more descriptive error message.

ACMI variables ACMISR and MINTLK were marked as unused, though the code that uses them, guarded by the ACMI conditional assembly variable, was not yet removed from the sources.

Note

This package contains these sources in orig-src/xl-rev-4-ver-0-1984-07-19.asm.

1984-07-24: Help Text Viewer and SIO fast mode updated

Michael Barall made the last changes to the Help Text Viewer by 24 July 1984. He added an "error code handling of Help key" feature in the CHK routine: if the HNDLOD variable (previously unused since July 12) is set to non-zero, then pressing the Help key does not launch the Help Text Viewer, but returns with status code KELPKD=149.

He also adjusted the status code BADHFT, introduced on 13 July, from 178 to 148; and adjusted the HCSMSG text message, removing the word "LAST" from it. Lastly, he adjusted the KGB (Perform Keyboard GET-BYTE) routine: he moved the check for the Help key, introduced on 13 July, a few lines down after the check for the Break key; and he reorded the code around the KGB10 label to support the above-mentioned error code handling of Help.

While he was at it, he also added missing comments in KGB and TCKD related to the Control+3 key. He also removed the "LIST L" directives previously added for debugging.

Barall also enhanced the SIO fast mode routines further (xl-rev-4-ver-0-1984-07-24.asm lines 12239-12241). Apparently the standard IRQ-based SIO routines were not fast enough to maintain error-free communication at 38400 baud when receiving a data frame. Barall introduced a "supercritical I/O" code path for the SIO receive routines. The WCA routine, when an SIO device requested fast mode, sets the high bit (previously unused) of CRITIC to indicate "supercritical I/O". When receiving a data frame, the RCD (Receive a Data Frame) routine tests this flag and if it is set, it reads the full data frame in a busy loop, without using POKEY IRQs.

The SIO code was reorganized a bit to implement this feature. A part of REC (Receive) was split off into a separate routine PTR (Prepare to Receive). A call to REC in SIO was redirected to the new routine RCD (Receive a Data Frame) instead, and a new routine ICI (Invoke Serial Input Ready Routine) was intriduced that is called from RCD.

A CLI instruction was added to ITO (Indicate Time Out), because due to the above changes it can now be called when IRQs are disabled, and had it not cleared the I flag, the system could return from an SIO read with disabled IRQs.

Servicing of the Break key was slightly modified in PBK (Process BREAK Key).

The Help Text Viewer

Now in its final form, the Help Text Viewer provides a facility for displaying context-sensitive help screens. When the user presses Help while the screen editor waits for input, or calls the Viewer via the HTXTVV vector, the system reads a help file, using RELADR as a pointer to the filespec ("D1:HELPTEXT.SYS" by default). If the help file has incorfrect format, the system returns status code BADHFT=148 - otherwise it displays the help to the user. The help text file is organized into screens: each screen contains some text, and may link to several next screens. The user navigates between screens using the keyboard. They choose one of the next screens by pressing A to Z - or, if there is only one next screen, they press Space. Pressing Return always returns to a previous menu screen, and Esc returns to the main menu screen. To leave the Help Text Viewer, the user presses Break.

Each screen may contain up to 22 rows of text. The Viewer draws a dividing line on the next-to-last screen row (using a character whose screen code is set in HIBYTE) and displays a prompt on the last row. The prompt’s text depends on how many links to next screens are defined for this screen:

  • If there are 2 or more links (a "menu"), then the prompt is "SELECT TOPIC OR RETURN FOR LAST MENU". The user should press A to Z to select a next screen, or Return to return to a previous menu. (The screen’s text should describe the list of available options.)

  • If there is 1 link (a "continuing screen") then the prompt is "PRESS SPACE BAR TO CONTINUE". The user should press Space to follow to the next screen, or Return to return to a previous menu.

  • If there is 0 links (a "concluding screen") then the prompt is "PRESS SPACE BAR FOR MENU". The user should press Space or Return to return to a previous menu.

  • Regardless of number of links, if a screen is marked with a "main menu" flag (bit 7 set in number of links) then the prompt is "SELECT TOPIC OR BREAK TO EXIT".

One screen is designated as the main menu - the Help Text Viewer will display this screen by default, and it will also return to this screen every time the user presses Esc. The help file may also define a list of "context entries" - the user may choose to start the Viewer at a chosen context screen, by setting the screen’s index in LCOUNT before pressing Help or calling HTXTVV. This allows an implementation of context-sentitive help, with different help menus available from different places in an application.

The help file may also contain 960 bytes of screen swap area. If so, Help Text Viewer will save the current contents of the editor screen to that area, before replacing it with the help screen; upon leaving the viewer, the OS will restore the editor screen from disk. The user may disable this screen saving and restoring by setting RECLEN to 0 before calling HTXTVV; entering the Viewer via the Help key always enables this function though.

The Help Text Viewer’s file format is based on "pointers" - whenever the Viewer wants to show a particular screen, it reads a 3-byte "screen pointer" from the file, which contains disk sector number (low byte, high byte) and offset in sector (byte), and feeds these 3 bytes straight to a CIO POINT command, thus setting the file’s current read position to the beginning of a screen’s data. As a consequence, a help file may contain superfluous data that is not reachable by any "pointer", and still be considered valid.

A Help Text Viewer starts with a header of at least 10 bytes:

Offset Size (bytes) Name Contains

0

2

HFTYPE

$FD $FD

2

1

HFILL

Non-zero if file contains screen swap area

3

3

HFIRST

Pointer to first screen

6

3

HIMAGE

Pointer to screen swap area

9

1

HCOUNT

Number of context entry screens

10

3*HCOUNT

HNEXT

Pointers to context entry screens

The HFIRST pointer and every pointer in HNEXT shall point to locations in the file that contain screen data. Whenever the user presses Esc, the Help Text Viewer will display the screen pointed to by HFIRST. If the user launched the Viewer after setting LCOUNT to a non-zero value N, then the Viewer will display a screen pointed to by the (N-1)th entry in HNEXT.

Additionally, if HFILL is non-zero, then HIMAGE shall point to a 960-byte area in the file that will be used as a buffer for the current screen contents when starting and leaving the Viewer.

Each screen data has the following format:

Offset Size (bytes) Name Contains

0

size

SCREENDATA

Screen contents

size

1

HPTYPE

Bit 7 - Screen type; Bits 6-0 - Number of next screens

size+1

3*([HPTYPE bits 6-0]+1)

HNEXT

Pointers to next screens

SCREENDATA is a sequence of characters - not ATASCII, but ANTIC internal screen codes. It can contain any characters, some being interpreted specially:

  • $C0 - escape charater; causes next character to be output literally

  • $C1 - carriage return

  • $C2 - page feed; marks an end of SCREENDATA

  • $C3-$DF - multiple space; outputs from 2 to 30 spaces

The text in SCREENDATA should not span more than 22 rows - any additional text will be omitted. Since the Viewer honors margins set in LMARGN and RMARGN when displaying screen data, the user should set their margins wide enough to ensure the screen data will also fit horizontally. SCREENDATA must end with an unescaped $C2 (page feed) code.

Then the value of HPTYPE follows. HPTYPE contains the number of next screens the user can choose from; this number also determines the prompt shown to the user on the last line. If its 7th bit is set, then the screen is considered a "main menu" screen, with a different prompt.

After HPTYPE, pointers to next screens follow. The number of these pointers shall be 1 more than the value in HPTYPE. This is because the first pointer is a pointer to a "previous screen", i.e. the screen the user will return to when they press Return. The rest are pointers for next screens, which the user chooses from by pressing A..Z (or Space, if there is only one next pointer).

Note

This source listing contains an Atari BASIC program that generates an example HELPTEXT.SYS file: GENHELP.BAS. It contains comments for help in analysis.

Run this program with a DOS loaded and a disk in the D1: drive. It will create D1:HELPTEXT.SYS (be patient though). Then press Help to see the Help Text Viewer in action.

1984-07-24: XL OS Rev. 4, Ver. 0 sources

ROM identifier: Date 1984-07-17, CPU series 2, Part CC000001, Rev. 4

Source files for Revision 4, Version 0 of the OS, were found by Ken van Mersbergen on a tape backup from Atari’s Data General MV/8000 mainframes, and published in 2024 (Mersbergen, OS Rev. 4 1984-07-24). This copy of the sources is newer than the last one - it contains Michael Barall’s changes up to 24 July (xl-rev-4-ver-0-1984-07-24.asm lines 12239-12241), although the date in the header comments (xl-rev-4-ver-0-1984-07-24.asm lines 76-81), and the ROM Identifier (xl-rev-4-ver-0-1984-07-24.asm lines 161-170) were not updated.

Note

This package contains these sources in orig-src/xl-rev-4-ver-0-1984-07-24.asm.

1984-09-04: XL OS Rev. 5, Ver. 0 started

On 4 September 1984, Michael Barall and Vincent H. Wu started developing Revision 5 of the OS (xl-rev-5-ver-0/OS.ASM lines 83-89).

By this time, plans to release the Atari 1450XLD were apparently scrapped. Instead, Atari started development of a cost-reduced machine under the moniker "900XLF" - which would be released as the 65XE. The 900XLF was planned to be functionally identical to the 800XL, but omit the Parallel Bus Interface. OS Revision 5 was apparently destined for this new computer - It would retain the Help Text Viewer and the SIO fast mode, but remove all the functionality relating to features that the 900XL would not have. Support for the PBI, ACMI and F1-F4 keys would be removed.

1984-09-06: XL OS Rev. 5, Ver. 0 binary

ROM identifier: Date 1984-09-06, CPU series 2, Part CC000001, Rev. 4

A binary image of a work-in-progress OS Revision 5, Version 0 was found by Ken van Mersbergen on a tape backup from Atari VAX mainframes, in the form of a (modified) MOS Technology hex format, and published in 2024 (Mersbergen, OS Rev. 5). Its ROM identifier holds the date of 6 September 1984, though other ID values have not been changed - the Revision field, in particular, still contains the value 4.

The support for ACMI was completely removed - all code guarded by the ACMI conditional assembly variable was cut. The Parallel Bus Interface support was also removed; the Parallel Input/Output device handler routines now return an error (#NONDEV in the Y register) when called.

The cassette, printer, keyboard, editor and screen handlers were reverted to the Revision B version, the goal being to achieve 100% compatibility with old software and eliminate the need to use "The Translator" disk. The change was done rather heavy-handedly - instead of reverting only the changes introduced since Rev. B while preserving code formatting and names of routines, the handlers were replaced wholesale with Rev. B sources, and all references to the handlers in other modules were modified to use old Rev. B names of routines. In this process, the developers failed to notice that the routine named SMS in the XL version of the handlers is the same exact routine as PUTMSC in Rev. B, and retained both of them in the sources.

Any new features and bugfixes in the handlers were re-applied in the form of patches, to avoid shifting the binary locations of the routines around and retain binary compatibility with Rev. B. The following new features remained:

  • Support for printer device numbers

  • Automatic PAL & NTSC timing in cassette handler

  • Variable key repeat delay

  • Disabling the keyboard click

  • Keyboard click routine modified to not use WSYNC

  • Fix for the clear screen routine writing past RAMTOP

  • Support for screen modes 12-15 in screen handler.

  • Fix for the screen open not-enough-memory condition locking the whole system (see XL OS Revision 11)

  • Help Text Viewer launched via the Help key

These features did not survive:

  • Support for F1-F4 keys, including all Shift+Fn and Control+Fn functions, and console LEDs.

  • Redefinition of key functions.

  • Modification of the Caps key action - Caps without Shift always switches to lowercase instead of toggling the case.

  • Fine scrolling of the screen editor.

  • Insertion of EOL to the printer buffer at CLOSE operation to ensure that the contents of the buffer are printed immediately.

Support for screen mode 15 is slightly broken though - the screen opened in this mode contains one line of ANTIC mode $F instead of $E.

Further changes to improve Rev. B compatibility were made:

  • An "IOCB not open" routine was added at $E4C1.

  • A jump to CIO was added at $E4C4.

  • A jump to SVP (Set VBLANK Parameters) was added at $E8ED.

The keyboard layout in Self Test was updated to reflect the 800XL’s and 900XLF’s physical keyboard better. The F1-F4 keys were removed, the Break key moved to the right of the Backspace key, the Inverse Video key - to the right of the right Shift key. The top row of Keyboard Test now contains, in order, Start, Select, Option, Help and Reset.

Note

This package contains orig-src/xl-rev-5-ver-0-early.asm - approximation of XL OS Rev. 5 Ver. 0 sources with the screen mode 15 bug. It is derived from the later Rev. 5 Ver. 0 sources The source code matches van Mersbergen’s ROM. Note that if you build a Rev. 5 Ver. 0 (early) ROM using this package, it will contain correctly computed checksum bytes, which will make it different from van Mersbergen’s ROM - the latter had the checksums left unset.

1984-09-06: Screen mode 15 fixed; XL OS Rev. 5, Ver. 0 sources

ROM identifier: Date 1984-09-06, CPU series 2, Part CC000001, Rev. 4

Curt Vendel found source files for OS Revision 5, Version 0 on tape backup from Atari’s VAX mainframes and published them in 2005 (Vendel, OS Rev. 5). Ken van Mersbergen found the same source files in 2024, together with the ROM binary described above (Mersbergen, OS Rev. 5) These sources do not match van Mersbergen’s ROM binary: they are slightly revised. The only change is, the support for screen mode 15 was fixed.

Note

This package contains:

  • orig-src/xl-rev-5-ver-0/OS.ASM - XL OS Rev. 5 Ver. 0 source code from Curt Vendel.

  • orig-src/xl-rev-5-ver-0/PATCH.ASM - Patches for XL OS Rev. 5 Ver. 0 device handlers, that restore XL functionality to Rev. B handlers. This file was found by Curt Vendel together with OS.ASM. Since OS.ASM already has the patches integrated, this file is superfluous. Besides, the patches here are incomplete and in an earlier version than the ones integrated in OS.ASM. In particular, "PATCH #3 for DISPLAY handler" contains the screen mode 15 bug.

1984: XL OS Rev. 2 source listing

Sometime in 1984, Atari, Inc. prepared the source code of XL OS Revision 2 for publication as part of the XL Addendum (XL Addendum), although according to Ian Chadwick the sources have never been published officially (Chadwick 212). The listing is truncated to 60 columns.

The sources have evidently been revised before publication. Richard K. Nordin’s initiative to document all the routines was partially completed, but mostly aborted. A few comments were improved, mainly in the Floating Point Package, but most question marks that Nordin had left for future completion, were just removed from the sources.

Note

This package contains:

Compare these sources with the Rev. 2 sources as they could look in mid-1983.

1984: Swedish 600XL produced

Atari Scandinavia was a local subsidiary of Atari, Inc. established in Sweden in the early 1980s. They were distributing a localized version of the 600XL computer on the Swedish market in 1984 (P1r, Description). The localization was apparently done by the distributor, as it did not involve any production of custom parts - rather, the keyboard layout was modified to Swedish by means of overlay stickers (P1r, Pictures). The computer also contained a localized version of the OS that supported the modified keyboard layout. The OS ROM has been since dumped and shared by multiple owners of these computers (Roydea6; Degerfält).

The international character set (ICSORG) was modified: it contains Swedish characters "å", "ä" and "ö", in both letter cases, but all other characters are the same as in the domestic set, including the semigraphics. TCKD (Table of Character Key Definitions) was modified to support the Swedish keyboard layout. KGB (Perform Keyboard GET-BYTE) was modified to support proper case switching for the Swedish letters.

A patch was applied to KIR (Process Keyboard IRQ), that allows to switch between the domestic and Swedish character sets by means of keyboart shortcuts. Shift+Control+2 enables the Swedish character set, while Shift+Control+1 reverts back to the domestic one. The selected character set is stored in the new flag at $06FF (which may cause issues with software that uses page 6).

The PPB (Perform Printer PUT-BYTE) routine was also patched. If the user sends an "å" (ATASCII $60) character to a printer while the $06FF variable inidcates the Swedish character being enabled, the character will be replaced with code $7D. It is unknown which printer would require such change.

The whole Self-Test was translated to Swedish. A patch was added to STH (Self Test Hardware), to enable the Swedish character set before running Self-Test. The Keyboard Test screen was modified with the Swedish keyboard layout. The F1-F4 keys were removed from the screen, too.

For an unknown reason, the power on ROM memory test was disabled in this version - the instruction in PRS (Preset Memory) that sets the NGFLAG to indicate that the ROM is invalid, was replaced by NOPs.

Note

This package contains:

1985-01-05: Atari 65XE and 130XE on the Winter CES

Atari Corporation presented their new lineup of 8-bit computers on the Winter Consumer Electronics Show on 5-8 January 1985. The new machines were the cost-reduced 800XL-compatible 65XE, the 130XE with RAM expanded to 128 KB, the 65XEM with an AMY sound chip, and the portable 65XEP. While the 65XEM and the 65XEP never materialized, the 65XE and the 130XE would reach the market the same year.

1985-03-01: XE OS Rev. 3 ready

ROM identifier: Date 1985-03-01, CPU series 2, Part BB000001, Rev. 3

Atari has developed a new revision of the OS, with the date in the ROM identifier being 1 March 1985. It was based on Revision 2 from the 800XL, and did not contain any of the changes and additions introduced later. Apparently the new management of Atari had decided to abandon any significant development of the OS.

Compared to Revision 2, this OS version contains changes in the Self Test to support testing of expanded memory in the 130XE computer, which was available by setting bits 2-3 of PORTB. The Memory Test does no longer flash the (now non-existing) console LEDs during the test - instead it tests the additional memory banks after finishing with the main RAM, and displays the results in the form of four green or red horizontal bars below the main RAM display, one for each bank. But the testing was programmed incorrectly - the values in the TXEB table are so defined that the test uses bits 1-2 of PORTB instead of 3-4. While this is invisible for the user, the test effectively checks only 2 of the 4 banks, and switches BASIC on and off in the meantime.

Other than that, the Memory Test had its delay loops shortened so that it performs faster.

The Keyboard Test was also updated, to match the keyboard layout to the XE keyboard, although this was done independently to the previous attempt in XL OS Revision 5. Also, the easter egg in All Tests was updated so that the keyboard now types out "Copyright1985Atari".

Overall, parts of Self Test were rewritten to free ROM space for new features. The Audio-Visual Test was subject to the most refactoring, and the STH (Self-test Hardware) routine was removed because it only jumped to EST (Execute Self-test).

Apart from the Self Test, XE Revision 3 incorporates one bugfix originally developed in XL Rev. 3, namely the fix in the SEN (Send) routine in checksum computation - the only change retained from all the development in 1984. Otherwise this revision is identical to XL Revision 2.

The XE Rev. 3 OS would be produced in the form of a single ROM chip:

  • C300717 - 16 KB

It would be included only in later 65XE and 130XE computers, and in all 800XE units. Apparently it reached the market quite late, possibly even after the XEGS shipped (which had rev. 4 built in), when Atari Corp. started moving its focus, and production volume, to the European (especially Eastern) market instead of the dwindling U.S. one. As a result this OS revision is more common in PAL systems than in NTSC ones.

Note

This package contains orig-src/xe-rev-3.asm - approximation of XE OS Rev. 3 sources, derived from the earlier Rev. 2 sources. The source code matches the Rev. 3 ROM.

1985-03-30: Atari 65XE and 130XE shipped

An Atari Corporation official announced on 30 March 1985, that the 130XE had just shipped in the United States and the 65XE was being shipped in Canada (Current section 11.1, 1985/March 30).

Both machines contained the old XL OS Revision 2 in their ROM chips. The new OS revision was apparently not ready by this point, so they had no choice but to use the old stock of Rev. 2 ROM chips in their new machines.

1987-01-08: Atari XEGS at the Winter CES

At the Winter Consumer Electronic Expo on 8-11 January 1987, Atari previewed their new game console: the XE Game System (Bell). It was a 65XE computer disguised as a game machine. It had a separate keyboard, attached to the main console by a cable with 15-pin connector, while the Start, Select, Option and Reset keys would be placed on the console itself. It would also have a built-in game of Missile Command, that would launch automatically if the keyboard was not attached and no game cartridge was inserted. It would require changes in the OS to support the new features.

1987-05-07: XE OS Rev. 4 ready

ROM identifier: Date 1987-05-07, CPU series 2, Part BB000001, Rev. 4

Atari developed a new revision of the OS for the XE Game System console. It was dated 7 May 1987 in the ROM identifier. It contained a few changes from the XE Revision 3, to support the XEGS’s new features.

The system now detects if the keyboard is attached by the value of TRIG2 (0 = keyboard attached). The PMI (Perform Miscellaneous Initialization) routine tests the value of TRIG2 and the state of Select and Option keys, and decides if it should enable the on-board BASIC or Missile Command. PORTB bit 6 now controls whether the game’s ROM is enabled - setting the bit to 0 makes the ROM visible in the $A000-$BFFF area.

The cassette handler was updated as well - the AUB (Alert User with Beep) routine, called when booting from tape, now checks if the user pressed the Start key, in addition to any keyboard key. This allows to load programs from tape even if the keyboard is not attached, by pressing Start again after the beep.

The Rev. 4 OS would be produced in the form of a single ROM chip:

  • C101687 - 32 KB

The chip also contains Atari BASIC rev. C and the Missile Command game (slightly modified from the original 1981 cartridge version, to fix direct 400/800 OS calls that prevented the level select function from working (Ryan, Missle Command)). It would be included in all XEGS units.

Note

This package contains orig-src/xe-rev-4.asm - approximation of XE OS Rev. 4 sources, derived from the earlier Rev. 3 sources. The source code matches the Rev. 4 ROM.

1987-07-21: Arabic XE OS Rev. 59 ready

ROM identifier: Date 1987-07-21, CPU series 2, Part BB000001, Rev. 59

Atari had introduced the Atari 65XE to Arabic countries starting in 1987. The Arabic version of the computer was marketed in cooperation with aDawliah Electronics under their "Najm" brand. These computers had a keyboard with additional Arabic symbols printed on the keys, and contained a new OS revision, expanded with support for the Arabic language. The new revision was based on XE Revision 3.

The Domestic Character Set was modified to contain letters and symbols from the Arabic alphabet in place of lowercase letters, digits and semigraphics (capital letters remain English). The Arabic alphabet is always cursive, so letters in a word are joined to each other, and each has up to 4 shapes depending on whether it appears in an initial, medial, final or isolated position (a system known as IMFI). Since the computer’s character set would not fit all 4 forms of all 28 Arabic letters, only two forms are included: one for the initial and medial positions (generally in the area of lowercase letters $60-$7F), and another for the final an isolated positions (generally in the area of semigraphics $00-$1F). For an unknown reason, some of the digit glyphs, located at the 0-9 characters, are also duplicated replacing the Esc, pipe, back space, and arrows glyphs.

The original Domestic Character Set (i.e. with English characters and semigraphics) was not removed though, but moved to the International Character Set’s space. The default character set when the system starts is the new domestic (i.e. Arabic) one.

The screen editor was enhanced with right-to-left text entry: the mode is enabled whenever the user switches to lowercase with Caps or to semigraphics with Control+Caps. In this mode, entering a character shifts the whole line right and puts the character at the freed space, with the cursor remaining at its position. While writing, the cursor’s original position is tracked by the new data base variables LTRCOL and LTRROW, so that when the user switches back to left-to-right mode with Shift+Caps, the next written character will appear after the previously entered text, instead of overwriting it immediately. This feature allows to enter BASIC PRINT statements that contain Arabic text quite fluidly.

The right-to-left entrymode seems a bit half baked though, as it has a few minor issues:

  • It is activated in small caps or control caps mode, but it is also activated when the user enters a single letter by pressing Control+letter, even in capital caps mode.

  • It may be activated even if the current character set is not Arabic, e.g. when CHBAS is switched to the International Character Set (i.e. English).

  • When in right-to-left mode, the two Arabic letters that are located under non-alphabet keys, i.e. period and semicolon, require holding Control to enter them.

  • If the screen is cleared while in the right-to-left mode, the LTRCOL/LTRROW cursor tracking is not reset, so the following sequence:

    1. Press Caps to switch to small caps

    2. Enter some Arabic text

    3. Press Shift+< to clear screen

    4. Press Shift+Caps to switch to capitals

    5. Enter some English text

    will cause the cursor to jump to a location that does no longer make sense since the screen was cleared.

Sometimes called rev. 3B (59 dec = 3B hex), this OS revision was produced in the form of a single ROM chip with a printed text similar to: (Delsarte; Staworzyński)

C101700-001A
(C) ATARI 1987
RP2D129 0922
38 7K1 50

It was included in early Arabic 65XE units, produced from 1987.

Note

This package contains orig-src/xe-rev-59-1987.asm - approximation of XE OS Rev. 59 sources from 1987, derived from the earlier Rev. 3 sources. The source code matches the Rev. 59 ROM from 1987.

1988-09-22: Arabic XE OS Rev. 59 improved

ROM identifier: Date 1987-07-21, CPU series 2, Part BB000001, Rev. 59

The Arabic OS was developed further, to enhance the Arabic language-related functionality. A new revision, confusingly bearing the same exact ROM identifier block as the previous Revision 59, was ready by 22 September 1988, according to a date on an Arabic EPROM chip’s label (atari65xenajm).

Compared to the 1987 version, it contains more enhancements in the screen editor. The Arabic character set was redefined: previously all Arabic letters were drawn using single-pixel-wide lines, and now they were redrawn thicker, presumably to improve readability on displays connected by the RF port. Three new Arabic glyphs were added:

  • A new Arabic letter in place of the backslash ($3C),

  • The underline ($3F) was redefined to allow to be used as a base line connecting Arabic letters,

  • An Arabic (i.e. mirrored) question mark was added in place of the tab character ($7F).

The Esc, pipe, back space, and arrows glyphs, occupied by unnecessary copies of Arabic numerals in the 1987 version, have been restored to their original designs (Esc being the exception, as is slightly differs from the original design).

This revision supports a new Shift+Help keyboard shortcut, that toggles between the domestic (Arabic) and the international character sets. This is done by modifying the part of KIR (Process Keyboard IRQ) that checked for the Control+F4 shortcut (remaining in the OS since the 1200XL). The unfortunate side effect of this modification is that the HELPFG data base variable no longer allows to detect pressing Shift+Help nor Control+Help - it changes its value only when Help is pressed without modifier keys.

The right-to-left entry mode was developed further. It is now active only when the Arabic character set is enabled, and only in the small caps mode. The Arabic letters located on non-alphabet keys, i.e. period and semicolon, no longer need to be entered while holding Control. (The new letter introduced at the backslash character needs to be entered by pressing Shift+plus though.) Clearing the screen when right-to-left entry is active does not later cause the cursor to jump to an invalid location. Most importantly, the last letter of each entered word is automatically converted to its final/isolated form, so the user does not need to enter the last letter of a word with holding Control anymore.

In addition to the above, a new feature was introduced: a right-to left display mode. Activated by pressing Control+Caps, it causes the whole screen’s contents to be shifted to the right margin; new characters also are entered from the right side. (One cannot enter the semigraphics mode with Control+Caps anymore, though.) Additionally, non-Arabic words (i.e. words entered with Arabic mode disabled) will have their order reversed, as will statements separated with a doublequote character. The reason for this feature is not really known.

This display mode is implemented in the simplest way possible: by setting up a second screen buffer, to which the system copies the standard screen’s contents, simultaneously converting it to right-to-left layout. When right-to-left display mode is enabled, the system leaves the original screen (pointed to by SAVMSC) intact, and instead modifies the display list to display a secondary screen located at address RTLMSC=$9858. Every time the screen editor expects a key press, the system copies the whole contents of the original screen to the secondary screen (see MRTLSC), shifting each copied line to the right margin and reversing the order of words. When the screen editor accepts a key from the user and updates the screen, it operates on the contents of the original screen, and the secondary screen is again updated by the copy routine.

Since this screen copying is done at each keypress, the process is quite slow. It becomes noticeable when the user sets a fast key repeat rate (POKE 730,1) - the system, busy with copying the screens over and over, will decrease the key repeat rate when the right-to-left display mode is enabled. Another consequence of this approach is, the screen is not updated while text is being output (such as when listing a long BASIC program), only after the output ends. This makes it impossible to read long programs while they are being written on the screen.

The screen copying procedure has an off-by-one bug: the resulting screen is shifted one byte to the right. So if the user sets the left margin to 0 (POKE 82,0), the rightmost column of the text will end up wrapped to the left side of the screen.

The way the KGB (Perform Keyboard GET-BYTE) routine was modified to accept the Control+Caps shortcut, it breaks processing of Shift+Control+key shortuts. In the earlier revisions, such combinations were ignored. Now they are not, instead they print random characters on the screen. Another, more obvious consequence, is that it is no longer possible to lock the editor to semigraphics mode.

The new features needed freeing ROM space, which was achieved by yanking the whole "Part 3" section of the Peripheral Handler Loading Facility. The PHR, PHP, PHPA, LPH, PHG, GNL, GNLA, SHC, PHW, PHI, PHC, PHQ and PHX routines were removed, and references to them in other system code replaced with NOPs. The rest of the Peripheral Handler Loading Facility remained untouched though.

In all known cases the OS ROM consists of one 16 KB 27128 EPROM chip with a paper label that covers its window. The text printed on the label comes in two variations:

  • The first variation (atari65xenajm) specifies both the ROM’s production date and its checksum 66B3, which is a straight sum of the ROM’s bytes:

    (C)ARAB XE OS
    C101700-002C
    XE #1 66B3
    09/22/88
  • The second variation (Savetz, Arabic 65XE 2013; Brenski) is shorter:

    C101700-002C
    (C) ATARI 1988

The EPROM form suggests that the number of units produced was too small to warrant manufacturing of proper mask ROMs.

This OS version was included in Arabic 65XE units starting in 1988 or later. Most of them are PAL (Jones; Savetz, Arabic 65XE 2013), which is expected considering that all Arabic countries used the PAL system, but there also exists one known NTSC unit, bought by Kevin Savetz in 1999 (Savetz, "Atari 65XE Arabic").

Note

This package contains orig-src/xe-rev-59-1988.asm - approximation of XE OS Rev. 59 sources from 1988, derived from the earlier Rev. 59 sources. The source code matches the Rev. 59 ROM from 1988.

1991-12: Atari 8-bit computers discontinued

Atari Corporation decided in December 1991 to discontinue the Atari 8-bit computer system including the XEGS (Duarte 22; Poehland).

5. Acknowledgements

This work would not be possible without support of multiple people who shared their knowledge, time and resources withouth expecting much in return. Greeting go to, in no particular order:

  • Bruce Tomlin, who OCR-ed the OS Rev. B source listing (Tomlin), which served as the starting point for this work.

  • Freddy Offenga, who traced existence of various OS revisions and gatered binary ROM dumps in a single collection (Offenga, "Operating Systems 3.6").

  • Kevin Savetz, who provided ROM dumps and photos of Arabic 6XE units (Savetz, Arabic 65XE 2013; Savetz, "Atari 65XE Arabic").

  • Sijmen "mr-atari" Schouten, who scanned and shared his copy of the XL Addendum (Schouten).

  • James "sup8pdct" Bradford, who scanned and shared his copy of OS Listing 1981-08 (Bradford).

  • Curt Vendel, who digged through immense historical archives of Atari and shared his findings over the years, including resources about the 1400XL (Vendel, "Atari 1400XL"), the 1450XLD (Vendel, "Atari 1450XL"), and the XL OS Rev. 5 source code (Vendel, OS Rev. 5) Rest in peace, Mr. Vendel.

  • Ken "Dutchman2000" Van Mersbergen, who archived plenty of artifacts from Atari backups and shared XL OS Rev. 3 Ver. 4 and XL OS Rev. 4 source codes (Mersbergen, OS Rev. 3 Ver. 4; Mersbergen, OS Rev. 4 1984-07-19; Mersbergen, OS Rev. 4 1984-07-24).

  • Karl "kheller2" Heller, who provided ROM dump of XL OS Rev. 3 (Heller).

  • Michael "hunmanik" Current, who maintains an immensely detailed collection of citations in the history section of his Atari 8-bit FAQ (Current), which was the basis of a lot of historical facts quoted in this work.

  • All Atari enthusiasts from the AtariAge forums and elsewhere, not mentioned by name, who shared materials, analyses and knowledge publicly, and for free.

6. To do

  • Confirm existence of an 800XL unit with OS Revision 1.

  • Include all region-specific OS revisions installed officially by local distributors:

    • Polish 192XT by PZ Karen

    • Hebrew 600XL by ARAM - but did these machines have a built-in ROM, or only supplied additional routines on cartridge?

7. References