[Simh] Custom ROMs on PDP-11 sim
Johnny Billquist
bqt at softjar.se
Sat Dec 16 18:07:07 EST 2017
On 2017-12-16 23:32, Timothe Litt wrote:
>
> On 16-Dec-17 16:38, Johnny Billquist wrote:
>>
>> However, such a device would be wrong to start with. And I've never
>> seen anyone do that, but sure, it could be done.
>>
> Read the OP. He has such a device. It has ROMs with PDP-11 code -- or
> at least, that's his assumption. And it's a Unimate robot controller.
> If that assumption is correct, it fits the architecture that I described.
No, you are making several assumptions here.
First of all, there is nothing saying that it even works if you have
several devices. Second, we do not know if it can be at different
addresses. Third, even though you have ROMs on it, there is nothing that
says that those are even exposed to the PDP-11. Fourth, what was often
done was that if you had PDP-11 code available on the card, it was
separately enabled compared to the CSRs as such, and if the memory was
enabled, it was located at a fixed address in I/O space (several
examples of such controllers exist). Fifth, another solution some
controllers applied was that the code would be DMAd from ROMs into
PDP-11 ram, and then executed from there, and that was only used for
diagnostics and configuration stuff (see most SCSI controllers for
example). Point 4 and 5 have lots of previous art, and those are the
only ones I know of which present any PDP-11 code, and those do not use
the scheme you are suggesting, but do use absolute addresses for CSRs in
the PDP-11 code. For the SCSI controllers, you interactively have to
tell which CSR the code should access, and for some other controllers,
they have the code at a fixed address, for booting, and only support
booting from the controller at a fixed CSR address.
>> But with the limited space in the I/O page, you would not want to have
>> the same code replicated all over the space.
> It depends. If I were an OEM, and I anticipated a small number of my
> devices per CPU, this would be a good way to avoid having a separate ROM
> module. Robots costing $100Ks fit that bill.
>
> Further, the typical code isn't very large. For example, the M9301-YA,
> 512 words - in I/O space, can bootstrap 8 different devices AND has 7
> CPU self-tests and a memory test. The -YB has a console emulator,
> self-tests, and 11 device bootstraps.
Yes. And these bootstraps are very tight, and only works on fixed CSR
addresses.
> So it's quite plausible to have a host-run self-test, bootstrap,
> calibration, or other code on- board without consuming unreasonable
> amounts of I/O space.
If you repeat those 512 word on each card, you'll run out of I/O space
after 6 cards (at best). Add any other devices, and you hit trouble even
earlier.
> There are other schemes to avoid duplication, but I'll leave those as an
> exercise for the reader.
Any scheme will by necessity have you not repeat the same code and
memory use on each card.
>> So in the end no, I do not believe that it would ever be the right
>> thing to have relative addressing for CSRs. Your example is valid in
>> that such a design would make sense to have relative addressing, but
>> such a device is already a wrong thing to start with, and should not be.
>>
> You don't get to decide and enforce what is right/wrong or what should
> not be. As a system architect, I had some power to ordain what should
> be. But one quickly discovers that even that power is limited. You can
> have an opinion, but sometimes reality butts in. Your idea of
> architectural purity and/or design constraints will be tested (and
> changed) by Manufacturing, OEMs, customers, and the field - which have
> their own challenges.
>
> It is unwise to assume that you know enough to say "never" or "always".
> Unless you like being proven wrong.
I certainly do not get to decide right or wrong.
The rest we can continue argue, if you want to.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
More information about the Simh
mailing list