VOGONS

Dynamic Disk Overlays Technical Information

Topic actions

First post, by RJDog

Posted on 
User metadata
Rank Member
Rank
Member

I am intending to make some more useful posts on my blog surrounding retro PC builds other than just the current "hey look what I built". One of the posts I want to do is about the technical inner workings of Dynamic Disk Overlay utilities, however before I do, I want to make sure I know what I'm talking about first (funny that, eh?). I really can't find any good resources online by searching that describes the technical inner workings of DDO software. I'm speaking specifically about OnTrack, but I assume the fundamentals are the same with EZ-Drive.

What I know:

  • DDO software overwrites the disk's MBR (sector 1) so that it is loaded on system boot (assuming the system is booted from the drive that has the DDO software in the MBR)
  • The existing MBR is moved to sector 2; this boot code is executed after the DDO software is loaded, as if it were on sector 1
  • The DDO software itself is actually kept in the first ~9kB of the disk before any other partitions are placed, and the DDO boot loader code finds and executes the DDO software there
  • When an operating system install takes place (i.e. DOS, Windows 95, etc.) and attempt to install their bootloader onto the MBR, the DDO software somehow redirects this to write to sector 2 instead of sector 1.
  • For OnTrack 9, at least, the partition table is kept in the usual spot on the real MBR on sector 1, in LBA format. This means that LBA-capable motherboards that natively support the drive size in question can actually read the partitions as usual, and is perfectly usable transplanted into a new machine without reformating

The blanks that I am not sure on that I'm hoping you guys can help me out:

  • The DDO software overwrites the BIOS code in RAM to support (presumably) LBA-style disk access. This sounds like it is very vendor and version specific for the BIOS firmware... does the DDO software know what location(s) in RAM to hook into for each and every BIOS vendor and version of the BIOS firmware? Sounds almost unmanageable from the development standpoint, but I'm not quite sure how it would work otherwise.
  • Kind of related, does the DDO software hook into Int 13h, or just use BIOS's normal means for Int 13h and just hook into the code for disk access as above?
  • I know most DDO software can/will go in and set some fake (or maybe real) CHS values in the BIOS... I guess this is kind of the same question again, but I suppose the DDO software must know where/address/how to modify these values for each and every BIOS vendor and version of the BIOS firmware?

And, of course, if you have any additional knowledge that you want to share, by all means!

Reply 1 of 4, by Rhuwyn

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie

I am interested in what sort of things you uncover on this. I am more or less in the same boat as you. Understand more or less what it writes to the disk but don't really understand how that actually forces the system to work with LBA. I didn't think anything would able to overwrite the BIOS code in RAM like that.

Reply 2 of 4, by Jepael

Posted on 
User metadata
Rank Oldbie
Rank
Oldbie
Rhuwyn wrote:

I am interested in what sort of things you uncover on this. I am more or less in the same boat as you. Understand more or less what it writes to the disk but don't really understand how that actually forces the system to work with LBA. I didn't think anything would able to overwrite the BIOS code in RAM like that.

It does not overwrite anything, the DDO code is run instead of the original BIOS code. The DDO code knows how to access hard drives using LBA even if BIOS did not.

When the machine boots, the original BIOS reads and executes the boot sector from the hard drive. But when there is a special DDO boot sector code installed and the unused area before first partition is installed to contain the rest of the DDO code, the boot sector code in turn loads the rest of the DDO code from hard drive using original disk BIOS code to the RAM at end of the conventional memory (right before 640KB mark) and disk interrupt vector is pointed to run that code instead of original BIOS code. Also it reduces the amount of available RAM by the amount the DDO code takes so that for example DOS understands there is less memory than 640KB available to protect the DDO code from being overwritten by DOS.

And if an operating system asks the hard drive parameters, the DDO code is the one that returns a sane result, not what BIOS would have reported.

Reply 3 of 4, by RJDog

Posted on 
User metadata
Rank Member
Rank
Member
Jepael wrote:

It does not overwrite anything, the DDO code is run instead of the original BIOS code.

Okay, this is one of the things that I was unclear about. This makes a bit more sense if it doesn't actually overwrite any of the BIOS code.

Jepael wrote:

...disk interrupt vector is pointed to run that code instead of original BIOS code.

I guess this is essentially the answer that I was looking for. This was also one of my theories on the operation of the software, that it puts its own code as the interrupt vector for Int 13h, instead of the BIOS's own interrupt vector.

Jepael wrote:

Also it reduces the amount of available RAM by the amount the DDO code takes so that for example DOS understands there is less memory than 640KB available to protect the DDO code from being overwritten by DOS.

Yeah, if it's going to have its own code loaded to be the target of the Int 13h interrupt vector, then it obviously needs to put that code in RAM somewhere, so it makes sense to put it at the end of the available conventional RAM and just report to DOS that the amount of conventional RAM available is less than what is actually there to account for the DDO code.

Marketing material for DDO software would lead you to believe that nothing stays resident in RAM and that no programs or system memory needs to be consumed for operation... which isn't totally untrue, but it does consume a small amount of RAM, reducing the amount available to the operating system. I really should have paid attention to the before-and-after RAM availability on my system... It looks like I have 618kB total conventional RAM reported by DOS... missing a whopping 22kB just for the DDO. Robbed!

Go to top of page Go to top of page
Back to General Old Hardware
Close window
Close window