You could clean up the ribbon cables by removing the unused header connectors for extra drives and separate them into fifths and tape or zip tie them to give a cleaner look. Or swap the main pc card to the last slot and run the ribbon cable under the backplane this was always my preferred cable management in at pc's they stay in place and out of sight just be careful while screwing down the backplane after that never have to to deal with management again.
Break a leg in course! Honestly though, I regret all my exposure to x86 and would rather forget it. ARM v6 would have been my choice. Have options like PiZero or RP2040 and a ton of STM options. Is in regular use in current day.
Thanks! I did seriously consider RISC-V. Maybe in a future semester. One obstacle to using RISC-V and ARM is the relative lack of standardization of the boot process and peripheral availability, so you're more or less obligated to target one specific dev board, and then you need to arrange for the emulation environment to match that board. Going with good old 32-bit x86 means you can just assume standard PC BIOS and peripherals for both emulation and actual hardware. I agree that x86 isn't elegant, although 32-bit x86 isn't too horrible (especially when you compare it to its 16-bit predecessors.) You can just set up the code and data segments to be flat and then you basically have a VAX 🙂
@@davehohacks I would agree with RISC-V but would just add, don't conflate with ARM. Arm has been around since 80's (Acorn Computers), is the most popular architecture of all time and will be for long time to come. It is a descendant of 6502. QEMU emulates ARM just as well as x86. You may have a point with most popular BIOS perspective. For a CPU course though, skip the BIOS? I did some searching on open source BIOS'es and there are interesting options although I don't recommend anything specific. (There does seem to be a UEFI published standard now, and there is reference implementation .. but yeah, the BIOS history for ARM is more complex up to late 90's .. arm-trusted-firmware)
@@kippie80 I definitely don't have any objection to ARM. I did actually think about the Raspberry Pi as a candidate development platform, since its boot process is reasonably well documented. I also agree that the BIOS isn't really important other than as a means of loading the kernel. Mostly I'm going with 32-bit x86 because it's a platform that I have some experience with writing low-level code for.
@@kippie80 1980s ARM systems didn't have a BIOS, Acorn wrote the OSs to the bare metal, there wasn't really provision for 3rd party OS. Where they did come to exist with the NetBSD and Linux ports they bootstrapped through "RISC OS" using it as a bootloader and "BIOS". A vintage late 1980s Archimedes would probably make quite an interesting target for teaching OS design, it's even simpler than a PC/AT without even DMA support and very well documented. But they're getting pretty rare now, many have succumbed to battery leakage. A modern ARM system like a RPi would introduce the same kind of complexity as using a modern PC. I think Dave probably made the right choice. I wouldn't really say the ARM descended from 6502, although 6502 definitely influenced some design decisions, and the ARM development software did run on a second processor equipped (2x 6502) BBC Micro! The instruction level simulator written in BBC as I recall.
another wonderful video! thank you for sharing
You could clean up the ribbon cables by removing the unused header connectors for extra drives and separate them into fifths and tape or zip tie them to give a cleaner look. Or swap the main pc card to the last slot and run the ribbon cable under the backplane this was always my preferred cable management in at pc's they stay in place and out of sight just be careful while screwing down the backplane after that never have to to deal with management again.
12:27 - I think that's the first time I've seen you! Hello Dave! 👋😁
18:48 - I remember that! Driven to drink by fighting with the floppies! 😉🍺😁
I'd forgotten how slow floppy drives are. I think it took about an hour to install FreeDOS.
Break a leg in course! Honestly though, I regret all my exposure to x86 and would rather forget it. ARM v6 would have been my choice. Have options like PiZero or RP2040 and a ton of STM options. Is in regular use in current day.
Thanks! I did seriously consider RISC-V. Maybe in a future semester. One obstacle to using RISC-V and ARM is the relative lack of standardization of the boot process and peripheral availability, so you're more or less obligated to target one specific dev board, and then you need to arrange for the emulation environment to match that board. Going with good old 32-bit x86 means you can just assume standard PC BIOS and peripherals for both emulation and actual hardware. I agree that x86 isn't elegant, although 32-bit x86 isn't too horrible (especially when you compare it to its 16-bit predecessors.) You can just set up the code and data segments to be flat and then you basically have a VAX 🙂
@@davehohacks I would agree with RISC-V but would just add, don't conflate with ARM. Arm has been around since 80's (Acorn Computers), is the most popular architecture of all time and will be for long time to come. It is a descendant of 6502. QEMU emulates ARM just as well as x86. You may have a point with most popular BIOS perspective. For a CPU course though, skip the BIOS? I did some searching on open source BIOS'es and there are interesting options although I don't recommend anything specific. (There does seem to be a UEFI published standard now, and there is reference implementation .. but yeah, the BIOS history for ARM is more complex up to late 90's .. arm-trusted-firmware)
@@kippie80 I definitely don't have any objection to ARM. I did actually think about the Raspberry Pi as a candidate development platform, since its boot process is reasonably well documented. I also agree that the BIOS isn't really important other than as a means of loading the kernel. Mostly I'm going with 32-bit x86 because it's a platform that I have some experience with writing low-level code for.
@@kippie80 1980s ARM systems didn't have a BIOS, Acorn wrote the OSs to the bare metal, there wasn't really provision for 3rd party OS. Where they did come to exist with the NetBSD and Linux ports they bootstrapped through "RISC OS" using it as a bootloader and "BIOS". A vintage late 1980s Archimedes would probably make quite an interesting target for teaching OS design, it's even simpler than a PC/AT without even DMA support and very well documented. But they're getting pretty rare now, many have succumbed to battery leakage. A modern ARM system like a RPi would introduce the same kind of complexity as using a modern PC. I think Dave probably made the right choice.
I wouldn't really say the ARM descended from 6502, although 6502 definitely influenced some design decisions, and the ARM development software did run on a second processor equipped (2x 6502) BBC Micro! The instruction level simulator written in BBC as I recall.