DOS 2.0S DUP.SYS Source Code?

[AGiambra]

Bob,

 

Load DUPSYS2.M65 and search through the listing for "MDEND+" You'll find a line that says "MDEND+$0C00". Change the $0C00 to any value you like and you'll move the resident portion of DUP.SYS up by that value.

 

Attached is an .ATR of DOS with DUP.SYS moved up by $0C00 bytes. If you look at the heading after you boot, you'll see I changed the Version number to 3.0S. I wanted to have something visual so I'd know which version of DUP.SYS I was running.

 

Have fun!!!!!

 

Ange

 

PS Why didn't I think of simply attaching an .ATR berfore???? This makes it so easy. On the .ATR disk I have included all the files you'll nned to modify DUP.SYS. Ain't this fun??????

Atari Dos with Modified DUPSYS.atr

[AGiambra]

Concerning your question "Can I just move it up $0200 bytes instead of $0C00 bytes" I wouldn't recommend this Bob. Atari chose to put it at least $0300 bytes above DOS. This is because Atari DOS needs at least that much memory for its buffers. If you put it any lower you risk crashing DUP.SYS. But you can experiment and see what happens.

Edited January 22, 2015 by AGiambra

[+sm3]

I suppose you are using the disk version of MAC/65? Also, which 800, 800 xl or the 48k 800. Thanks.

[AGiambra]

Yes I used the disk version of MAC/65 (although during this project I also used the cartridge based version. I like the cartridge version because it allows you to use the SET 6 command to create an offset. I don't know why this was not included in the disk based version),

 

I am running on an 800 XL.

[+sm3]

OK thanks.

[+bob1200xl]

That's great - thanks!

 

I was thinking of $200 bytes more, not total. I'll try some values.

 

Isn't there a way to configure DOS buffers by setting values in $70x somehow?

 

Bob

 

 

Concerning your question "Can I just move it up $0200 bytes instead of $0C00 bytes" I wouldn't recommend this Bob. Atari chose to put it at least $0300 bytes above DOS. This is because Atari DOS needs at least that much memory for its buffers. If you put it any lower you risk crashing DUP.SYS. But you can experiment and see what happens.

[Rybags]

Dos 2.x has flexibility in the number of drive and file buffers, which affects it's memory footprint.

 

I imagine DUP probably sits at it's fixed higher location such that it's "worst case" minimum requirements are catered for... which I imagine is probably 4 drive + 2 file buffers which would equate to $300 bytes.

 

I've not looked at the code for a long time but I imagine DUP must reconfigure the drive/file flags otherwise it would need to sit even higher in order to cater for the 4 drive + 7 sector buffer config.

Edited January 22, 2015 by Rybags

[AGiambra]

DOS uses location $709 to determine how many bufers to allocate. By default this is set to 3. So DOS will allocate 3 128 byte buffers.

 

Location $70A is used to tell DOS how many drives you have. If you set this to 3 it means there are two drives. If you set this to 7 it means you have three drives. 15 means you have four drives.

 

Of note, DOS also has a bug. Put three double density drives online and then try copying a file from one drive to the other. You'll get an error 161 (no buffers available). DOS doesn't allocate enough buffers when your have three DD disks online. To fix this, set location $709 to 7.

[+bob1200xl]

and, $709 and $70A only configures DOS, not where DUP loads. IC...

 

A long time ago, I enabled the memory at $D600-$D7FF and pointed DOS up there for its buffers. Seemed to work OK, but you still only had $200 bytes of space. I think I would like to try pointing DOS up into linear memory (at something like $060000) and allocate max buffers/drives up there.

 

DOS 2.0S works pretty well on DD drives, you just need a lot more buffers. One for a 5.25, one for a 3.5, a couple of HDDs - like that.

 

Great stuff - thanks!

 

Bob

[AGiambra]

That's pretty cool stuff Bob.

 

I recently wrote a utility that puts the DOS Directories from each drive into the RAM beneath the OS. Whenever you issue a directory command or copy files or do anything that accesses the disk, my utility reads from the RAM resident directories instead of the drives. On drives where you have lots of files it saves a lot of IO. The utility is smart enough to know when directory entries have been changed and need to be written back to the disk. It's even smart enough to know if you have swapped out the disk because then the RAM versions of the directory need to be refreshed. Fun stuff.

[Atari_Ace]

Hopefully of use to someone, I've updated the DUP.SYS listing to add the omitted comments and made some other minor fixes to that listing and the DOS.SYS listing trying to make them as close as possible to the pdf scan and Inside Atari DOS. The main difference is I added a handful of missing semicolons the original assembler somehow didn't need. I left the expanded HILO macros in DUP.SYS listing although they probably should be removed.

 

Included in the file is a perl script to convert the listings to something MADS can handle.

 

dosdup20s.zip

 

[+sm3]

Yes, much appreciated. Thanks for your efforts!

[tschak909]

So, what's the difference between the 2.0S and 2.0D FMS, with regard to code changes to support double density?

 

-Thom

[Atari_Ace]

2.0S already has all the code to support double density. If you compare the files, you'll mostly see differences in defaults. DRVMDL, DRVLBT and DRVTYP are set to double density values ($FD, $FF, $02) instead of single density values ($7D, $7F, $01). DUP.SYS has lower case in the menu text and 2.0D, but otherwise seems to be the same. The rest of the differences seem to be in buffer contents which get captured when DOS files are written and in the area just before the INIT code for DUP.SYS which is resident in DOS.SYS, which I think is just remnants from development or some driver.

 

 

 

[Atari_Ace]

Hopefully of use to someone, I've updated the DUP.SYS listing to add the omitted comments and made some other minor fixes to that listing and the DOS.SYS listing trying to make them as close as possible to the pdf scan and Inside Atari DOS. The main difference is I added a handful of missing semicolons the original assembler somehow didn't need. I left the expanded HILO macros in DUP.SYS listing although they probably should be removed.

 

Included in the file is a perl script to convert the listings to something MADS can handle.

 

dosdup20s.zip

 

 

I've further edited these listings while restoring the assembly output on the left hand side, which revealed some minor errors. The files without the assembly output are attached, the fuller versions can be found at

• DOS.SYS: http://ksquiggle.neocities.org/iad.htm#src
• DUP.SYS: http://ksquiggle.neocities.org/dup2.htm#src

dosdup20s_2.zip

[+kheller2]

On 1/22/2015 at 1:38 PM, AGiambra said:

DOS uses location $709 to determine how many bufers to allocate. By default this is set to 3. So DOS will allocate 3 128 byte buffers.

 

Location $70A is used to tell DOS how many drives you have. If you set this to 3 it means there are two drives. If you set this to 7 it means you have three drives. 15 means you have four drives.

 

Of note, DOS also has a bug. Put three double density drives online and then try copying a file from one drive to the other. You'll get an error 161 (no buffers available). DOS doesn't allocate enough buffers when your have three DD disks online. To fix this, set location $709 to 7.

 

I haven't tested the 3 DD drives, but I am curious if its "correct".  DOS is supposed to issue status commands to determine 810 or 815 and allocate buffers accordingly.  The example here is no different than 6 single density drives.  $1311 is the drive table type, 0=none, 1=Single, 2=Double.

 

Images from Inside Atari Dos: