6

The Apple II disk bootstrap process looks at the first byte of track zero sector zero to see how many sectors long the bootstrap code will be. It then loads these sectors at location 0x0800 and jumps to address 0x0801, just after the "number of boot sectors" byte.

Normally the number of boot sectors is 1, but some custom boot loaders use more. I've got a few disk images which say 5.

So when there are multiple boot sectors, are they the first physical sectors, disregarding any sector interleave? Or should the interleave for the logical sectors of DOS 3.3 be used? (Surely ProDOS interleave would never be a factor?)

When dealing with disk image files, the common .DSK format (aka .do and .po) have no header telling which sector ordering to use. They use either DOS 3.3 order or ProDOS order. They never use physical order. For OS disks you can look for OS structures at known offsets on the disk to determine the sector ordering. But some games don't use any OS disk structures.

Which sectors did the Apple 2 load, and what should emulators and disk image utilities do?

UPDATE:

I've found some annotated disassembly of the boot process with commentary on Usenet comp.sys.apple2 from four years ago. So far it's difficult for me to understand not being an Apple II guy. I'll keep trying to grok it while waiting for somebody who knows this stuff to come along...

Improve this question
6
  • @NickWestgate: The ones I'm looking at are not NIBs. They have the .dsk extension. The ones in front of me are both rev A and rev B of Loderunner (probably from here) but I'm sure I saw it in another image earlier too. By "normalized" you mean put into physical order right? The subsequent few sectors in the image files seem to be all zeros which make me think they're not the ones.
    – hippietrail
    Commented Jul 1, 2020 at 3:53
  • 1
    I must not be understanding something. I got the basics of the boot process from Raffzahn's answer here: the first sector is loaded at 800 and then jumped to 801 (800 holds a counter for the number of sectors to read by the bootloader - usually 1)
    – hippietrail
    Commented Jul 1, 2020 at 5:52
  • 1
    A thousand apologies, I misinterpreted your question. I'll reply later.
    – Nick Westgate
    Commented Jul 1, 2020 at 6:06
  • 1
    Both DOS and ProDOS number sectors in physical order, and use a logical to physical mapping internally to implement "soft" skew. When multiple sectors are loaded by boot zero they're found by physical number 0, 1, 2 etc. The translation from DO to physical order is done by the emulator or tool that reads the disk image, and it creates a track image with the sectors in physical order. When there's nothing to distinguish DO from PO, the default should be DO, but if that's wrong then obviously the boot will fail. BTW, that diassembly is from here.
    – Nick Westgate
    Commented Jul 1, 2020 at 6:47
  • 2
    The ROM boot code simply reads them in ascending address sequence (0..n), by checking the sector numbers found on disk. It doesn't know about any interleave, nor does it expect or handle one - except for simply waiting until the header for the one to read comes along. Everything else is up to whatever gets booted.
    – Raffzahn
    Commented Jul 1, 2020 at 19:43

1 Answer 1

Reset to default
4

Emulators should emulate the Disk ][ hardware at a low level, or they're going to have a bad time. Attempting to pull in the right set of sectors will work for standard DOS or ProDOS disks, but won't work for anything custom.

You can find a commented disassembly of the boot ROM here and a "typical" T0/S0 here. You'll note there's a sector interleave map at $084D in the latter, which translates physical sector numbers to logical. This isn't needed to read T0/S0 because logical sector 0 is always physical sector 0, but it does limit what the boot ROM can do.

The only parts of the BOOT1 (T0/S0) sector that are fixed are the sector count and the jump to $0801. It's pretty rare to see something other than 1 at $0800; usually the BOOT1 code wants to do its own thing. The important part is that BOOT1 can do whatever it feels like: it can use a standard interleave, it can read them in physical order, it can define its own scrambled version. That's true even if it's using standard DOS sectors.

I think what some emulators do is convert DOS tracks into nibble images internally, and then work off that (essentially .DO/.PO -> .NIB). You don't need to get too fancy unless you want to support copy-protected images in .WOZ format.

FWIW, "[images] never use physical order" isn't strictly true, as some versions of Copy ][+ created physical-order .IMG files. These were rarely if ever used though.

(For anyone else reading this, the gory details of logical/physical/DOS/ProDOS were explored in a previous question by the OP.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .