• Please review our updated Terms and Rules here

Booting from CF drive, has this being done before?

P

Plasmo

Experienced Member
Joined
Aug 29, 2017
Messages
217
Location
New Mexico, USA
I am developing a SBC based on the Z280 operating in the 16-bit Z-BUS mode. To save the cost of two boot ROM and to simplify the process of reprogramming the boot software, I have an unusual way of booting up the Z280 via CF drive:

At power up or reset, a state machine in CPLD holds Z280 in reset and initializes the CF drive such that the boot sector (track 0, sector 1) is read into the 512-byte FIFO of the CF data register. The state machine also temporarily maps Z280 memory location 0x0-0x1FF to the CF data register. The state machine then releases the Z280 reset and gets out of the way. Z280 begins program execution at 0x0, fetching instructions from the 512-byte FIFO. Because instructions are destroyed with every FIFO read, the 512-byte instruction stream has no looping instructions. Instead, it creates a small program in memory, one opcode at a time, and jumps to the newly created program before the FIFO runs out of instructions. The small program in the memory is a simple CF loader that loads the full-size monitor program from CF and execute.

My question is this: I'm struggling with a clear description of this CF booting process, I don't know whether the above description makes sense to the readers or not. It is also likely such boot method has been done already and I can save myself all kind of explanation by just referring to it. Has booting from CF being done before? What is the name for such booting method?
 
The technique of force-feeding a boot program to a CPU is very old.

I don't know the name of it, but look at the PP boot sequence for the CDC 6600. On system start, all PPs are set to an input instruction (not actually in memory; just simulated) on their corresponding channels--and the P-counter of every PP is set to 0000. The small program on the deadstart panel feeds into channel 0 a word at a time, then releases channel 0, causing PP0 to begin execution at location 0. It then reads from tape (usually) and passes start programs to other PPs on their associated channel.

I suspect that many other old mainframes used a similar scheme; usually via a LOAD or IPL button. Automatically selects some I/O device and sucks the first record into low memory.

Personally, I'd just run the CPU out of a bit of flash memory--it would seem to be simpler in execution.
 
I don't know anything about CDC6600 (other than the university I went to in the 1970's had one), but the "small program on the deadstart panel" suggests it couldn't auto-start from mass storage devices, do I understand it correctly? Perhaps the old mainframes that started with a LOAD/IPL button also had the startup program stored in ROM somewhere?

I'm looking for an example of ROM-less computer that can autostart out of mass storage devices. Perhaps it is not as common as I've thought. It should, think of the cost saving and the flexibility of booting up to whatever OS that's in the CF disk.
 
I've been playing with DiskOnChip lately, and the DiskOnChip does have boot capability. Commonly this is implemented as a BIOS extension, which would presume the existence of a BIOS ROM. However, the documentation leads me to believe that you could write your own boot code and place it in the DiskOnChip's boot block. I was toying with the idea of trying to do this on a Z80.
 
Plasmo said:
I don't know anything about CDC6600 (other than the university I went to in the 1970's had one), but the "small program on the deadstart panel" suggests it couldn't auto-start from mass storage devices, do I understand it correctly? Perhaps the old mainframes that started with a LOAD/IPL button also had the startup program stored in ROM somewhere?

I'm looking for an example of ROM-less computer that can autostart out of mass storage devices. Perhaps it is not as common as I've thought. It should, think of the cost saving and the flexibility of booting up to whatever OS that's in the CF disk.
Click to expand...

What's the difference? An IDE device is not exactly a dumb device--the fact that it will read a sector into a buffer automatically says that there's ROM somewhere doing this. If you want to demonstrate a ROM-less example, then try doing it from a floppy disk with a "dumb" controller.

Let's take a simpler (and earlier) example. Push the "LOAD" button on an IBM 1620. The console typewriter (or card reader) enters data into low memory and the system jumps to it when either the RELEASE key is pressed or the first card is read. No program ROM at all. Many other systems worked this way.
 
Last edited:
It is the state machine in the CPLD that sequences through a series of commands to the CF to put boot sector data into the 512-byte data reg FIFO. I don't know enough about the floppy disk controllers to know whether there are an equivalent set of commands to pull data out of the floppy into controller's memory.

I have delivered a Z280 SBC prototype and is in the middle of writing user's manual describing its features. I was hoping there are well-known examples of such booting method to help me with the explanations. If not, I'll just have to work harder. This short conversation is already helpful.
 
Some/most/all Alpha CPUs bootstraped themselves by reading a serial bit stream into their Icache, then having the CPU start execution at address zero, which was then resident in the cache. The data cache could then be initialized and the remainder of the memory subsystem configured and initialized to access other ROM resident code to continue the boot process. That first ROM contained up to eight separate bit streams that could be selected by a jumper, and at least one of them was capable of picking up the second stage ROM from a floppy.
 
Chuck(G) said:
Why not a small MCU to wiggle the bus lines and preload memory before the Z80 goes off of reset?
Click to expand...

That seems to add complexity and part count. The existing design has 5 active components, 24MHz oscillator, Z280, 4-meg SIMM memory, CF disk, and Altera EPM7128 CPLD. The recent discussion on using a microcontroller as the I/O processor is interesting, but the design is more complex and the component count is greater than 5.


cruff said:
Some/most/all Alpha CPUs bootstraped themselves by reading a serial bit stream into their Icache, then having the CPU start execution at address zero, which was then resident in the cache. The data cache could then be initialized and the remainder of the memory subsystem configured and initialized to access other ROM resident code to continue the boot process. That first ROM contained up to eight separate bit streams that could be selected by a jumper, and at least one of them was capable of picking up the second stage ROM from a floppy.
Click to expand...

The Tiny68K design uses the serial EEPROM as boot ROM. It works well, but the CPLD (the same Altera EPM7128) is more complex. It was close to 100% utilized. I prefer the simpler CF boot scheme which also eliminates the serial EEPROM, but I couldn't figure out the chicken-and-egg problem of how to create the first bootable CF disk. The Z280 has an UART bootstrap feature that allow the processor to boot off its serial port. I use that feature to boot up a board with new CF disk, transfer the CF bootstrap codes and then boot off the CF afterward.
 
What are you using for console I/O?

Can your CPLD hold the Z80 off the data bus? The Z80 could execute NOPs while the CF fed data and asserted MEMW. Reset again, while enabling the Z80 data bus and you're booted--no restrictions on instructions.

The old Tarbell floppy controller used a 32-byte bipolar PROM to feed instructions to the CPU while allowing the writes to pass through to memory.
 
Console I/O is 57600 baud, odd parity, 8-bit, 1 stop, no handshake.

Yes, I can hold Z280 in reset. Z280 bus are shared by DRAM and CF, so I cannot feed Z280 NOP while transfer data from CF to DRAM, but I can hold Z280 in reset while transfer data from CF to DRAM. It is quite a bit more complicated because of the DRAM address generation and multiplexed RAS & CAS addresses. The state machine to initialize the CF to put boot sector data into data register FIFO is pretty simple, about a dozen flip flops. To transfer data to DRAM and associated address generation and muxing will probably double the number of flip flops required. Now the CPLD logic resources will be tight. It is preferable for the software to do the data transfer, even though the code is pretty cryptic.
 
Chuck(G) said:
What are you using for console I/O?
Click to expand...

While plasmo answered the question, I think you're after another detail. The Z280 has a built-in UART channel, and that's what's being used for the console. The Z280 is rather different from the Z80 in several areas.

Plasmo's technique here I think is just plain elegant. The CPLD's state machine sets up the sector transfer on the CF, and then, after releasing RESET and doing the WAIT dance you have to do with a Z280, the CPLD maps the first 256 bytes of memory to the CF data register. So the Z280 is actually executing out of the CF buffer. This, as Plasmo notes in his reply, puts some pretty unique constraints on the code in the boot sector (no branching of any kind can be done), but he made it work. He wrote up the technique on the retrobrewcomputers.org site at: https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:tinyz280:cfboot_operation

Can your CPLD hold the Z80 off the data bus? The Z80 could execute NOPs while the CF fed data and asserted MEMW. Reset again, while enabling the Z80 data bus and you're booted--no restrictions on instructions.
Click to expand...
The CPLD may not have enough resources to do this, but since there is a Z280 sitting right there that can easily do it, why not use it.... it's a design tradeoff: complexity in the CPLD versus complexity in the short cold boot generator code. The cold boot generator gets used once and then goes away; if the data read logic was in the CPLD then it's there all of the time, even when not needed. IMHO, a misuse of valuable CPLD resources.

But, again, this is a Z280 we're talking about here, not a Z80.
 
Last edited:
Thanks! When someone else said it, it doesn't sound that crazy complicated after all. I tried the concept first on a version of Tiny68K. The bootstrap code is even more weird because of 68000's prefetch (undocumented) operations.
 
My IMSAI has a similar bootstrap from floppy. On reset, the disk controller reads the first sector into RAM( 125 bytes ). I have the address switches set to 0 and then hit RUN. It then bootstraps itself by loading some more code that brings in the rest of CP/M. The system itself has no system ROM, 100% RAM. There is a state machine on in the controller that runs the floppy. It has 4 small 4x32 fuse ROMs that run the state engine, like a bitslice with not ALU. The controller was actually one of the first controllers available for the Altair and IMSAI. Most all the other controllers depended on the disk controller have some boot ROM in the system code space.
On my NC4000 machine, I have a flop that maps the ROM into memory with the RAM as a shadow write. The boot code then just reads itself and then writes back to the same address. When it hits the last address of the ROM, it toggles the reset flop and it's running from the RAM with no ROM visible to the processor. Almost no circuitry to do this. A 7474 and it uses the normal address decoder that is already there for the RAM. I think there are one or two gates.
Dwight
 
Yup, the early Tarbell controller did this with a bipolar ROM, all 32 bytes of it. It's almost no logic--and 32 bytes is enough to get the first floppy sector read into memory.

The Amstrad Joyce uses the printer controller to force a bootstrap onto the Z80 bus, IIRC.
 
Chuck(G) said:
Yup, the early Tarbell controller did this with a bipolar ROM, all 32 bytes of it. It's almost no logic--and 32 bytes is enough to get the first floppy sector read into memory.

The Amstrad Joyce uses the printer controller to force a bootstrap onto the Z80 bus, IIRC.
Click to expand...

It was such a cool way to do it, I wonder why they didn't make chips that would do it. My controller runs on just 4 program bits wide. I'd have though it could have been easily done in a 40 pin part. It couldn't have been much more complex then what was done.
Dwight
 
I don't know about floppy disk controllers, but the logic to initialize CF disk to read the boot sector is pretty simple, basically 2 4-bit counters, some hold registers and logic gates. Having to go back to IMSAI era to find an example of booting off disk sector is surprising. Beside saving two ROM chips, the process of updating the boot software is really easy and quick. With this approach, I don't think of boot software as a part of hardware; it can be reconfigured so easily that it is just the first stage of a specific application.
 
You must log in or register to reply here.
Back
Top