Atari DOS 1 Source Listing?

[pcrow]

If I'm looking at all the correct pieces, the define device option uses 333 bytes in DOS 1.  (I could also see a project where various operations like define device and duplicate disk are set up in the code with conditionals to make it easy to build a light version of DOS 1 without them.)  That's 253 bytes of mostly code and an 80-byte table.  But I think it's really only 58 bytes of code that needs to be resident, plus the table.  The rest of the code is the user interface for adding new redirections, and that code needs some rewriting anyway to include the ability to list current redirections and remove unwanted ones.  With a bit of optimization, it could probably fit in the bottom of page 4 which is the cassette buffer (making it incompatible with actually using the real C: driver).  That seems like the best place for maximum compatibility.

Edited August 10 by pcrow
Try to undo smiley when I really want to say "C:"

[pcrow]

I just found another bug, and it explains some things.

 

I'm doing most of my work in an emulator, but I default to 800 mode, as that's what I grew up with.  The DEFINE DEVICE option works perfectly.  But if I switch to an XL, it crashes.  It turns out there are two bugs.  First, the new devices are added at the end of the handler address table, and the XL OS shortens it by one entry.  But the real problem is that it's using three different internal CIO calls to do the redirection, and those routines moved in the XL OS.  In looking at what they did, I just don't get it, as it's far easier to just patch up the IOCB and jump back into the main CIO vector.

 

I played around with this a bit, and switching to the simpler code makes it work on both an 800 and an XE.

 

I'm still not clear about the removal of one HATAB entry, as I see those listed on a memory map now as PUPBT1-3 which are "Power-up and reset validation registers 1-3.  Used on warm start to verify the integrity of memory."  Maybe it's overloaded?  Using the last HATAB entry seems to still work.

 

But this explains why I heard someone referring to the DEFINE DEVICE option as buggy or broken.  They must have been using an XL.

[pcrow]

I've committed the fix for DEFINE DEVICE to work correctly on XL/XE systems.  I did some simple tests, and couldn't find any issues.  The code involved is now simpler and shorter, which is also good.

[+DjayBee]

8 hours ago, pcrow said:

In looking at what they did, I just don't get it, as it's far easier to just patch up the IOCB and jump back into the main CIO vector. 

It might be needed to avoid overwriting CIO-internally created and used ZP(?) data due to the re-entry into CIO after handler-redirection.

Just wildly guessing. 

[ClausB]

On 8/9/2024 at 12:45 AM, pcrow said:

binary load files in DOS 1 start with 84 09 instead of FF FF.  I would love to know why that was picked.

Oooo, a puzzle! Maybe 3 characters packed into 2 bytes? $0984 is 2436 decimal.

 

Try base 26 with 0 as A and 25 as Z, get DPS.

 

Try base 32 with Baudot coding, get EBY.

 

Programmer's initials? 

 

Could be other encodings in other bases, like 36 (alphanumerics) or 40 (largest to fit in 2 bytes).

Edited August 13 by ClausB

[+kheller2]

https://archive.org/details/OverviewOfAtariDOSVersion2.4/mode/1up
 

discusses why FF FF was chosen (concatting files and the Assembler cart format) but doesn’t explain why the old was used. There are some interesting notes in here about why DOS 2.4+ is better and bug fixes.  It is also odd to me that it was called DOS II yet the released version is 2.9 I believe. 

[pcrow]

8 hours ago, DjayBee said:

It might be needed to avoid overwriting CIO-internally created and used ZP(?) data due to the re-entry into CIO after handler-redirection.

Just wildly guessing. 

That makes sense, at least as far as they were thinking.  They probably were very familiar with the CIO internals and just figured it was the right way to do it.  Now with emulators, it's extremely fast to assemble and test things, so I'm confident that just calling CIO again is OK.  I could look at where the RTS from the first call is set at, but I doubt there shouldn't be much left to process.

[pcrow]

2 hours ago, kheller2 said:

https://archive.org/details/OverviewOfAtariDOSVersion2.4/mode/1up
 

discusses why FF FF was chosen (concatting files and the Assembler cart format) but doesn’t explain why the old was used. There are some interesting notes in here about why DOS 2.4+ is better and bug fixes.  It is also odd to me that it was called DOS II yet the released version is 2.9 I believe. 

