Talk:Apple DOS

Untitled

Did Woz largely write DOS 3.1 or did Paul Laughton do this? We may need to clarify. See: Paul Laughton's account of writing DOS 3.1 --PZ 01:26, 25 March 2006 (UTC)

As I understand it, Woz wrote the low-level part of RWTS (nibblize/denibblize routines), Randy Wigginton wrote the high-level part of RWTS, and Paul Laughton wrote the rest of DOS (command interpreter and file manager). I'm not sure about the second stage boot code and the relocator. --Brouhaha 19:26, 25 March 2006 (UTC)

I had an Apple IIc and it ran ProDOS, I remember that very well, that means the integrated card came from IIc, not IIe. I corrected that.

No, that's wrong. The Apple //e was released a year before the Apple //c. The //c is later than the //e. I've returned to the correct version. - Nunh-huh 03:42, 18 August 2006 (UTC)

DOS 3.3 for the 3.5" drive?

What was the name of the commercial DOS alternative that supported the 3.5" drive? As I recall, it split the 800k disk into two separate 400k "sides" and had some weird way of dealing with two drives, and two sides per drive. I believe this was sold in Nibble magazine at one time.

I probably still have some of these 3.5" disks somewhere, with old DOS 3.3 games that didn't like ProDOS. Though I'm not (yet) motivated enough to dig them out for this article. DMahalko (talk) 19:39, 13 October 2008 (UTC)

ISTR that there were at least two commercial alternatives for the Unidisk 3.5" drive; furthermore, the sides of the disk were individually addressed (as the VTOC could only hold enough info for one side's worth of data); they were typically accessed as ,D1 and ,D3 . --moof (talk) 08:02, 14 October 2008 (UTC)

Unfinished new section, saving work

This is not finished, but I need to save and quit for now.

Disk formatting structure

Sector label key
1	DOS boot sector
2	DOS boot/RWTS program code
3	Reserved for Master Diskette relocation code
4	DOS program sectors
5	Volume Table of Contents (VTOC)
6	Catalog sectors
7	Track/Sector List for HELLO program
8	Data sector for HELLO program
9	2.75kb not used by DOS, but not free sectors

A newly formatted bootable DOS 3.3 disk with a simple HELLO program has the following 35 track, 16 sector structure:

		00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31	32	33	34
		00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F	10	11	12	13	14	15	16	17	18	19	1A	1B	1C	1D	1E	1F	20	21	22
0	0	1	4	4															5
1	1	2	4	4															6
2	2	2	4	4															6
3	3	2	4	4															6
4	4	2	4	4															6
5	5	2	4	9															6
6	6	2	4	9															6
7	7	2	4	9															6
8	8	2	4	9															6
9	9	2	4	9															6
10	A	3	4	9															6
11	B	3	4	9															6
12	C	4	4	9															6
13	D	4	4	9															6
14	E	4	4	9															6	8
15	F	4	4	9															6	7

Volume Table of Contents (VTOC)

The VTOC is used to store information about the disk structure, with most of the VTOC occupied with a sector map so that DOS knows what sectors are used and which are available for storage. It also stores the disk volume number, and tells DOS where to find the disk catalog sectors.

By default DOS 3.3 formats track 17 (hex $11), sector 0 as the VTOC location. This track was chosen because the VTOC is accessed every time a file is accessed. Track 17 is in the center of the disk, so this reduces the average seeking latency from moving the disk drive head across the disk surface.

VTOC Byte Offset	Purpose	Normal Value
$01	Track of first catalog sector	$11 (17)
$02	Sector of first catalog sector	$0F (15)
$03	DOS release number	$03
$06	disk volume number	$FE (254)
$27	max number of track/sector pairs in a list sector	$7A (122)
$30	direction of last track allocation	(???)
$31	Tracks per disk	$23 (35)
$32	Sectors per disk	$10 (16)
$36-37	Number of bytes per sector, in 16-bit format	$00 01 ($0100 / 256)

The disk usage bit map for each track begins at position $38 of the VTOC and consists of four bytes per track. The last two bytes of each group are not used, and are normally stored as 00 00. The sixteen bits of the first two bytes are used to represent the 16 sectors per track, with bit 1 signifying a free sector and bit 0 representing a used sector.

For a newly initialized disk containing DOS in the first three tracks, those three tracks are completely used, followed by empty tracks:

