It's neat to see how people have been able to collect and save all sorts of information about older chipsets which makes projects like this possible.
I've often wondered about how to re-solve certain problems now that we have decades of hindsight. For instance, your BIOS doesn't boot from CDs or from large disks. So what do we do? We make a disk image (vnd on BSD and whatever the equivalent on Linux make this so easy) and install an old fashioned BIOS boot block. We have a small 40 megabyte or so FAT-16 filesystem (FAT-32 wasn't a thing until 1996), on which we have a kernel, such as NetBSD because NetBSD can still run on 486 systems without fuss.
The kernel, once loaded, knows how to access large disks, CDs, or even mount a filesystem over NFS. We then use that system to disklabel / fdisk the rest of the disk, format an FFS filesystem and swap, and install our OS. Simple, right?
But how do we get this image on to an 80486 system? We really shouldn't lose to history the kinds of tools that let us boot from floppy. NetBSD still can, even though it takes something like six of them.
Since the i80486 has no management engine, running an open source BIOS would make it fully, 100% open. Interesting... Will my next email server be an i80486 system? It's worth considering.
Goodness, this is cool! Do you have experience with this FPGA/toolchain? How long does it typically take to render something from Verilog to bitstream? E.g. a hello world adder v/s a risc v cpu?
I do! I’ve played around with it with this exact setup. It really depends on your processor, these toolchains really love a good mix of both high frequency and multi core. A hello world adder is less than a minute, a riscv core much much longer. A 16 core zen4/zen5 can compile the riscv core and linux in roughly 20 minutes? Compared to about an hour on a M1 Max macbook pro - It’s been awhile so I could be misremembering.
TLS on a 33 MHz m68030 is passable. Since the i80486 should be closer in performance to the m68040, negotiation could take place inside of the timeout that many servers would have. In some ways it would be a good rate limiter since you'd likely only want to allow a single connection at a time.
Looking at the sizes and structure of the source alone, it is obvious that Coreboot is a product of the post-HLL average developoor, while in the 486 era BIOSes were exclusively written in very carefully optimised Asm. One naturally wonders what the latter could fit in the space of today's multiple-megabyte flash ROMs.
> while in the 486 era BIOSes were exclusively written in very carefully optimised Asm
Nope; the change happened in the 386 era; by the 486 era most BIOSes would be (partially/mostly) written in a pretty uncarefully written "HLL". Even before I would argue against the "carefully optimized" ASM.
They were written in Asm up into the 2000s; at least AMI and Award were. Despite a lot of macro use, there was certainly an emphasis on keeping things as small as possible.
Contrast that with just shoving compiler output into the ROM image.
They had _some_ asm (you just can't avoid it), plus whatever historical crap they already had, but most definitely the immense majority of an Award BIOS of the 2000s is compiled C code (e.g. "new setup"). And done by "developoors" as much as it gets.
Do note that, even with compilers of the era, using HLL with care can result in having an _easier_ time managing codesize than some of the garbage written in assembly by random developers... specially as feature creep starts to set in, which by the 2000s was in full force.
Have you ever seen a USB stack (even for HID boot protocol) in assembly on a commercial BIOS?
I will take a look, but right now I would be skeptical of any such "100% asm" "leak", considering how easy it is to get a lightly commented listing. My position is indefensible, so no point arguing though.
> C didn't start showing up in BIOS until the UEFI era (Tianocore etc.).
"Showing up" is an understatement, since Tianocore is almost all C. And we didn't switch from 100% asm to 99% c overnight.
Funny. I searched the term and found Hell Let Loose. Glad it was clarified because I never would have figured it out on my own. Also, incredible game worth checking out.
I've often wondered about how to re-solve certain problems now that we have decades of hindsight. For instance, your BIOS doesn't boot from CDs or from large disks. So what do we do? We make a disk image (vnd on BSD and whatever the equivalent on Linux make this so easy) and install an old fashioned BIOS boot block. We have a small 40 megabyte or so FAT-16 filesystem (FAT-32 wasn't a thing until 1996), on which we have a kernel, such as NetBSD because NetBSD can still run on 486 systems without fuss.
The kernel, once loaded, knows how to access large disks, CDs, or even mount a filesystem over NFS. We then use that system to disklabel / fdisk the rest of the disk, format an FFS filesystem and swap, and install our OS. Simple, right?
But how do we get this image on to an 80486 system? We really shouldn't lose to history the kinds of tools that let us boot from floppy. NetBSD still can, even though it takes something like six of them.
Since the i80486 has no management engine, running an open source BIOS would make it fully, 100% open. Interesting... Will my next email server be an i80486 system? It's worth considering.