<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 16-Dec-17 07:35, Johnny Billquist wrote:<br>
<blockquote type="cite"
cite="mid:64aefdc3-cf35-87a3-13e0-232347b6bf44@softjar.se">Top-posting
to make it simple, while still keeping the original text.
<br>
<br>
While it is true that device access might be done using relative
addressing, that would in general be a bad software design. Things
like device CSRs should never be accessed as relative addresses,
but should be absolute. Any sane programmer should know that. And
it is not any extra effort in doing this on a PDP-11, so the
programmer have no real excuse for not doing it right. (But I know
that people sometimes still do things wrong anyway.)</blockquote>
<br>
While this case is moot, dumping peripheral ROMs has come up before,
so correct information may be useful to someone in the future.<br>
<br>
I'm pretty sure that (among other things), I'm knowledgeable, sane
and a programmer. I was not writing about "the general case". This
thread was specifically about ROMs embedded in a peripheral. This
is a different environment from the "general" case, and one where
your comments are off-base. This is the exception to *never*. It
has nothing to do with laziness or 'wrong'; I assumed neither. And
PIC is only one aspect of the problem as presented.<br>
<br>
It is true that in a typical OS driver, a CSR base is specified by
an absolute (if possibly mapped) address, with code like<br>
<br>
mov #173100, r0 ; or <br>
mov csrbase(R5), r0 ; where r5 points to some data structure,
and csrbase contains an absolute I/O address<br>
bit #100, 4(r0)<br>
<br>
This ensures that the *code* can be moved; *the device is at some
fixed address* determined by SYSGEN, autoconfiguration, or the
like. So the references are register deferred and/or indexed
relative to an "absolute" address. The code should be PIC, as most
(later) OSs want to be able to dynamically load drivers. I'd agree
that in this case, PIC with an absolute device address is the
preferred (and sometimes required) implementation.<br>
<br>
In the specific case of a device ROM, CSR access would indeed be
properly done with relative addressing. There isn't much (sane)
choice. Calling it 'bad software design' is inappropriate, and
overlooks the environmental constraints and functional requirements
of a device ROM.<br>
<br>
The key point is that a device ROM is an integral part of the
peripheral that it serves; its CSRs are at a fixed offset to the
code, but both are at an unknown base address. *There is no
absolute address; both the CSRs and the code are relocatable* as a
unit: when the peripheral is installed, and when/if an OS maps it to
a virtual address. And *executing the code requires that the CSRs
are emulated*. Thus, *both the code and CSR references in the ROM
must be position-independent*.<br>
<br>
Consider: <br>
<ul>
<li>Plugin a device with some CSRs, a boot ROM, and more than one
IO space address.</li>
<li>(Since we're being pedantic, turn on power.)</li>
<li>Press (processor) RESET</li>
<li>Enter the boot ROM address in the switches; load address;
start. (Or the ASCII console equivalent.)</li>
</ul>
<ul>
<li>Later, the OS may have mapped the device at some random (well,
properly aligned) virtual address, and calls into the boot rom
for some function that it provides. (For a disk, it might be to
write a crash dump.)<br>
</li>
</ul>
Either way, the ROM code is running, and ready to operate the
device.<br>
<br>
Now, where, exactly is an absolute address for the CSRs going to
come from? There is no generally useful absolute address that can
be encoded in the ROM.<br>
<br>
"Divine inspiration" isn't an option.<br>
<br>
For the first case, there's no outside source of data. No OS data
structure or config file; no base address in a register. And
implementing autoconfigure is not practical. (You'd probably call a
proposer 'not sane'). The code can't read its CSRs to find its
Unibus address - because the problem is finding its CSRs. But it
does have PC.<br>
<br>
For the second case, the OS could pass a CSR address. But sane
coders will do something that works in both<br>
cases. And saves code.<br>
<br>
Note that the CSRs and the code live on the same (hardware) module.
So the offset between them is fixed.<br>
(And, no, an OS isn't allowed to change the offset with memory
mapping, even when the distance might allow it.)<br>
<br>
So, the CSRs are found using this offset and PC. That's relative
addressing - though there's more than one possible implementation.<br>
<br>
PC-relative addressing is a perfectly valid (and sane) solution.
Here are some code snippets that illustrate the situation.<br>
<br>
.title DevROM<br>
.sbttl YMMV<br>
<br>
.psect CSRs D,RW,GBL ; May or may not overlay part of the ROM<br>
CSRBASE: .blkw 8 ; This device has 8 CSRs<br>
<br>
CSR0 = CSRBASE+0<br>
CSR1 = CSRBASE+2<br>
CSR3 = CSRBASE+6<br>
<br>
.psect CODE I,RO<br>
bit #100, CSR0 ; This is PC-relative<br>
<br>
Of course, if CSRs are referenced more than once some space can be
saved by putting one or more CSR addresses into (a) register(s) and
using register deferred addressing. But those addresses are
determined relative to the PC - so somewhere, there is still
PC-relative address computation.<br>
<br>
move PC, r0<br>
10$: sub #<10$-CSRBASE>, r0<br>
bit #100, (r0)<br>
<br>
bic #200, 6(r0) ; Indexed - doesn't save space<br>
or, if CSR3 gets used a lot, spend 3 words to save one/reference<br>
mov r0, r1<br>
add #<CSR3-CSR0>, r1<br>
bic #200, (r1)<br>
<br>
The only case that a peripheral ROM wouldn't find its CSRs using the
PC is where it has no code. (Or, if ITS coder wasn't 'sane' - e.g.
forced the device to a fixed address in IO space.)<br>
<br>
And yes, the code must be PIC - that is, the code's references to
itself must be position-independent since the hardware can be
installed at various addresses, and the OS can later map it to one
or more VAs.<br>
<br>
As for data; all data references (pointers) need to be
position-independent - self-relative or relative to the base of the
ROM.<br>
<br>
Device base address:<br>
+----------------------------+<br>
| CSR 0<br>
| CSR 1<br>
| ...<br>
| CSR n<br>
| Gap<br>
| Code<br>
+----------------------------+<br>
<br>
Exactly how the hardware is implemented may vary. Usually the CSRs
are below the code, though the converse can be true. And whether
the gap exists - and how big varies. Sometimes CSRs overlay the
ROM; others the gap aligns the code to a convenient boundary for
address multiplexing - no sane hardware designer of this period
would have included an adder.<br>
<br>
(Note that 'gap' here is not the 'gap' used in floating address
assignments; if in floating address space, it must not NXM modulo
10, per the address assignment rules.)<br>
<br>
This brings us back to my original points:<br>
<ul>
<li>To execute code in a peripheral ROM that touches its CSRs, the
ROM must be in I/O space</li>
<li>(Almost) certainly, the code will find its CSRs using
PC-relative offsets (addressing and/or math)</li>
<li>Thus, if you load the ROM into RAM, it will assign some RAM
location to the CSRs. This won't work.</li>
<li>If the ROM contains code that talks to the device, it is a
near certainty (not a 'risk') that it must be placed in I/O
space <b>and</b> that the CSRs are implemented. E.g. a full
device emulation must be created.</li>
<li>The code in the ROM must be PIC, as must any pointers to data.</li>
</ul>
It is always possible that someone built a device that has a single
fixed Unibus address (e.g. no more than one per system, no address
jumpers). And that the ROM is never called with memory mapping
enabled. In that case, all the PIC requirements go away. However,
it would still require working CSRs, however they're found. But
that would be a design with severe limitations, and I'd be surprised
if an engineer with any PDP-11 background would have created such a
beast.<br>
<br>
Before quoting doctrine and casting aspersions, it is best to
completely understand the problem.<br>
<br>
<blockquote type="cite"
cite="mid:64aefdc3-cf35-87a3-13e0-232347b6bf44@softjar.se">
<br>
<br>
However, that said, actually writing programs fully PIC on a
PDP-11 takes a little more effort, and many times, people didn't
do that, so there is a risk that the program really needs to run
located on the addresses given by the card.
<br>
<br>
But, as have been said several times now, this is all moot.
Without the ROM contents, nothing to really do here.
<br>
<br>
Johnny
<br>
<br>
On 2017-12-16 12:14, Timothe Litt wrote:
<br>
<blockquote type="cite">On 15-Dec-17 22:14, khandy21yo wrote:
<br>
<blockquote type="cite">Can't you just load them into ram and
run them from there?
<br>
Rom is just non writable memory.
<br>
<br>
<br>
</blockquote>
He could, except that these ROMs are probably in I/O space, so
would need
<br>
to be part of a simulated device for any code to execute
properly[1].
<br>
(And any
<br>
code in them probably touches the device registers, so you need
the device
<br>
to get anywhere.) As Mark pointed out, SimH doesn't currently
support any
<br>
devices that way - it does functional emulation of I/O devices.
(It
<br>
wouldn't
<br>
be difficult to write such a device emulation if there were a
reason to.)
<br>
<br>
However, to disassemble code/view data, they could be loaded
into any RAM
<br>
address & poked at with the SimH console.
<br>
<br>
Some reformatting would be required, since ROMs of that era
would
<br>
typically be
<br>
byte-wide, with 2 devices/word - e.g. one ROM contains the even
bytes,
<br>
another
<br>
the odd ones. (There are other organizations.)
<br>
<br>
FWIW, ROMs in I/O devices tend to be one or more of:
<br>
<br>
* Code for on-board processors (rare in early PDP-11s, but
Ethernet
<br>
and (t)MSCP boards had them)
<br>
* Identifying data for the device (e.g. device type, model,
serial,
<br>
timing, geometry, etc)
<br>
* Bootcode/self-test/primitive driver for the host to execute
<br>
* Data for the host (e.g. Fonts or strings)
<br>
<br>
However, as Aaron says that the devices have been erased, it's
all moot
<br>
at this point :-)
<br>
<br>
So that's probably more than you wanted to know...
<br>
<br>
[1] While the code would likely be PIC, things like references
to the
<br>
device's registers would also be relative to where the code is
loaded.
<br>
Looping on a "done" bit relocated to RAM is likely to be
frustrating...
<br>
<br>
<blockquote type="cite">
<br>
Sent from my Galaxy Tab® A
<br>
<br>
-------- Original message --------
<br>
From: Aaron Jackson <a class="moz-txt-link-rfc2396E" href="mailto:aaron@aaronsplace.co.uk"><aaron@aaronsplace.co.uk></a>
<br>
Date: 12/15/17 10:37 AM (GMT-07:00)
<br>
To: Mark Pizzolato <a class="moz-txt-link-rfc2396E" href="mailto:Mark@infocomm.com"><Mark@infocomm.com></a>
<br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:simh@trailing-edge.com">simh@trailing-edge.com</a>
<br>
Subject: Re: [Simh] Custom ROMs on PDP-11 sim
<br>
<br>
Hi Mark,
<br>
<br>
It probably does not matter anymore unfortunately. I have a
PDP-11 from
<br>
a Unimation PUMA robot, which has a 16x EPROM board in it but
no power
<br>
supply. I was hoping to try running what was on them inside a
<br>
simulator. I started dumping them and realised that they have
all been
<br>
erased before it was sent to me.
<br>
<br>
Of course I could have tried installing the card in my
PDP-11/73 but I
<br>
thought there might have been an easier way with the
simulator.
<br>
<br>
Never mind, thanks anyway.
<br>
<br>
Aaron.
<br>
<br>
<br>
<br>
<br>
<br>
Mark Pizzolato writes:
<br>
<br>
<blockquote type="cite">Hi Aaron,
<br>
<br>
On Friday, December 15, 2017 at 7:18 AM, Aaron Jackson
wrote:
<br>
<blockquote type="cite">I am wondering if it is possible to
use attach ROM dumps in the
<br>
</blockquote>
</blockquote>
PDP-11 simh?
<br>
<blockquote type="cite">
<blockquote type="cite">I haven't found anything about it in
the documentation. If not, I
<br>
</blockquote>
</blockquote>
suppose it
<br>
<blockquote type="cite">
<blockquote type="cite">wouldn't be too hard to modify the
bootrom header.
<br>
</blockquote>
<br>
The PDP11 simulator (which simulates MANY different PDP11
models)
<br>
</blockquote>
doesn't
<br>
<blockquote type="cite">actually use any ROMs and doesn't
currently support simulation of
<br>
</blockquote>
any cards
<br>
<blockquote type="cite">which user supplied ROMS might have
been installed in.
<br>
<br>
What problem are you trying to solve???
<br>
<br>
- Mark
<br>
</blockquote>
<br>
<br>
--
<br>
Aaron Jackson
<br>
PhD Student, Computer Vision Laboratory, Uni of Nottingham
<br>
<a class="moz-txt-link-freetext" href="http://aaronsplace.co.uk">http://aaronsplace.co.uk</a>
<br>
_______________________________________________
<br>
Simh mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
<br>
<br>
<br>
_______________________________________________
<br>
Simh mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
<br>
</blockquote>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
Simh mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</body>
</html>