I changed the subject line since unless you recognise 43201 others might not make the connection :-)
> On 22 Jul 2015, at 4:18 pm, Eric Smith <space...@gmail.com> wrote: > now, I have just wired up the 43201 on a breadboard in microcode ROM > dump mode, and captured the ROM contents using a logic analyzer. > Photos: > > https://www.flickr.com/photos/22368471@N04/sets/72157653865063443 As someone who has held an interest in the iAPX 432 since it was released, this is an exciting development, thank you for sharing your intentions and progress. > The 43201 has 4K words of 16 bits of vertical microcode ROM, however > the top-level control is not done by the microcode ROM, but rather by > a bunch of PLAs and hardwired logic. Many of the simpler 432 > instructions are executed without use of the microcode ROM at all. Do you know if this was where the so-called “SiliconOS” was stored? was it simply mixed in with the regular instruction set? For others the SiliconOS provided quite high-level constructs like resource-scheduling (multi-tasking) and other operating system like functions, hence the name. > There is not known to be any surviving coherent release of iAPX 432 > software, so I'm developing my own software from scratch. I guess the other challenge with original iAPX 432 software, if I have this right, is how dependent it was on the iRMX-86 environment which was used to bootstrap iMAX? so effectively two operating systems needed to coexist with the supporting hardware, that is a lot of moving parts and presumably particular software pieces (with dependencies) that would need to be pulled together. On your website you mention you have some VAX VMS software that supported the iAPX 432? does this include any form of cross-compiler? have you tried to resurrect any of it? > It is a > large task, because the iAPX 432 architecture is completely > object-oriented (implemented by the microcode and hardware), and there > have to be several dozen properly formed system objects in memory just > to execute the simplest program. This is an interesting point of distinction between classes of machines. The Burroughs B5000 and B6000 families had a similar requirement in that they needed to be a formed execution environment, with the operating system to function; so dependent were they on having an OS which could respond to residency interrupts etc. Other system classes by comparison could be switched on, loaded with stand-alone object-code and do something useful (obvious examples being the PDP-8 and PDP-11). > By studying the bus > activity leading up to the halt, I hope to be able to determine what > problem with the memory image led to the halt. May your logical analyser capture all the needed events and your logic probe strike unerringly.
