IRC channel logs
2022-06-12.log
back to list of logs
<Hagfish>muurkha: maybe there is. i think if it just implemented the gen1 rules/dex, an optimal strategy could probably be brute-forced <oriansj>interesting, an ASR33 defaults to MARK parity <muurkha>interesting, I didn't know they had parity! <oriansj>no, it appears to always be set to 1 and if 0 is an error <muurkha>oh, so it's not parity at all, it's just, like, an extra start or stop bit <oriansj>or a disconnect sort of thing in the event the thing goes down during a data transfer <muurkha>ISTR the 8250 has an option for 1 or 2 stop bits <muurkha>a disconnect sort of thing is BREAK though <oriansj>as there is even, odd, mark and space parity behavior for the parity bit <muurkha>great thing about 60mA current loop is that you can detect BREAK extremely reliably <oriansj>assuming one puts in the hardware to do so <muurkha>I don't remember if the ASR-33 itself could detect BREAK <muurkha>but BREAK detection was extremely widely deployed <oriansj>fair, I'm mostly just down a pdp-8 programming sinkhole <muurkha>pretty sure the PDP-8 could detect BREAK but I've never used one <oriansj>as alt.sys.pdp8 seems to be actually active these days <muurkha>the second of these explains that telegraph operators could detect a BREAK condition by noticing that their key wasn't activating their sounder <muurkha>and claims that the ASR-33 would print an endless stream of NULs in this case <muurkha>well, doesn't the ASR-33 also send start and stop bits? <muurkha>I'd think that sending MARK during the parity bit period would be just the same as sending an extra stop bit <muurkha>btw, did you look at John Cowan's PDP-8/X design? <muurkha>it's a 32-bit machine based on the PDP-8 <muurkha>the PDP-8 (in the form of the 4000-transistor Intersil 6100) is probably close to the simplest computer that it's practical to run a high-level-language compiler on <oriansj>I don't deny the efficiency of the PDP-8 (it is brilliant in its efficiency); the need to do funky string packing and unpacking is less than ideal if one wants bootstrapping simplicity <oriansj>and having used skip instructions in knight, I think they are unsound if one wishes to expand the instruction set <oriansj>as you either lock your instruction size to a single standard (bad idea) or read the first byte of the next instruction to guess what size it will be (ugly idea: only works for big endian instruction encoding and has some really bad page fault problems) or you are forced to read the full next instruction (horrific idea with lots of bad problems to address and kills performance) <oriansj>but the idea of mark parity being an extra stop bit does seem reasonable <muurkha>string packing is an optimization; if you have enough memory you can just store one character per word <muurkha>the RISC-V approach to instruction size encoding seems reasonable to me; difficult-to-decode instruction sizes are a big performance problem whether you have skips or jumps <oriansj>well instruction sizes don't have to be a difficult-to-decode problem <oriansj>and if your instructions are big-endian encoded with the opcode first, then you need only look at the first few bits to know the size <oriansj>instead of having to guess where the opcode is for little-endian encoding with opcode first or big-endian encoding with opcode last. <oriansj>and risc-v did go with little-endian with opcode last, so kinda