I've been looking through documentation on The Sinclair/Amstrad Spectrum +3 which was the only Spectrum that came with a built-in floppy disk drive. The disk format was based on The Amstrad CPC and PCW disk format, which was based on CP/M.

I'm struggling with some details of the boot process.

I know there's an optional boot block on side 0, track 0, sector 1, at offset $0010, right after the 16-byte 'disk specification'.

But since this block is optional, there must be a way for the system to detect whether it's present or not.

I know that in some disks the file directory will be here instead, and starting at offset $0000 without a disk specification.

Some disk images seem to be of protected disks with purposely confusing sector layouts that must've made it harder to pirate them back in the 80s, which makes it challenging to figure out by looking at the raw data.

So is there somewhere on the disk layout that I'm missing that indicates to the OS that a boot sector is there or not? Or could it possibly all hinge on that one-byte checksum which seems like it could easily give false positives? If so, is the checksum just a sum of the bytes of the boot sector modulo 256?

If it makes a difference I'm using DSK and EDSK format disk images.

4 Answers 4


I think some of the answers here are combining determining the disk format with detecting if it's bootable. I've answered how the format is detected on its own question, so here I'll concentrate on the boot process.

The +3 tries to boot from a disc by using the DOS_BOOT function. This selects drive A:, closes any open files on it, and then tries to read logical sector 0 into the +3DOS internal cache. Assuming that worked, it sums all 512 bytes of that sector modulo 256. If the result is 3, it copies the sector to 0FE00h in bank 3, sets the memory paging to the all-RAM 4-5-6-3 configuration, and jumps to 0FE10h.

If the checksum is not 3, DOS_BOOT returns error 35, 'Disk is not bootable'. The loader then falls back to executing the BASIC command LOAD "DISK". If that in turn fails, it selects cassette tape and executes LOAD "" to run the first program on the tape.

There is no requirement that the boot disk should be in the "standard" +3 format, begin with the 10-byte disk specification, or even have reserved tracks - as long as the checksum of the first sector is 3, DOS_BOOT will happily boot from a disk in CPC System or CPC Data format. In this respect, the +3 boot process is more flexible than the otherwise-similar PCW, on which the boot sector has to be physically numbered 1.

  • Awesome! Some dos and comments made it seem like I only had to checksum the 16-byte disk spec. My goal was to exercise my rusty coding and reversing skills by writing an extension for Ghidra to list all code files including the bootsector. Turned out trickier than I expected! May 1, 2020 at 0:52
  • I have no idea how this computer works, but you're on Hot Network Questions now. Why would the first sector not be physically numbered 1 (or 0, I assume there's nothing special about 1)?
    – user253751
    May 1, 2020 at 1:50
  • 1
    @user253751: The Amstrad CPC System and Data formats, which are supported by the +3, number the physical sectors from 41h and 0C1h (65 and 193) respectively, using the high bits of the sector number to detect what format the disk is in.
    – john_e
    May 1, 2020 at 7:09
  • 1
    It's a classic example of cludging new information into an inflexible older format. We've all done it! May 1, 2020 at 10:02

From my answer to How do I know where the file directory is stored on a Spectrum +3 disk layout?

Part 26 of the +3 manual is what you need to read. There is even a complete example of how to write boot code and how to store it into the disk. This part is the relevant one regarding which values the disk specification block must have:

bootstart: ; ;The bootstrap sector contains the 16 bytes disk
specification at the start. ;The following values are for a AMSTRAD
PCW range CF2/Spectrum +3 format disk. ;

               db   0                   ;+3 format
               db   0                   ;single sided
               db   40                  ;40 tracks per side
               db   9                   ;9 sectors per track

               db   2                   ;log2(512)-7 = sector size
               db   1                   ;1 reserved track
               db   3                   ;blocks
               db   2                   ;2 directory blocks

               db   02Ah                ;gap length (r/w)
               db   052h                ;page length (format)
               ds   5,0                 ;5 reserved bytes

cksum:         db   0         ;checksum must = 3 mod 256 for the sector

