[LMH]Nevermore

nyef@sc.am nyef@sc.am
Fri May 21 05:56:01 2004


On Thu, May 20, 2004 at 11:34:09PM +0100, Robert Swindells wrote:
> 
> Alastair Bridgewater wrote:
> >On Thu, May 20, 2004 at 05:31:12PM +0100, Robert Swindells wrote:
> >> 
> >> 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.

Oop. Yeah, that's in my current version. I tried to send you a tarball 
of my WIP directory, but I guess that didn't go through.

> >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.

The first thing that comes to mind is "Dear lord this is nasty". The 
most horribly K&R C I've seen in ages, half of the system in Pascal as 
well, it -is- a NuPI simulator, and they depend absolutely on the system 
not only being 24-bit capable (not true of the later machines) but also 
running in 24-bit mode (if memory serves, not true of System 7). It 
might be possible to get an MX running on a more recent machine 
(possibly even a powermac), but it'd require basically rewriting all of 
the MacOS-side code.

> Feel free to merge any shared stuff back together.

Yeah, I'm thinking separate packages for nevermore itself, the raven 
emulation, and the hummingbird emulation.

> >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.

Actually, the encoding is fairly obvious just from looking at 
humfmt.lisp. The constants can be either left- or right-justified, and 
will sign extend if they are right-justified. The only question I have 
is if the sign bit is chopped off if they are left-justified (I doubt 
it, it'd be hard to justify that decision). Well, and what it looks like 
to the assembler.

I am kindof concerned about the 4-deep instruction pipeline and the 
cache setup. Figuring them out without better documentation could be a 
little difficult.

> >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.

Mmm... That config ROM image doesn't look right at all. It looks to be 
short a byte, and shouldn't it be longer if you're doing word-wise dumps 
and the bytelanes value is #xE1? (at least, I assume that's the 
bytelanes value...)

What would be really nice is if one of the nice TI people would stumble 
across a copy of the 256-word IROM code from the hummingbird chip. 
Otherwise we may have to write a custom microload to extract the code 
once we have access to a working system... I suppose it doesn't really 
matter for now, we can probably fake something up to get it working in 
the meantime...

> Robert

--Alastair