Yes, this is actually a hardware post. I'm thinking about bootloaders. A "small program that places [another program] into memory".

There are bootloaders that are programmed into (EEP)ROM and then use an interface to load the target program. These are often integrated into a Monitor program, but I suppose not always.

Alternatively, there are folks who have a bootloader that's directly connected to the address and data lines of the memory chip (perhaps also directly connected to the CPU data bus lines, with WDC's /BE pin) that write the target program to RAM before resetting the CPU.

Are there generally agreed upon terms for these two "classes" of bootloaders? Would anyone even agree with my classification, or propose a different set of delineations?

_________________
https://github.com/Individual-Solid/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It might be interesting to ask, "What in the definition above excludes a system with a socketed memory chip and a person with a memory device programmer?" (Well, if you take RAM specifically to mean "volatile RAM," there would be that.)

The classification of "self-bootstrapping" versus "external IPL" (just to randomly introduce a couple more terms) seems reasonable, though. At least until one considers the CDP1802 with its built-in DMA controller:

_________________
Curt J. Sampson - github.com/0cjs

I think I might use the term bootloader to mean a short program present at power-on or entered by front panel which has no more functionality than to load something more featureful. I might use the term bootstrap hardware to mean some machinery which runs at power-on to initialise memory with a bootloader.

But as ever with terminology, Postel's law applies: while we might wish to be strict in what we write, we should be flexible and forgiving in what we read.

If we can agree bootstrap is a small piece of code executed at power up or a mechanism to load program for power on execution, then I think there are two major classes of bootstrap and, of course, hybrid of both.
1, ROM-less bootstrap: This is where CPU is held in reset and RAM memory is loaded with program that's executed when reset is released. It is common to have a single-chip modern processor does the loading of program, however, there are also examples of DMA with front panel, serial port, and CF disk.

2, Bootstrap ROM: where a small ROM is used to load larger application. You can find small piece of memory in some real-time clock controllers; CPLD can be programmed with 32-64 bytes of ROM; and it is possible to set up a CF disk such that a sector (256 bytes) of data can be read immediately after power up. This bootstrap ROM then load applications from serial port, CF disk, or SPI devices.

Hybrid, Non-volatile RAM can be loaded with the appropriate software that's executed at power-on, but getting the power-on software into RAM (especially if it is soldered down), require a bootstrap mechanism to load initial program into RAM.

I have designed a number of retro processors with many the above bootstrap schemes. The purpose is to reuse serial, CF, and CPLD for both bootstrap and normal applications. This make possible smaller, faster, and more economical computers.
Bill

Bill, can you provide some links to your designs? I'm not much of a hardware guy, but I enjoy at least the opportunity to expand my horizons.
My favorite set-up would probably be the example of a small "auto-start" ROM mapped in by default at power-up and mapped out after it's done. It looks for a valid boot device signature in the I/O space and passes control when it finds one. If none are there, it can try to map in a larger ROM and punt.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

One advantage of hardware bootstrapping is that it's much faster than doing it in software. You can DMA from ROM to RAM at the fastest rate they support. A few months ago I built an ARM2-based system and used this approach during reset, and it worked beautifully. It was kind of complex, but that was mostly due to the ARM's wide data bus - the same thing for a 6502 would only need a couple of counters and flip flops I think.

The definition of IPL - initial program load - on the host defines it as loading the operating system into memory.

I actually used the term for a hardware bootstrap to load the actual boot loader into memory (via SPI using a CPLD)

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

It's not uncommon to have a multi-stage bootloader. On a system with disk (or solid state storage) the amount of code just to load the first block from the first device can be very small. It might be that the first block only needs to know enough to load something a bit bigger which can in turn understand the filesystem and load the next stage.

Packing a bootloader into a CPLD isn't, I think, something I've yet seen done on any projects I've been associated with, but we've certainly discussed the possibility.

For 65xx family I only have two bootstrap designs. If you are interested in other processors (68000, Z80, Z280), I have more examples. The parenthesis indicates which types of bootstrap scheme: Bootstrap ROM, ROM-less, or Hybrid.
For 65xx:
CRC65 (Bootstrap ROM) has 64 bytes of ROM, serial port, and CF interface in the CPLD. The normal sequence of bootstrapping is 6502 executes CPLD ROM code which initializes CF and load code in CF's master boot record which then loads code from other sectors in CF disk. In case of a blank CF disk, the CPLD ROM can boot from serial port and load utility program to initialize the new CF disk. Because codes are executed out of CPLD, RAM or CF disk, CRC65 is small and quite fast, reliable operation at 29.5MHz and can operate to 33MHz if CF disk is fast enough.

G8PP+6502 (ROM-less) has a battery-backed RAM. Normally 6502 boots from the program on battery-backed RAM; in case RAM is not loaded with program, a jumper selects serial bootstrap mode where 6502 is tri-stated and 255 byte of serial data is DMA into memory then 6502 is released to run.
------------------------------------------------
For processors other than 65xx:

Tiny68K (ROM-less): CPLD holds 68000 in reset and use I2C bus to pre-load 32K program from one of two serial EEPROM into DRAM, then release 68000 to run. The serial EEPROM needs to be programmed offline with a TL866 programmer.

Z280RC (ROM-less): CPLD holds Z280 in reset and initializes CF disk so 256 bytes of data is ready to be read out. Z280 is released and directly executes the 256-byte data streaming out of CF disk (a bit of tricky programming here); it then loads more data from rest of the CF disk.

Z80SBC64 (ROM-less) has battery-backed RAM and 2 modes of perations very similar to G8PP+6502. Normal mode is boot out of the RAM; if RAM is not programmed, it boots out of serial port and load the appropriate program to initialize RAM.

ZRCC (Bootstrap ROM) has 64 bytes of ROM in CPLD and normally boots from CF disk, but when CF disk is blank, it can boot from serial port and load the appropriate program to initialze CF disk.

There are many other designs in my homepage but their bootstrap schemes are similar to the ones I've described.

Bill

Note: packing 32-64 bytes of bootstrap ROM in CPLD is my current favorite scheme. It is counter-intuitive, but 32-64 byes of ROM lookup table takes very little macrocell resources due to the very roubust CPLD logic fabric so most of CPLD resources are still available for other logic designs.

Edit: I changed the "Hybrid" to "ROM-less". On further examination, I don't have example of Hybrid design in the list above.

I should probably clarify. The 6502 boot loader code is not stored in the CPLD but a Flash ROM. The CPLD keeps the 65816 in my case in reset until it has DMA'd the code into RAM. Similar to other approaches already described.

Putting code into the CPLD indeed seems counter intuitive at first. OTOH each output bit is just a logic equation with 8 inputs for a 256 word memory...

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

There's also this scheme:

https://www.ecstaticlyrics.com/electron ... rogrammer/

Here there's no ROM of any description, not even 32 bytes crammed into a PLD. Instead, the Z80 directly executes opcodes sent by a host via an FT240 USB interface chip.

That's neat - executing from a port, and gluing the FT240's flow control into the MPU's WAIT input.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Nicely rediscovered Garth!

Did we already mention this thread?
Bootstrapping an SBC

A search like this (threads with titles matching boot*) might be fruitful.