[continued from previous message]

- S: Display Handler (read/write)
Offers the special CIO commands DRAW and FILL.
- E: Screen Editor (read/write)
- Uses the K: Keyboard Handler and the S: Display Handler to provide
"line-at-a-time" input with interactive editing functions, as well as
formatted output.
- C: Cassette Handler (read/write)
- P: Printer (write only)
- 400/800 OS: Supports a single printer device; any
device number is ignored. All powered printers attached via SIO or
the 850 parallel port respond to all print commands.
- XL OS: Supports 8 different printer devices: P1:-P8:
P: (no device number) is interpreted to mean: P1:
Printer devices are associated with specific models of Atari printers as
follows:
P1: All printers attached via SIO or the 850 parallel port
P2: 850 Interface Module parallel port (e.g., Atari 825)
P3: 1025 Printer
P4: 1020 Color Plotter
P5: 1027 Printer
P6: 1029 Printer
P7: XMM801 Printer
P8: XDM121 Printer
Tomasz Krasuski contributes (May 2011):
This feature is buggy in XL OS Rev.A/Rev.B/Rev.1. Behavior was
fixed to reliable operation as of XL OS Rev.2.
Also provided by the Atari OS:
- Resident Diskette Handler
- Not a full device handler / not CIO-compatible
- Detailed in the section of this FAQ list introducing Disk Operating
Systems
- Generic Parallel Device Handler (XL OS Rev.1+)
- Responsible for invoking the handler routines within the parallel
device ROMs.
Nonresident Handlers can be added to the system environment in several ways:
- Loaded from diskette or cassette
- Loaded from the ROM of an SIO device (850 interface, 1030 modem). May be
loaded at system startup without disk drive ("bootstrap without disk
drive"), may be loaded as part of a Disk Boot ("bootstrap with disk
drive"), or may be loaded afterward.

DEVICE CONTROL BLOCK (DCB)
Carries communications between higher-level device handlers and lower-level Serial I/O (SIO). There is a single DCB only.

SERIAL I/O (SIO) utility/routine
Low-level communication with serial bus peripherals
- Control of all Serial bus I/O, conforming to the bus protocol
- Bus operation retries on errors
- Return of unified error statuses on error conditions
- Used by the OS-resident P: handler and the OS-resident Diskette Handler
- Not used by the OS-resident K: S: and E: handlers (non-SIO devices)
- While the OS-resident C: handler uses the SIO bus hardware, it does not use
the SIO utility/routine.

Any lower level (lower than CIO) access to a device by a user program involves the direct reading and writing of the hardware registers associated with the device.

------------------------------

Subject: 7.1.5) What is attract mode?

From the Atari Operating System User's Manual (1982) p. 215:

Attract mode is a mechanism that protects the television screen from having
patterns "burned into" the phosphors due to a fixed display being left on
the screen for extended periods of time. When the computer is left
unattended for more than 9 minutes, the color intensities are limited to 50
percent of maximum and the hues are continually varied every 8.3 seconds.
Pressing any keyboard data key will be sufficient to remove the attract mode
for 9 more minutes.

Laurent Delsarte contributes:

To launch the attract mode from BASIC, use a "POKE 77,128"
To disable the attract mode from BASIC, use a "POKE 77,0"

------------------------------

Subject: 7.1.6) What is the Atari cassette utilization/filesystem?

(Section sources include: De Re Atari, OS Users Manual, XL Addendum)

The following are characteristics of the cassette utilization/filesystem
as implemented by the Atari Operating System.

