M9301-YB Bootstrap/Terminator ROM dumps / listings?

[Josh Dersch]

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!
>
> 	Noel
>
> 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!
- Josh