28 Feb
2008
28 Feb
'08
3:47 p.m.
Subject: Re: Q-bus to CF [was: IOmega]
From: Gordon JC Pearce <gordonjcp at gjcp.net>
Date: Thu, 28 Feb 2008 08:41:13 +0000
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
On Thu, 2008-02-28 at 00:19 -0500, tiggerlasv at aim.com wrote:
Generally IDE and CF (compactflash) are the same interface and for
Qbus-11 fairly simple. It's been done, however, the problem is the
driver as bare IDE or CF is NOT MSCP not is it DL, DX, DY or RK
so a driver is needed and noone has apparently stepped up to do it.
I beleive its fairly straight forward work but never having done it
but having seen drivers like DD and DY They have a structure that
must be held to.
SCSI is actually harder to talk to than CF or IDE, I have done that
for CP/M and SCSI is a pain as you have to deal with the SCSI chips
and their particular protocal.
MSCP is a complex protocal whols primary job is to create a logical
abstraction hardware from the software and I don't think an atmel uP
is enough and definatly enough ram plus enough is not known to create
it(MSCP) from scratch.
Allison
I stopped holding my breath for creation of a Q-Bus IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
Actually SATA is extremely exacting and needs unbelievably complicated
controller chips.
PATA, on the other hand, is just a fast parallel port. You can hook a
CF card up to anything, even a microcontroller, with just a tiny amount
of glue logic.
At any rate, back to the topic, Q-Bus to Compact
Flash.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Exactly. Simply grafting a PATA interface onto a QBus card is trivial.
Actually getting something that will either pretend to be an existing
controller or writing a device driver for the operating system in use is
much much harder.
If you really wanted to push this forwards, write me some MSCP
controller firmware for an Atmel microcontroller...
Right now, I have Compact flash / IDE on my
Q-bus,
albeit in a round-about way.
I have older CMD SCSI controllers (CQD-200's).
Attached to those are ACard 7720U SCSI <> IDE adapters.
http://www.acard.com
These seem to crop up on the various sampler mailing lists I'm on, as a
way of using CF with older samplers which often have "funny" SCSI
implementations.
Gordon 
28 Feb
28 Feb
11 p.m.
Generally IDE and CF (compactflash) are the same
interface and for
Qbus-11 fairly simple. It's been done, however, the problem is the
driver as bare IDE or CF is NOT MSCP not is it DL, DX, DY or RK so a
driver is needed and noone has apparently stepped up to do it.
Not quite true.
Some time back (years), someone was working on an IDE interface for a
Qbus MicroVAX and I was doing the driver. (This was not bootable; the
idea was to netboot to get the kernel onto the machine.)
We never got it working, and it is not clear to me, now, why not. I'm
not sure whether this is because it wasn't clear why then or because my
wetware memory has bitrotted - what memory I have indicates that there
were hardware issues, but I had no physical access to the hardware, so
I'm not sure that that's right even aside from bitrotted memory.
I once was one of two people who built a one-off Qbus board out of
wirewrap, so I feel I ought to be able to build such a thing myself.
Perhaps someday I'll gather the parts and try it. (Anyone have a Qbus
development board looking for a home? :)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
29 Feb
29 Feb
7:24 a.m.
On Feb 28, 2008, at 6:47 PM, Allison wrote:
MSCP is a complex protocal whols primary job is to
create a logical
abstraction hardware from the software and I don't think an atmel uP
is enough and definatly enough ram plus enough is not known to create
it(MSCP) from scratch.
Actually I'm pretty sure one of my Emulex ESDI controllers (QD21 I
think) that does MSCP uses an 8031 microcontroller. Many of the
Atmel chips have quite a bit more resources than that.
-Dave
--
Dave McGuire
Port Charlotte, FL
5 Mar
5 Mar
1:03 p.m.
On Thu, 28 Feb 2008 18:47:07 -0500
Allison <ajp166 at bellatlantic.net> wrote:
MSCP is a complex protocal whols primary job is to
create a logical
abstraction hardware from the software and I don't think an atmel uP
is enough and definatly enough ram plus enough is not known to create
it(MSCP) from scratch.
1. There is http://www.mscpscsi.com/
2. There are several different Atmels. The 8 bit AVR line, 32 bit AVR32
and 32 bit ARM core based contolers. The later features a DMA engine...
uCLinux runs on the ARM based devices. The AVR32 has a MMU and thus is
capable of running "regular" Linux.
Hell! With an AVR32 on the disk contoler the disk contoler can _emulate_
a VAX or PDP-11 at higer speed then the real CPU in your QBus box!
PATA <=> SATA: SATA is a serial transport for ATAPI and ATAPI is more or
less a subset of SCSI...
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
2:35 p.m.
Jochen Kunz wrote:
On Thu, 28 Feb 2008 18:47:07 -0500
Allison <ajp166 at bellatlantic.net> wrote:
I was planning on using an 8-bitter with a couple-K of RAM built-in and
a built-in IDE interface.
Peace... Sridhar
MSCP is a complex protocal whols primary job is
to create a logical
abstraction hardware from the software and I don't think an atmel uP
is enough and definatly enough ram plus enough is not known to create
it(MSCP) from scratch.
1. There is http://www.mscpscsi.com/
2. There are several different Atmels. The 8 bit AVR line, 32 bit AVR32
and 32 bit ARM core based contolers. The later features a DMA engine...
uCLinux runs on the ARM based devices. The AVR32 has a MMU and thus is
capable of running "regular" Linux.
Hell! With an AVR32 on the disk contoler the disk contoler can _emulate_
a VAX or PDP-11 at higer speed then the real CPU in your QBus box!
PATA <=> SATA: SATA is a serial transport for ATAPI and ATAPI is more or
less a subset of SCSI... 
2:47 p.m.
On Wed, Mar 05, 2008 at 05:35:05PM -0500, Sridhar Ayengar wrote:
I was planning on using an 8-bitter with a couple-K of
RAM built-in and
a built-in IDE interface.
I've built and maintained 68000-based Unibus, Qbus, and VAXBIcommunications
boards (not like anything DEC ever made, so we were free to/had to write
all of our own drivers for RSX, RSTS, VMS, and Ultrix). Given that the
IDE interface wants to be 16 bits, and given that the bus interface is
16 bits for Unibus and Qbus, a) that's a lot of I/O pins for an
integral MCU, and b) it might take some external hardware to have an
8-bit CPU passing data between two 16-bit pipes (latches, or some way
to handle a measurable delay between writing the top half and bottom
half of your data.
We had to resort to some tricks to interface a 16-bit CPU to the 32-bit
VAXBI BIIC interface chip (the one in the corner of all VAXBI boards).
I see similar issues with an 8-bit CPU on a Unibus or Qbus.
Just something to keep in mind if you get high-byte/low-byte race
conditions, etc.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 5-Mar-2008 at 22:40 Z
South Pole Station
PSC 468 Box 400 Temp -57.5 F (-49.7 C) Windchill -91.9 F (-68.8 C)
APO AP 96598 Wind 12.1 kts Grid 64 Barometer 682.5 mb (10534 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
6 Mar
6 Mar
9:05 a.m.
On Wed, 5 Mar 2008 22:47:09 +0000
Ethan Dicks <ethan.dicks at usap.gov> wrote:
M68k is still alive: ColdFire!
Looking at the MSCP-SCSI stuff: It seems that the data is pumped between
QBus and SCSI by glue logic hardware. (There is a CPLD etc.) So the MCU
has to do only supervisory tasks. With a faster (16 or 32 bit) MCU this
could be done in software. A software solution would be more flexible
and much easier to build. (debugging, PCB, programming a CPLD, ...)
Also: There are ColdFire MCUs with PCI interface. This would ease
attachment of a SATA controller...
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
I was planning
on using an 8-bitter with a couple-K of RAM built-in
and a built-in IDE interface.
I've built and maintained 68000-based Unibus,
Qbus, and
VAXBIcommunications boards 
11:13 a.m.
IDE interface wants to be 16 bits, and given that the
bus interface is
16 bits for Unibus and Qbus, a) that's a lot of I/O pins for an
integral MCU, and b) it might take some external hardware to have an
8-bit CPU passing data between two 16-bit pipes (latches, or some way
to handle a measurable delay between writing the top half and bottom
half of your data.
Ethan, a very nice implementation of a simple CF interface is the speccy
one. I don't have a link handy and I'm on a hurry. But look for cf
interfaces for ZX Spectrum and you'll find a very simple way to drive a CF
card. Maybe it can be implemented on your big iron :)
noon
On Thu, Mar 06, 2008 at 04:13:01PM -0300, Alexandre Souza wrote:
>IDE interface wants to be 16 bits, and given that
the bus interface is
>16 bits for Unibus and Qbus...
Ethan, a very nice implementation of a simple CF
interface is the speccy
one. I don't have a link handy and I'm on a hurry. But look for cf
interfaces for ZX Spectrum and you'll find a very simple way to drive a CF
card. Maybe it can be implemented on your big iron :)
I didn't say "CF", I said "IDE". CF supports 8 or 16-bit access,
but
in any case, Qbus and Unibus are still 16 bits, and I think using an
8-bit CPU to talk to a Qbus or Unibus will add complexity to the project
vs using a 16-bit CPU.
It's been beaten to death on the list in the past, but CF is not a good
choice for a long-term use with a swapping OS (VMS and Ultrix in this case).
I don't know enough about RSX and RSTS internals to know if they do lots of
writes to the boot drive or not.
Oh... and not all CF-interfaced rotating media support 8-bit mode. I have
a 5GB CF-interfaced drive here (in a USB wrapper), and from researching the
drive mech on Seagate's site, it explicitly does *not* support 8-bit mode,
only 16-bit "true IDE" mode. I was thinking of stuffing onto my IOB6120
until I found that out. I also have a real IBM-branded 340MB Microdrive
with me; I haven't checked on that one yet.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 6-Mar-2008 at 19:50 Z
South Pole Station
PSC 468 Box 400 Temp -40.9 F (-40.5 C) Windchill -78.8 F (-61.6 C)
APO AP 96598 Wind 21.8 kts Grid 17 Barometer 679.7 mb (10640 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
7 Mar
7 Mar
3:33 p.m.
On Thu, 2008-03-06 at 20:00 +0000, Ethan Dicks wrote:
It's been beaten to death on the list in the past,
but CF is not a good
choice for a long-term use with a swapping OS (VMS and Ultrix in this case).
I don't know enough about RSX and RSTS internals to know if they do lots of
writes to the boot drive or not.
So have a storage device and a swap device. The swap device can just be some RAM ;-)
Gordon
6134
days inactive
6142
days old
9 comments
8 participants
participants (8)
-
ajp166＠bellatlantic.net -
alexandre-listas＠e-secure.com.br -
ethan.dicks＠usap.gov -
gordonjcp＠gjcp.net -
jkunz＠unixag-kl.fh-kl.de -
mcguire＠neurotica.com -
mouse＠Rodents.Montreal.QC.CA -
ploopster＠gmail.com