29 Feb
2008
29 Feb
'08
7:03 a.m.
Subject: Re: Q-bus to CF [was: IOmega]
From: der Mouse <mouse at Rodents.Montreal.QC.CA>
Date: Fri, 29 Feb 2008 02:00:53 -0500 (EST)
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
the likely reason is PDP-11 and VAX does read before write and IDE
does not like that. The fis is to make the READ address different
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. from the write addresses, even DEC did that with
interfaces.
It is otherwise straightfoward with the usual observance for timing and
the like.
Allison
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
1 Mar
1 Mar
12:33 p.m.
> Some time back (years), someone was working on an
IDE interface for
> a Qbus MicroVAX and I was doing the driver. [...]
> We never got it working, and it is not clear to
me, now, why not.
> [...] what memory I have indicates that there were hardware issues,
the likely reason is PDP-11 and VAX does read before
write and IDE
does not like that.
Huh? The only sense I can think of in which the PDP-1 and VAX could be
said to do read before write is in the bus transaction sense, and
anything that could be called "IDE" was insulated from bus
transactions. While the card didn't have much smarts, it did have that
much; it looked enough like a wdc that I did the driver as an "attach
wdc at uba with wdc_uba" attachment layer, rather than a completely new
driver. I find I still have my copy of the dev directory, including a
boot-time console log:
uba0 at ibus0: Q22
ubasearch: cf_loc[0] 0171000, pa 0x20001200
[wdc_uba_probe: ua->ua_ioh 020500251000]
st0=52 st1=50
wdc_uba_probe: setting vector 774
wdc0 at uba0 csr 171000 vec 774 ipl 17
st0=52 st1=50
wd0 at wdc0 channel 0 drive 0: <Samsung Electronics 120MB SHD-3062A>
wd0: drive supports 16-sector pio transfers, chs addressing
wd0: 114 MB, 917 cyl, 15 head, 17 sec, 512 bytes/sect x 233835 sectors
wd1 at wdc0 channel 0 drive 1: <WDC AC31200F>
wd1: drive supports 16-sector pio transfers, lba addressing
wd1: 1222 MB, 2484 cyl, 16 head, 63 sec, 512 bytes/sect x 2503872 sectors
wd1: drive supports PIO mode 3, DMA mode 1
wdc0: establishing interrupt, vector 1774
I'm not sure how it worked enough to query the disk like that but
failed later. That serial-console log file seems to indicate that it
worked fine for 512-byte transfers but attempts to do larger transfers
led to an unending stream of "wdc_uba_intr: stray", meaning it was
seeing interrupts that the wdc interrupt routine was declining to
handle.
/~\ 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
12:58 p.m.
der Mouse wrote:
Well if my SBC6120 ( PDP 8 Clone) can have a IDE interface
why not some other PDP. We are not looking for high speed
just hardware in this case.
> Some time
back (years), someone was working on an IDE interface for
> a Qbus MicroVAX and I was doing the driver. [...]
> We never got it working, and it is not clear
to me, now, why not.
> [...] what memory I have indicates that there were hardware issues,
the likely reason is PDP-11 and VAX does read
before write and IDE
does not like that.
Huh? The only sense I can think of in which the PDP-1 and VAX could be
said to do read before write is in the bus transaction sense, and
anything that could be called "IDE" was insulated from bus
transactions. While the card didn't have much smarts, it did have that
much; it looked enough like a wdc that I did the driver as an "attach
wdc at uba with wdc_uba" attachment layer, rather than a completely new
driver. I find I still have my copy of the dev directory, including a
boot-time console log: 
1:07 p.m.
Well if my SBC6120 ( PDP 8 Clone) can have a IDE
interface
why not some other PDP
Ah, but for the SBC6120 I wrote a custom device driver for OS/8. The IDE
interface doesn't emulate any standard PDP-8 device.
As somebody already pointed out, if you're willing to write device drivers
for all the PDP-11 operating systems, it'd be easy enough to do the same
thing for QBUS or UNIBUS.
Bob
7:46 p.m.
Bob Armstrong wrote:
True, but then it becomes a software rather than a hardware problem.
Well if my
SBC6120 ( PDP 8 Clone) can have a IDE interface
why not some other PDP
Ah, but for the SBC6120 I wrote a custom device driver for OS/8. The IDE
interface doesn't emulate any standard PDP-8 device.
As somebody already pointed out, if you're willing to write device drivers
for all the PDP-11 operating systems, it'd be easy enough to do the same
thing for QBUS or UNIBUS. Bob
2 Mar
2 Mar
2:46 a.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles H Dickman wrote:
woodelf wrote:
And in the case of the PDP-11, several 20-year-old OSes, or in the case
of the VAX, a few old OSes, of many versions.
I have an sbc6120 w/IDE interface. It's great. It's also a case of
writing _a_ device driver for the most common case, OS/8. While there
are a few versions of OS/8 out there, there's no compelling reason to
want to write an IDE driver for, say, OS/8 v2, since there is little
reason to _run_ OS/8 v2, even on real hardware. This is very much _not_
the case for newer DEC hardware.
For the PDP-11, RT-11 is very popular for small systems, but does run
on pretty much every -11 made, from an LSI-11 (11/03) all the way up
to an 11/93. If you happen to have an 11/70, you are probably going to
be running some flavor of RSTS/E or BSD UNIX, but it's not a requirement.
Same goes for the other large Unibus machines - they will run RT-11,
but you are probably going to have some multi-user OS on it. On real
machines, I've seen the spread from RT-11 V2, V4.00, V5.X, to RSX-11
and -11/M 2.X, 3.X, 4.X, as well as nearly every version of RSTS/E
True, but then it becomes a software rather than a hardware problem.
True... and I think that was his point.
There are not many people capable of writing *new* device drivers for
PDP-11 or VAX OSs.
Software development for a 20 year old OS is not easy. from V5 up to V11 plus 2BSD in various flavors (2.9BSD
and 2.11BSD
being the most popular).
To increase the fun and complexity, sticking merely with Unibus and
Qbus VAXen, the interest is there for running VMS 1.0, VMS 3.X,
VMS 4.X and VMS 5.X (I don't imagine someone is likely to run VMS 6.X
on hardware with a Qbus or a Unibus, but it's not impossible). There
are favorite spots in there, so it's not like you'd even try to support
every single point-release of VMS, but at the very least, 3.6, 4.0,
4.5 and or 4.6, plus 5.4 or 5.5 come to mind, and there was a lot of
evolution in drivers and priv mode code over that spread, especially
between 4.x and 5.0 (adding SMP support with spinlocks, etc).
My point is that it makes sense in the near monoculture of the PDP-8
to craft a new interface and a new driver. You can cover 90%+ of
your audience with one piece of code. In the PDP-11 and VAX realm,
there are so many more choices that even to hit 50% of your target
audience, you'd need three drivers, let's say - RT-11 V5.3, some
arbitrary version of VMS (V5.4?), and 2.11BSD.
Emulating a real DEC or third-party disk controller wipes away
a *lot* of software effort, concentrating the effort into one
place - the microcode/firmware on the disk controller. If there
are bugs, you fix them in one place, not potentially several.
the behavior of most disk controllers is (was?) well known, so
that any register-exact emulation failures should show up fairly
quickly.
When I used to run a room full of DEC equipment, we had nearly
all DEC disk controllers, since we had to support about a dozen
OSes based on what our customers were using. We had one VAX
with RK07s that we _didn't_ upgrade, specifically because we could
swap out a pair of packs, reboot, and match our customers'
specific environment. Later, we did upgrade that same VAX to
have a pair of RA81s (plus other disks) so that we could
have two primary OSes on a largish system (VMS and Ultrix)
for the same reason. Each of our PDP-11s was rigged to handle
two or three OSes (some flavor of RSX-11, of RSX-11/M, and
sometimes one or two flavors of RSTS/E) on two to four RL02
drives.
Out of all of this variety, one machine stood out - our main
company shared VAX on which we did all of our C development,
word processing (MASS-11), and e-mail... it had a Fuji Eagle
attached via an SI9900 - I've written about it here before -
The single most difficult part of our entire machine room to
deal with when it came time for upgrades. We had to wait
until Systems Industries issued patch tapes to twiddle the
DRDRIVER.EXE with a new geometry table. It was the real
and genuine DEC driver for our OS, but we couldn't use our
big disk because the driver didn't know about it. That's
nowhere near as hard as a third-party disk with an entirely
third-party driver.
So... while a cheap and simple IDE interface might be
a seductive path, given how many different OSes would
have to be supported, I think it's worth a little design
time to come up with something that can use the drivers
that are already there on the install media for a large
collection of platforms and operating systems.
Obviously, older OSes might have a problem with a card
that only speaks MSCP (newer ones will *love* it), but
someone's suggestion for a flexible card that might be
able to emulate an RL02 w/four drives (as was really
done for small systems w/ST-506-type drives) or an RK611
w/multiple RK07 drives or even a third-party controller
like an Emulex w/SMD or ESDI drives (hpdriver under 2BSD,
for example) might be a way around both issues (OS MSCP
support and the complexity of building an MSCP controller
in the first place).
My purely personal preferences would be to be able to
run such a card under RT-11 v5.3 and newer, 2.9BSD
and 2.11BSD, and VAX/VMS from, say, 4.0 through 5.6,
with VMS 3.6 being a bonus (since it was my first
exposure to VMS). I might want to eventually run a
different OS on a PDP-11 (RSX and RSTS), but I would
not make a purchase based on those. I'm sure everyone
else here has their own unique combinations of OS
and platform priorities, but I thought I'd throw mine
out there for debate.
And, yes, I _would_ buy a card that fit that niche,
as long as I could get it for, say $200 (even if I
can only get a bare board and stuff it myself for
that price). I'd be substantially less inclined at
the $350 level. For that kind of money, I'd be more
likely to slap an IDE interface on an old COMBOARD
and start writing drivers (all COMBOARDs have DMA
interfaces and 8MHz-10MHz 680x0 CPUs that could push
about 200kb/sec to the bus. I have a pile of Unibus
and VAXBI COMBOARDs, but only one or two Qbus).
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 2-Mar-2008 at 07:09 Z
South Pole Station
PSC 468 Box 400 Temp -53.7 F (-47.6 C) Windchill -87.6 F (-66.4 C)
APO AP 96598 Wind 12.5 kts Grid 11 Barometer 688.3 mb (10317 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
10:18 a.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
Ethan Dicks (ethan.dicks at usap.gov) wrote:
All true, although it might not be as bad as it sounds. There are a lot
of people on this list, and some of them used old DEC computers and
operating systems. Some of them might already know how to write a driver
for one of these OSes - get a group of them together and you'll have all the
old OSes covered. And it is fairly well documented how to write device
drivers for at least RT, RSX and VMS. And the first thing you should do is
hack up simh to include emulation of your proposed new "RQATA" interface
card; then you could start writing drivers before the hardware was even
done, and simh is a great tool for debugging the driver software. If you
actually had a group of motivated (i.e. they were getting paid for it :-)
people together it would not be that hard.
OTOH, the SBC6120 was sort of my experiment in open source old computer
development. I always hoped people would expand and add to it, both in
hardware and software, but for the most part that never really happened.
Most people wanted to buy a turnkey system that they could plug in, turn on,
and start using it - people seem to have jobs, families and real lives and
just don't have the time to do a lot of development.
Bob
On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles
H Dickman wrote:
...
Software development for a 20 year old OS is not easy.
And in the case of the PDP-11, several 20-year-old OSes, or in the case
of the VAX, a few old OSes, of many versions.
11:16 a.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
On Sun, Mar 02, 2008 at 07:18:51AM -0800, Bob Armstrong wrote:
True, but there are a lot of dusty neurons to polish before much progress
could be made. I haven't written a device driver for DEC hardware in
over 15 years (I've worked on Ultrix, and VMS 4.x and VMS 5.x, myself).
Ethan Dicks
(ethan.dicks at usap.gov) wrote:
All true, although it might not be as bad as it sounds. There are a lot
of people on this list, and some of them used old DEC computers and
operating systems. Some of them might already know how to write a driver
for one of these OSes - get a group of them together and you'll have all the
old OSes covered. On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles
H Dickman wrote:
...
Software development for a 20 year old OS is not easy.
And in the case of the PDP-11, several 20-year-old OSes, or in the case
of the VAX, a few old OSes, of many versions. ... the first thing you should do is
hack up simh to include emulation of your proposed new "RQATA" interface
card; then you could start writing drivers before the hardware was even
done, and simh is a great tool for debugging the driver software.
That's an excellent suggestion (and I say that having helped Bob Supnik
debug one of _his_ drivers long ago).
OTOH, the SBC6120 was sort of my experiment in open
source old computer
development. I always hoped people would expand and add to it, both in
hardware and software, but for the most part that never really happened.
Most people wanted to buy a turnkey system that they could plug in, turn on,
and start using it - people seem to have jobs, families and real lives and
just don't have the time to do a lot of development.
From my own standpoint, especially since I have an
IOB6120 and FP6120,
it does pretty much everything I'd want it to do. About the
only feature
I can think of off the top of my head would be to jimmy the IOB6120
FPGA firmware to be able to talk to a real RX01/RX02 hanging off of the
I/O pins (with suitable line drivers/receivers, of course). I'd probably
only want that to be able to image disks, anyway, though. Out of the box,
the SBC6120 boots up OS/8 and that works for most of what I'd do with a
"real" PDP-8 anyway - boot it up, play a few games, and marvel at what's
going on under the hood.
In terms of software dev, folks can just as easily fire up simh and work
on software there. I always thought the appeal of the SBC6120 was to
have a real 12-bit machine in ones hands, not the developement aspect of it.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 2-Mar-2008 at 15:49 Z
South Pole Station
PSC 468 Box 400 Temp -52.8 F (-47.1 C) Windchill -87.4 F (-66.3 C)
APO AP 96598 Wind 13.4 kts Grid 12 Barometer 685.9 mb (10406 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
8:27 p.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
Why can't the driver(s) for RAM disks be used? Then the hardware
interface might be a whole lot simpler, just make the IDE drive look
like an extended section of memory.
At 11:16 AM 3/2/2008, you wrote:
On Sun, Mar 02, 2008 at 07:18:51AM -0800, Bob Armstrong
wrote:
have all the
Ethan
Dicks (ethan.dicks at usap.gov) wrote:
All true, although it might not be as bad as it sounds. There are a lot
of people on this list, and some of them used old DEC computers and
operating systems. Some of them might already know how to write a driver
for one of these OSes - get a group of them together and you'll On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles
H Dickman wrote:
...
Software development for a 20 year old OS is not easy.
And in the case of the PDP-11, several 20-year-old OSes, or in the case
of the VAX, a few old OSes, of many versions. old OSes covered.
True, but there are a lot of dusty neurons to polish before much progress
could be made. I haven't written a device driver for DEC hardware in
over 15 years (I've worked on Ultrix, and VMS 4.x and VMS 5.x, myself).
... the first thing you should do is
hack up simh to include emulation of your proposed new "RQATA" interface
card; then you could start writing drivers before the hardware was even
done, and simh is a great tool for debugging the driver software.
That's an excellent suggestion (and I say that having helped Bob Supnik
debug one of _his_ drivers long ago).
OTOH, the SBC6120 was sort of my experiment in
open source old computer
development. I always hoped people would expand and add to it, both in
hardware and software, but for the most part that never really happened.
Most people wanted to buy a turnkey system that they could plug
in, turn on,
and start using it - people seem to have jobs,
families and real lives and
just don't have the time to do a lot of development.
From my own standpoint, especially since I have an
IOB6120 and FP6120,
it does pretty much everything I'd want it to do. About the
only feature
I can think of off the top of my head would be to jimmy the IOB6120
FPGA firmware to be able to talk to a real RX01/RX02 hanging off of the
I/O pins (with suitable line drivers/receivers, of course). I'd probably
only want that to be able to image disks, anyway, though. Out of the box,
the SBC6120 boots up OS/8 and that works for most of what I'd do with a
"real" PDP-8 anyway - boot it up, play a few games, and marvel at what's
going on under the hood.
In terms of software dev, folks can just as easily fire up simh and work
on software there. I always thought the appeal of the SBC6120 was to
have a real 12-bit machine in ones hands, not the developement aspect of it.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 2-Mar-2008 at 15:49 Z
South Pole Station
PSC 468 Box 400 Temp -52.8 F (-47.1 C) Windchill -87.4 F (-66.3 C)
APO AP 96598 Wind 13.4 kts Grid 12 Barometer 685.9 mb (10406 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html 
9:12 p.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
Ethan Dicks wrote:
On Sun, Mar 02,
2008 at 07:18:51AM -0800, Bob Armstrong wrote:
All true, although it might not be as bad as it
sounds. There are a lot
of people on this list, and some of them used old DEC computers and
operating systems. Some of them might already know how to write a driver
for one of these OSes - get a group of them together and you'll have all the
old OSes covered.
True, but there are a lot of dusty neurons to polish before much progress
could be made. I haven't written a device driver for DEC hardware in
over 15 years (I've worked on Ultrix, and VMS 4.x and VMS 5.x, myself).
... the first
thing you should do is
hack up simh to include emulation of your proposed new "RQATA" interface
card; then you could start writing drivers before the hardware was even
done, and simh is a great tool for debugging the driver software.
That's an excellent suggestion (and I say that having helped Bob Supnik
debug one of _his_ drivers long ago).
9:11 p.m.
New subject: new disk controllers for DEC platforms (was Re: Q-bus to CF)
Bob Armstrong wrote:
Ethan Dicks (ethan.dicks at usap.gov) wrote:
On Sat, Mar 01, 2008 at 08:35:14PM -0500, Charles
H Dickman wrote:
...
Software development for a 20 year old OS is not easy.
And in the case of the PDP-11, several 20-year-old OSes, or in the case
of the VAX, a few old OSes, of many versions.
OTOH, the SBC6120 was sort of my experiment in open
source old computer
development. I always hoped people would expand and add to it, both in
hardware and software, but for the most part that never really happened.
Most people wanted to buy a turnkey system that they could plug in, turn on,
and start using it - people seem to have jobs, families and real lives and
just don't have the time to do a lot of development.
I guess that being retired now - I am the exception. I have been
making bug fixes and extensive enhancements to RT-11 for more than
25 years including my own set of Y2K bug fixes - which eventually
I want to expand to Y9K. I think the problem with any 3rd party
changes was that most companies felt that DEC was the only supplier
which could be counted upon. By 1994, DEC had sold the PDP-11
software to Mentec - who supported RT-11 even less than DEC with
good reason, of course, since there was really very little call
for any bug fixes except for Y2K and even less call for enhancements.
At present, I can't seem to find anyone else who is making changes
and fixing bugs in RT-11. If you have made any recent changes to
RT-11, I would be VERY interested in hearing about them!!!!!!!!!!
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
3 Mar
3 Mar
10:27 a.m.
Bob Armstrong wrote:
Or if you're willing to write an MSCP layer into your controller firmware.
Peace... Sridhar
Well if my
SBC6120 ( PDP 8 Clone) can have a IDE interface
why not some other PDP
Ah, but for the SBC6120 I wrote a custom device driver for OS/8. The IDE
interface doesn't emulate any standard PDP-8 device.
As somebody already pointed out, if you're willing to write device drivers
for all the PDP-11 operating systems, it'd be easy enough to do the same
thing for QBUS or UNIBUS.
1:48 p.m.
Bob Armstrong wrote:
The question is who is the interface for. Is this like the SCB1620 interface to provide
a hard drive to a small system that may not have any other major storage device,
or is this for a commercial system that has a *Standard* I/O allready?
Sridhar
Ayengar (ploopster at gmail.com) wrote:
Or if you're willing to write an MSCP layer
into your controller firmware.
I actually think this is the "right" way to solve the problem in the case
of the PDP-11 and VAX, but then controller is no longer a simple device. Bob
PS: I was reading the 1966 PDP 8 user
handbook, I am finding usefull programing
information since they give real detail in I/O devices.
Any ideas on how impliment POWER on fail IRQ and restore?
5:37 p.m.
woodelf (bfranchuk at jetnet.ab.ca)
The question is who is the interface for. Is this like
the SCB1620
interface to provide
a hard drive to a small system that may not have any
other major storage
device,
or is this for a commercial system that has a
*Standard* I/O allready?
Sorry, I disagree. The target system hardware doesn't matter at all -
it's the target system _software_ that counts. The SBC6120/PDP8 really has
only one viable disk operating system, so all I had to do was make that work
and the job was done. The PDP-11 has many disk operating systems, and
there's even more if you plan on using this interface in a MicroVAX. I
think we're just going in circles, though - somebody else already made this
point before me.
Any ideas on how impliment POWER on fail IRQ and
restore?
Do you mean in the SBC6120? Power fail isn't that complicated - it's just
a flag, a skip-on-flag IOT, and an interrupt. It seems pointless, though,
since the SBC6120 doesn't have non-volatile main memory. OTOH, the SBC6120
is so low power to start with that you could run it for days on a gel cell -
it'd be easier just to provide the whole system with a mini-UPS :-)
Bob
5985
days inactive
5988
days old
15 comments
9 participants
participants (9)
-
ajp166＠bellatlantic.net -
bfranchuk＠jetnet.ab.ca -
bob＠jfcl.com -
chd_1＠nktelco.net -
dj.taylor4＠verizon.net -
ethan.dicks＠usap.gov -
jhfinedp3k＠compsys.to -
mouse＠Rodents.Montreal.QC.CA -
ploopster＠gmail.com