- Mark = 5327Hz (audible sound frequency)
- Space = 3995Hz (audible sound frequency)
- Bit = space(0) or mark(1)
- Byte = 10 bits:
- 1 start bit (space)
- 8 data bits
- 1 stop bit (mark)
- Record = 6-132 bytes, as follows:
- Speed measurement byte, first of two. Marker character = $55 (hex)
- Speed measurement byte, second of two. Marker character = $55 (hex)
- Control byte. One of three values:
1) $FC = Record is a full data record.
2) $FA = Record is a partially full data record, and the next record
should be an end-of-file record.
3) $FE = Record is an end-of-file record.
- Data bytes. 128 bytes for a full data record or an end-of-file record,
or 2-128 bytes if a partially full data record, where the last byte is
not really a data byte, but rather contains the number of actual data
bytes (1-127).
- Checksum byte
- Pre-Record Write Tone (PRWT) = pure mark tone
- Post-Record Gap (PRG)
- Record Frame = PRWT + Record + PRG
- Inter-Record Gap (IRG) = PRG + PRWT
- Normal IRG Mode: Tape comes to stop after each record frame
- Short IRG Mode: Tape is not stopped between record frames.
(Short IRG Mode is supported by the Atari BASIC commands CSAVE and CLOAD.)
- Normal IRG PRWT = 3 seconds of mark tone
- Short IRG PRWT = 0.25 second of mark tone
- Normal IRG PRG = Up to 1 second of unknown tones (motor stop/start time)
- Short IRG PRG = pure mark tone, duration set by user program (may be zero)
- File consists of:
1) 20-second leader of mark tone
2) Any number of data record frames (each frame contains one data record)
3) End-Of-File record frame (contains an end-of-file record)

------------------------------

Subject: 7.1.7) What programs run only on the 400/800 (not the XL/XE) and why?

Fandal site search for games requiring 400/800 OS Rev.B: http://a8.fandal.cz/search.php?search=os-b&butt_details_x=x

Fandal site search for games requiring 400/800 OS Rev.A: http://a8.fandal.cz/search.php?search=os-a&butt_details_x=x

Utilities reported to require the 400/800 OS:
Atari Word Processor Atari
File Manager 800+ Synapse
Letter Perfect (before v6) LJK (all version 6.x releases OK on XL/XE) Mac/65 [ver. 1.00, orange] OSS (all releases after 1.00 OK on XL/XE)
Monkey Wrench Eastern House
Synassembler Synapse
Text Wizard Datasoft
VT-10-Squared Dave Bailey

Note that while some 400/800 programs fail to run on the XL/XE at all, others, such as Atari's own Missile Command and Space Invaders cartridges, run on the XL/XE with only minor problems such as sound glitches.

Many 400/800 programs incompatible with XL/XE computers can nevertheless be made to run flawlessly on the XL/XE using the Atari Translator (or equivalent) which is described in another section of this FAQ list.

Also, modern programmers have hacked many of the above titles and released fixed versions for use with XL/XE computers.

Thomas Richter contributes the following (16 Jan 2004):

There are a couple of reasons why some games don't run on the XL/XE
models. I try to order them by "likeliness", of course biased by my
personal observations:

1) The printer buffer of the XL Operating System in page 3 is a couple
of bytes shorter. The additional bytes are used for extended OS
variables not available in the 800 series. Most prominent is the $3FA location, holding a shadow register of GTIA's TRIG3 signal. While a
true joystick trigger line in the 400/800 series, this signal is used
as "cartridge inserted" signal for XL/XE models. Unfortunately, the OS compares GTIA TRIG3 with the shadow register at $3FA in each vertical
blank, running into an endless loop if the register contents don't
match. This causes hangs for games using page 3 either as copy-buffer
or for player-missile graphics. (Hangs by Ms. Pac-Man and
Bacterion! are caused by this, and many others...) This is "fixable"
either by the translator disk, or by a quick hack into the game,
replacing the OS vertical blank or poking TRIG3 frequently into its
shadow. The reason for the OS behavior might be that Atari wanted to
prevent crashes if the cartridge is inserted or removed while the
machine is running. The 400/800 is powered down when a cartridge is
inserted, the XL/XE lacks the cover of the older models that triggered
a little switch to interrupt the power line.

2) Similar to the above, writes to $3F8. This OS equate defines
whether on a warmstart, the BASIC ROM shall be mapped back in. If
its contents are altered, a program triggering a reset as part of its initialization will find itself then with 8KiB less RAM occupied by
a BASIC ROM, making it crash. Similarly, writes to the cartridge checksum
$3EB could cause a cold-start on a "reset initialization". This is
fixable by the translator disk.

3) Some games use a four-joystick setup, or at least initialize
PIA itself. If this happens inadequately, PIA Port B, bit 0 gets changed, disabling the ROM, and thus crashing the machine. This is not fixable
by the translator since it is a hardware issue.

4) Direct jumps into the OS ROM, not using the documented vectors in
the $E450 area. Interestingly, this fault is not as common as it may
sound since games hardly ever use the OS. It causes failures of
some "serious applications", most notably "QS Forth" and applications
compiled by it. This is fixable by the translator disk.