A non bootable disk will have 0 reserved tracks.

  • 1
    Your last paragraph doesn't follow - it's possible to have a non-bootable disk with any number of reserved tracks. Disks created by the +3DOS "FORMAT" command, for example, will have one reserved track but no machine-code boot block.
    – john_e
    Apr 30, 2020 at 13:41
  • @john_e: I just confirmed this by in Spectaculator. The resulting fresh 3" ss EDSK img has no 16-byte disc spec but does have an unused first sector and has a directory in the second sector. Otherwise I'm getting nowhere. Can't even get my checksum code to work. The protected disk images are throwing me off and I seem to have a pair of CPC disk images in the mix too but I'm too confused to know really. Too many decades away from this low-level stuff maybe? Apr 30, 2020 at 16:25
  • This image claims to be a Plus 3 compilation but might be for Amstrad: planetemu.net/rom/sinclair-zx-spectrum-dsk/… Apr 30, 2020 at 16:32
  • In fact that disk image didn't work in any of the two Speccy emulators and one Amstrad emulator I threw it at even though it looks right in a hex editor. May 1, 2020 at 0:37
  • Oddly, my code to read the directory of DSK and EDSK image files does work on image in the comment above, so I'm doing something right according to what I've learned and according to those images, but not according to the four emulators I've tried them on. May 17, 2020 at 15:44

On a CPC system, you can determine if the disc is in System format (i.e. bootable) by the number of the first physical sector. If the sector is 41h, the disc is in System format, with 2 reserved boot sectors, whereas C1h means Data format, no reserved sectors.

The PCW and Spectrum +3 can also determine the bootability of a disc from a 16-byte record on track 0, head 0, physical sector 1. The checksum of this record indicates if the disc is bootable:

  • 1 - sector contains a PCW9512 bootstrap
  • 3 - sector contains a Spectrum +3 bootstrap
  • 255 - sector contains a PCW8256 bootstrap

The rest of the sector contains the bootstrap code. Information gleaned from https://www.seasip.info/Cpm/amsform.html

  • 1
    On many of the disk images files I've downloaded, this sixteen-byte record is only there for bootable disks. Many of the non-bootable disk images have the first directory entry in this position. On DSK and ESK image files, this is offset 0x0200. At least one has an unformatted track in this position. This seems to be the case for all of the images using the extended format, EDSK, while the DSK ones are a mix. I feel like I must be missing something? Apr 30, 2020 at 11:57
  • When you say "by the number of the first physical sector" do you mean the first byte of the first physical sector? Apr 30, 2020 at 12:24
  • 2
    @hippietrail no, he means the sector number in the address mark that preceded the sector. In the DSK image format you’d check the corresponding sector information blocks, which come before sector contents within the track image.
    – Tommy
    Apr 30, 2020 at 12:53

But since this [boot] block is optional, there must be a way for the system to detect whether it's present or not.

There isn't. The +3 (like the Amstrad CPC) doesn't autoboot. Using the Loader on a +3 (or |CPM on an Amstrad CPC) on a disk that's in Data or Vendor format (that is, does not have CP/M or custom boot code in the reserved tracks already mentioned) results in:

+3 dropping back to loader after trying to boot from a Data disk

after the system has failed to load a valid boot block and reserved tracks containing boot code.

(Data disks have no reserved tracks. System disks have reserved tracks containing boot data and a valid boot block. Vendor disks have reserved tracks, but they're blank. They were meant for software vendors to distribute programs without including proprietary CP/M code. You didn't encounter them very often.)

  • Ah yes sometimes I'm confused about booting since some emulators bypass the Loader menu if you doubleclick on a .dsk file, or perhaps invoke the loader automatically. But if I change disk images and reboot the virtual Speccy it behaves as you say. BUT should all disks have the 16-byte disk specification at the start of the first sector? Or is it that the system tries to interpret those 16 bytes as a disk specification and if that fails, by however success is decided, then the disk is treated as having no reserved tracks? Apr 30, 2020 at 12:49
  • 1
    The logic used is: Firstly, do a DD READ ID to read a physical sector number from track 0. If it's 40h-7Fh then the disk is in CPC System format, 2 reserved tracks, not bootable. If it's 0C0h-0FFh then the disk is in CPC Data format, 0 reserved tracks, not bootable. If it's 00-3Fh then the disk may be in a +3 / PCW format - read cylinder 0 head 0 sector 1 and try to decipher it as a disk spec / boot block. If there is a boot block run it, otherwise execute the BASIC command LOAD "DISK". If that failed prompt for a tape.
    – john_e
    Apr 30, 2020 at 13:45
  • 1
    @john_e, why not edit this into my answer above, or create your own answer? This seems to be the most accurate response to the question as asked. Apr 30, 2020 at 18:41
  • 2
    I've put a fuller description of format determination at retrocomputing.stackexchange.com/a/14601/1912 and will answer the bootability question here.
    – john_e
    Apr 30, 2020 at 19:39

You must log in to answer this question.

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