flash (or ide) storage for unibus 11?

[Noel Chiappa]

{Catching up, after being on the road all day yesterday... Replies
to quite a few people in this, sorry you'll have to read through it
to find yours, didn't want to inundate the list with 17 replies.}


    > From: Jacob Ritort

    > Are you on keeping bits and/or status for these projects on github or
    > anywhere else that might encourage participation and contribution?

We're going to make it public, but at the moment, it's a bit early for that;
for one thing, we are working with hand-wire-wrapped prototypes, front-ending
a ZTEX FPGA/uC (micro-controller) board, not a PCB card. And the 'software'
(which includes FPGA code, we don't have any code for the uC yet) is in a
very primitive state. We'll probably get a couple of controllers done (RK11,
RP11, probably RL11, qetc) and then turn it loose for people to add others.

    > I'd be glad to pitch in if I can. 

We we get to the stage of turning it into a production PCB, we are definitely
going to really encourage help for that step - doing PCB layout, etc, is sort
of terra incognita for us both.

    > Actually, I (and I bet others) would love to see an up to date wiki
    > entry or somesuch listing folks' retro projects like these

Well, we'd need the wiki first! But I hope to have some news on that front
soon - I've located an existing one, and am discussing with the person who
runs it, using it for material from CCTalk.


    > From: Henk Gooijen

    > Tell us more ... and keep us posted Noel.

Not much more to say, at the moment.

The plan is that it will be a dual QBUS card, with slots for two SD cards,
and also one (or more) USB 2.0 connectors; although it will be possible to
plug in memory sticks (to the USB), the SD cards will probably offer higher
performance. Oh, and one will be able to configure virtual disks on on-board
RAM; the contents won't survive a power cycle, but they will be very high
performance, useful for swapping disks.

We will definitely keep CCTalk posted when there is any news.

    > We *love* blinkenlights !!

Why do you think they are in our plan? :-) We love them too! :-)

    > if you have a blank front panel this "fills nicely"

Well, like the originals, they will be half-panels (i.e. 5-1/4 inches).

They will not be electrically compatible with the original DEC indicator
panels (we plan on driving them like Guy, with just a clock and data on a
couple of wires, not one wire per light - in fact, I'd like to use a common
connector and electrical spec with Guy's, so they are compatible); making
them electrically compatible would be a _lot_ of work, and I don't see that
it would be worth it.

However, they will be mechanically compatible with the DEC originals; our
plan is that if someone has an original indicator panel PCB (I know at least
one person here does), they could mount it with one of our new production
bezel/inserts (with the light captions on it), and the whole thing will work.
I.e. in the original DEC design, we're just replacing the PCB.

    > Heck, why not address (all 22) and data too?

Although 'classic' RP11/etc panels will probably be available (for purists),
we intend to also do 'updated' panels which will drop a lot of lights that
make no sense when you don't have a real disk (e.g. the shift registers) and
replace them with useful lights that the originals don't have (e.g. full
memory address, on the RP11).


    > From: Paul Koning

    > For a classic/straightforward programming interface, the Massbus disks
    > (RP04 and successors) are a good choice. That will take you just over
    > 500 MB, if you emulate the layout of the RP07.

We'll probably do those too, but before that, we're thinking of doing an
RP11+, i.e. an RP11 with the cyclinder address extended to 16 bits; i.e
without changing the register format _other than using unused bits_ in the
cyclinder address register. (Very easy for us to do, of course.)

For those with the ability to tweak drivers, that will produce disks with
2^28 blocks, or 2^36 bytes, or 64GB. That's most of a large SD card... :-)

    > Sure, you can throw in a microcontroller, but interfacing that is
    > likely to take far more gates than doing the mapping in the device
    > directly.

Alas, we pretty much have to have a uC; it's pretty much mandator to support
USB. And once you have one, there's a lot of stuff that's easier to do in a
uC, e.g. reading the configuration of the virtual controllers, and
configuring the FPGA to match, etc, etc.


    > From: Rich Alderson

    > Why bother with the RP11? 

Because, for FPGA implementation, it's basically an RK11 with a few tweaks
--> very easy to do! And with the RP11+ variant, it will support up to 65GB
disks.. :-)


    > From: Mike Ross

    > Because, blinkenlights! :-)

That too! Although there's nothing to stop us doing light panels for
controllers that never had them, e.g. RL11's!


    > From: Johnny Billquist

    > 22-bit addressing is not possible on the Unibus.

True, but my concept is that the eventual UNIBUS version will include ENABLE
functionality (i.e. mapping boxes to 4MB memory, one for the CPU, and an
11/70-compatible UNIBUS map for DMA devices), and it could therefore _also_
'emulate' a MASSBUS RP11, i.e. an RP11 with an additional 'extended memory
address' like the identical registers on e.g. the MASSBUS RP04. (And yes, I
know no such device ever existed, so unmodified DEC OS's won't support it,
but...).

    > Your native interface have the additional problem that in addition to
    > requiring people to write their own device driver for any OS usage, it
    > will be rather difficult to get booting from it, since that require
    > special support.

Right, but since adding another controller on the QSIC will be a trivial
configuration option, we assume no machines will have _only_ an RQ11 (our
aname for the 'native' interface), but rather an RK11 and RQ11, RL11 and RQ11
etc. Boot off the first, only use the second once the OS is running.

    > RK11 and RP11, while fairly simple, are also very small devices.

Well, there's always the RP11+! :-)

And the 'RPV21' (again, I know this never existed) will, like the RLV21, have
native 22-bit addressing.

    > Massbus is a bit more useful, as it at least gives some larger devices,
    > but you need to implement each device.

It's all 'software' (in the FPGA and the uC); so if we (in the community
sense) upgrade the 'software' to support more controllers/disks, all boards
could be upgraded to support them.

Let's get the RK11 and RP11 working to start with, and then we'll figure out
where to go from there.

    > However, if you want to write a device driver for a device you want to
    > boot from, you need to modify SAV as well, which is *not* documented,
    > and very non-trivial. Not recommended for the faint of heart.

Which is why it's probably easier to just _also_ configure a standard
RK11/RP11 whatever, and boot off that. (It's all 'software'! With the
right FPGA load, you could have 127 RK11 controllers! :-)

	Noel