------------------------------

Subject: 7.1.8) Why do some programs run only on the XL/XE (not the 400/800)?

Section started by Konrad M. Kokoszkiewicz.

Software designed for the Atari XL/XE won't work on the 400/800 if:

1) It uses shadow RAM at $C000-$CFFF (4KiB) or $D800-$FFFF (10KiB). In other
words, it requires 64KiB RAM.
2) It uses RAM expansions at $4000-$7FFF controlled by PORTB $D301. In other
words, it requires at least 128KiB total RAM.
3) It uses XL OS vectors (routines) not present in the 400/800 OS. Some of
these correspond to XL/XE specific hardware, such as the [HELP] key or the
PBI/ECI interface.
4) Rather than using documented OS vectors, it "illegally" uses OS routines
directly for routines that were located at different memory addresses in
the 400/800 OS.
5) It uses the International Character Set.

------------------------------

Subject: 7.1.9) How can I run older programs using the Atari Translator?

While each later revision of the Atari Operating System (OS) was designed to
be backward compatible with earlier versions, software incompatibilities were sometimes introduced. In particular, a number of programs written for the 400/800 OS versions do not run correctly or at all under the XL OS versions.
In order to allow many "400/800-only" programs to be run on an XL (or later, XE) computer, Atari made the Atari Translator available via the Atari Program Exchange (APX) or Atari Customer Service.

The auto-booting Translator diskette installs the 400/800 OS in RAM "under"
the ROM-based XL OS in an XL/XE Atari computer. Once this disk has been loaded, the user is prompted to remove it and insert the application diskette (or cassette) and press the [SELECT] key. When this occurs the system undertakes a coldstart in the new, RAM-based 400/800 OS environment.

The Translator disk is a two-sided disk, providing two slightly different versions of the Translator. The Side A Translator provides a version of the 400/800 OS that is slightly modified to allow the [RESET] key to be pressed without reverting to the XL OS on ROM. The Side B Translator provides an
even higher degree of compatibility, including support for programs that boot the 850 interface, but the 400/800 OS in RAM would be disabled if the [RESET] key is pressed.

Atari shipped two versions of the Translator disk:
- Atari Translator DX5063 NTSC version: 400/800 OS Rev.B/NTSC
- Atari Translator FK100807 PAL version: 400/800 OS Rev.A/PAL

Translator programmers at Atari:
- Greg Riker: Original version 83-03-20
- Joe Miller: Added graphics and code for [RESET] 83-09-15

Atari Translator partial source code: http://www.atariage.com/forums/topic/78381-xl-translator-source/

Similar "translator" programs from 3rd parties include:
- XL Fix by Computer Software Services (CSS), 1983 (ad Antic Apr84p102)
- Commercial program released (originally) in disk and cassette versions
- Also released in ROM version
- OldOper ver. 1.0 by MasterSoft, April 1984
- The FIXXL by Belathiel (widely distributed by Antic magazine), 6/11/84
- The Emulator by ATCO int. systems (ATCO-IS) Stuttgart, version 4.0, 1984
- "Home-Made Translator" by Angelo Giambra, ANALOG July 1985 p.28-34
- Follow-up by D.D. Davids II to above article, ANALOG Sept. 1985 p. 6
- XOS/Translator, by Computer Support, 1985
- Also released in ROM version as: XOS/Fix
- Ultra Translator: Ultrafix/XL (400/800 OS Rev.B or Rev.A), by Tim Patrick
- Revision 1.3, 1984/86
- Revision 2.0, 1984/86
- This version also produced on cartridge by Video 61
- Revision 2.2, 1984/86
- Super Translator, by Duplicating Technologies

See a separate section of this FAQ list for 400/800 OS "translator" products sold on ROM chips (replacement operating systems)

------------------------------

Subject: 7.1.10) How can software detect NTSC versus PAL/SECAM computer types?

Several techniques are available to programmers, as follows:

1) The XL OS (not the 400/800 OS) provides a flag called PALNTS at decimal memory location 98 (hex: $62). PALNTS indicates whether the CTIA/GTIA/FGTIA has reported itself to be NTSC or PAL/SECAM, where 0 means NTSC, or 1 means PAL/SECAM. In Atari BASIC, enter "? PEEK(98)" to determine the value of the PALNTS flag.

