MEM11 Status Update
Guy Sotomayor
ggs at shiresoft.com
Tue Jan 20 09:27:15 CST 2015
On 1/20/15 6:09 AM, Noel Chiappa wrote:
> > From: Guy Sotomayor
>
> > a multi-function Unibus board that contains all of the more difficult
> > items to allow a PDP-11/20 to run Unix V1 entirely within the CPU
> > chassis. Other than the CPU and the RK11-D controller, everything else
> > will be on the MEM11 board.
> > ...
> > What's on the board is the following:
> > ...
> > RF11 controller with non-volatile memory emulating 8 RS11 drives
>
> What form is the NVM in - an SD card, or just a chip, or what? I assume it's
> flash memory of some kind? (What's the limit on the number of write cycles
> with current flash memory, I wonder...) BTW, a removable card would be great
> - that would provide a way to get bits into the machine, other than loading
> them all in over a serial line.
I'm using FRAM. They have unlimited write cycles and are accessed just
like SRAM. I didn't
want to have any sort of removable media as that bring its own sets of
challenges.
>
> I'm kind of curious about your decision to only have an RF11, given the
> capacity of contemporary flash memory chips/cards. Why not an RK11 too? (You
> may have plenty of RK controllers/drives, but some of the rest of us aren't so
> lucky... :-) Is there not enough room in the 16K code block to do that too?
> And how about an RP11 too, for those of us running these cards in later
> PDP-11's? :-)
The RF11 is because it's "fixed" so I knew what the maximum size would
be and didn't have
to come up with a UI to allow for pack changes.
Various disk emulators is another project. ;-)
>
> (Oh, speaking of the 16K limit - any way to increase the size? Probably not
> without munging the J1 architecture, I would guess - I need to go grab it and
> read it. But limited addresses spaces always turn out to bit you where it
> hurts... :-)
I looked at it but it's driven by the instruction encoding (all
instructions are 16-bits). One cool
thing is that the load immediate allows you to load 15 bits of data in
one instruction so there's
a bit of "fudging" to make constants not be a full 16-bits. ;-) Full
16-bit constants are possible,
it's just that they take 3 instructions. ;-)
>
>
> > As I was competing the configuration UI, I found that I couldn't have
> > both the configuration UI and the emulation code both fit in 16K
> > (strings take up a lot of space).
>
> I seem to recall this problem from my days of writing packet switches for
> PDP-11's... :-) The code was famous for log messages that left out all the
> vowels, to save space.. :-)
The UI doesn't currently have any sort of "help" which makes me sad.
However, I've been thinking
about it and I still have plenty of space in the primary FRAM, so I may
put all of the HELP text in
there an have the HELP command just know where to look for the text.
>
> Please, make the UI as cryptic as needed to make all the features (e.g. more
> disk controllers :-) fit - documentation can explain what all the cryptic
> names are. (Or perhaps even a front-end running on a PC which is connected to
> the MEM11 over the serial line.)
That was my original thought (command front end) but that would mean
writing/supporting a
bunch of different programs for different OS/platforms and I want the
MEM11 to pretty much
stand on its own (which is why I'm unhappy about not having HELP...but I
may have solved that
one). I intentionally didn't make the UI cryptic. It's all command
line driven and somewhat
verbose (ie SET DL11 0 BASE-ADDRESS 777540).
>
>
> Don't take any of this to mean I don't think this is really, really neat, and
> very impressive - it's both! Needless (perhaps) to say, I'll be buying a stack
> of these when they are ready! :-)
I plan on producing as many as folks want (including a few for myself)
but the realistic limit will
be on the Unibus interface ICs. I have (at last inventory) enough for
~25 boards. After that I'll have
to see if I can either source additional parts or re-design that part of
the board to use something
else.
TTFN - Guy
More information about the cctech
mailing list