Jump to content

Photo

Multiple versions of DOS 2.0s?


7 replies to this topic

#1 Farb OFFLINE  

Farb

    Dragonstomper

  • 659 posts
  • Location:Frankfurt, Germany

Posted Sat May 12, 2018 3:02 AM

Hi everyone,

 

We've recently come across original DOS 2.0s disks that are slightly different. One has DOS.SYS, DUP.SYS and AUTORUN.SYS files. The other has DOS.SYS, DUP.SYS and a FORMAT.BAS file.

 

Any thoughts on why there would be a difference? I've attached them here.

Attached Files



#2 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,755 posts
  • Location:Australia

Posted Sat May 12, 2018 4:43 AM

I'd need to double check and look at the source but I do suspect in many cases since the "Write Dos Files" option uses what's loaded in memory at the time, you can get resultant files that'll be different and therefore give different checksum, CRC32, MD5 results.  My suspicion being that parts of buffers and work areas within the program will be different depending on config and what's been going on.

 

Also, not forgetting the well documented "POKES" such as getting rid of the near pointless "write with verify".

 

The flags indicating what drives are active and buffer counts etc are kept on the boot sector so should be isolated from the DOS.SYS file itself.


Edited by Rybags, Sat May 12, 2018 4:45 AM.


#3 flashjazzcat ONLINE  

flashjazzcat

    Quadrunner

  • 13,756 posts
  • Location:United Kingdom

Posted Sat May 12, 2018 5:09 AM

The POKEs (to change file buffers, verify, etc) work exactly because the file system is written to the disk from memory.

#4 Farb OFFLINE  

Farb

    Dragonstomper

  • Topic Starter
  • 659 posts
  • Location:Frankfurt, Germany

Posted Sat May 12, 2018 5:54 AM

Thanks for the information. As I mentioned, these dumps were from original Atari disks (without a write notch). Would what you are saying still apply?

 

I suppose someone could have overwritten one of them with a drive that ignored the write protect sensor.



#5 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,755 posts
  • Location:Australia

Posted Sat May 12, 2018 7:07 AM

Inside Atari Dos provides some insight - and has the 2.0s source code.

 

Or even easier - just dump out DOS.SYS to a text file.  Amazing that they used the program/workspace layout that they did, they probably could have saved 2 or 3 sectors by moving the embedded work areas to the end so that they weren't part of the loaded file.

 

I dumped out mine, there's a directory sector buried as well as FCB and other work areas.

 

So yeah, if you had a proper "virgin" copy of DOS, it might have a bunch of zeros in those areas or might have even been mastered from a "work" situation where there's remnants of a directory listing from something else.

 

(OK - I was doing this with DOS 2.5 but it's virtuall the same thing and I do suspect 2.0s would have the same bad habits)


Edited by Rybags, Sat May 12, 2018 7:09 AM.


#6 invisible kid OFFLINE  

invisible kid

    Chopper Commander

  • 101 posts
  • Location:New Jersey, U.S.A.

Posted Tue May 15, 2018 6:30 PM

Here are text file dumps using hexdump -Cv. You can diff them with a diff tool to see what's different

 

1-dos.sys.hexdump.txt is from Master Diskette II (1980)(Atari)(US)[!].atr

2-dos.sys.hexdump.txt is from Master Diskette II (1980)(Atari)(US)[a].atr

 

I also included screen shots of tkdiff of the 3 different areas.

Attached Thumbnails

  • diff1and2.png
  • diff3.png

Attached Files



#7 Rybags OFFLINE  

Rybags

    Quadrunner

  • 15,755 posts
  • Location:Australia

Posted Tue May 15, 2018 7:25 PM

The offset of the loaded DOS.SYS vs your dump there is +$7CC - ie those first changed bytes there at $B3E in the dump are at $130A in memory.

 

So you can work out the function from the assembly listing in Inside Atari Dos.

Everything different in the first dump is within work areas.  When assembling using e.g. *=*+4 to allocate work areas the assembler will usually output zeroes if it's to a file but just skip over if it's going to memory.  In assemblies to memory then there's the chance of getting different binaries from the exact same source code.

 

The second dump - we have a problem.  The listing in the book has Dos ending @ $1500 but in reality there's code living well beyond that.  LOMEM of a DOS 2.0s image I have here is $1CFC which even when considering buffers and stuff is more bloated than that listing would suggest.

The different values in the second dump aren't program code - my suspicion is that they've created masters from live disks that have been loaded and done some work.



#8 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 4,813 posts
  • Location:10-0-11-00:02

Posted Thu Jun 14, 2018 12:39 PM

as you may have referenced from writings about the subject... there were several iterations of DOS, and the example source does not cover all of them. DOS, DOS 2.0 (S and D) "that's single and double"... DOS 3.0 (black dot, no black dot) "that is bug no black, fixed black dot or whole punch) at least 3 different dos 3.0 existed but no change in the number... really bad practice... then of course DOS 2.5 and all the variants as well as hacks etc....

 

Both disks could be factory, a real analysis of them and using them for an extended period of time would shed some light on the subject, how does each act with early vs later 810 disk drives etc.

 

I have a vague recollection of this being discussed before, and hope it will be dug up and expanded on...

 

_The Doctor__






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users