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 program sectors
3	Volume Table of Contents (VTOC)
4	Catalog sectors
5	Track/Sector List for HELLO program
6	Data sector for HELLO program
7	3kb 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	2	2															3
1	1	2	2	2															4
2	2	2	2	2															4
3	3	2	2	2															4
4	4	2	2	7															4
5	5	2	2	7															4
6	6	2	2	7															4
7	7	2	2	7															4
8	8	2	2	7															4
9	9	2	2	7															4
10	A	2	2	7															4
11	B	2	2	7															4
12	C	2	2	7															4
13	D	2	2	7															4
14	E	2	2	7															4	6
15	F	2	2	7															4	5

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.

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.

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