Slash Boxes

SoylentNews is people

posted by janrinok on Saturday January 08, @08:10PM   Printer-friendly
from the PC-introns dept.

Anyone trying to disassemble the PC DOS 1.1 boot sector soon notices that at offsets 1A3h through 1BEh there is a byte sequence that just does not belong. It appears to be a fragment of code, but it has no purpose in the boot sector and is never executed. So why is the sequence of junk bytes there, and where did it come from?

The immediate answer is "it came from FORMAT.COM". The junk is copied verbatim from FORMAT.COM to the boot sector. But those junk bytes are not part of FORMAT.COM, either. So the question merely shifts to "why are the junk bytes in FORMAT.COM, and where did they come from?"

It is not known if anyone answered the question in the past, but the answer has been found now, almost 40 years later—twice independently.

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by bzipitidoo on Sunday January 09, @02:44AM (1 child)

    by bzipitidoo (4388) Subscriber Badge on Sunday January 09, @02:44AM (#1211179) Journal

    Old nerdiness. I like it!

    I've been studying the history of computing, and if I had to pick just one word to describe it, it would be "haste". Everyone was in a tremendous hurry to push the kludge out the door once it was in a functional state, however fragile. Had to beat the competition to market. Or, academia was desperate to promulgate a standard, quick, before all the commercial vendors pushed out a dozen or more mutually incompatible methods for solving the problems of the moment. They often did rush things out too fast.

    But yes, in the 1970s memory was tight, really, really tight. People did sweat over every byte. So these junk bytes being overlooked is a little odd. The Apple II disk controller had only a tiny program capable of only a braindead pulling of the arm to the edge of the disk, and loading the first few bytes. SCSI it was not. It would move the arm the full width of the disk regardless of where it happened to be when the boot sequence was started, thus the thudding noise it often made on boot as the arm bumped up against the limiter at the edge. The code it loaded from those first few bytes of the disk had to contain the instructions to tell the computer how to read the rest of track zero, which contained the code to perform disk arm movements so that the computer could read the rest of the tracks. Today, all that is built into the controller hardware. Back then, it was a very literal bootstrap process, and the C in CPU was meant in a very total way. Almost everything the computer did went through the CPU. One of the major ways computer performance has improved so greatly over the years is in offloading all the work that can be offloaded, freeing the CPU for general work, no more loading it down with low level disk read and write work, audio work, and especially video graphics work.

    The slop in the Apple DOS was that in their haste to push it out the door, they overlooked a few simple things that greatly slowed disk reads and writes. The time it took their code to process a sector was a shade too long, and by the time it finished, the start of the next sector had rotated just past the head, forcing a wait for the disk to spin all the way around. Took as many as 17 revolutions of the disk to read the entirety of one track. Wasn't long before aftermarket DOSes appeared that addressed that deficiency, reducing the read times for a track to 2 or even 1 revolution.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Interesting) by looorg on Sunday January 09, @08:04AM

    by looorg (578) on Sunday January 09, @08:04AM (#1211216)

    While this does sound like a plausible explanation I sort of wonder why you would allow this junk into the program tho if the goal was to save bytes of memory? You probably would also waste bytes of storage, which at the time also was quite expensive. Wouldn't it have been a lot better in that regard to just zero it out, or just make it something controlled so it could be compressed better?

    In that regard I almost wonder if some of it was left in there as a copyright claim. Considering there was a multitude of DOS:es etc at the time things was probably left behind there for all the people that copied your stuff so you could later claim they copied you and it was lawsuit time. So instead of leaving something legible you leave some "junk". Sounds like something Bill and friends would do.