M9301-YB Bootstrap/Terminator ROM dumps / listings?
derschjo at gmail.com
Tue Apr 28 11:09:46 CDT 2015
On 4/28/15 8:12 AM, Noel Chiappa wrote:
> > From: Charles Dickman
> > You can find a dump and partial disassembly
> So I decided, just for grins (this may be duplicative of what's on a fiche
> somewhere) to complete the disassembly, and there was something that was
> puzzling me.
> There a bunch of entry points (for auto-booting from different devices) which
> all are of the form:
> BR foo
> where foo is the same location. The code doesn't save anything before the
> branch, it just does it right off. So how does it know, when it gets there,
> which entry point was used?
> Well, it turns out that the answer, I am pretty sure, is that with the M9312,
> location 773024 is even more magic than it first appears.
> (Slight digression, for those who didn't get the reference: the way the M9312
> forces the 11/04 or /34 CPU into the ROM, on power-fail or manual restart, is
> that when the CPU tries to fetch the PC/PS pair from location 024 - the
> power-fail/restart vector - the card jams the high UNIBUS address lines to
> 773000 for two bus cycles, directing the fetch of the new PC/PS to locations
> 773024-6. Next, when the CPU fetches the contents of location 773024, the
> basic contents of that location, in the ROM - 173000 - are or'd with switch
> S1-3 (bit 8, 4xx) through S1-10 (bit 1, 2). So that's how the code jumps to
> different entry points, based on the contents of S1.)
> However, from reading the code (yet to verify this on prints, but it _has_ to
> work this way, the code doesn't make any sense otherwise), it appears that
> _any_ reference to location 773024, at _any time_, produces the contents of
> ROM location 773024 or'd with the contents of switch S1!!
> In other words, location 773024 is effectively a hacky register that allows
> S1 to be read. (And the M9312 Maint Manual does _not_ make this clear. It
> talks about how the contents are modified during the power-on PC/PS fetch
> cycle, but _not_ about the later references part.)
> Very clever, though!
> PS: Josh, from what I've seen so far, the code tends to loop on error, not
> halt. So if your machine's halting...
Nice analysis, that's very interesting!
Just a quick update on my situation -- it looks like my M9301's got some
bad PROMs in it, comparing the diagnostic/console PROM listings to what
I have at 165000 shows some corrupted data, and it's not just missing
bits -- e.g. 165020 is supposed to contain "005003" but on my machine
it's "000070" which isn't even a valid instruction as far as I know.
Some locations contain data that matches, some do not. This would tend
to indicate faulty PROMs rather than a bad data buffer or similar
dropping bits along the way.
I have come into possession of an M9312 (which is pretty similar to the
M9301, just a bit more general) and this appears to work perfectly. I
now get the ODT prompt as expected and all seems well. I haven't yet
loaded up real diagnostics but I'll be giving that a shot tonight.
Thanks all for the assistance!
More information about the cctalk