That's fascinating.  I would assume they had a number of middle internal versions with various changes, as the total change list is long.  I figure the double-density support was one of the first changes, as Atari was probably pushing for that thinking the 815 would come out soon.  It would have been nice to have had a DOS II with everything but that in retrospect (would have saved memory).

 

The one thing I didn't realize was that open for append didn't link the new sectors in until the file was closed, which explains why it leaves files partially used in the middle, as well as why the sector chaining had to change.

 

I didn't see any reference to burst I/O.  Perhaps that was added after that document was written, or maybe they forgot to mention it?  Otherwise it looks like they hit everything that I can think of.

 

Interestingly, there's no mention of DOS 1's AUTO.SYS file when they talk about AUTORUN.SYS.  I guess since they left off the run support, so it only loaded memory, it wasn't a feature worth referencing.  They also didn't mention dropping define device.  Perhaps they were hoping management wouldn't notice and ask them to put it back.

[thorfdbg]

On 8/6/2024 at 9:45 PM, pcrow said:

I just tested, and MyDOS does this, too.

And so does Dos 2, and Dos 2.5. It is not so unique as feature, really.

[+kheller2]

Some of the preliminary docs I read imply that DOS II -S was only ever for single density drives (to save buffer space) where as -D was to support both the new "dual density" and single density drives -- at the expensive of buffers.  It was also written that the only difference between S and D was the buffer configurations -- while that may be close to accurate for DOS.SYS, DUP is different in a few places.  I'm still trying to figure out why we have -D with upper and lowercase menu versions.   I'm thinking one is a later version/earlier version.  There is a Corvus source code disk floating around that has FMSDUAL and DUPDUAL sources and they are in upper case.  Then I also noticed there is a DOS 3 Cleanup utility document from Feb 1981!  The first code version of DOS 3.0 wasn't until November 1982.  So what might that 1981 doc be talking about... hmm..

[+kheller2]

So while investigating what this "FUNCTIONAL SPECIFICATIONS FOR A DOS 3 DISK CLEANUP UTILITY" 1/20/81 was about (https://archive.org/details/AtariDOS3DiskCleanupUtilityFRS/mode/2up),  I noticed that it was dated long before the first build of what would become Atari DOS 3.0.  [Side note: this specification is very different from what DOS 3.0 became/was.  I'm assuming it was the rumored internal DOS 3 based on (maybe) the DOS 2.9 release; hence 3.0 being the next interation].  In the document they talk about providing the same functionality as its DOS 2 counterpart.

 

Counterpart?  That jogged my memory that I had seen source code for such a DOS 2 utility.  That utility is here:  https://atariwiki.org/wiki/Wiki.jsp?page=Fixdump and its source code is on the Corvus sources disk here: https://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/dos-2-0-source-code-for-corvus-815-system/

 

Looking at the code, you can compile it two ways.  The above "FIXDUMP 2.0SD" version... or a "DISK FIXER 1.0SD" version.

 

The comments in the source:

;
;
;************************************************************************
;               FILENAME = $MICHAEL.FIXME
;************************************************************************
;WRITTEN BY IAN SHEPPARD APPROX. MAY 22,1979
;MODIFIED BY MICHAEL EKBERG MAY 15,1980 TO WORK ON NEW DOS
;(9/24 MODIFIED) AND TO GIVE SECTOR DUMP AND MODIFY SECTOR
;COPYRIGHT BY ATARI,INC. MAY 15,1980
;MODIFIED FOR DOS 2.X JULY 1, 1980 *INDICATES MODS.
;
;

 

So that got me thinking.  Does 9/24 MODIFIED mean it works on DOS 1 9/24 release (when recompiled) or does 9/24 MODIFIED mean post DOS 1 before DOS 2?  The assembly flag basically changes the menu and adds some new options, implying there isn't that much difference in the disk layout of DOS 1 and DOS 2.  The Ian Sheppard date of 5/22/79 is also interesting as that is before DOS 1.0 9/24. 

 

The utility implies it also works on double density disks.  So does "SD" mean "Single" and "Dual"  and not "Single Density"? hmm