flash (or ide) storage for unibus 11?

[Noel Chiappa]

    > From: Phil Budne

    >>> allow the board to be connected to a modern computer as a peripheral?

    >> Not sure I see the purpose?

    > Simulated serial port to MCU "console" and/or simulated q/unibus SLU(s)

Yes, but... what's the point of being able to gain access to SLU's on the QBUS
from a modern machine? Just plug serial ports into the modern machine.  Etc,
etc. If you meant 'a simulated console for the -11 that some other machine can
get to', just run a serial cable from that machine to the real -11 console
line.

(BTW, which expansion of the "MCU" acronym did you have in mind?)

    > Simulated ethernet to MCU internal network and/or simulated
    > q/unibus NIC

Not sure I entirely follow this? 

We had talked about eventually writing code to support a common USB Ethernet
interface, and have the QSIC emulate the Interlan NI2010 etc cards, which
were very nice to program (unlike all the DEC native Ethernet interfaces).

    > Block device access to "unmounted" flash partitions

Like I said, plug the storage unit (we don't have any that are physically
built into the QSIC) directly into the other machine.

The QSIC is not intended to provide an SD port for some other kind of machine
that doesn't have a native SD port; you can justq buy an SD carrier that is a
USB device.


Sorry, I'm just not into the whole 'desert topping / floor wax' concept (and
a tip of the hatly hat to Marshall Rose for the phrase).

'Can do something' != 'good idea to do something'!!


    > I suppose "host" ports can used to support physical USB dongles of
    > various sorts (serial, ethernet), but I guess my orientation is "why
    > connect extra hardware that can be simulated?"

Simulated, how? It's not clear that it's easier to do the simulation (via
some complex lash-up) than have the QSIC provide something that looks,
programming-wise, just like the DEC originals.

Although there are no plans to to serial lines. In general, my philosophy is
not to provide things which are still _readily_ available for real - and
serial lines fall into that cateory.


    > ability to halt/reset the q/unibus (PDP-11) processor
    >  (making the MCU into a "front end")

If the LSI-11 console is i) plugged into something else, and has 'halt on
break' enabled, you pretty much already have that.

    > If it's possible to make a board that's operable without an MCU

Huh? The QSIC is planned to be a standalone QBUS card - i.e. take a running
QBUS system with CPU, memory, etc, and plug in a QSIC for 'disk' storage.

Or by 'MCU' were you referring to the -11 CPU? Bridgham has at times wanted to
do that, but I'm not enthusiastic - see desert-topping/floor-wax point, plus
my point about 'only doing things that aren't easily available' - and QBUS
PDP-11 CPUs are readily available.


    > design the board so that it accepts a processor in "gumstix" or SODIMM
    > form factor, and expose connections for USB/ethernet.

More desert-topping/floor-wax.

    > Linux has "gadget" support for simulating various flavors of USB
    > devices on a 'device' port.

I have zero, none, nada interest in doing a board that can run Linux.


    > From: David Bridgham

    > It could then halt the processor and examine memory

Not sure about that. I don't know if the CPU processes DMA requests when it's
stopped. You can't use go ahead and use the bus without asking because the
processor is in tight loop issuing DATI's to the console CSR.

	Noel