29 Aug
2015
29 Aug
'15
10:05 p.m.
I'm making good progress on the MEM11 firmware. I spent the last few days
re-doing the firmware build environment. Previously, it would build all the
files each time. Now there is a proper Makefile (even though it takes about
a minute to build everything). I realized that I needed something
better than
what I had because there are multiple targets (emulator, FPGA eval board and
the MEM11 board itself). Right now I'm focused on getting as much debugged
on the emulator since it has a reasonable debuging environment.
I've also integrated various test programs into the build environment
and use
various low level code as part of the main firmware for hardware access.
This "kills two birds with one stone" since it tests not only the
various hardware
functions it also allows me to debug some of the firmware separately from
the full code base.
At this point, the emulator fully supports all of the J1 instructions
(and they
all work too!). In terms of I/O (that will be part of the MEM11 board) it
supports LEDs and various configuration inputs, FRAM, UART and timers.
The biggest risk that I'm taking is that the UART is emulated as being
directly exposed. On the MEM11 hardware, the UART will be connected
through a SPI interface which requires that all accesses to the UART are
asynchronous transactions.
The biggest piece of work remaining on the emulator will be emulating the
Unibus interface. The work here will mainly to create a means to script
various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and
the configuration firmware since none of that is dependent upon the
existence of functional Unibus hardware.
TTFN - Guy
29 Aug
29 Aug
10:16 p.m.
Hi Guy,
Hello!?! What is the MEM11 Board and are there other boards to make this a fully
functional PDP11? I definitely want to know! Thanks in advance.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/Kip_Koon
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Guy Sotomayor
Sent: Sunday, August 30, 2015 1:06 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: MEM11 Status Update
I'm making good progress on the MEM11 firmware. I spent the last few days re-doing
the firmware build environment. Previously, it
would build all the files each time. Now there is a proper Makefile (even though it
takes about a minute to build everything). I
realized that I needed something better than what I had because there are multiple
targets (emulator, FPGA eval board and the
MEM11 board itself). Right now I'm focused on getting as much debugged on the
emulator since it has a reasonable debuging
environment.
I've also integrated various test programs into the build environment and use various
low level code as part of the main firmware for
hardware access.
This "kills two birds with one stone" since it tests not only the various
hardware functions it also allows me to debug some of the
firmware separately from the full code base.
At this point, the emulator fully supports all of the J1 instructions (and they all work
too!). In terms of I/O (that will be part of the
MEM11 board) it supports LEDs and various configuration inputs, FRAM, UART and timers.
The biggest risk that I'm taking is that the UART is emulated as being directly
exposed. On the MEM11 hardware, the UART will be
connected through a SPI interface which requires that all accesses to the UART are
asynchronous transactions.
The biggest piece of work remaining on the emulator will be emulating the Unibus
interface. The work here will mainly to create a
means to script various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and the
configuration firmware since none of that is dependent
upon the existence of functional Unibus hardware.
TTFN - Guy
11:08 p.m.
The MEM11 is a multi-function memory board for Unibus based PDP-11
computers. It contains:
* 128KW memory
* Emulates console ROM & boot ROMs
* 2 SLUs (DL11s)
* KW11K
* KW11P
* KW11L
* KW11W
* RF11 (emulating up to 8 RS11 disks)
* KE11
Because of the large number of devices that exist on the board, it
operates in 2 modes:
- Run Mode. This is the operational mode of the MEM11 where it
appears as the
indicated devices to the rest of the PDP11.
- Config Mode. This is a mode where the devices on the MEM11 can
be configured.
This is all done though a CLI that is accessed through one of
the SLUs.
Because all of this is implemented in firmware on the MEM11 board (it
contains a J1
uP in the FPGA), I've implemented a boot loader to load various versions
of the code
into the FPGA. The firmware is stored in the FRAM not used for
emulating the
Unibus memory, ROMs or RS11 disks. The boot loader (based upon the
settings of
the only 2 jumpers on the board) will determine what code to load into
the FPGA.
It should be noted that the memory that the J1 executes out of is all
contained in
the FPGA itself. The J1 RAM (as it's called) initially contains the
"cold boot" loader
which determines which area from the FRAM is to be loaded.
When in Config Mode, various parts of the FRAM can be updated. This
allows for
me to send out firmware updates without folks having to use a JTAG
programmer.
Config Mode also contains the ability to transfer data to/from the
various FRAM
regions using the XMODEM protocol. This also allows for the various ROM
images
to be loaded/dumped as well as the contents of the RS11 disks.
The biggest struggle has been one of space. The J1 only has 16KB of RAM
space.
Right now the Config Mode image is a bit over 15KB. I also have to
reserve 512B
in each image for the boot loader. In order to get the Config Mode
image to fit
all of the strings that are used for printing, parsing, help text, etc.
remain in FRAM.
Individual strings are only fetched into J1 RAM when the string is to be
used.
The Config Mode firmware is now complete. I've been building up the
emulator
so that I'm very close to starting to actually debug the full firmware
image. I have
a few other tests to perform first.
The Run Mode firmware is not yet complete. The main parts of the firmware
have been written. Currently the Run Mode firmware supports:
- Unibus memory
- ROMs
- SLUs
I want to get that working on the emulator before I write the remaining
firmware.
The main objective is to provide the memory and I/O necessary to be able
to run
Unix V1 (I also added a few more things because they're just "code").
There's a lot to this (and various things have kept me from working on
this as
much as I wanted to). I also plan on providing fairly detailed
documentation
with each board (but there is a fairly extensive help system in Config
Mode).
TTFN - Guy
On 8/29/15 10:16 PM, Kip Koon wrote:
Hi Guy,
Hello!?! What is the MEM11 Board and are there other boards to make this a fully
functional PDP11? I definitely want to know! Thanks in advance.
Kip Koon
computerdoc at sc.rr.com
http://www.cocopedia.com/wiki/index.php/Kip_Koon
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Guy Sotomayor
Sent: Sunday, August 30, 2015 1:06 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: MEM11 Status Update
I'm making good progress on the MEM11 firmware. I spent the last few days re-doing
the firmware build environment. Previously, it
would build all the files each time. Now there is a proper Makefile (even though it
takes about a minute to build everything). I
realized that I needed something better than what I had because there are multiple
targets (emulator, FPGA eval board and the
MEM11 board itself). Right now I'm focused on getting as much debugged on the
emulator since it has a reasonable debuging
environment.
I've also integrated various test programs into the build environment and use various
low level code as part of the main firmware for
hardware access.
This "kills two birds with one stone" since it tests not only the various
hardware functions it also allows me to debug some of the
firmware separately from the full code base.
At this point, the emulator fully supports all of the J1 instructions (and they all work
too!). In terms of I/O (that will be part of the
MEM11 board) it supports LEDs and various configuration inputs, FRAM, UART and timers.
The biggest risk that I'm taking is that the UART is emulated as being directly
exposed. On the MEM11 hardware, the UART will be
connected through a SPI interface which requires that all accesses to the UART are
asynchronous transactions.
The biggest piece of work remaining on the emulator will be emulating the Unibus
interface. The work here will mainly to create a
means to script various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and the
configuration firmware since none of that is dependent
upon the existence of functional Unibus hardware.
TTFN - Guy
31 Aug
31 Aug
10:05 a.m.
On 8/30/2015 1:08 AM, Guy Sotomayor wrote:
The MEM11 is a multi-function memory
board for Unibus based PDP-11
computers. It contains:
* 128KW memory
* Emulates console ROM & boot ROMs
* 2 SLUs (DL11s)
* KW11K
* KW11P
* KW11L
* KW11W
* RF11 (emulating up to 8 RS11 disks)
* KE11
Guy,
Fascinating and great work (not that
I understand more than a bare minimum).
Is this board something that will
work with the PDP-11/05? The 11/05 has
a built-in console SLU which I'm not
sure whether can be disabled or not.
Thank you-
-John
10:21 a.m.
On 8/31/15 10:05 AM, js at cimmeri.com wrote:
On 8/30/2015 1:08 AM, Guy Sotomayor wrote:
It should work (famous last words!) in any Unibus based PDP-11.
Any of the devices can be configured enabled/disabled and as to what the
based address
is (this includes the memory...if you want to use the memory to "fill
in" the remainder, it
can do that too). There is space for 32 boot ROM images, of which you
can select any 4
to appear in the Unibus address space.
So, that was a long answer to if (for example) on the 11/05 you want to
retain the built
in console SLU, you can do that and either have 2 additional SLUs, (or 1
or none).
TTFN - Guy
The MEM11 is a multi-function memory board for
Unibus based PDP-11
computers. It contains:
* 128KW memory
* Emulates console ROM & boot ROMs
* 2 SLUs (DL11s)
* KW11K
* KW11P
* KW11L
* KW11W
* RF11 (emulating up to 8 RS11 disks)
* KE11
Guy,
Fascinating and great work (not that I understand more than a bare
minimum).
Is this board something that will work with the PDP-11/05? The
11/05 has a built-in console SLU which I'm not sure whether can be
disabled or not.
1 Sep
1 Sep
8:01 a.m.
On Sun, Aug 30, 2015 at 1:08 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:
The MEM11 is a multi-function memory board for Unibus
based PDP-11
computers. It contains:
* 128KW memory
* Emulates console ROM & boot ROMs
* 2 SLUs (DL11s)
* KW11K
* KW11P
* KW11L
* KW11W
* RF11 (emulating up to 8 RS11 disks)
* KE11
Nice collection of features!
The main objective is to provide the memory and I/O
necessary
to be able to run Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
According to http://www.in-ulm.de/~mascheck/various/ancient/index.html
Unix v1 requires/supports:
"32K, RF-11 + RK03 disks, KE11A module [extended arithmetic element
for multiply/divide], DC-11 8 TTYs, TC-11 DECTape"
I haven't dug through the device driver code, but I expect that the RK
driver would support either the RK11-C (Flip Chips) or the RK11-D
(M7254, M7255, M7256 and M7257) since AFAIK they are
register-compatible. I have both, but the RK11-D has been tested/used
(the RK11-C has a lot of parts and a lot of connections to corrode).
At least an RK11-D and one or more RK05s is a lot easier to find than,
say, an RF11.
-ethan
8:39 a.m.
On 9/1/2015 10:01 AM, Ethan Dicks wrote:
You could also try Mini-Unix on your 11/20, which might support a wider
range of devices.
http://www.tuhs.org/Archive/PDP-11/Distributions/usdl/Mini-Unix/
The main objective is to provide the memory and
I/O necessary
to be able to run Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
5:56 p.m.
On Tue, Sep 1, 2015 at 11:39 AM, Jay Jaeger <cube1 at charter.net> wrote:
On 9/1/2015 10:01 AM, Ethan Dicks wrote:
You could also try Mini-Unix on your 11/20, which might support a wider
range of devices.
I could, but the point is to run 1972 Unix on machine that was around
in 1972, even if I have emulate things like the RF disks.
-ethan
run Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
9:19 p.m.
On 9/1/2015 7:56 PM, Ethan Dicks wrote:
On Tue, Sep 1, 2015 at 11:39 AM, Jay Jaeger <cube1
at charter.net> wrote:
I suppose. Mini Unix dates from around 1977, though I remember LSX
showing up around 1975 or 1976.
Jay
On 9/1/2015 10:01 AM, Ethan Dicks wrote:
You could also try Mini-Unix on your 11/20, which might support a wider
range of devices.
I could, but the point is to run 1972 Unix on machine that was around
in 1972, even if I have emulate things like the RF disks.
-ethan
run Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
2 Sep
2 Sep
8:42 a.m.
On Tue, Sep 1, 2015 at 11:39 AM, Jay Jaeger<cube1 at charter.net> wrote:
On 9/1/2015 10:01 AM, Ethan Dicks wrote:
You could also try Mini-Unix on your 11/20, which might support a wider range of
devices.
Very interesting. Does Guy's MEM11 provide what's needed for Mini Unix without
having to write special drivers?
- John
run
Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
10:50 a.m.
On 9/2/15 8:42 AM, js at cimmeri.com wrote:
On Tue, Sep 1, 2015 at 11:39 AM, Jay Jaeger<cube1 at charter.net> wrote:
Not sure what Mini-Unix requires w.r.t. devices.
TTFN - Guy
On 9/1/2015 10:01 AM, Ethan Dicks wrote:
You could also try Mini-Unix on your 11/20, which might support a
wider range of devices.
Very interesting. Does Guy's MEM11 provide what's needed for Mini
Unix without having to write special drivers?
run
Unix V1
I am very interested in the MEM11 for this exact reason. I have a
PDP-11/20 that I'd love to do this with.
11:33 a.m.
> run Unix
V1
I am very interested in the MEM11
for this exact reason. I have a
PDP-11/20 that I'd love to do this
with. [Ethan Dicks]
You could also try Mini-Unix on your
11/20, which might support a wider
range of devices. [Jay Jaeger]
10:07 p.m.
On 9/1/15 9:45 PM, tony duell wrote:
I think the point here, is that much of the hardware that
is necessary
to run Unix V1 on an
11/20 is unobtainium. Therefor, if one wants to run Unix V1 on 11/20
hardware, there is
going to be, by necessity, some compromises made. Witness the previous
discussion on
the IBM 1620 where the core memory has been replaced with a modern
equivalent in order
to allow it to work. I view this in a similar vein.
I also think that given the historical significance of both Unix V1 and
the 11/20, this is a
worthwhile endeavor.
TTFN - Guy
I could, but
the point is to run 1972 Unix on machine that was around
in 1972, even if I have emulate things like the RF disks.
Except that the MEM11
wasn't around in 1972. 
10:10 p.m.
I could, but the point is to run 1972 Unix on machine
that was around
in 1972, even if I have emulate things like the RF disks.
Except that the MEM11
wasn't around in 1972. going to be, by necessity, some compromises made.
Witness the previous
Remaking the missing hardware following the original designs and using technology
close to the original is one thing. A functional emulator is something quite different.
The 11/20 in 1972 did not (AFAIK) use any programmable logic chips, for example.
discussion on
the IBM 1620 where the core memory has been replaced with a modern
equivalent in order
to allow it to work. I view this in a similar vein.
So do I.
-tony
10:18 p.m.
On 9/1/15 10:10 PM, tony duell wrote:
I think the point here, is that much of the hardware
that is necessary
to run Unix V1 on an
11/20 is unobtainium. Therefor, if one wants to run Unix V1 on 11/20
hardware, there is I don't think you are running Unix V1 on 11/20 hardware
here. An 11/20 CPU,
sure, but a computer system is not just the CPU.
Do let me know when you've got a production line going for a new RS11.
Until then, I suppose the MEM11 will have to do...
- Josh
I could, but
the point is to run 1972 Unix on machine that was around
in 1972, even if I have emulate things like the RF disks.
Except that the MEM11
wasn't around in 1972. going to be, by necessity, some compromises made.
Witness the previous
Remaking the missing hardware following the original designs
and using technology
close to the original is one thing. A functional emulator is something quite different.
The 11/20 in 1972 did not (AFAIK) use any programmable logic chips, for example. 
30 Aug
30 Aug
12:50 a.m.
-----Oorspronkelijk bericht-----
From: Guy Sotomayor
Sent: Sunday, August 30, 2015 7:05 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: MEM11 Status Update
[... snip ...]
The biggest piece of work remaining on the emulator will be emulating the
Unibus interface. The work here will mainly to create a means to script
various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and
the configuration firmware since none of that is dependent upon the
existence of functional Unibus hardware.
TTFN - Guy
------------
Guy,
as you have sort-of all possible UNIBUS transactions because
of the devices supported by the MEM11, I guess there is still
so work to do ;-)
One question came to my mind.
Suppose I manage to "crash" the board in such a bad way that
it does not start up anymore. Is there a jumper to force it to
execute a "golden boot"? That is, load a minimal "kernel" to
bring the MEM11 back to life to reload the bootloader and
firmware?
Shipping a dead MEM11 back to the Creator inside USA is
OK, but from Europe etc. might get costly. And Customs
probably wants to put tax on it when shipped back from you.
Good work!
- Henk
8:45 a.m.
On 8/30/15 12:50 AM, Henk Gooijen wrote:
-----Oorspronkelijk bericht----- From: Guy Sotomayor
Sent: Sunday,
August 30, 2015 7:05 AM To: General Discussion: On-Topic and Off-Topic
Posts Subject: MEM11 Status Update
[... snip ...]
The biggest piece of work remaining on the emulator will be emulating the
Unibus interface. The work here will mainly to create a means to script
various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and
the configuration firmware since none of that is dependent upon the
existence of functional Unibus hardware.
TTFN - Guy
------------
Guy,
as you have sort-of all possible UNIBUS transactions because
of the devices supported by the MEM11, I guess there is still
so work to do ;-)
One question came to my mind.
Suppose I manage to "crash" the board in such a bad way that
it does not start up anymore. Is there a jumper to force it to
execute a "golden boot"? That is, load a minimal "kernel" to
bring the MEM11 back to life to reload the bootloader and
firmware?
Shipping a dead MEM11 back to the Creator inside USA is
OK, but from Europe etc. might get costly. And Customs
probably wants to put tax on it when shipped back from you.
Yea, I'm trying to avoid having folks to send stuff back to me.
The FRAM map that I'm currently working with has locations
for 5 complete firmware images. The bootloader and Config
Mode firmware all have support for this. Here's what they are for:
- 2 sets of Config Mode images. This allows for downloading
a new image while still keeping the previous one around.
- 2 sets of Run Mode images. This allows for downloading
a new image while still keeping the previous one around.
- a "safe" Config Mode image. This image will be used when
the jumpers are set to "safe" mode or the boot loader
determines that the selected image isn't bootable. This
image is *not* writable by the MEM11 firmware. I *may*
decide to physically write protect it (the FRAM allows me to
write protect sections).
I'm seriously contemplating putting something in the cold boot
code (initial J1 RAM contents) that allows for downloading
image contents into FRAM. This would help me out when I'm
bringing up an individual board for the first time (ie manufacturing).
It would also allow for recovery if the safe boot image became
corrupted for some reason.
I'm hoping that with all of the above, the only time a board would
have to be shipped back to me would be in the case of a HW failure.
TTFN - Guy
8:55 a.m.
On 8/30/15 8:45 AM, Guy Sotomayor wrote:
On 8/30/15 12:50 AM, Henk Gooijen wrote:
I also forgot to mention that the cold boot code is contained within
the FPGA bitstream. So if the cold boot code is corrupted, the FPGA
probably won't be programmed properly. However, the FPGA bitstream
is located in its own flash part which is not writable/accessable by
the firmware. It's only accessible through JTAG. There will be a
header on the board since I won't have the flash parts pre-programmed
and it also allows me to update the FPGA bitstream after the board
has been built.
So, if the cold boot code doesn't run, I'd consider that a hardware
failure that would require the board to be sent back. I'm hoping
that doesn't happen too often. ;-)
TTFN - Guy
-----Oorspronkelijk bericht----- From: Guy
Sotomayor Sent: Sunday,
August 30, 2015 7:05 AM To: General Discussion: On-Topic and
Off-Topic Posts Subject: MEM11 Status Update
[... snip ...]
The biggest piece of work remaining on the emulator will be emulating
the
Unibus interface. The work here will mainly to create a means to script
various Unibus transactions.
However, before doing that, I'll be testing out the boot loader code and
the configuration firmware since none of that is dependent upon the
existence of functional Unibus hardware.
TTFN - Guy
------------
Guy,
as you have sort-of all possible UNIBUS transactions because
of the devices supported by the MEM11, I guess there is still
so work to do ;-)
One question came to my mind.
Suppose I manage to "crash" the board in such a bad way that
it does not start up anymore. Is there a jumper to force it to
execute a "golden boot"? That is, load a minimal "kernel" to
bring the MEM11 back to life to reload the bootloader and
firmware?
Shipping a dead MEM11 back to the Creator inside USA is
OK, but from Europe etc. might get costly. And Customs
probably wants to put tax on it when shipped back from you.
Yea, I'm trying to avoid having folks to send stuff back to me.
The FRAM map that I'm currently working with has locations
for 5 complete firmware images. The bootloader and Config
Mode firmware all have support for this. Here's what they are for:
- 2 sets of Config Mode images. This allows for downloading
a new image while still keeping the previous one around.
- 2 sets of Run Mode images. This allows for downloading
a new image while still keeping the previous one around.
- a "safe" Config Mode image. This image will be used when
the jumpers are set to "safe" mode or the boot loader
determines that the selected image isn't bootable. This
image is *not* writable by the MEM11 firmware. I *may*
decide to physically write protect it (the FRAM allows me to
write protect sections).
I'm seriously contemplating putting something in the cold boot
code (initial J1 RAM contents) that allows for downloading
image contents into FRAM. This would help me out when I'm
bringing up an individual board for the first time (ie manufacturing).
It would also allow for recovery if the safe boot image became
corrupted for some reason.
I'm hoping that with all of the above, the only time a board would
have to be shipped back to me would be in the case of a HW failure.
3400
days inactive
3403
days old
18 comments
8 participants
participants (8)
-
ard＠p850ug1.demon.co.uk -
computerdoc＠sc.rr.com -
cube1＠charter.net -
derschjo＠gmail.com -
ethan.dicks＠gmail.com -
ggs＠shiresoft.com -
henk.gooijen＠hotmail.com -
js＠cimmeri.com