[LMH]microcode rom

[Nyef]

On Tue, Dec 30, 2003 at 02:11:33PM -0800, Michael Larson wrote:
> Thanks, found it. Any idea on what the format is? If the EII used a 64  
> bit 16k microcoded RAM then the size would be about 128k... it probably  
> has some of the dispatch table stuff in there also.

The format is documented in SSDN2, appendix A. The links are on the E3
site. The format that we don't have documentation for is E1 microloads
(although it's fairly obvious once you find the right point in a
disassembly of the boot proms).

> As a point of history I took my first AI class on an Explorer II  
> machine, although my focus was on a BSEE and couldn't wait to be done  
> with the class, I have re-discovered Lisp in the past few months and  
> this looks like a fun project.

It's fun, but some parts of the system are insane and not documented
well. Stack-group switching, microcode instructions, etc.

> The idea I had for the microcode was to parse the microcode  
> instructions into a C (or asm) switch statement based on the decode of  
> the instruction for each case statement, this would provide a nice fall  
> back to emulate the dispatch table used by the lisp compiler. On newer  
> processors it would be better just to churn through the assembled code  
> and avoid as much decode (branches) as possible.

I've had several ideas on how to tackle the problem of emulating an
Explorer system. I'm still not sure quite what the best method is...

If you're going to be messing around with microcode, you might take a
look at the E1 microcode interpreter I started writing a while back.
It's at http://www.dridus.com/~nyef/lispm/nevermore/ and includes a
disassembler, which might prove to be the interesting bit. The output
from the disassembler is as close as I could figure out to the input
for the original microcode assembler, and is the sanest way to look
at the microcode that I've found thus far. It would need updating or
rewriting for the E2, but you can at least use it for ideas.

> It would be nice to boot my G5 to a VM that could access all 8 GBytes  
> physical or 64 TeraBytes virtual.

It won't be an Explorer VM, then. Those are limited to 25 bits, word
addressed.

> Cheers,
> 
> Mike

--Alastair Bridgewater