MEM11 Status Update

[Mike Ross]

RF11s? None. But I have an RP11 and RP02s :-)

Put me down for  three or four, and as beta tester if needed!

Mike

On Wed, Jan 21, 2015 at 2:32 AM, Guy Sotomayor <ggs at shiresoft.com> wrote:

> Yes, it'll be useful for anything you want and will work in any Unibus
> PDP-11.  The original motivation was to allow Unix V1 to run on an 11/20
> without requiring an expansion chassis or trying to find unobtainium
> devices (how may RF11/RS11s have you come across?).
>
> TTFN - Guy
>
>
> On 1/19/15 11:10 PM, Mike Ross wrote:
>
>> Splendid news Guy!
>>
>> I presume this won't be restricted to just the 11/20, and just Unix V1.0?
>> It will, tweaked as necessary, have more general utility?
>>
>> If so, the question won't be 'if?', it'll be 'how many can I afford??!!'
>> :-)
>>
>> Mike
>>
>> On Tue, Jan 20, 2015 at 6:27 PM, Guy Sotomayor <ggs at shiresoft.com> wrote:
>>
>>  As some of you know I've been working (on and off again) 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.
>>> Here's the background on what the MEM11 is and the current progress.
>>>
>>> What's on the board is the following:
>>>
>>>   * Up to 124KW of non-volatile memory
>>>   * Console Emulator ROM
>>>   * 4 Boot ROMs selected from 32 images on the board
>>>   * 2 DL11 SLUs
>>>   * RF11 controller with non-volatile memory emulating 8 RS11 drives
>>>   * KE11 EAE
>>>   * KW11K
>>>   * KW11L
>>>   * KW11P
>>>   * KW11W
>>>
>>> I know I went overboard with the KW11s as only the KW11L (line-time
>>> clock)
>>> is needed.
>>>
>>> Early on, because of the number of devices and trying to fit all of this
>>> on a SPC-sized board so it can fit in the 11/20 chassis (can't fit in hex
>>> sized cards) I decided to "soft" configure everything.  That is, all of
>>> the
>>> configuration of the MEM11 will be done over one of the serial ports.  To
>>> get everything to fit on a board that small, I would need to have a
>>> reasonable level of integration.  This meant that I would be using an
>>> FPGA
>>> and with a few exceptions all components will be SMT (sorry folks, no
>>> kits
>>> on this one).
>>>
>>> I originally thought I would do everything in Verilog with no
>>> microprocessor (for a whole host of reasons).  I quickly realized that my
>>> Verilog coding skills were not up to a task that large so I put the
>>> project
>>> on hold while I regrouped.  I figured that I would have to integrate some
>>> sort of microprocessor core into the FPGA but was not happy with any
>>> that I
>>> was finding.  They were either very simple cores with poor tools support
>>> or
>>> very complex (ie big) cores that had reasonable tools.
>>>
>>> About 18 months ago, I came across a paper by James Bowman titled "J1: a
>>> small Forth core for FPGAs".  Best of all it was implemented in about 200
>>> lines of Verilog (ie it was incredibly small).  Also available was a
>>> complete cross environment (written in Forth of course).  It produced
>>> very
>>> tight code.  I spent a while trying to understand the J1, the cross build
>>> environment and getting familiar with Forth again.
>>>
>>> I got serious in November 2014 in laying out the structure of how to put
>>> everything together.  I decided that the J1 would be fast enough (should
>>> see ~100MIPs on the FPGA I plan to use) to actually do most of the device
>>> emulation code in Forth with only enough Verilog to offload some of the
>>> more performance critical bits. For example, the J1 is fast enough to
>>> actually receive the Unibus transaction, read a word from the FRAM and
>>> complete the Unibus transaction and still be close to maximum Unibus
>>> throughput.
>>>
>>> I've spent most of my time writing Forth code to implement the emulation
>>> of the devices and the configuration UI.  I decided that by writing the
>>> Forth code first, I would have a pretty good idea of how everything will
>>> go
>>> together.  What the H/W will look like will fall out from that and if I
>>> do
>>> have to change the H/W interface only small changes will need to be made
>>> to
>>> the S/W. Forth lends itself to building up from a very low level to a
>>> high
>>> level where the high level is isolated from many of the low level
>>> details.
>>>
>>> I've been coding furiously.  As of tonight I have ~60% of the emulation
>>> code written and 100% of the configuration UI (and it all builds).  I'll
>>> be
>>> working on finishing off the emulation code and then starting on the
>>> Verilog.  Since I want to get familiar with running the J1 in a real
>>> FPGA,
>>> I'll be building code and testing the configuration UI on one of my FPGA
>>> development boards.  This also has the advantage of having (mostly)
>>> tested
>>> code when I actually have real MEM11 hardware.
>>>
>>> A few comments on the capabilities.  Everything is configurable through
>>> the configuration UI (ie you'll be able to change everything regarding
>>> what
>>> devices are enabled, what they're base addresses are, the interrupt
>>> vector,
>>> priority, frequency of the line clock, etc, etc).  Basically, as I've
>>> been
>>> reading up on the devices, if there's a jumper or option on the device,
>>> there will be a way to set it through the configuration UI.  I also
>>> decided
>>> that to upload/download ROM images, memory images, etc that I would
>>> provide
>>> XMODEM capabilities.
>>>
>>> One thing that I decided on was that I wanted to be able to send code
>>> updates to folks and not require them to have a JTAG probe in order to
>>> perform an update (and hence the desire for XMODEM).  So the code in the
>>> FPGA is basically just a boot-loader that loads an image from an area of
>>> non-volatile memory on the board.  I'm allowing for 4 J1 images (16KB
>>> each...the code address space for the J1) plus a "safe" boot image that
>>> no
>>> matter how screwed up everything is, you'll be able to fall back to that
>>> image.
>>>
>>> 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).  By the time I was done with the configuration UI I
>>> was
>>> hitting up against the 16K limit (presently there's about 200 bytes free
>>> and there's a bit more refactoring that I could do if I need to get
>>> really
>>> aggressive). So my insight in having a boot loader and organizing along
>>> those lines paid off.  ;-)
>>>
>>> I'm sure there are a number of folks who will want one and are eager to
>>> know what it'll cost.  ;-)
>>>
>>> I have a basic BOM for the MEM11, but I haven't cost it out in a while so
>>> while I *think* I know what it'll cost to produce, I'm not going to give
>>> out pricing (even though a few folks know what my target is) until after
>>> I
>>> have a prototype built and working.
>>>
>>> Also, since there will be a high level of integration, I'm only going to
>>> offer this only as a fully assembled and tested unit with all of the FPGA
>>> programming, ROM emulation images, J1 code images and a reasonable
>>> configuration setup.
>>>
>>> As I said, as of tonight, I've finished the configuration UI. I'll be
>>> working on finishing up the emulation code.  This is the biggest risk
>>> since
>>> I won't really be able to test the emulation code until I have an actual
>>> prototype board built.  Once all of the code is written, I'll be working
>>> on
>>> the Verilog.  During all of this, I'll be doing some testing on my FPGA
>>> evaluation board.
>>>
>>> Given my progress so far, I'm hoping (fingers crossed) to be testing a
>>> prototype some time in June/July 2015.  Once I have the prototype tested,
>>> I'll have a good idea of the remaining work that needs to be done.  At
>>> that
>>> point, I'll let folks know what the cost will be and will start to take
>>> orders.  Once I have a reasonable number of (committed) orders, I'll do a
>>> production run.
>>>
>>> Ok, so this has been much longer than I expected.  ;-)
>>>
>>> I'll update folks as the project progresses.
>>>
>>> TTFN - Guy
>>>
>>>
>>>
>>>
>>
>


-- 

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'