3

I can find enough mentions of bootable disks for TRS-80 Model I and Model III to be confident that they could boot from disk, but so far I'm failing to find much info on how that worked.

  • In particular, where on the disk is the boot track/sector/block? Is it in the same place on Model I and III?
  • Does the boot sector have any format or is it just read directly into memory and executed?
  • Into which memory address range is it loaded, and from which address does execution begin?

One thing that I am finding is that the boot block must, on at least some types of setup, be on single-density tracks, and that this is the case even when the rest of the disk is formatted double-density. It seems this is unusual and causes problems when trying to use TRS-80 floppies in other computers' drives.

1

After Googling this for an hour or two and not finding much, I have found something solid just minutes after posting my question!

From page 40 of TRS8BIT volume 09 issue 02 from June 2015 there is an article on a "FreHD Expansion Interface" which includes this paragraph:

If a WDC1771 Disc Controller is found then the LII ROM programs the chip to retrieve the first 256 Bytes from Physical Drive 0, Track 0, Sector 0, i.e. the Boot Block, this is executed and LDOS, TRSDOS, NEWDOS etc. continue to boot

The information missing is where the code is loaded and executed. I suppose it could be position-independent code. I think that was possible on the Z80 if you restricted which instructions/addressing modes you used.

It's also possible this is not the full story and might only apply to the Model I.


Update: Using the above info, I looked at some JV1 format disk images and several contain identical bytes for this area except some at the end, presumably junk after the code. But the first three bytes do not seem to be code. Code seems to start at offset 0003h with a DI instruction to disable interrupts. Before this, all the ones I've looked at have 00 FE 11 which could be some sort of header or magic signature?


Update 2: Apparently the various DOSes in use on TRS-80s were only somewhat mutually compatible. Some used the byte at offset 0002h to declare the track used for the directory, usually track 17 or 11h, but not always. Either the initial NOP or it together with the following FE compare instruction are referred to as a "recognition code", which seems to mean the same as "signature" or "magic word", but the ROMs did not seem to verify this. It must be used by some of the DOSes for some purposes, but not at power-on boot time.

... and here it is stated more clearly in this disassembly I just found, originally from the HACKER'S HANDBOOK FOR NEWDOS/80, page 42:

; Addr.  Code         Instruction           Function
  4200H  00           NOP                ; No operation
  4201H  FE 11        CP   11H           ; Recognition Code + 17 = Dir Sector
  4203H  F3           DI                 ; Disable Interrupts
| improve this answer | |
  • 2
    According to the model I ROM disassembly at trs80.nl/software/model1hddboot the boot block is copied to hex address 4200. – ninjalj May 29 at 13:40
  • Interesting! I had that page loaded into a tab but I'm a very slow reader and hadn't got to it yet. I see the disk images I have all start with 00 FE 11 which produces the seemingly meaningless code NOP; CP 11h before disabling the interrupts with a meaningful DI. The compare looks useless since the accumulator doesn't appear to have any useful value and even if it does, the flags don't seem to be checked for any result. Those bytes could be dual-purpose. Acting as a signature, magic word, or version as well as being harmlessly executable. – hippietrail May 29 at 14:08
  • 1
    And apparently 4300 for model III: trs-80.com/wordpress/dos-newdos80/manual-6/#chapter10 During a reset/power-on, the ROM’s bootstrap routine receives computer control from the hardware reset logic and reads the first sector of the diskette mounted in drive 0 into the DOS system buffer (4200H -42FFH on the model I and 4300H – 43FFH on the model III). – ninjalj May 29 at 14:10
  • @ninjalj: Is there any kind of verification to prevent executing garbage or even an unformatted sector? Such as a checksum or magic word? – hippietrail May 29 at 14:20
  • 1
    The disassembly for model I doesn't have any such check, it just copies the 256 byte block to 4200 and jumps there. – ninjalj May 29 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.