VTOC byte offset	Sector usage bytes	Track number	Sector bit map
$38-3B	00 00 00 00	$00 (00)	0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
$3C-3F	00 00 00 00	$01 (01)	0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
$40-43	00 00 00 00	$02 (02)	0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 0
$44-47	FF FF 00 00	$03 (03)	1 1 1 1 1 1 1 1   1 1 1 1 1 1 1 1
$48-4B	FF FF 00 00	$04 (04)	1 1 1 1 1 1 1 1   1 1 1 1 1 1 1 1
. . .
$7C-7F	3F FF 00 00	$11 (17)	0 0 1 1 1 1 1 1   1 1 1 1 1 1 1 1
. . .
$C0-C3	FF FF 00 00	$22 (34)	1 1 1 1 1 1 1 1   1 1 1 1 1 1 1 1
$C4-FF	Future expansion (Room for 15 tracks)

The sector usage map cannot be larger than 50 tracks of 32 sectors at 256 bytes per sector, or 409,600 bytes. The VTOC is the primary reason why disks over 400k could not be supported, because the VTOC was designed to only occupy a single 256-byte sector. It is not possible to span the sector map across multiple VTOC sectors.

Catalog sectors

The disk catalog is a flat-file structure that simply lists files one after the other, without support for a folder hierarchy. The catalog stores up to 33 characters for the file name, the file type, the total sectors used, whether the file is locked (write-protected) or not, and tells DOS the track and sector of the first sector of the file. At the end of each catalog sector is a pointer to the next catalog sector, ending with a null pointer for the last sector.

By default DOS 3.3 initializes a disk with catalog sectors on the same track as the VTOC. The sectors are used in reverse order from sector 15 down to sector 1.

Files can be eight different types: B-A-R-S-B-A-I-T .. Note there are two B types and two A types, which are different, but appear to be the same in the catalog.

• B - Binary file
• A - Applesoft / Floating-Point BASIC
• I - Integer BASIC
• T - Text file
• The second B, second A, R, and S are almost never used normally.

Technically the catalog sectors can be anywhere on the disk. Customized disks may have only 1 catalog sector to recover space for large files, or can have more than 15 catalog sectors spanning onto other tracks, for many small files. It is also possible to make a catalog that repeats forever, by making a catalog sector refer to itself as the next sector.

Control characters are allowed as parts of a file name, and were used to make certain files unreadable if the secret keypresses were not known. Codes for cursor control (ASCII 8 - Left, ASCII 21 - Right, ASCII 10- Up, ASCII 11- Down) were literally interpreted when displayed.

• A file saved as ?CHR$(4)"SAVE FRED";CHR$(8);CHR$(8);CHR$(8);"IRE" would display as "FIRE"
• A file saved as ?CHR$(4)"SAVE THIS";CHR$(21);"FILE" would display as "THIS FILE"

The Apple II character set includes normal, inverted, and flashing characters as part of a single combined 8-bit code. Although it is not possible to type these special codes from the keyboard, they can be directly inserted into file names using a sector editor. This was used by expert hackers and commercial programers for visual effects such copyright information in an inverted marquee, in the catalog.

Track/Sector lists

For all file types except text files, the data sectors which make up the file are stored in a separate type of sector known as Track/Sector lists. This listing contains byte pairs indicating the track and sector of each consecutive sector in a file. Track/Sector lists can span multiple sectors to contain all pairs for each file.

The smallest possible BASIC or Binary file consumes 2 sectors of disk space. The first sector contains the track/sector list, which then points to the single data sector.

Text files do not use the track/sector lists, and instead contain at the end of the sector a two-byte pair indicating the location of the next data sector. Consequently the smallest text file consumes just one sector.

(The above statement about text files is untrue. If a book states this, it is wrong. Text files DO use track/sector lists. A text file could possibly have only one sector if it is completely EMPTY, and therefore consists only of its "null" track/sector list, and no data sectors.) 108.1.70.132 (talk) 15:55, 19 February 2011 (UTC)

DMahalko (talk) 20:23, 19 October 2008 (UTC)

... Ummm, yeah, so I haven't touched this in about two years. If someone else wants to move it into the main article, go ahead, but it should have book citations before that happens. I think I still have the books where I sourced this. DMahalko (talk) 17:15, 15 February 2011 (UTC)

Misleading screen shot

The screen shot shows an immediate-mode Applesoft BASIC command, not a DOS command. (As there is no filename, DOS would have punted on that command and handed it over to Applesoft.) It should probably be updated to show RUN HELLO or somesuch. Jerry Kindall (talk) 15:18, 18 June 2013 (UTC)

Someone fixed this already Trembluer12 (talk) 01:42, 23 April 2016 (UTC)