IRC channel logs

2023-06-22.log

back to list of logs

<roconnor> https://www.budgetronics.eu/en/building-kits/mynor-single-board-computer-kit-main-board/a-25819-20
<oriansj>roconnor: yeah the 64KB eeprom hides all of the logic for the CPU; and making a simple x86 system is on about the same level with most 8bit systems: http://sasteven.multics.org/8088page.html
<oriansj>mihi: well the plastic-leaded chip carrier (PLCC) form factor has most of the advantages of Dual Inline Packaging but has the advantage of being able to exceed the 64pin limit (Available in 18, 20, 22, 28, 32, 44, 68, 84 pin counts) but unfortunately the simplest 386 I found was: https://theretroweb.com/chip/documentation/m6117d-6454b7cbef102095220558.pdf
<oriansj>Quad Flat Pack (QFP) is less than ideal for replacement but certainly much easier to replace than Ball Grid Array
<muurkha>supposedly someone did at one point prove that an arbitrarily large number of delay line elements and a NOR gate was adequate for universal computation, though I don't remember what their proposed memory was
<muurkha>but of course an EPROM and a register is sufficient to implement any finite state machine; you don't even need a NOR gate
<muurkha>you wire your input lines to some of the address lines of the EPROM, your output lines to some of the data lines of the EPROM, and the remaining address and data lines of the EPROM go to the register
<muurkha>so each clock cycle the register transitions to the state looked up in the EPROM by the previous combination of state and input
<muurkha>I'm not sure if you can implement a usable CPU that way with an EPROM with few enough address lines to actually buy
<muurkha>although I guess that's not really an obstacle if you're allowed to use multiple EPROM chips; you can use one-hot encoding for the chip-enable lines on the EPROMs
<oriansj>muurkha: mercury delay lines?
<muurkha>not necessarily; D flip-flops would be a much more reasonable approach nowadays
<muurkha>even in the analog-delay-line epoch, mercury got displaced; acoustic delay-line memory in many 60s calculators used torsional waves in a coil of wire instead, and I have an acoustic delay line here from a PAL VCR that is made of glass
<muurkha>an ultrasonic wave reflects back and forth several times through the glass between the input transducer and the output transducer
<muurkha> https://news.ycombinator.com/item?id=36416325 points out that the "MyNOR" board also has a 74HC08, a 74HC32, and 74HC138 and 139, which is really quite a lot of random logic, a lot more than just a NOR gate
<oriansj>toss in a https://vgamuseum.info/index.php/cpu/item/download/269_d7f376888f21148d10bed1b40f27da1f and you'll have a vga 386SX system in only 10 Chips (vga bios, boot bios, the M6117D, F65535 and a couple RAM chips [and an optional opl if you want music while you bootstrap])
<muurkha>I tried installing Linux on a 386SX once
<muurkha>I was not successful
<muurkha>C&T 65535, not familiar with the chip
<oriansj>a pretty minimal and slow vga chip honestly
<muurkha>I didn't read enough of the datasheet to see if it supported TrueColor
<muurkha>TrueColor simplifies graphics a lot
<oriansj>it says: Additionally true color bypass modes are
<oriansj>supported displaying color depths of up to 24bpp (8-red, 8-green, 8-blue).
<muurkha>nice
<muurkha>1MiB at 16bpp is only 524288 pixels tho
<oriansj>the biggest advantage is these chips are still being made and sold
<muurkha>so I guess 800×600?
<oriansj>plenty for bootstrapping
<muurkha>being still made and sold is definitely an advantage
<muurkha>not sure VGA compatibility matters to
<muurkha>*tho
<oriansj>well gives us a commonly known and supported standard; which can function as a fixed target while we sort out a hardware bootstrap and start making our own custom hardware
<muurkha>conceivable, but I suspect simplicity matters more than popularity
<muurkha>I mean you do at least want Linux to be able to draw a text console I guess
<oriansj>muurkha: well simplicity in what direction? Is a chip with everything integrated and only a handful of I/O pins or a single CPU chip, with some single function SRAM chips and a single Video chip and you can wire up whatever I/O you want to the memory bus?
<oriansj>if your video logic goes bad, is is better to throw out the whole computer or just replace the Video chip that needs replacing?
<oriansj>I am partial to simple to repair and replace parts; design for repairability. The X200 came out 15 July 2008 (almost 15 years ago) and it is still my daily driver thanks to libreboot and Guix.
<sam_>:)
<oriansj>If the MNT's Reform laptop just had its nonfree RAM training replaced by free software, it would actually be a possible upgrade path
<theruran>what about the Raptor Talos II as a bootstrap platform?
<oriansj>theruran: entirely valid
<theruran>just expensive (:
<oriansj>and less portable
<theruran>well I think Guix supports it??
<oriansj>and not listed in: https://www.fsf.org/givingguide/v13/ but the motherboards are listed here: https://ryf.fsf.org/categories/mainboards
<oriansj>well they have https://ftpmirror.gnu.org/gnu/guix/guix-binary-1.4.0.powerpc64le-linux.tar.xz but that is for Guix running upon your linux distro of choice, they don't actually have install media for powerpc (32 or 64bit)
<theruran>ohhh
<oriansj>and the stage0 porting work to powerpc only worked out the ELF oddities; not done a full set of steps yet
<muurkha>oriansj: hmm, I was thinking of simplicity in the sense of less modes, less ways for software to fail, and less logic gates in the chip
<muurkha>I didn't mean simplicity in the sense of "lack of difficulty"
<oriansj>muurkha: well less ways for software to fail and less logic gates in the chip are sometimes mutually exclusive (ECC hardware for example)
<oriansj>but yes, I agree carefully thought out design details allow for simpler hardware implementations and easier to reason about software
<muurkha>oriansj: indeed