This is a discussion on Re: RXV11 emulator - 11-Feb update - VMS ; On Thu, 17 Feb 2005, Christopher Zach wrote: > I thought the RK05 does not work properly on 22 bit OSes, esp in Q-Bus land. > They spent the time re-writing the driver for the RXV21, but they upgraded > ...
On Thu, 17 Feb 2005, Christopher Zach wrote:
> I thought the RK05 does not work properly on 22 bit OSes, esp in Q-Bus land.
> They spent the time re-writing the driver for the RXV21, but they upgraded
> the RLV11 and ditched the RK05.
> Probably the best for OS support would be the RM drivers.
How do you figure that? RM means massbus. But the earliest massbus drive
was the RP, wasn't it? So that would probably be better.
But then again, a Q-bus machine cannot really have massbus, so support
there is nonexistant in boot roms.
No, if we ditch small/odd devices, the ones with best support would
probably be the RL01/RL02 drives.
After that, we're probably talking MSCP.
After all, when Q-bus started hitting off, Q-bus machines normally shipped
with MSCP controllers (RQDX1).
Hmm, we could try go through this systematically...
What do we have?
TU56: DMA. Little support on older Unibus. Fairly slow. Small.
TU58: Serial interface. Wide support on all machines. Slow. Small.
RX01: Programmed I/O. Wide support on all machines. A bit faster. Small.
RX02: DMA. Wide support on all machines. A bit faster. Small.
RX50: See MSCP.
RL01/RL02: DMA. Wide support on all machines. Fairly fast. Medium.
RK05: DMA. Fairly wide support on older machines. Fairly fast. Medium.
RK06/07: DMA. Fairly wide support on Unibus. Fairly fast. Medium.
RMxx: DMA. Fairly wide support on Unibus. Fast. Large.
RPxx: DMA. Fairly wide support on Unibus. Fast. Large.
MSCP: DMA. Wide support. Fast. Large.
This all from a firmware point of view (boot ability). From an OS point of
view, it's all a question of age. Newer versions support newer
controllers. The big break is probably pre/post MSCP.
>From an implementaion point of view, we can divide it into two complexity
views. Interface complexity and protocol complexity.
Devices without DMA is obviously much less complex interface wise. Older
devices are usually much less complex from a protocol point of view.
When you want to emulate a device you also have a question of timing
complexity. Here, the MSCP is actually by far the easiest device. Timing
requirements are very loose, while on more hardware based controllers,
timing is tricky (which people just have realized here :-) ).
A really fast PC of today still have problems meeting the timing
requirements of a bus, especially if we hook into a paralell port.
(Personally, I'd never even try that one for a number of reasons.)
What I guess it all boils down to is that if you want a simple interface
with wide support, and a little better perfomance than TU58, RX01 is
probably the way to go.
If you don't mind the complexity of the protocol, DMA, and lack of support
in older OS versions, MSCP is definitely the way to go.
All other choices are really hard to motivate. Why do a complex design for
something much more limited? If a special version of some software sets
the limit, then perhaps it might be motivated to go for the largest
capacity drive for that version, since the complexity for all DMA devices
are roughly similar.
And I doubt you'll ever get an implementation running on the paralell port
of a PC to work correctly and dependably.
(Heck, I doubt it just as much if we build a special bus interface, unless
we actially implement a lot more intelligence on that board, so that it
becomes a buffered, smart device on both buses.
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: firstname.lastname@example.org || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
To unsubscribe (or subscribe) from (to) this list, send a message to
email@example.com, with the first line of the message
body being "unsubscribe" or "subscribe", respectively (without the quotes).