<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 04-Sep-18 14:14, Lars Brinkhoff
wrote:<br>
</div>
<blockquote type="cite" cite="mid:7wo9ddi0z4.fsf@junk.nocrew.org">
<pre wrap="">Phil Budne wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I seem to recall VAX boot ROMs handled by doing "load -r kaxxx.bin"
How are VAX boot ROMs done? At _some_ point I thought it was done
with "load -r". Is that not available in the PDP-11 simulation?
</pre>
</blockquote>
<pre wrap="">
I randomly checked one of the VAX models. It seems memory is modeled
with at least two arrays: M[] for RAM, and a separate rom[]. Digging
further, I see there's also NVRAM and some other memory regions. The
PDP-11 doesn't have this.
</pre>
</blockquote>
The Unibus/QBus can have multiple ROMs. Besides the various M9301
variants (on the Unibus), the 11/34 ASCII console can be loaded as
can the M9312, M792 & M873 variants, MRV11, etc. And the
corresponding QBus console & boot ROMs. There are dozens
(literally) of ROM variants for different combinations of devices
& consoles. Not just from the -11 world - LCG created quite a
few custom ROMs for PDP-11 based ANF-10 nodes & communications
front ends.<br>
<br>
If a ROM device is added to the -11, I suggest that:<br>
<br>
a) It be capable of multiple units<br>
b) each unit with a start address (in I/O space) & length<br>
c) the unit accept "attach <FILE>" to provide the code/data<br>
d) the existing gt40 hack that Mark described be migrated to use the
ROM<br>
e) preferably, provision be made for the other functions of a ROM
module, mentioned below.<br>
<br>
Some ROM modules respond to power failure by forcing the trap to
24/26 to use the ROM's address (e.g. power-on boot). These usually
provide a pin that allows an external switch to force a bootstrap -
this is used by the console ROMs and also by the KL10(DTE)/DL10 to
allow the host to control an -11. (It's also used by DMC/DMR11s,
but in a slightly different way). There's a M9312 tech manual on
bitsavers... There's also a commented listing of that ROM -
<a class="moz-txt-link-freetext" href="http://www.bitsavers.org/pdf/dec/unibus/K-SP-M9312-0-5_Aug78.pdf">http://www.bitsavers.org/pdf/dec/unibus/K-SP-M9312-0-5_Aug78.pdf</a>
Bitsavers also has an M9301 tech manual. And some M9301 ROM dumps
turned up at
<a class="moz-txt-link-freetext" href="http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Stuff.html">http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/PDP-11_Stuff.html</a><br>
<br>
Attach will accept switches, so you can provide loaders for straight
binary, ASCII (e.g. S-record or Intel Hex), or whatever else comes
to mind. I'd start with straight binary (byte 0 of the file maps to
ROM address +0).<br>
<br>
With this architecture, adding a boot (or device) ROM becomes as
simple as distributing the ROM image. And SimH doesn't have to
compile-in every ROM. And it would bring us closer to being able to
handle PDP-11 host and network boot.<br>
<br>
<br>
</body>
</html>