2) An approach which works on all 400/800/XL/XE systems is to use the same method used by the XL OS to set the value of the PALNTS flag described above. That is, to read and interpret the "PAL" memory flag, decimal location 53268 (hex: $D014). The value of PAL is provided by the CTIA/GTIA/FGTIA chip
itself. Meanings are:
Bit 1-3 clear (xxxx000x) = PAL/SECAM
Bit 1-3 set (xxxx111x) = NTSC
(Proper interpretation of the value returned by PEEK(53268) in Atari BASIC would thus be a bit of a programming challenge. This is left to the reader!)

3) Software may determine NTSC or PAL/SECAM by determining how many scan
lines are being generated by ANTIC. This is done by monitoring the VCOUNT memory register. VCOUNT (54283 decimal, $D40B hex) is used by ANTIC to keep track of which line is currently being generated on the screen. Values
reflect the line count divided by two. VCOUNT values range from zero to 130 for an NTSC ANTIC (131*2=262 scan lines), while VCOUNT values range from zero to 155 for a PAL ANTIC (156*2=312 scan lines).

------------------------------

Subject: 7.2.1) What is Atari BASIC?

(Thanks to Laurent Delsarte for cartridge variation pics and testing.)

BASIC is an acronym for Beginner's All-purpose Symbolic Instruction Code. Developed by John Kemeney and Thomas Kurtz in the mid 1960s at Dartmouth College, BASIC is one of the earliest and simplest high-level programming languages, incorporating components of FORTRAN and ALGOL.

In October 1978 Atari contracted with Shepardson Microsystems, Inc. (SMI; headed by Bob Shepardson) to create a version of BASIC (as well as a File Management Subsystem) for the upcoming Atari personal computers. Credits:
Paul Laughton - Main programmer (also wrote: FMS for DOS I and DOS 2.0S)
Kathleen O'Brien - Floating point routines (also wrote: Assembler Editor)
Bill Wilkinson - Preliminary specifications for the language;
floating point scheme design
Paul Krasno - Implemented the math library routines following
guidelines supplied by Fred Ruckdeschel
Mike Peters - Keypunching, operating

While SMI developed Atari BASIC to occupy 10KiB of ROM, including a 2KiB Floating Point Package (FPP) for internal use by the language, Atari placed
the FPP component in operating system ROM (memory locations 55296 to 57343 or $D800 to $DFFF) for universal availability. Thus, the Atari BASIC ROM was slimmed to 8KiB. Please see the "What is the Atari OS" section of this FAQ
for further information about the FPP.

Atari released 3 different Revisions of Atari BASIC:

Revision A
----------
- Shipped with the 400 computer systems from 1979-1981
- Shipped with the 800 computer systems from 1979-1982

Atari BASIC Rev. A was produced by Atari on cartridge (CXL4002), standard 400/800-style brown label, which reads either "BASIC Computer Program" (early) or "BASIC Computing Language" (most).

The cartridge was produced in mass quantities before SMI had finished
debugging it. One place these bugs are documented is in this article by Steve Hanson from Compute! magazine, Oct. 1981: http://www.atarimagazines.com/compute/issue17/171_1_DOCUMENTED_ATARI_BUGS.php

On February 25, 1981, the source code to Atari BASIC (including the FPP) was purchased from SMI by Optimized Systems Software (OSS), headed by former SMI employees Bill Wilkinson and Mike Peters.

The Atari BASIC Source Book (Compute! Books, 1983, 0-942386-15-9), authored by Bill Wilkinson, Kathleen O'Brien and Paul Laughton, made the source code to Atari BASIC (Rev. A; and including the FPP) available to the public.
Available: http://users.telenet.be/kim1-6502/6502/absb.html

Revision B
----------
When the 600XL/800XL computers shipped in the fall of 1983 they included a newly debugged Atari BASIC Rev. B built-in on ROM. Unfortunately, while most existing bugs were fixed, Rev. B introduced a new bug more serious than any of the earlier problems. In his article in the June 1985 issue of Compute!, Bill Wilkinson writes:
Each time you LOAD (or CLOAD or RUN "filename") a program, rev B adds 16
bytes to the size of your program. If you then save the program, the next
time you load it in it grows by ANOTHER 16 bytes, and so on.
http://www.atarimagazines.com/compute/issue61/323_1_INSIGHT_Atari.php
The problem can be alleviated by periodically, if not exclusively, using
LIST instead of SAVE or CSAVE to save your programs.

