> 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