20 Jan
2015
20 Jan
'15
6:09 a.m.
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 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? :-)
(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... :-)
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.. :-)
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.)
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! :-)
Noel
20 Jan
20 Jan
7:27 a.m.
On 1/20/15 6:09 AM, Noel Chiappa wrote:
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.
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.
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 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.. :-)
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
8:03 a.m.
My hope is to drop one of these boards in my 11/45. The only issue is I'm
afraid even though it will give the /45 maximum memory (as I understand it,
Guys board includes the MMU) that it won't be enough to run my favored OS on
that platform which is RT-11 (for about 10 seconds, yes, I know that will
fit) and then TSX+ v5x (which I'm not sure will fit).
I think the minimum memory for TSX+ is 256kb... but that's the minimum and I
think Guys board would take the /45 to 128kw (256kb). Anyone know for sure
if TSX+ will run on a /45 with 128kw?
I think I have too many pdp11 racks and it could be time to thin the herd
before too long. Or maybe I just need to get more space. Yah, that's the
ticket!
J
8:20 a.m.
Can you upload your TSX+ images? The only ones I have are corrupted.
Sent from my iPhone
On Jan 20, 2015, at 11:03, Jay West <jwest at
classiccmp.org> wrote:
My hope is to drop one of these boards in my 11/45. The only issue is I'm
afraid even though it will give the /45 maximum memory (as I understand it,
Guys board includes the MMU) that it won't be enough to run my favored OS on
that platform which is RT-11 (for about 10 seconds, yes, I know that will
fit) and then TSX+ v5x (which I'm not sure will fit).
I think the minimum memory for TSX+ is 256kb... but that's the minimum and I
think Guys board would take the /45 to 128kw (256kb). Anyone know for sure
if TSX+ will run on a /45 with 128kw?
I think I have too many pdp11 racks and it could be time to thin the herd
before too long. Or maybe I just need to get more space. Yah, that's the
ticket!
J
8:37 a.m.
On 20 January 2015 at 15:27, Guy Sotomayor <ggs at shiresoft.com> wrote:
One possible random thought - you could have a supporting program
which just provides an enhanced CLI interface, with all the help, TAB
for commandline completion etc, command history, plus local commands
to load/save the config to a file and an xmodem implementation.
It should be _relatively_ easy to keep it OS agnostic with small per
OS methods for opening the serial port and reading characters from the
CLI.
The base system would still be completely standalone, but the enhanced
UI would be easy to spin up for those who like a plush armchair CLI
experience :)
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). 
9:35 a.m.
On Tue, Jan 20, 2015 at 07:27:15AM -0800, Guy Sotomayor wrote:
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.
Aw sweet! I was going to jump in and suggest FRAM (it's the only part of
my on-paper RF08/RS08 emulator that I've actually built) but you're way
ahead of me. It's such cool stuff -- the parallel version might even make
sense for an Omnibus RAM board, if we didn't already have new ones of those
recently. I love the fact that a whole string of RS08s fits on a
daughterboard that's about 2" square (with the serial version), and
the write durability is way above a real RS08.
This sounds like an unbelievably awesome project. Nice going!
John Wilson
D Bit
3576
days inactive
3576
days old
5 comments
6 participants
participants (6)
-
abs＠absd.org -
b4＠gewt.net -
ggs＠shiresoft.com -
jnc＠mercury.lcs.mit.edu -
jwest＠classiccmp.org -
wilson＠dbit.com