Atari never produced Atari BASIC Rev. B on cartridge.

"Revision C Converter: Type-in fix for buggy BASIC revision B" by Matthew Ratcliff was published in the September 1985 issue of Antic: http://www.atarimagazines.com/v4n5/revisioncconverter.html

Revision C
----------
Atari BASIC Rev. C is the final "fully debugged" version. It was first made available on cartridge from Atari Customer Service in June 1984 (free to 600XL/800XL owners still within warranty). The silver label on the first Rev. C cartridges reads "(c)1982 Atari, Inc." and "Made in U.S.A." Atari, Corp. also produced Rev. C on cartridge, using two different silver labels designs, both of which read "(c)1985 Atari Corp." and "Made in Taiwan". Rev. C was
also built-in on ROM in late-production 800XL computers as well as the 65XE, the 130XE, the XE System console, and the 800XE.

Determining Revision version
----------------------------
When running Atari BASIC, memory location 43234 ($A8E2, BASIC ROM) indicates which Revision of BASIC is running. At the READY prompt, enter:
? PEEK(43234)

If the result is: You have Revision: Atari Part#:
162 A C012402+C014502
96 B C060302A
234 C C024947A

All 3 versions of Atari BASIC may be available for download here: http://www.ataripreservation.org/websites/freddy.offenga/atari_dev.htm

Manuals from Atari:
(See the "What is the Atari OS" FAQ section for FPP documentation.)
- Atari BASIC (Wiley Self-Teaching Guide) C014385 by Albrecht/Finkel/Brown
(c)1979, 332 pages (see: http://www.atariarchives.org/basic/)
- Shipped with the 400 computer systems from 1979-1981
- Shipped with the 800 computer systems from 1979-1982
- BASIC Reference Manual (400/800 ed.), C015307, (c)1980, 120 pages
- Authors: Carol Shaw and Keith Brewster
- Shipped with the 800 computer systems from 1980-1982
- Inside Atari BASIC, C060992, Carris for Reston, (c)1983, 183 pages
- Atari BASIC Reference Manual Update, C061038, (c)1982, 6 pages
- BASIC Reference Manual (400/800/1200XL ed.), C061456 / BX4211, (c)1983,
126 pages
- Atari BASIC Reference Guide For Experience Programmers, C061570, (c)1983,
14 pages
- Atari BASIC Reference Guide, C061948, (c)1983 (international; 61 pages)

------------------------------

Subject: 7.2.2) How do I load/run or save an Atari BASIC program on cassette?

To load and run an Atari BASIC program from cassette:
1. Insert the cassette into the recorder.
2. Use REWIND or ADVANCE/F.FWD on the recorder, if necessary, to bring the
tape to the position where the program is located.
3. Boot the computer to the Atari BASIC READY prompt.
4. There are several possibilities for the next step, depending on how the
program was saved, and whether you want to run the program or just load
it into RAM. Enter one of the following four commands:
a. CLOAD loads programs saved with CSAVE
b. LOAD "C:" loads programs saved with SAVE "C:"
c. ENTER "C:" loads programs saved with LIST "C:"
d. RUN "C:" loads and runs programs saved with SAVE "C:" 5. The system buzzer sounds (to signal you to press PLAY on the recorder).
6. Press PLAY on the recorder.
7. Press the RETURN key on the computer keyboard.
Tape motion starts, the program loads from the cassette into RAM, and then
tape motion stops.
Then, if you entered RUN "C:" above, the loaded program runs; otherwise a
READY prompt is displayed.
8. You may press STOP on the recorder once the program is loaded, unless the
program is designed to control further tape motion start/stop.
9. If the loaded program is not running yet (you did not enter RUN "C:"
above), now enter the command: RUN

