I once read about an OS that booted before the floppy had fully spun up, and was inspired, only to discover when I tried it myself that at computer speeds, even with the floppy seek to load a kernel from a FAT image, it's actually rather easy.
(to be fair, I think media corruption was more common back then, so boot-time file system checks and other sanity checks may have been what kept mainstream boots slower?)
Loading speed for cassette tapes and floppy disks was measured in bits per second at the time (usually between a few hundred to a few thousand bps), that was just what the hardware could handle, even without expensive error correction ;)
Makes a lot of sense, too. Why would you even want to load data faster than you can read it on screen, or print it out on paper? That's just a waste for such a minor increase in overall speed.
Everything was in ROM: 16k BASIC, 16k operating system, optional 16k disk operating system. The 464 (“646” is a typo) shipped with a cassette deck, not a floppy disk drive, so there was no possibility of loading the OS from volatile storage.
> so there was no possibility of loading the OS from volatile storage.
There are exceptions to this rule: Sharp was known for their concept of "clean computers" (MZ series and X1), which came only with a simple monitor in ROM, while at the same time featuring just a cassette drive to load a BASIC interpreter (of which there were several flavors) from.
DDI-1. It was a package including the disk interface (with AMSDOS in ROM and CP/M 2.2 partly in ROM) plus the drive itself. The FDD-1 was an optional second drive but you had to have the DDI-1 first.
Wow, I had no idea! There might be a 664 in box in my parent's house somewhere -- although it also might have been discarded some time in the last 20 years (as I imagine happened to many of them).
More like less than a second after power-up to reach full usefulness at the command line.
These type computers did not need to actually boot their OS from a "peripheral" storage device.
They did not "boot" at all, they just ran the built-in OS/BASIC straight from where it was contained on ROM.
This was like the C64 which had its BASIC in internal ROM too.
With the early Atari's the internal ROM was more like a skeletal BIOS which ran whichever ROM cartridge you had in the game slot, whether it was a commercial game or not. And the Atari BASIC command line was only available if you had the BASIC cartridge inserted where a game would otherwise be.
...that's pretty much what "booting" means though. Even on those hardwired machines with operating system and BASIC interpreter in ROM, the hardware still needs to be brought into a defined state (IO, timer, audio and video chips need to be initialized, interrupts need to be setup, the operating system needs to initialize portions of RAM used for keeping variable state, also checking what peripheral devices and hardware modules are connected and initializing those, and so on and on...).
on the Amstrad computers, and that's the context, BASIC was an interpreter on top of AMSDOS, which is a DOS, and an OS (just without any UI) indeed.
It's AMSDOS that provided hardware and disk handling, while BASIC could focus on running BASIC code. I think even the graphics routines (like setting a pixel) may have been implemented in AMSDOS, but not sure - and the line between two is blurry from user perspective. While those are two ROMs by two companies, they were developed in cooperation.
> I think even the graphics routines (like setting a pixel) may have been implemented in AMSDOS
Since I just have the CPC Intern book lying around on my desk :)
The graphics routines were not part of AMSDOS, but of the GRA ROM pack (the CPC OS was modularized into "packs" each coming with a standardized interface jump table: Kernel (KL), Machine Pack (MP), Jump/Restore (JRE), Screen Pack (SCR), Text Screen (TXT), Graphics Screen (GRA), Keyboard Manager (KM), Sound Manager (SOUND), Cassette Manager (CAS), Screen Editor (EDIT).
The book doesn't tell much about the AMSDOS ROM, only that the 16 KByte ROM is split into 8 KByte for the actual AMSDOS, and the other 8 KByte are used for a part of the LOGO interpreter coming with CP/M 2.2
PS: also important to note that not all CPC models came with the AMSDOS ROM or builtin floppy drive, so the actual operating system and BASIC interpreter couldn't be built on top of AMSDOS.
> PS: also important to note that not all CPC models came with the AMSDOS ROM or builtin floppy drive, so the actual operating system and
Right, technically correct! On the other hand, the command to return to BASIC from CP/M was "AMSDOS" - the distinction to be seen by the user was to be AMSDOS vs CP/M as two operating systems.
As it was understood with 1980's microprocessor desktops, booting was a more complex stepwise startup procedure than simply running the fully-functional factory OS or video game instantly from ROM.
Booting required a storage medium other than memory (such as punch cards, paper tape, magnetic tape, disks) to peripherally store the actual OS or shell which had to be loaded into memory in a "bootstrapping" process before it could run. RAM was used for the working OS rather than ROM, so process control was "booted" to RAM right after the ROM code merely establishes a hardware interface and serves as an Initial Program Loader.
Nobody ever talked about "booting" a C64 or Atari400 if all you were going to run was the factory BASIC command line.
Which was the vast majority of non-gaming use. Far fewer users had external storage to begin with and almost all of them used it only for storing & loading their own code or non-ROM game files [0].
Only the uncommonly advanced operators (not me) were actually using their external storage to "boot" to a different OS or programming language, but it was necessary if you were going to use something like Pascal [1]:
"Kyan PASCAL consists of two programs: the editor program (ED) and the compiler/assembler program (PC). When your Apple (ATARI) is booted (to boot the ATARI, push the <OPTION> key during power-up) with a KyanPASCAL disk in the drive the following will be displayed:
KYANPASCAL VERSION 1.0 COPYRIGHT
1985 BY KYANSOFTWARE
1850 UNION STREET, SUITE 183
SAN FRANCISCO, CA 94123
>"
IOW when you didn't push the <OPTION> key during power up (which very few users ever pushed) you weren't booting the Atari, but merely powering up and running the game or command line directly from ROM.
It was not like an x86 PC which used its ROM firmware mainly as an Initial Program Loader, otherwise known as a bootloader, to load your desired OS from storage into RAM, giving you access to a correspronding command line the booting way. If you weren't going to run something like a Disk Operating System why would you want to boot anyway?
It may be obvious but I really did like it with computers that you didn't need to boot.
Sorry if I hurt anyone's feelings.
[0] so BASIC was dabbled in more often and widely as a "game" similar to the regular game cartridges, where they had to start from the beginning each time you turned on the computer, and all progress was lost when you powered down.
(to be fair, I think media corruption was more common back then, so boot-time file system checks and other sanity checks may have been what kept mainstream boots slower?)