11:45 |
asciilifeform |
$ticker btc usd |
11:45 |
busybot |
Current BTC price in USD: $20411.32 |
| |
~ 54 minutes ~ |
12:39 |
phf |
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 |
12:39 |
bitbot |
Logged on 2022-10-31 18:32:57 asciilifeform[6]: ( it aint as if photo == netlist, naturally, that -- by hand, sit for yr+... ) |
12:42 |
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) |
12:43 |
phf |
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" |
12:43 |
asciilifeform |
afaik thing had no way of loading revised microcode, so nfi why it was distributed with the thing, come to think of it |
12:44 |
asciilifeform |
extracting microcode tho is 1 of the easier parts of jpg->netlist, as it is arranged in mask rom in grid pattern |
12:45 |
asciilifeform |
it's errything ~else~ that is 1st class bitch |
12:45 |
phf |
ah, so you basically see 1 and 0s from the jpegs? |
12:45 |
asciilifeform |
aha |
12:47 |
asciilifeform |
example of ucode extraction from (early '80s) ic fwiw. |
12:48 |
phf |
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 |
12:49 |
phf |
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 |
12:49 |
asciilifeform |
iirc 'ivory' used 'vertical' (i.e. sequences of microinstructions) rather than 'horizontal' (toggles circuits in parallel) microcode, but nfi concretely |
12:51 |
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) |
12:52 |
asciilifeform |
also allows to read out microcode program counter (step through indiv. uinstructions) |
12:54 |
asciilifeform |
the macroscopic schema of the thing is in the '87 press release fwiw. |
12:55 |
phf |
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 |
12:55 |
phf |
i'm starting to remember things. i feel like i relearn the same facts about ivory every couple of years |
12:56 |
asciilifeform |
best public photo of the die afaik, ftr. |
12:58 |
phf |
what's that from? |
12:59 |
asciilifeform |
phf: was from anuther paper of theirs, can't seem to find the orig locally tho |
13:00 |
phf |
there's that same basic photo in one of the vlsi conference proceedings that i have, but the quality is much lower |
13:02 |
phf |
"notes on future implementations of ivory chip" oh sweet summer child |
13:03 |
asciilifeform |
the photo is prolly of the pre-release die. |
13:04 |
phf |
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 |
13:05 |
asciilifeform |
right, that 1 afaik only existed as marketing lit (and possibly a demo unit or 2, sitting in indiana jones warehouse sumwhere) |
13:06 |
asciilifeform |
this brochure fwiw had a higher quality scan of the block schem. |
| |
↖ |
13:11 |
phf |
we should bring back measuring things in GIGAWORDs |
13:12 |
asciilifeform |
indeed (along with, naturally, tagged words, rather than byte-addressed soup) |
13:12 |
phf |
http://logs.bitdash.io/pest/2022-11-01#1015179 << that is basically your cadr architecture, but on a chip |
13:12 |
bitbot |
Logged on 2022-11-01 13:06:28 asciilifeform[jonsykkel|deedbot]: this brochure fwiw had a higher quality scan of the block schem. |
13:14 |
asciilifeform |
well, 3600 was 'cadr on steroids', and 'ivory' -- logical progression, with moar instrs & moarbitness |
13:19 |
asciilifeform |
the 'ivory in space' piece seems to confirm the 'verticality' of the ucode : |
13:19 |
asciilifeform |
The first stage fetches |
13:19 |
asciilifeform |
the instruction, decodes it, and adjusts the program |
13:19 |
asciilifeform |
counter. The second stage fetches the initial microinstruction, computes the operand address, and adjusts the stack pointer. The third stage fetches the |
13:19 |
asciilifeform |
operands and computes the result. The fourth stage |
13:19 |
asciilifeform |
stores the result, unless a fault has occurred, in which |
13:19 |
asciilifeform |
case it restores the state of the third stage. yy |
| |
~ 17 minutes ~ |
13:37 |
* |
asciilifeform back in '19 drew up a test jig pcb for 'ivory', usb <-> fpga <-> 5v buffer <-> zif socket, but not had it baked |
| |
~ 30 minutes ~ |
14:07 |
phf |
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 |
14:09 |
asciilifeform |
phf: naturally, if had src, would be 0 reason to bother with micrography etc |
14:11 |
phf |
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 |
14:12 |
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 |
14:13 |
phf |
right, that's how for example how cadr system did it, a mixture of explicit "uinstrs" and ucode calls |
14:17 |
phf |
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 |
14:17 |
* |
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 |
14:22 |
phf |
yeah, the vlm documentation is pretty sparse ( i mean in document examiner ) |
14:22 |
phf |
e.g. there's a section for IBIN (obv without details), but not even a mention of VBIN |
| |
~ 2 hours 29 minutes ~ |
16:51 |
phf |
completely unrelated question but did anyone (signpost?) try building the absolute minimal framebuffer xorg? |
16:52 |
phf |
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 |
| |
~ 21 minutes ~ |
17:14 |
asciilifeform |
phf: a while ago asciilifeform built an xorg for rk, but never tested ( couldn't get fb going on that thing ) |
17:15 |
asciilifeform |
not certain it was 'minimal' in the sense described, also ( defo included freetype, sumthing depended on it ) |
17:16 |
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? ) |
17:17 |
phf |
no, separate install, but has been mostly kept up to date |
17:17 |
asciilifeform |
a |
17:17 |
* |
asciilifeform at one time used a crapple 'mbp' as an xterm |
17:20 |
phf |
i'm looking at the xserver sources and it looks like "xquartz" is mainlined |
| |
~ 5 hours 5 minutes ~ |
22:25 |
asciilifeform |
phf: does your arm-mac port of the emulator still use x11 for output? or has own fb |
| |
↖ |
22:26 |
* |
asciilifeform would buy that emulator, fair an' square, like bought other dksisms, if were forsale |