• Please review our updated Terms and Rules here

Boot time floppy initialisation required if booting from HDD?

JonB

JonB

Veteran Member
Joined
Jan 26, 2014
Messages
1,652
Location
South Herefordshire, UK
So.. hello all, I return with another odd question.

There's a weird thing going on with my Superbrain when booting from uIDE. Drive A: occasionally spins up (I have implemented the motor control mod) and doesn't stop until a disk is inserted and the door closed. I put it down to a glitch of some sort. It doesn't happen on the Superbrain II.

Fast forward a few years and I've got the machine out of storage after moving house last year. After repairing a shorted tanatalum cap - grrrr, poxy things - I'm playing with it and there's this random spin up happening. Thing is, it doesn't seem to happen when the machine is booted from a floppy drive - so it is, logically, my boot code or a hardware issue. I figure that, if the latter, it'd happen all the time irrespective of boot device. So, I'm left to ponder the former. So, what happens differently when you boot off floppy vs uIDE? Well, mainly the floppy boot routine doesn't get called. Could this imply the FDC is in some sort of unitialised state? It works as normal under CP/M when booted from uIDE...

I'm just looking at the floppy boot code. It's doing a homedisk (seek to track 0) prior to tring to boot; if this fails it prints the "Insert disk in drive A:" error. I'm wondering if this sets up the FDC in some way and me not doing it when booting uIDE could be the issue. Bear in mind the FDC boot code is legacy, I didn't write it and I don't fully follow it. But, is this line of thinking reasonable or am I just guessing? The SB has a 1791 FDC - does this have an "uninitiated" state when powered up? Any other thoughts?
 
I don't know anything about the superbrain, but I would think the issue, if in CP/M, is probably in the BIOS implementation. Have you examined the signals to the drive itself? I would think that unless a command is sent via the CCP, that there is little likelihood that anything is driving the disk itself under CP/M. There are plenty of reasons why the A drive should be accessed on booting, since all kinds of things are going on at boot time, but perhaps an I/O pin is left in a state where it assumes an activity will occur, then drops out from there and doesn't reset the pin.

I've read somewhere that the superbrain has it's own z80 as a disk controller, so I assume that it could run independently of the OS in any event and wait on signals from the drive, and act on them, but that would have nothing to do with the OS per-se. Are you examining the disk operation via the disk controller or via the operating system?

It should be possible to trap I/O to the disk controller with a logic analyzer though which at lease will tell you what the OS is doing.

Kind Regards
David
 
I don't know the SuperBrain either, but typically (often maybe) the boot ROM does the minimal in order to load the OS off the target drive. I also have to wonder if uIDE was original or was added later. Either way, on systems that have multiple storage controllers it is not unusual for the BIOS to have to (re-)initialize everything because it can't tell where it booted from so can't assume anything has been initialized already.
 
uIDE was designed and implemented by me, with help from Grant Searle's CP/M SBC source. I reverse engineered the BIOS and extended the boot ROM (which includes the FDD CPU code; original disassembly by Warren Gay in 1991). I've always suspected some sort of hardware glitch as the issue doesn't occur on my SB II (also with uIDE). However, in testing this morning, both A: and B: floppy drives seem to have stopped working - really that means "will not read data" as the drives are spinning up - so perhaps I ought to fix that first.. Moreover, my SB II has the long beeeeeeeeeeeeeep of death so it needs attention as well.

Not sure I agree with your comment about the system not knowing its boot source. On my implementation, uIDE boot knows what it is and where it came from. Floppy boot does not have access to the uIDE drives as it is the usual Intertec boot code - so you can argue it knows where it came from too. In both instances, you are booting from a specific device and the boot code and BIOS / BDOS are different. For example, uIDE boots from track 0/1 of the IDE device, and logs drive C: (first partition) on startup, so CCP begins with a C> prompt. Warm boots also come from IDE tracks 0/1. Whereas, the Intertec boot is from drive 0 and you get a more usual A> prompt at the CCP. The uIDE booted system has access to the floppy drives by the way, as A: and B.

My question was more a sort of general CP/M question, rather than aimed at the SB in particular.
 
JonB said:
...

Not sure I agree with your comment about the system not knowing its boot source. On my implementation, uIDE boot knows what it is and where it came from. Floppy boot does not have access to the uIDE drives as it is the usual Intertec boot code - so you can argue it knows where it came from too. In both instances, you are booting from a specific device and the boot code and BIOS / BDOS are different. For example, uIDE boots from track 0/1 of the IDE device, and logs drive C: (first partition) on startup, so CCP begins with a C> prompt. Warm boots also come from IDE tracks 0/1. Whereas, the Intertec boot is from drive 0 and you get a more usual A> prompt at the CCP. The uIDE booted system has access to the floppy drives by the way, as A: and B.

My question was more a sort of general CP/M question, rather than aimed at the SB in particular.
Click to expand...
I was not suggesting any "right way", simply relaying what I've seen in other systems. Heathkit H8/H89 systems do provide an indication of what the boot device was, while Kaypro does not (just to give two examples). But generally it is up to the BIOS to ensure that ALL hardware is initialized, based on any knowledge it can glean from the ROM boot or other sources.
 
Last edited:
On the old systems, it wasn't unusual to have a floppy-only boot, after which the driver code for the hard disk gets loaded. I've got two such from the 70s. Hard disks before 1980 could double the price of a system.
 
All fair points. @Chuck(G) I'd think this is likely down to being after market addons, as the price of HDDs came down. I implemented uIDE for the Amstrad PCW first, and, due to the way it boots, it's floppy only boot. I couldn't figure out how to get it booting from the IDE device, although others have managed it. The boot code for that machine resides on the printer driver IC, not in a separate ROM, so it's tricky to intercept. Also, my first IDE driver implementation for CP/M (XDRIVER for the TRS-80 Model II with Lifeboat CP/M), which uses a LoTech TRS-80 Model IV IDE card, only boots from floppy. Then, post boot you run a program to patch the BIOS and load up the driver. It relies on the user making space for the drivers with MOVCPM beforehand. Heh, I should probably revisit that one, as the machine has a proper boot ROM which could be patched... if there is enough space!

Anyway.. with the experience I gained with these three implementations, I can say that it's much easier to have floppy boot, then run an installer to "activate" the hard drive than to have to reverse engineer the BIOS and boot ROM for a proper solution.
 
Anyone have a price list circa-1978 for adding a hard disk (14") to an Intel MDS-800? I recall that it wasn't inexpensive.
In our case, adding a hard disk to the F85 involved adding another small backplane (3 slot) as well as associated cabling and connectors. Back then, the hard disk was an SA-4000 series, not exactly what one would call a desktop drive. This was eventually replaced by a 5.25" drive that replaced one of the floppies. The second backplane was still necessary, however.
 
You must log in or register to reply here.
Back
Top