DOS 3f

[Savetz]

Mike Albaugh (interview) gave me a disk of DOS 3, but it's not the DOS 3 that was released by Atari. This might be a planned DOS 3, very different from the thing that Atari released

 

As he explains it: "It is a preliminary version of a DOS for the Atari 8-bit line, different in disk structure from the various Atari DOSes, which used a linked list of sectors. I know nothing about the various third-party DOSes, but this one was, IIRC, an Extent-based file system, and had dosk parameters in the boot (like MSDOS or CP/M use), so could be adapted to different size disks.

 

The released "DOS 3" was essentially a continuation of the original DOS line. Sort of DOS2+. This one is a clean-sheet design.

 

As you may recall, the big jump from DOS 1 to DOS 2 was the split between FMS (the File Management System) and DUP (Disk Utility Program), so that only FMS had to be resident in memory while user stuff was running. DOS 3 continues this split (which is pretty common in most Disk Operating Systems; You shouldn't need to whole menu systems and the code it invokes to be in RAM while using BASIC).

Anyway, The disk has only the FMS. No DUP. You have to tell it what program to run if it is booted with no cartridge. Of course, if you boot it _with_ a cartridge, that cartridge can make the usual calls to FMS to do the usual things, like SAVE and LOAD from BASIC. For example, I suspect that if you boot with a BASIC cart inserted, and LOAD DIR.BAS, you'll be able to get a directory listing via BASIC. Also probably to get an idea how to do so by looking at the BASIC code.

My guesses about the contents:

> FMS F

This is probably the binary of the FMS. That is, I suspect that the boot code contains enough of a mini-FMS to open the directory and find the real FMS in a file named FMS.F, then load that file. It's a pretty normal thing. For example, the boot disks for the coin-op "blue box" development systems used the RT-11 disk structure, and the boot code knew enough about that structure to find a file called BOOT.LDA and load it.

> FORTH DD3

This is almost certainly the "root" of the DOS-based FORTH, all the pre-compiled stuff. In this case the version for DOS3

> FORTH D2S

Similar for DOS2S. That was the first version we wrote to run under a DOS, rather than "bare metal".

> FORSYS DAT

This is the "source code", which is compiled to extend the root FORTH for various things. Probably does not include the code for the stuff that is loaded as binary, as it would have been built in assembly or meta-compiled on a different system. Gotta remember that 92K is not a heckuva lot.

> FMS F

See above. The boot probably loads this by name.

> DIR BAS

My guess (as above) is that this is a BASIC program to get a directory listing.

> MRBILL DOS

No idea.

> FORMATV1 D3

My guess is that .D3 indicates a binary program (in typical ATARI format), and that this one will format a disk in DOS3 format.

>

> @PERFIN

> @START NEW

No idea.

> h

>

> FORMATV1 D3

> FORMATV1 D3 FORMATV1 .D3 2893

Wild guess is that these are "leftover" instances that were not over-written when a file ws changed, but that's a tentative guess.

I'll go take another dive into the filing cabinet where I dimly recall seeing the manual/spec. I've been putting of some stuff I really need to do, but if/when I finish that, I'll try taking my own advice and boot this image in the emulator, with a BASIC cartridge."

End of quote.

@Klund and I took a look and didn't get far. Maybe you brilliant people will have better luck understanding what this is.

dos3f.atr

-Kevin

[Kyle22]

Cool historical stuff, but could this ever be able to support clusters of 512 byte sectors? Extend the limit beyond 32MB per partition? I would much rather trust SDX to do this in a reliable, compatible way.

[Savetz]

A clarification from Mike: "I want to make sure you know that the 'f' in "DOS3F" is almost certainly just what I used as a disk label, for "DOS 3 with DOS_based Forth", not some official name for the DOS itself."

[Kyle22]

So this is only good for FORTH. Nothing against FORTH, but it's not a powerful language. Some good things were written using it, but I can't tolerate a boot disk that refuses to cooperate with a modern DOS.

[Savetz]

So this is only good for FORTH. Nothing against FORTH, but it's not a powerful language. Some good things were written using it, but I can't tolerate a boot disk that refuses to cooperate with a modern DOS.

 

 

OK, fair, but that's not really the point. The point is: here's something Atari made that no one has been before! Maybe some people want to dig in and figure out what's interesting about it.

[+tf_hh]

Mike Albaugh (interview) gave me a disk of DOS 3, but it's not the DOS 3 that was released by Atari. This might be a planned DOS 3, very different from the thing that Atari released

 

I´m still very surprised what comes to light today - nearly 40 years after the first bytes of code are made for our Atari 8 bit computers!

 

WOW!

[Atari_Ace]

I've poked around the disk a bit and don't see anything that looks like a BASIC program. I think the file names that appear around sector 20 are just leftover buffer contents captured at some point, and not related to this particular disk. There seems to be only 4 files on this disk, FMS.F, FORTH.DD3, FORTH.D2S and FORSYS.DAT. The FMS code has no Forth in it, but I detect the NEXT routine from Forth at three places on the disk (offset 0x20d8, 0x2f52, and 0x6cd8) and a small chunk of FORTH source code on the disk.

 

If anyone wants to poke around the FMS, the 'D' handler is at $0CEA:

0CEA: 29 0E             .WORD $0E2A-1 ; OPEN
0CEC: BD 0E             .WORD $0EBE-1 ; CLOSE
0CEE: A7 0D             .WORD $0DA8-1 ; GET BYTE
0CF0: A7 0D             .WORD $0DA8-1 ; PUT BYTE
0CF2: EA 0D             .WORD $0DEB-1 ; GET STATUS
0CF4: A7 0D             .WORD $0DA8-1 ; SPECIAL
0CF6: 4C 51 0D          JMP $0D51

and the special handler vectors are at $0DC9:

0DC9: 05                .BYTE $05 ; Get text record
0DCA: 12 35             .DBYTE $1236-1
0DCC: 09                .BYTE $09 ; Put text record
0DCD: 12 6A             .DBYTE $126B-1
0DCF: 0B                .BYTE $0B ; Put binary
0DD0: 12 23             .DBYTE $1224-1
0DD2: 07                .BYTE $07 ; Get binary
0DD3: 12 09             .DBYTE $120A-1
0DD5: 20                .BYTE $20 ; Rename
0DD6: 0F 16             .DBYTE $0F17-1
0DD8: 21                .BYTE $21 ; Erase
0DD9: 0E F9             .DBYTE $0EF9-1
0DDB: 23                .BYTE $23 ; Protect
0DDC: 0F 7B             .DBYTE $0F7C-1
0DDE: 24                .BYTE $24 ; Unprotect
0DDF: 0F 7F             .DBYTE $0F80-1
0DE1: 25                .BYTE $25 ; Point
0DE2: 0F C0             .DBYTE $0FC1-1
0DE4: 26                .BYTE $26 ; Note
0DE5: 0F A6             .DBYTE $0FA7-1
0DE7: 27                .BYTE $27 ; ??
0DE8: 0D 0E             .DBYTE $0D0F-1
0DEA: 00                .BYTE $00

 

[_The Doctor__]

Don't worry, more stuff is floating around from Atari, I have no doubt the drip drip drip will continue for another 15 or so years...

 

We have a new old toy! Let's play with it!

[Kyle22]

I think they're will be a large dump of something very soon. Things tend to happen this way.

Q

[AtariGeezer]

[thorfdbg]

 

Mike Albaugh (interview) gave me a disk of DOS 3, but it's not the DOS 3 that was released by Atari. This might be a planned DOS 3, very different from the thing that Atari released

 

The released "DOS 3" was essentially a continuation of the original DOS line. Sort of DOS2+. This one is a clean-sheet design.

 

As you may recall, the big jump from DOS 1 to DOS 2 was the split between FMS (the File Management System) and DUP (Disk Utility Program), so that only FMS had to be resident in memory while user stuff was running. DOS 3 continues this split (which is pretty common in most Disk Operating Systems; You shouldn't need to whole menu systems and the code it invokes to be in RAM while using BASIC).

There seems to be some confusion here. The released DOS 3 *is* a clean-sheet design and completely different from Dos 2. It is an extent-based file system, and it is even more modular than Dos 2. We have FMS.SYS, for the handler alone, then KCP.SYS, which is the resident part of the "keyboard command processor". Actually, it is only the loader of it. Then we have "KCPOVER.SYS", which is the non-resident part of it - this is the closest equivalent to "DUP.SYS", and then we have several external "plug in" commands for format, diskcopy and so on, that are also on the master disk.

 

I do not know what this is in particular. Forth - or at least the variants of forth I have seen on the atari - used a "disk-based, dos-less" approach where the source code editor edited raw sector contents, without any administration through dos.sys. Probably because Forth required larger source codes - larger than memory - and more space for compling, and the "link-based" dos 2 system did not enable this in a useful way. The forth-versions I saw just go directly to the disk, enabling random access without seeking.

 

Dos 3 could also do the same, i.e its much simpler to seek to a particular byte offset in Dos 3 than it was in Dos 2, so maybe that is why it was used here, but without looking into the code, it is hard to say what we have here, exactly.

[+hunmanik]

I hope this doesn't just muddy things further, but could this be the "DOS 3" Harry Stewart was contributing to in 1981, which I think was also not the DOS 3 that was released?

 

https://archive.org/details/AtariDiskFileManagerFunctionalDescription

https://archive.org/details/AtariDOS3DiskCleanupUtilityFRS

https://archive.org/stream/AtariHarryStewart/Atari%20my%20major%20projects

[_The Doctor__]

[tschak909]

This is truly bonkers.

 

It's definitely an FMS, BUT, the Forth that's here is literally a straight port of Bill Ragsdale's forth, including showing the bit 7 being set for the last char of each word in the dictionary, which Atari of course shows in reverse video.

 

But the forth itself has NO logic for talking to this FMS, and it simply uses straight get/put sector SIO calls, so if not careful, you'll find yourself wiping over the parts of the disk that DOS is managing.

 

Interestingly enough, the CIO directory call isn't implemented, so can't see the disk directory from BASIC.

 

-Thom

[tschak909]

Some forth code on screen 20 (circular wipe)

 

-Thom

[flashjazzcat]

That's odd: I was able to get a directory listing from Altirra BASIC by simply typing 'DIR'.

 

I wasn't able to figure out everything about the file format yet, but (rather unsurprisingly given this is supposed to be 'extent based') the files appear to be entirely contiguous. The directory entry simply supplies a 16-bit sector number and the FMS starts delivering sequential sectors of file data. Didn't look into new file creation yet or how file growth, etc, is managed.

 

So - I assume an application which knows the file size and start cluster could quite happily perform raw sector IO.

[tschak909]

Oh there we go, PEBKAC.

 

This is definitely interesting... Will take some time to disassemble and figure out what they were going for.

 

No format command, disk must be sector copied if you want another one.

[tschak909]

can read, write, and delete.

 

-Thom

[tschak909]

memlo is $2079...meh.

[tschak909]

will do some more testing as soon as I figure out how to get stuff ONTO the disk.

 

-Thom

[tschak909]

The biggest difference that I see here, is what Jon alluded to, the filesystem is infinitely simpler, definitely meant for maximizing disk space, while potentially limiting potential random access and updating of th disk over time... It might have made sense for distributing ready to run software.

 

Files in the directory have their actual byte size, versus being padded to the next sector.

 

-Thom

Edited September 7, 2018 by tschak909

[flashjazzcat]

The only reason DOS 2.x doesn't need an exact file size in the directory structure is that the three byte chain link also describes the number of bytes used in a sector, so DOS can work out the precise file size by adding those up. Without that, a byte count in the directory is essential.

 

I believe there's a stand alone utility for formatting (forget how I deduced this).

[_The Doctor__]

He may even have them, disk version, cart, colleen forth, wonder if he would dig it all up.... you know how the fellows love to mess with everything and see the differences.

 

at the other stuf that's because this is his forth disk, not just the dos disk...maybe he has more elsewhere.

Edited September 7, 2018 by _The Doctor__

[tschak909]

I'd love Mike to weigh in on this, as it is quite possibly one of the weirder artifacts to come in lately...

 

-Thom

[morelenmir]

I think they're will be a large dump of something very soon. Things tend to happen this way.

Q

 

Are you sure this doesn't contain an inadvertent ROM dump for Polybius???

 

I always get an eerie feeling when things like this appear straight from the murky days of the early eighties...

Edited September 28, 2018 by morelenmir