16 Oct
2012
16 Oct
'12
4:56 p.m.
On Oct 16, 2012, at 17:54, Christian Gauger-Cosgrove <captainkirk359 at gmail.com>
wrote:
In terms of a "udisk" board, instead of
re-inventing the wheel and
trying to rediscover all of the various controller information, could
one not attempt to reuse code from a software emulation of said
device? In other words, doing something like abusing the code of
SIMH's RQ, or RL driver into something usable by the electronics on
the board as a definition of the controller. If that could work, you
could easily cut down on the needing to re-invent the wheel with
regards to figuring out protocols. (Since if the protocol wasn't
written correctly enough for the emulator, software wouldn't run
correctly, or at all.)
That's certainly what I'd planned to do as a start (or at least
use SIMH's MSCP implementation as a guideline if it's not
directly usable).
How difficult a job would it be to "rip out"
the CPU/bus
controller/memory code of SIMH, and replace it with an interface to a
real bus controller/listener program? This way you could keep the
already written and functional-in-the-eyes-of-the-original-software
device code, and you get a small plethora of devices.
Things like that certainly exist commercially (I'd
provide links, but I'm on my phone). It typically requires
something rather low-latency, like an ISA or PCI card
on the host end; something like USB just has too long
a latency to be useful. My proposition for my card is
(for simple devices, anyway) a microcontroller attached
to an FPGA or CPLD which provides a thin QBUS/UNIBUS
transaction layer. This is how a lot of controllers were
implemented back in the day, only somewhat less integrated; the onboard micro responds to
bus transactions as an interrupt service routine. This
allows you to pretty fully decouple the controller logic
from the somewhat-more-static FPGA/CPLD design.
- Dave