[Simh] Custom ROMs on PDP-11 sim
Timothe Litt
litt at ieee.org
Sat Dec 16 10:21:40 EST 2017
On 16-Dec-17 07:35, Johnny Billquist wrote:
> Top-posting to make it simple, while still keeping the original text.
>
> 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.)
While this case is moot, dumping peripheral ROMs has come up before, so
correct information may be useful to someone in the future.
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.
It is true that in a typical OS driver, a CSR base is specified by an
absolute (if possibly mapped) address, with code like
mov #173100, r0 ; or
mov csrbase(R5), r0 ; where r5 points to some data structure, and
csrbase contains an absolute I/O address
bit #100, 4(r0)
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.
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.
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*.
Consider:
* Plugin a device with some CSRs, a boot ROM, and more than one IO
space address.
* (Since we're being pedantic, turn on power.)
* Press (processor) RESET
* Enter the boot ROM address in the switches; load address; start. (Or
the ASCII console equivalent.)
* 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.)
Either way, the ROM code is running, and ready to operate the device.
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.
"Divine inspiration" isn't an option.
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.
For the second case, the OS could pass a CSR address. But sane coders
will do something that works in both
cases. And saves code.
Note that the CSRs and the code live on the same (hardware) module. So
the offset between them is fixed.
(And, no, an OS isn't allowed to change the offset with memory mapping,
even when the distance might allow it.)
So, the CSRs are found using this offset and PC. That's relative
addressing - though there's more than one possible implementation.
PC-relative addressing is a perfectly valid (and sane) solution. Here
are some code snippets that illustrate the situation.
.title DevROM
.sbttl YMMV
.psect CSRs D,RW,GBL ; May or may not overlay part of the ROM
CSRBASE: .blkw 8 ; This device has 8 CSRs
CSR0 = CSRBASE+0
CSR1 = CSRBASE+2
CSR3 = CSRBASE+6
.psect CODE I,RO
bit #100, CSR0 ; This is PC-relative
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.
move PC, r0
10$: sub #<10$-CSRBASE>, r0
bit #100, (r0)
bic #200, 6(r0) ; Indexed - doesn't save space
or, if CSR3 gets used a lot, spend 3 words to save one/reference
mov r0, r1
add #<CSR3-CSR0>, r1
bic #200, (r1)
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.)
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.
As for data; all data references (pointers) need to be
position-independent - self-relative or relative to the base of the ROM.
Device base address:
+----------------------------+
| CSR 0
| CSR 1
| ...
| CSR n
| Gap
| Code
+----------------------------+
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.
(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.)
This brings us back to my original points:
* To execute code in a peripheral ROM that touches its CSRs, the ROM
must be in I/O space
* (Almost) certainly, the code will find its CSRs using PC-relative
offsets (addressing and/or math)
* Thus, if you load the ROM into RAM, it will assign some RAM location
to the CSRs. This won't work.
* 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 *and*
that the CSRs are implemented. E.g. a full device emulation must be
created.
* The code in the ROM must be PIC, as must any pointers to data.
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.
Before quoting doctrine and casting aspersions, it is best to completely
understand the problem.
>
>
> 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.
>
> But, as have been said several times now, this is all moot. Without
> the ROM contents, nothing to really do here.
>
> Johnny
>
> On 2017-12-16 12:14, Timothe Litt wrote:
>> On 15-Dec-17 22:14, khandy21yo wrote:
>>> Can't you just load them into ram and run them from there?
>>> Rom is just non writable memory.
>>>
>>>
>> He could, except that these ROMs are probably in I/O space, so would
>> need
>> to be part of a simulated device for any code to execute properly[1].
>> (And any
>> code in them probably touches the device registers, so you need the
>> device
>> to get anywhere.) As Mark pointed out, SimH doesn't currently
>> support any
>> devices that way - it does functional emulation of I/O devices. (It
>> wouldn't
>> be difficult to write such a device emulation if there were a reason
>> to.)
>>
>> However, to disassemble code/view data, they could be loaded into any
>> RAM
>> address & poked at with the SimH console.
>>
>> Some reformatting would be required, since ROMs of that era would
>> typically be
>> byte-wide, with 2 devices/word - e.g. one ROM contains the even bytes,
>> another
>> the odd ones. (There are other organizations.)
>>
>> FWIW, ROMs in I/O devices tend to be one or more of:
>>
>> * Code for on-board processors (rare in early PDP-11s, but Ethernet
>> and (t)MSCP boards had them)
>> * Identifying data for the device (e.g. device type, model, serial,
>> timing, geometry, etc)
>> * Bootcode/self-test/primitive driver for the host to execute
>> * Data for the host (e.g. Fonts or strings)
>>
>> However, as Aaron says that the devices have been erased, it's all moot
>> at this point :-)
>>
>> So that's probably more than you wanted to know...
>>
>> [1] While the code would likely be PIC, things like references to the
>> device's registers would also be relative to where the code is loaded.
>> Looping on a "done" bit relocated to RAM is likely to be frustrating...
>>
>>>
>>> Sent from my Galaxy Tab® A
>>>
>>> -------- Original message --------
>>> From: Aaron Jackson <aaron at aaronsplace.co.uk>
>>> Date: 12/15/17 10:37 AM (GMT-07:00)
>>> To: Mark Pizzolato <Mark at infocomm.com>
>>> Cc: simh at trailing-edge.com
>>> Subject: Re: [Simh] Custom ROMs on PDP-11 sim
>>>
>>> Hi Mark,
>>>
>>> It probably does not matter anymore unfortunately. I have a PDP-11 from
>>> a Unimation PUMA robot, which has a 16x EPROM board in it but no power
>>> supply. I was hoping to try running what was on them inside a
>>> simulator. I started dumping them and realised that they have all been
>>> erased before it was sent to me.
>>>
>>> Of course I could have tried installing the card in my PDP-11/73 but I
>>> thought there might have been an easier way with the simulator.
>>>
>>> Never mind, thanks anyway.
>>>
>>> Aaron.
>>>
>>>
>>>
>>>
>>>
>>> Mark Pizzolato writes:
>>>
>>>> Hi Aaron,
>>>>
>>>> On Friday, December 15, 2017 at 7:18 AM, Aaron Jackson wrote:
>>>>> I am wondering if it is possible to use attach ROM dumps in the
>>> PDP-11 simh?
>>>>> I haven't found anything about it in the documentation. If not, I
>>> suppose it
>>>>> wouldn't be too hard to modify the bootrom header.
>>>>
>>>> The PDP11 simulator (which simulates MANY different PDP11 models)
>>> doesn't
>>>> actually use any ROMs and doesn't currently support simulation of
>>> any cards
>>>> which user supplied ROMS might have been installed in.
>>>>
>>>> What problem are you trying to solve???
>>>>
>>>> - Mark
>>>
>>>
>>> --
>>> Aaron Jackson
>>> PhD Student, Computer Vision Laboratory, Uni of Nottingham
>>> http://aaronsplace.co.uk
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>>
>>>
>>> _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>>
>>
>>
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20171216/a58d339f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20171216/a58d339f/attachment-0001.bin>
More information about the Simh
mailing list