[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