[LMH]Nevermore

[Robert Swindells]

Alastair Bridgewater wrote:
>On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote:
>> 
>> I started by trying to parse the microload, I then realized that it
>> wouldn't fit into the 56 bit wide arrays. Once I had started modifying
>> them I thought I might as well start on the microengine and
>> disassembler.

>Mmm... I suppose it wouldn't hurt to at least change the cached 
>microinstruction storage to be 64 bits wide globally...

They are also a different length...

>> I saw in an old message that you had worked out the ExpI ROM format,
>> have you had any thoughts on the likely format of an ExpI microload ?

>Ages back. See dise1uc.lisp, disassemble-mcr-partition for some of the 
>details. I also posted a partially-commented disassembly of the STBM 
>code to my webspace a while back ( http://www.dridus.com/~nyef/lispm/ ), 
>which has the code to start a microload running on the machine.

I don't seem to have that function in dise1uc.lisp.

I had downloaded the STBM listing already.

>> >Starting a microload without having the STBM code will be... 
>> >interesting. Particularly if you start by loading the primitive.
>> 
>> The source to the Macintosh loader program is supplied with the
>> microExplorer tree. It doesn't seem to be doing very much to start
>> the board up.

>Heh. Is it just using the micronet interface to indicate the presence of 
>a microload and having the STBM take it from there?

I think it must be.

See what you think when you get the tarball.

>> >I can think of a couple things I'd want to change if we're going to 
>> >support Hummingbird in the same codebase. NuBus handling, for starters.
>> >Breaking the CPU emulation out into a separate package from everything 
>> >else as well... We might also want to look for a better name. Poe never 
>> >wrote about a Hummingbird that said 'Nevermore'. ^_-
>> 
>> I have broken the ExpII versions of things out into their own files.

>Right, but there are a few things that should be common to both that are 
>in files with 'raven' in the name.

Feel free to merge any shared stuff back together.

>> I have only really done the bits that have moved around slightly
>> within the microword. I have added handling of immediate a-mem
>> values to the microengine, but not to the disassembler yet.

>Oh, neat. A-Immediates look like they'd make a good improvement over the 
>A-CONSTANT stuff from the Raven microloads. One question I have, though, 
>is if they sign or zero extend...

I was hoping that the encoding of immediates would be obvious once we
started disassembling the microload.

>> I have had a go at reading the ROM in my microExplorer.
>> 
>> What I can't tell is whether the diagnostic microload ought to be
>> mapped into the NuBus address space or whether this is part of the
>> reason for the board not working.

>There's a specific diagnostic for the MX, right? Are you writing a 
>replacement set of interface routines, or are you using the 'correct' 
>ones?

My MX won't boot, so I'm just poking at it from the Macintosh side.

The ExpII processor document states that the NuBus config ROM contains
the STBM. I was just guessing that the MX was the same, but couldn't
see anything that looked meaningful.

Robert