To save an Atari BASIC program from computer RAM to cassette:
1. Insert a cassette into the recorder.
2. Use REWIND or ADVANCE/F.FWD on the recorder, if necessary, to bring the
tape to the position where the program is to be recorded.
3. Enter one of the following three commands:
a. CSAVE
(short inter-record gap - fastest read/write speed - tokenized files)
- According to Atari Tech Tip #5, 11/17/82, regarding the 400/800
computer models, pressing SYSTEM RESET does not reset the data I/O
line in POKEY. Subsequent use of CSAVE is unreliable because the
data I/O line is not clear, POKEY sends garbage, and the data stored
is unrecoverable.
Solution #1: Avoid using SYSTEM RESET before using CSAVE.
Solution #2: Following use of SYSTEM RESET, execute a serial bus
command that properly resets POKEY and clears the data I/O line.
Recommended: LPRINT
(If a printer is not attached when the LPRINT is executed, an error
138 occurs. This is normal and does not interfere with the reset of
POKEY and safe subsequent use of CSAVE.)
b. SAVE "C:"
(long inter-record gap - middle read/write speed - tokenized files)
c. LIST "C:"
(long inter-record gap - slowest read/write speeds - straight ATASCII -
tape actually stops in between block reads/writes)
4. The system buzzer sounds twice (to signal you to press both PLAY and
RECORD on the recorder).
5. Press both PLAY and RECORD on the recorder.
6. Press the RETURN key on the computer keyboard.
Tape motion starts, the program is copied from RAM to the cassette, and
then tape motion stops.
7. You may press STOP on the recorder once recording has finished.

------------------------------

Subject: 7.3.1) What is Atari DOS, and what versions did Atari release?

The 8-bit Atari Operating System (on ROM) includes a rudimentary Resident Diskette Handler that provides several functions:
1. GET SECTOR data
2. PUT SECTOR data (without verify) (XL OS only)
3. PUT SECTOR data WITH VERIFY
4. STATUS REQUEST
5. FORMAT
The unit of data transfer for the GET and PUT functions is one disk sector.
400/800 OS: 128 bytes/sector
XL OS: 128 bytes/sector at system boot;
1-65536 bytes/sector supported after system boot

The Resident Diskette Handler is utilized by the Atari OS in a disk boot,
where data is automatically loaded from powered disk drive number 1 into RAM
on system startup, and then optionally executed.

Advanced software programmers may utilize the Resident Diskette Handler for disk drive communications, though it is notably optional to do so.

While the Resident Diskette Handler provides limited functionality, a full- featured Disk Operating System (DOS) on the Atari consists of a flexible combination of software components provided in the Atari OS on ROM with software components loaded into RAM from disk:

1) SIO (Serial I/O bus Utility) routine
- Resident component of the Atari OS
- Generalized low level communications with SIO bus devices, including
disk drives
- Typically utilized directly by a File Management Subsystem
- Also utilized by the Resident Diskette Handler
2) FMS (File Management Subsystem)
- Must be loaded into RAM from disk
- Software for organizing and managing data stored on disks into
named files, freeing users/user programs from the need to keep track
of what data is located in what physical locations on the disk
- Typically provides a Disk File Manager ("D:") device handler that is
compatible with CIO
- Typically utilizes SIO directly, but may utilize SIO by way of the
Resident Diskette Handler, or may use neither
3) CIO (Central Input/Output Utility) routine
- Resident component of the Atari OS
- Generalized high level, device independent access to device handlers,
including a Disk File Manager ("D:") device handler provided by a FMS
4) DUP (Disk Utility Package) or equivalent software program(s)
- Optionally provided with a FMS
- Typically a DOS menu program, but could take any form of software
that provides a user interface to FMS management functions

Those DOS components loaded into RAM from disk, that is, a FMS and any additional programs distributed with that FMS (such as a DUP), are generally what is referred to as a "DOS" on the Atari.

The rest of this FAQ section describes the various DOS versions produced by Atari for use with their 8-bit computers: DOS I, DOS 2.0S, DOS 3, DOS 2.5, DOS XE, DOS XLE

