Readit NewsDeleted Comment
Have you tested this on an actual 486?
Sadly, it does not seem to boot on my 486 DX2, I even stuffed 32M of RAM into the machine (8*4M, maximum the mainboard supports), more than the recommended 20M.
I have copied the floppy image from the site. It churns for about a minute and a half, loading kernel and initrd, then says "Booting kernel failed: Invalid Argument" and drops into SYSLINUX prompt.
EDIT: I tried a few more floppies to rule that out as the cause of the problem.
Here are some screenshots: https://imgur.com/a/floppinux-0-3-1-Mdh1c0w
EDIT 2: I cloned SYSLINUX, checked out the specific commit and did some prodding around.
The function `bios_boot_linux` in `com32/lib/syslinux/load_linux.c` initializes errno to EINVAL. Besides sanity checking the header of the kernel image, there are a few other error paths that also `goto bail;` without changing errno.
Those other error paths all seem to be related to handling the memory map. I know that the BIOS in my machine does not support the E820h routine. I have a hunch that this might be the reason why it fails.
The website has an image gallery where people ran it on actual hardware: https://krzysztofjankowski.com/floppinux/floppinux-in-the-wi...
Most of those machines seem to be newer systems which probably support E820h, except for another 486 DX2 with a similar vintage as mine, that also failed to boot.
Deleted Comment
I thought Tar had an extension to add an index, but I can't find it in the Wikipedia article. Maybe I dreamt it.
You might be thinking of ar, the classic Unix ARchive that is used for static libraries?
The format used by `ar` is a quite simple, somewhat like tar, with files glued together, a short header in between and no index.
Early Unix eventually introduced a program called `ranlib` that generates and appends and index for libraries (also containing extracted symbols) to speed up linking. The index is simply embedded as a file with a special name.
The GNU version of `ar` as well as some later Unix descendants support doing that directly instead.
st_goliath commented on 80386 Multiplication and Division nand2mario.github.io/post... · Posted by u/nand2mario
No discussion of these instructions on the 386 would be complete without mentioning that early revisions had a bug in the 32-bit multiply: https://retrocomputing.stackexchange.com/questions/17803/int...
I wonder if anyone outside of Intel has discovered the actual bug in the circuitry yet.
Yes, one can only hope Ken Shirriff eventually happens to come across one of those models, but I guess they are probably very rare these days.
Besides the multiplication, the 386 had quite a number of teething problems[1], including occasionally broken addressing modes, unrecoverable exceptions, virtual address resolution bugs around the 2G mark, etc...
A while ago, there was also an article posted here that analyzed the inner workings of the Windows/386 loader[2]. Interestingly, Windows simply checks a pair of instruction (XBTS/IBTS) that early 386 steppings had, but was later removed, raising an invalid opcode exception instead.
Raymond Chen also wrote a blog post describing a few workarounds that Windows 95 had implemented[3].
[1] https://www.pcjs.org/documents/manuals/intel/80386/
[2] https://virtuallyfun.com/2025/09/06/unauthorized-windows-386...
[3] https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11...
st_goliath commented on x86 prefixes and escape opcodes flowchart soc.me/interfaces/x86-pre... · Posted by u/gaul
Fun little tidbit: The 0x40-0x4f range used for the REX prefix actually clashes with the single-byte encodings for increment/decrement.
When AMD designed the 64 bit extension, they had run out of available single-byte opcodes to use as a prefix and decided to re-use those. The INC/DEC instructions are still available in 64 bit mode, but not in their single-byte encodings.
For my 486 distro[see snacklinux.org], I use syslinux 4.07 due to similar issues. I never had any luck with syslinux 6.x, I’d recommend a similar path. It always seems funny to me when I see similar projects, claiming it runs on 486 hardware but rarely do I see people actually doing that, and just fire up qemu instead. Running Linux in a vacuum isn’t realistic, especially when we’re talking old hardware and configuring IRQs manually.
It is running some AMI BIOS variant with a copyright date of 1992, I currently don't have the exact version string around to compare with the ROM dumps on retroweb. vbindiff says the "F" and "M" images are identical and the "H" only has a few 1-byte differences, mostly typos in ASCII strings.
I've written a small boot sector program once that tries out memory and CPU information gathering techniques, so I know the INT 15h, E820h, E801h are not implemented but INT 12h and INT 15h AH=88h return something sane. When I have more than 16M installed, the later reports the full 31M of HIMEM, but I'm not sure how the ISA memory hole factors into this.
From what I saw glancing at the scanning code yesterday, syslinux 6.x should fall back onto AH=88h if AX=E820/E801 doesn't work. It's interesting to know that this worked in older SYSLINUX, I'm curious to check out what changed.