As a electronics engineer - I believe it would be entirelyy possible to start a computer or microprocessor from nothing, no boot rom or nothing. Would need RAM
How?
Sequence would be
Power on switch - turn ON.
Pause/halt computer to ON - ( ie computer is now not operating instructions but when pause/halt switch is reverted it will start to ....)
Now use hard ware to directly write data to a nominated memory address.
This hardware could be permanently included in computer circuitry or temporarily connected.
This hardware would have entry switches ( could be simple switches( on switch for each binary bit ) OR BCD encoded ( rotary? switch ) to enter the memory address and data.
The person entering the program would need to be familiar of the memory map of the computer / processor.
Ie it may need certain (interrupt/reset/restart) vectors , start addresses set correctly
Person would enter address and data and then press a switch that would cause the data to be written to the address nominated by switches.
Would be laborious to enter the needed few hundred bytes but would be possible.
Could be other included switches to make this memory write protected etc ...
A summary of the above would be "...use abank of physical switches to directly input binary data to memory " while the computer is halted.
Back in the "old days" the 80's ... we would get a static RAM chip (6116) put a battery on top of the chip along with a bit of circuitry to make "battery backed" could use the physical switch method to load a program into such a setup and then plug this RAM into computer, would need to be a right location in memory map for it to work...
From Google - describes such a circuit / mod from Elektor magazine ...
"An Elektor article from June 1985 describes a plugin circuit for using two battery-backed 6116 RAM chips as a replacement for a 2732 EPROM. This circuit uses a 2-bit binary decoder to select the correct 6116 RAM chip, ensuring proper operation and data retention via a battery backup, a key feature of the low-power "LA" version of the 6116 chip. ..."
I wasn't planning to use the front panel extensively because, as mentioned in the video, front-panel booting is not a practical way to start a computer.
The next step up is to use a hex keypad to enter 16 bits at a time. Some single board computers from the 1970's provided this. It was marginally practical - I used to enter programs of a couple of hundred bytes into a KIM-1 this way, it only took a few minutes.
Those computers did provide a simple monitor in ROM to support this, but that code was very small - Steve Wozniak's Wozmon monitor for the Apple I was 256 bytes. You could probably design some circuitry not much more complicated than
in this article to replace its row of switches with a keypad.
I've seen a lot of hand-waving explanations of how boot-strapping happens (and granted it is very implementation-specific) but this is delightfully complete without veering off into the rough.
Interface schematic
Architecture reference AND AVR Binary output reference for programming
Achievable
Fun!
I kind of wonder if the designers of the Atmega8 series had this in mind when they designed the parallel interface. I always wondered if there were any modern devices left other than say, EPROM where programming by hand was still possible. The fact that you can do this means you could use an Atmega8 to bootstrap a larger computer that was dependent on a serial interface. Always thought it would be interesting to see someone program a desktop “from nothing” starting with just hardware and no software (other than boot ROMs and firmware) and end up with a usable OS like that UEFI FORTH implementation.
I'm fairly certain that any simple MCU with static clock (ie: supports 0.01 Hz clock, or 100seconds per clock and slower) will suffice as a human level bootstrap.
ATmega8 happens to satisfy those requirements. It's also not too hard to program microcontrollers that would support human level inputs.
In practice, the bootstrap device will be like a Windows7 laptop we've got squirreled away somewhere. It's probably cheaper to buy up a ton of used / old laptops that are sufficient for bootstrapping rather than trying to build methodologies that bootstrap from scratch.
The main problem seems to be that the only way the BIOS can boot an OS is a mass storage device with executable code in the boot sector, in contrast to older computers that had some sort of monitor/debugger in their ROM. I haven't researched disk drive interfaces, but trying to hook up a floppy drive to some toggle switches so I could write a boot disk would be my first step. But then modern motherboards don't have floppy drive controllers ¯\_(ツ)_/¯
Of course you can also try to reprogram the BIOS ROM on the motherboard, but you're likely to need a full OS to first reverse engineer it enough to know where to stick your debugger code.
I think the broad idea isn't to directly, for example, program a floppy disk drive (to boot a PC from BIOS) driver from such a front panel (a gargantuan task), but to gradually bootstrap your way up there.
For example, you could build yourself a makeshift hex keyboard and load a driver for that keyboard onto an ATmega. Good! from that point on, you can enter bytes faster.
Then, you hook a few seg7 together to have some kind of display. Even better!
Finally, a programing job that AI won't be able to replace.
We had devices like those in university, left from previous generations where they'd manually program Z80s ROM by hand through switches and see the output on LEDs.
Then programing(not the correct term) CPLDs via obscure programming languages and some MS-DOS tool via the parallel port.
Looks down for me. https://web.archive.org/web/20251024110521/https://www.linus...
the video from that page: https://www.youtube.com/watch?v=S-2adBkW7Xo
As a electronics engineer - I believe it would be entirelyy possible to start a computer or microprocessor from nothing, no boot rom or nothing. Would need RAM
How? Sequence would be Power on switch - turn ON. Pause/halt computer to ON - ( ie computer is now not operating instructions but when pause/halt switch is reverted it will start to ....)
Now use hard ware to directly write data to a nominated memory address. This hardware could be permanently included in computer circuitry or temporarily connected.
This hardware would have entry switches ( could be simple switches( on switch for each binary bit ) OR BCD encoded ( rotary? switch ) to enter the memory address and data.
The person entering the program would need to be familiar of the memory map of the computer / processor. Ie it may need certain (interrupt/reset/restart) vectors , start addresses set correctly
Person would enter address and data and then press a switch that would cause the data to be written to the address nominated by switches.
Would be laborious to enter the needed few hundred bytes but would be possible.
Could be other included switches to make this memory write protected etc ...
Sorry if the above is a bit confusing .....
A summary of the above would be "...use abank of physical switches to directly input binary data to memory " while the computer is halted.
Back in the "old days" the 80's ... we would get a static RAM chip (6116) put a battery on top of the chip along with a bit of circuitry to make "battery backed" could use the physical switch method to load a program into such a setup and then plug this RAM into computer, would need to be a right location in memory map for it to work...
From Google - describes such a circuit / mod from Elektor magazine ...
"An Elektor article from June 1985 describes a plugin circuit for using two battery-backed 6116 RAM chips as a replacement for a 2732 EPROM. This circuit uses a 2-bit binary decoder to select the correct 6116 RAM chip, ensuring proper operation and data retention via a battery backup, a key feature of the low-power "LA" version of the 6116 chip. ..."
I wasn't planning to use the front panel extensively because, as mentioned in the video, front-panel booting is not a practical way to start a computer.
The next step up is to use a hex keypad to enter 16 bits at a time. Some single board computers from the 1970's provided this. It was marginally practical - I used to enter programs of a couple of hundred bytes into a KIM-1 this way, it only took a few minutes.
Those computers did provide a simple monitor in ROM to support this, but that code was very small - Steve Wozniak's Wozmon monitor for the Apple I was 256 bytes. You could probably design some circuitry not much more complicated than in this article to replace its row of switches with a keypad.
This is the way.
I've seen a lot of hand-waving explanations of how boot-strapping happens (and granted it is very implementation-specific) but this is delightfully complete without veering off into the rough.
I kind of wonder if the designers of the Atmega8 series had this in mind when they designed the parallel interface. I always wondered if there were any modern devices left other than say, EPROM where programming by hand was still possible. The fact that you can do this means you could use an Atmega8 to bootstrap a larger computer that was dependent on a serial interface. Always thought it would be interesting to see someone program a desktop “from nothing” starting with just hardware and no software (other than boot ROMs and firmware) and end up with a usable OS like that UEFI FORTH implementation.
I'm fairly certain that any simple MCU with static clock (ie: supports 0.01 Hz clock, or 100seconds per clock and slower) will suffice as a human level bootstrap.
ATmega8 happens to satisfy those requirements. It's also not too hard to program microcontrollers that would support human level inputs.
In practice, the bootstrap device will be like a Windows7 laptop we've got squirreled away somewhere. It's probably cheaper to buy up a ton of used / old laptops that are sufficient for bootstrapping rather than trying to build methodologies that bootstrap from scratch.
The main problem seems to be that the only way the BIOS can boot an OS is a mass storage device with executable code in the boot sector, in contrast to older computers that had some sort of monitor/debugger in their ROM. I haven't researched disk drive interfaces, but trying to hook up a floppy drive to some toggle switches so I could write a boot disk would be my first step. But then modern motherboards don't have floppy drive controllers ¯\_(ツ)_/¯
Of course you can also try to reprogram the BIOS ROM on the motherboard, but you're likely to need a full OS to first reverse engineer it enough to know where to stick your debugger code.
I think the broad idea isn't to directly, for example, program a floppy disk drive (to boot a PC from BIOS) driver from such a front panel (a gargantuan task), but to gradually bootstrap your way up there.
For example, you could build yourself a makeshift hex keyboard and load a driver for that keyboard onto an ATmega. Good! from that point on, you can enter bytes faster.
Then, you hook a few seg7 together to have some kind of display. Even better!
... and so on, until you can drive that FDD.
Or emulate one. Yeah, right.
Finally, a programing job that AI won't be able to replace.
We had devices like those in university, left from previous generations where they'd manually program Z80s ROM by hand through switches and see the output on LEDs.
Then programing(not the correct term) CPLDs via obscure programming languages and some MS-DOS tool via the parallel port.
> Finally, a programing job that AI won't be able to replace.
Well, at the recent VCF (vintage computer festival) Midwest they showed a robot using the Altair's front panel to toggle in a game:
https://techav.net/post/796938975198707712