DOS I
-----
DISK OPERATING SYSTEM 9/24/79 COPYRIGHT 1979 ATARI
- Contains two main parts:
- A File Management Subsystem (FMS)
- Developed by Paul Laughton (also wrote: Atari BASIC) for Shepardson
Microsystems, Inc. (SMI) for Atari
- A Disk Utility Package (DUP)
- Shipped with 810 disk drives manufactured from 1980-1981.
- Disk Utility Package (DOS menu) is loaded into memory with the FMS
- Uses the OS-resident Diskette Handler for all disk communications
- Disk drive type supported: Atari 810 (& compatible)
- Disk utilization/filesystem: "DOS I"
- 128 total bytes/sector, with 3 bytes of each sector used to address
the next sector
- 40 tracks * 18 sectors/track = 720 total sectors, with 11 sectors used
for software control or unused by the FMS.
- Data capacity per diskette:
709 sectors x 125 bytes/sector = 88,625 bytes/disk
- Cannot read disks written with DOS II, which require a 3 sector boot
- 11 special sectors:
1 Boot sector, containing the boot record accessed by the Atari OS
at system power-up
360 Volume Table of Contents (VTOC) (sector usage)
361-368 File Directory (8 directory entries per sector)
720 unused by the FMS (FMS interprets the VTOC sector bit map as
sectors numbered 0-719, ignoring nonexistent sector 0, while the
Atari 810 drive uses sectors numbered 1-720)
- Maximum of 64 files per diskette (8-sector File Directory)
- Uses binary file format unsupported by any other DOS version for the Atari
- D: Disk File Manager supports up to four 810 disk drives, D1: through D4:
- To configure DOS I for fewer drives (freeing system environment RAM),
adjust memory location 1802 ($70A or DRVBYT):
1. Boot the system to the BASIC READY prompt
2. Enter one of:
- POKE 1802,1 (for a one drive system; saves 397 bytes)
- POKE 1802,3 (for a two drive system, saves 258 bytes)
- POKE 1802,7 (for a three drive system, saves 130 bytes)
- POKE 1802,15 (for a four drive system; DOS I default value)
3. Go to DOS and use menu item H (WRITE DOS FILE) to write the DOS.SYS
file (with the new value of location 1802) to disk, replacing any
existing copy of DOS on that disk.
- Can open up to 3 files simultaneously
- Configurable by adjusting memory location 1801 ($709 or SABYTE) via
the same process as described for adjusting the number of disk drives.
Valid values for DOS I are 1-3 inclusive. Default is 3.
- AUTO.SYS can be used to automatically poke data in RAM locations on
system startup.
- Files copied or duplicated in small buffer
- Must redisplay menu before issuing new command
- Can only write DOS system file to drive 1
- N. DEFINE DEVICE menu option: "The full implementation of this selection is
not supported, so use it with caution." --DOS Reference Manual p.39
- DOS I is not compatible with the 850 Interface Module R: device handler
- Disk File Manager Master Copy (CX8101) disk contains:
DOS.SYS both the FMS with D: Disk File Manager and DUP with DOS Menu
- Manual: Disk Operating System Reference Manual C015200

DOS 2.0S
--------
DISK OPERATING SYSTEM II VERSION 2.0S COPYRIGHT 1980 ATARI
- Shipped with 810 and 1050 disk drives manufactured from 1981-1983.
Master Diskette also shipped with the Atari Touch Tablet.
- FMS (DOS.SYS) component developed by Paul Laughton for Shepardson
Microsystems, Inc. (SMI) for Atari, based on the Atari DOS I FMS.
Released code version: "19-Aug-80"
- Disk Utility Package (DUP.SYS -- DOS menu) is separate from the FMS, and
optional for use of the FMS, freeing up memory for user programs when the
DUP is not needed. Released code version: "ver 2.9 11/18/80"
- Does not use the OS-resident Diskette Handler after system boot.
- Utilizes SIO for disk drive communications
- MEM.SAV file can be employed to preserve the contents of memory to disk
when DUP.SYS is loaded.
- Introduces support for AUTORUN.SYS binary file launch upon system boot
(replaces AUTO.SYS of DOS I)
- Disk drive type supported: Atari 810 (& compatible)
- Disk utilization/filesystem: "DOS 2.0 Single Density"
- 128 total bytes/sector, with 3 bytes of each sector used to address
the next sector
- 40 tracks * 18 sectors/track = 720 total sectors, with 13 sectors used
for software control or unused by the FMS.
- Data capacity per diskette:
707 sectors x 125 bytes/sector = 88,375 bytes/disk
- Requires a 3 sector boot (provision for double density version DOS 2.0D)
- 13 special sectors:
1-3 Boot sectors, containing the boot record accessed by the Atari
OS at system power-up
360 Volume Table of Contents (sector usage)
361-368 File Directory (8 directory entries per sector)
720 unused by the FMS (same as DOS I)
- Maximum of 64 files per diskette (8-sector File Directory)

[continued in next message]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)