24 Nov
2015
24 Nov
'15
2:34 p.m.
From: Phil Budne
Any plans to allow USB "target" (as opposed
to "host" -- I dunno if
those are the correct terms)
'host' and 'device' are the two modes for USB, IIRC.
to allow the board to be connected to a modern
computer as a
peripheral?
Not sure I see the purpose? Any of the storage devices (SD card, or thumb
drive) can of course be pulled out and plugged into another machine.
From: Andrea
there's always the possibility to choose a
commercial development
board, and mount it as SOM over a larger board that would include only
psu and bus level translators. This way could be cheaper
That's basically what we're doing for the prototypes, except that our
prototype motherboard is wire-wrapped. The mobo (currently) has only i) bus
transceivers, ii) level converters from +5V logic to +3.3V (nobody supports
+5V in any modern FPGA part, and QBUS transceivers are pretty much only
available in +5V - although we'd be happy to be informed otherwise), and iii)
a pair of 64-pin DuPont connectors to a FPGA/uC board from ZTEX.
(We may add more, e.g. when we get to debugging the indicator panels, we'll
probably put the drivers on the prototype motherboard. Etc, etc. That's part
of the reason for going with wire-wrap, it's easy to add stuff like that.)
It is, alas, not that cheap overall. We think the production models, with all
the circuity on a single custom PCB, will be somewhat cheaper. In addition,
you can't really stack the ZTEX boards on another board, and meet the QBUS
inter-board spacing.
Noel
24 Nov
24 Nov
3:21 p.m.
Noel wrote:
I wrote:
Of the top of my head:
Simulated serial port to MCU "console" and/or simulated q/unibus SLU(s)
Simulated ethernet to MCU internal network and/or simulated q/unibus NIC
Block device access to "unmounted" flash partitions
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?"
Other wishy things:
memory region visible to q/unibus as boot rom
ability to halt/reset the q/unibus (PDP-11) processor
(making the MCU into a "front end")
If it's possible to make a board that's operable without an MCU,
design the board so that it accepts a processor in "gumstix" or SODIMM
form factor, and expose connections for USB/ethernet. Linux has
"gadget" support for simulating various flavors of USB devices on a
'device' port.
Any plans to allow USB "target" (as
opposed to "host" -- I dunno if
those are the correct terms)
'host' and 'device' are the two modes for USB, IIRC.
to allow the board to be connected to a modern
computer as a
peripheral?
Not sure I see the purpose? Any of the storage devices (SD card, or thumb
drive) can of course be pulled out and plugged into another machine. 
4:37 p.m.
On 11/24/15 18:21, Phil Budne wrote:
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?"
We talked about this and put it in the category of "the hardware can do
it so somebody probably will but we're not going to worry about it".
Other wishy things:
memory region visible to q/unibus as boot rom
An earlier comment about how we wouldn't be able to boot off our native
disk drives caused me to think along this direction too. This seems a
nice feature and should be easy enough to implement. No hardware
changes are needed.
ability to halt/reset the q/unibus (PDP-11) processor
(making the MCU into a "front end")
Huh. Cute. We weren't planning to put in the ability to assert BHALT
or BINIT. It could then halt the processor and examine memory but it
couldn't see the processor registers or even set a start address. Or
could it hack into the console terminal and send commands to ODT?
Anyway, I'll leave that one to you.
-Dave
3097
days inactive
3098
days old
2 comments
3 participants
participants (3)
-
dab＠froghouse.org -
jnc＠mercury.lcs.mit.edu -
phil＠ultimate.com