asciilifeform: $ticker btc usd
busybot: Current BTC price in USD: $20411.32
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-10-31#1015119 << re this, i'm not sure how this kind of reversing work (my only exposure to it is reading bunnie's xbox hacking book like a decade ago), but besides netlist also need to smh dump the microcode that's embedded in ivory
bitbot[asciilifeform|busybot]: Logged on 2022-10-31 18:32:57 asciilifeform[6]: ( it aint as if photo == netlist, naturally, that -- by hand, sit for yr+... )
asciilifeform: phf: netlist traditionally refers to all the transistors. the microcode tho iirc is actually on the ivory cd, for some unknown reason (tho would still want to see whether same as the iron one)
phf[busybot]: right, the point was that you get the netlist out by "tracing the datapaths by hand", and it's a different process, conceptually, from "extracting a rom data from a chip"
asciilifeform: afaik thing had no way of loading revised microcode, so nfi why it was distributed with the thing, come to think of it
asciilifeform: extracting microcode tho is 1 of the easier parts of jpg->netlist, as it is arranged in mask rom in grid pattern
asciilifeform: it's errything ~else~ that is 1st class bitch
phf[asciilifeform]: ah, so you basically see 1 and 0s from the jpegs?
asciilifeform: aha
phf[asciilifeform]: i've not really studied it in detail, but ivory i take it is just a vlsi take on traditional cadr/3600 "microcode evaluator" architecture
phf[busybot]: from that perspective the vlm implementation is deceptively more similar to "modern" cpu approach, where each instruction has its dedicated implementation on die, rather than being a microcode vop
asciilifeform: iirc 'ivory' used 'vertical' (i.e. sequences of microinstructions) rather than 'horizontal' (toggles circuits in parallel) microcode, but nfi concretely
asciilifeform: fwiw doc from 'anon informant'(tm) gives recipe for reading ucode via the pins; may be easier than via microscope (or at least to cross-check output of the latter, given as errything ~else~ can only be seen via microscope)
asciilifeform: also allows to read out microcode program counter (step through indiv. uinstructions)
asciilifeform: the macroscopic schema of the thing is in the '87 press release fwiw.
phf[busybot]: right right, architecture docs seemed to imply that you can put ivory on a bench, bootstrap it pretty much by just bringing it to power, and then inspect rom state using very straightforward programmer style interface
phf[busybot]: i'm starting to remember things. i feel like i relearn the same facts about ivory every couple of years
asciilifeform: best public photo of the die afaik, ftr.
phf[asciilifeform]: what's that from?
asciilifeform: phf: was from anuther paper of theirs, can't seem to find the orig locally tho
phf[asciilifeform]: there's that same basic photo in one of the vlsi conference proceedings that i have, but the quality is much lower
phf[asciilifeform]: "notes on future implementations of ivory chip" oh sweet summer child
asciilifeform: the photo is prolly of the pre-release die.
phf[asciilifeform]: there's by the way also http://www.bitsavers.org/pdf/symbolics/Sunstone_Architecture_198711.pdf which was supposed to be next gen, and i don't have any info on except that one pdf
asciilifeform: right, that 1 afaik only existed as marketing lit (and possibly a demo unit or 2, sitting in indiana jones warehouse sumwhere)
asciilifeform: this brochure fwiw had a higher quality scan of the block schem.
phf[asciilifeform]: we should bring back measuring things in GIGAWORDs
asciilifeform: indeed (along with, naturally, tagged words, rather than byte-addressed soup)
phf[asciilifeform]: http://logs.bitdash.io/pest/2022-11-01#1015179 << that is basically your cadr architecture, but on a chip
bitbot[asciilifeform]: Logged on 2022-11-01 13:06:28 asciilifeform[jonsykkel|deedbot]: this brochure fwiw had a higher quality scan of the block schem.
asciilifeform: well, 3600 was 'cadr on steroids', and 'ivory' -- logical progression, with moar instrs & moarbitness
asciilifeform: the 'ivory in space' piece seems to confirm the 'verticality' of the ucode :
asciilifeform: The first stage fetches
asciilifeform: the instruction, decodes it, and adjusts the program
asciilifeform: counter. The second stage fetches the initial microinstruction, computes the operand address, and adjusts the stack pointer. The third stage fetches the
asciilifeform: operands and computes the result. The fourth stage
asciilifeform: stores the result, unless a fault has occurred, in which
asciilifeform: case it restores the state of the third stage. yy
asciilifeform back in '19 drew up a test jig pcb for 'ivory', usb <-> fpga <-> 5v buffer <-> zif socket, but not had it baked
phf[asciilifeform]: i suspect the correct method to do an ivory-on-fpga is not to write a microcode evaluator by attempting to reconstruct netlists etc, but to write a compiler from microcode source to spit out verilog
asciilifeform: phf: naturally, if had src, would be 0 reason to bother with micrography etc
phf[asciilifeform]: i suspect that most recent versions of system don't really leak past micrcode, that is the whole system is expessed in terms of microcode vop, rather than e.g. a mixture of instructions for cpu and vop calls
asciilifeform: possibly only issues explicit uinstrs (appears to be allowed, 1 at a time) if the iron ucode not == to the 1 distributed on disk
phf[asciilifeform]: right, that's how for example how cadr system did it, a mixture of explicit "uinstrs" and ucode calls
phf[asciilifeform]: but also like vlm is not a ivory OR 3600 machine emulator, so for all i know they hacked up the compiler so it's a significantly different beast
asciilifeform ftr not knows the precise difference b/w the os distributed with the dec/x86 emulator and the macivory's -- possibly this is the key difference
phf[asciilifeform]: yeah, the vlm documentation is pretty sparse ( i mean in document examiner )
phf[asciilifeform]: e.g. there's a section for IBIN (obv without details), but not even a mention of VBIN
phf[asciilifeform]: completely unrelated question but did anyone (signpost?) try building the absolute minimal framebuffer xorg?
phf[asciilifeform]: actually no i lied, it's a very much related question. genera talks over network to clx, so i want to build an xorg on a small laptop that doesn't have all the various ((dependencies)). e.g. don't need freetype or of the freedesktop functionality
asciilifeform: phf: a while ago asciilifeform built an xorg for rk, but never tested ( couldn't get fb going on that thing )
asciilifeform: not certain it was 'minimal' in the sense described, also ( defo included freetype, sumthing depended on it )
asciilifeform: iirc genera's x11ism is quite compat, even seen to work with crapple's x ( does crapple still include it on the new arm boxen? )
phf[busybot]: no, separate install, but has been mostly kept up to date
asciilifeform at one time used a crapple 'mbp' as an xterm
phf[asciilifeform]: i'm looking at the xserver sources and it looks like "xquartz" is mainlined
asciilifeform: phf: does your arm-mac port of the emulator still use x11 for output? or has own fb
asciilifeform would buy that emulator, fair an' square, like bought other dksisms, if were forsale