26 Nov
2015
26 Nov
'15
4:29 a.m.
Jerry Weiss wrote:
On Nov 25,
2015, at 10:41 PM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
For example, the DSD 880/30 (from Data Systems Design of course) emulates
3 RL02 disk drives using a single internal (non-removable) hard drive. The box
also holds a single RX03 floppy disk drive (8" floppy disk drive which supports
using single-sided media specified by DEC as an RX02 floppy in addition to
media which have the same physical interface, but which are double-sided).
For a Qbus system, the dual module controller was the interface to both the
three RL02 hard drives and the single RX03 floppy drive. I don't know if
DSD also made a separate controller for the Unibus for the DSD 880/30.
With regard to the address support by the controller for the Qbus, the floppy
drive definitely supported only an 18-bit address. That 18-bit ONLY support
by DSD was identical to the 18-bit support that DEC provided for its Qbus
controller for the RX02, so both DEC and DSD needed a bounce buffer
managed by software to support the RX02 floppy disk for systems with more
than 256 KB of physical memory.
As for DSD support for the RL02 for a 22-bit buffer address, a quick look
at the DSD manual was not able to say one way or the other. However,
it seems more likely the the DSD controller for the RL02 supported ONLY
an 18-bit address. I have all the DSD hardware, but it is not operational
at this point. If anyone else has experience with the DSD controller for
the emulated RL02, let us know if there was 22-bit address support for
its emulated RL02 drive.
Confirming that the original DSD 880 only had support for 18 bits DMA. There are
only 2 bits
in the CS register for extended addressing. I doubled checked the RT-11 handlers I had.
There was a Unibus controller for the original 7.8Mbyte RL02 reduced drive.
Google 040018-01 DSD 880 Users Manual May81
The Sigma SDC RXV31 controller supported 22 bit DMA.
See 400255-C SDC-RXV31 Floppy Ctrl Man Aug86
I saw that model at one point. It was the only one I ever saw, so I
did not bother to include 22-bit support in the DYX.SYS device
handler - mostly because I would not have been able to test the code.
I used both, but double sided compatibility between the
two products was
occasionally spotty. Never did determine if it was a controller, floppy drive or media
issue.
Both the DSD 880/8 and the DSD 880/30 supported double-sided
media for the RX03 floppy drive. A check of the DSD 880/30 manual
from 1981 includes directions to modify the DYX.SYS
device driver
to support double sided operation with V04.00 of RT-11. Inspection
of the file, DY.MAC from V04.00 of RT-11, confirms that DEC had
code which supported double-sided media and even the CSR specs
in the DEC RXV21 controller specifies, as far as I can remember, a
bit to determine if the RX03 floppy drive has detected a double-sided
floppy in the drive. Note that the DEC RX02 floppy drive did not have
that electronics or hardware to detect double-sided media. It is possible
that DEC did produce an in-house RX03 drive, but I am not aware of
DEC actually selling RX03 drives to customers. PLUS, the code in the
file, DY.MAC from V04.00 of RT-11, has bugs (at least in the distribution
copy released with V04.00 of RT-11) which would prevent the correct
operation of a double-sided media. One other point of interest is that
by 1983 when DEC released V05.00 of RT-11, the extra code with
support for double-sided media had been removed from DY.MAC.
It probably should be mentioned that a different position is used for
the index hole for double-sided media (about 1/2" more to the right)
as opposed to the location of the index hole for single-sided media.
The DSD 880/30 RX03 floppy drive has TWO detection circuits
in the two possible positions to determine which media was present
in the drive. Because every floppy media that I ever saw has been
coated on both sides and could support double-sided operation
even if the index hole was in the single-sided location within the
cardboard jacket, I experimented with adding the index holes
required for double-sided operation and covered up the single-sided
index holes. After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position. To add to the success of that extra switch,
the DSD 880/30 supported an off-line LLF (Low Level Format)
which, of course, no DEC controller ever supported for 8" floppy
media.
In answer to the question of support for double-sided media, there
are two methods of using both sides of the floppy. One method
is to read all of one side, then read all of the other side of the floppy
media. The second method is to read both sides of the media for
each cylinder, then increment to the next cylinder. Based on the
code for DY.MAC which was present in V04.00 of RT-11, DEC
choose the former method. It seems possible that if you were using
floppy media written via one method and read by the opposite
method, there would obviously be some confusion. The SMS-1000
(I hope I have remembered the part number correctly) includes
an 8" RX03 type of drive which can handle both single-sided and
double-sided media - although the built-in controller is MSCP based
and both the internal hard drive and the single RX03 floppy drive are
considered DU: or MSCP devices under RT-11. When single-sided
floppy media are used, there is no difficulty. However, if an 8" media
that is double-sided is inserted and files are written to that floppy,
the results can'r be read on the DSD 880/30 using a modified DYX.SYS
device driver which supports double-sided operation since it is quite
obvious that the MSCP controller in the SMS-1000 wrote both sides
of the floppy before changing cylinders. This might have been the
cause of the problem between the two floppy drives. I agree it is
doubtful, but I can't think of anything else.
FINALLY, due to the 18-bit address restriction with all DYX.SYS
device drivers under RT-11, I added code to support a bounce buffer
that allows the user buffer to be in a 22-bit location, but still be able
to support DMA to the silo on the controller. The bounce buffer must
be in the first 256 KB of memory, but the device driver performs
the extra transfer one word at a time between the bounce buffer and
the user buffer if the latter is above the 256 KB boundary.
Jerome Fine
26 Nov
26 Nov
9:22 a.m.
On Nov 26, 2015, at 6:29 AM, Jerome H. Fine <jhfinedp3k at compsys.to> wrote:
This a nice summary of the state of affairs for DEC/RT-11 8 inches Floppies.
I have a idle RXV31 controller and a DSDD 8 inch floppy drive on the list of
devices to restore. Need to scramble up a 24 V supply. The Dilog DQ419
looks to be identical to the Sigma controller, including 22 bit support.
In my collection of handlers, I don?t see any with extra code to support 22 bits.
Thinking back, I?m not sure why I never noticed this before.
We had DSD 440, 480?s and both 880?s, Sigma Information Systems or
whatever was cheapest when we ordered it. We used floppies
as long term storage and often from INMAC. So media quality and
consistency was not high on our list. We collect quite a lot of
patched and tweaked handlers along the way.
The Sigma SDC RXV31 controller supported 22 bit
DMA. See 400255-C SDC-RXV31 Floppy Ctrl Man Aug86
I saw that model at one point. It was the only one I ever saw, so I
did not bother to include 22-bit support in the DYX.SYS device
handler - mostly because I would not have been able to test the code. I used both, but double sided compatibility
between the two products was
occasionally spotty. Never did determine if it was a controller, floppy drive or media
issue.
Both the DSD 880/8 and the DSD 880/30 supported double-sided
media for the RX03 floppy drive. A check of the DSD 880/30 manual
from 1981 includes directions to modify the DYX.SYS device driver
to support double sided operation with V04.00 of RT-11. Inspection
of the file, DY.MAC from V04.00 of RT-11, confirms that DEC had
code which supported double-sided media and even the CSR specs
in the DEC RXV21 controller specifies, as far as I can remember, a
bit to determine if the RX03 floppy drive has detected a double-sided
floppy in the drive. Note that the DEC RX02 floppy drive did not have
that electronics or hardware to detect double-sided media. It is possible
that DEC did produce an in-house RX03 drive, but I am not aware of
DEC actually selling RX03 drives to customers. PLUS, the code in the
file, DY.MAC from V04.00 of RT-11, has bugs (at least in the distribution
copy released with V04.00 of RT-11) which would prevent the correct
operation of a double-sided media. One other point of interest is that
by 1983 when DEC released V05.00 of RT-11, the extra code with
support for double-sided media had been removed from DY.MAC.
It probably should be mentioned that a different
position is used for
the index hole for double-sided media (about 1/2" more to the right)
as opposed to the location of the index hole for single-sided media.
The DSD 880/30 RX03 floppy drive has TWO detection circuits
in the two possible positions to determine which media was present
in the drive. Because every floppy media that I ever saw has been
coated on both sides and could support double-sided operation
even if the index hole was in the single-sided location within the
cardboard jacket, I experimented with adding the index holes
required for double-sided operation and covered up the single-sided
index holes. After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position. To add to the success of that extra switch,
the DSD 880/30 supported an off-line LLF (Low Level Format)
which, of course, no DEC controller ever supported for 8" floppy
media.
I found the LLF was the most frustrating feature of the DSD 880 line.
I never could trust a floppy so treated. Some of the other non-DEC
controllers also had the feature. Given that we were sourcing media
from sources that just stamped their brand on the
floppy, I never got a
handle on how to use the feature consistently.
In answer to the question of support for double-sided media, there
are two methods of using both sides of the floppy. One method
is to read all of one side, then read all of the other side of the floppy
media. The second method is to read both sides of the media for
each cylinder, then increment to the next cylinder. Based on the
code for DY.MAC which was present in V04.00 of RT-11, DEC
choose the former method. It seems possible that if you were using
floppy media written via one method and read by the opposite
method, there would obviously be some confusion. The SMS-1000
(I hope I have remembered the part number correctly) includes
an 8" RX03 type of drive which can handle both single-sided and
double-sided media - although the built-in controller is MSCP based
and both the internal hard drive and the single RX03 floppy drive are
considered DU: or MSCP devices under RT-11. When single-sided
floppy media are used, there is no difficulty. However, if an 8" media
that is double-sided is inserted and files are written to that floppy,
the results can'r be read on the DSD 880/30 using a modified DYX.SYS
device driver which supports double-sided operation since it is quite
obvious that the MSCP controller in the SMS-1000 wrote both sides
of the floppy before changing cylinders. This might have been the
cause of the problem between the two floppy drives. I agree it is
doubtful, but I can't think of anything else.
in our case, 99% of floppies were read on the same drive that wrote them, so it
generally wasn?t a problem. When we moved code and data between
systems, we stuck to RX02 formats to avoid all the compatibility
hassles. Didn?t have any SMS-1000 in our shop, but we often collaborated
with other researchers who had them and the same rule applied.
FINALLY, due to the 18-bit address restriction with
all DYX.SYS
device drivers under RT-11, I added code to support a bounce buffer
that allows the user buffer to be in a 22-bit location, but still be able
to support DMA to the silo on the controller. The bounce buffer must
be in the first 256 KB of memory, but the device driver performs
the extra transfer one word at a time between the bounce buffer and
the user buffer if the latter is above the 256 KB boundary.
We depended on the TSX+ feature to do the bounce automatically
for the 18 bit controllers for the RK,DY, DL or DM. We never threw out
anything working. On faster drives there was obviously a performance hit,
dependent on the processor speed. For the RX02?/3?s I?m sure I measured
it at one point, but on an 11/73 it never seemed to be perceptible on a
daily basis. Our systems did data acquisition and floppies
were used only apr?s experiment.
27 Nov
27 Nov
10:34 a.m.
On Nov 26, 2015, at 04:29, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position.
Wouldn't that approach result in the sectors being shifted with respect to the index
hole vs. the case where the conventional index sensor positions are used? I would imagine
that it's a moot point if the disks are being formatted, written and read on the same
drive, but I can imagine interoperation issues if you later punch the second jacket window
to read/write the disks on an unmodified drive.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
1:26 p.m.
On 2015-11-27 19:34, Mark J. Blair wrote:
If the drive were to use the same offset from the index hole to data,
and so on, yes.
But why would a drive keep those constants the same if the hole moved?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Nov 26, 2015, at 04:29, Jerome H. Fine
<jhfinedp3k at compsys.to> wrote:
After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position.
Wouldn't that approach result in the sectors being shifted with respect to the index
hole vs. the case where the conventional index sensor positions are used? I would imagine
that it's a moot point if the disks are being formatted, written and read on the same
drive, but I can imagine interoperation issues if you later punch the second jacket window
to read/write the disks on an unmodified drive.
28 Nov
28 Nov
6:32 p.m.
Johnny Billquist wrote:
On 2015-11-27
19:34, Mark J. Blair wrote:
On Nov 26, 2015, at 04:29, Jerome H. Fine
<jhfinedp3k at compsys.to>
wrote:
After that worked successfully, I became disappointed
that I had to deface the floppy media with the extra holes. The
simple solution was to use a DPDT switch and flip the detection
circuits so that the RX03 drive would signal a double-sided media
what there was a single-sided index hole and the DPDT switch was
in the alternate position. 
6:57 p.m.
On Sat, 28 Nov 2015, Jerome H. Fine wrote:
it did not cause a problem. The media could be LLF
using either
index hole and then read and written using the other index hole.
changing the rotational position of index will not cause a problem with
WD style controllers - they will read along the track until they find the
sector that they are looking for.
HOWEVER, on NEC 765 type of controllers, the controller is blind
momentarily after the index pulse. If you have a sector starting "too
soon" after the index pulse, the controller won't be able to read it, and
if a sector straddles the index pulse, you may get a read error.
Disabling the index pulse (which is needed for LLF) during read and write
will get around that problem.
If other errors occur, such as "requested sector header not found", they
may be misinterpreted by the drive - it may notice lack of index, and
misreport "time-out"
On some 5.25" drives (some Teac models, for example), the drive uses the
index pulse as part of its determination of "being ready", so on those
drives, any blocking of the index pulse should be done between the drive
and the controller, not by blocking the sensor.
So, . . .
WD style: no problem with index pulse timing relative to data
NEC765 style: index pulse is necessary during LLF, but may need to be
blocked during read/write, although a few of the newest drives may not be
happy without index.
7:39 p.m.
On Sat, 28 Nov 2015, Fred Cisin wrote:
If other errors occur, such as "requested sector
header not found", they may
be misinterpreted by the drive
that's "misinterpreted by CONTROLLER"
although some of the fancier newer drives can also have a problem
So, . . .
WD style: no problem with index pulse timing relative to data
NEC765 style: index pulse is necessary during LLF, but may need to be blocked
during read/write, although a few of the newest drives may not be happy
without index.
9:23 p.m.
On 11/28/2015 06:57 PM, Fred Cisin wrote:
WD style: no problem with index pulse timing relative
to data NEC765
style: index pulse is necessary during LLF, but may need to be
blocked during read/write, although a few of the newest drives may
not be happy without index.
765/8272 are particularly bad in this respect (they're blind for a full
millisecond or so) in contrast with 765A/8272A, which chopped the blind
spot by half.
In the 8272 days, I added a one-shot to delay the blind spot by a
varying amount, which solved the problem neatly, while still allowing
the index to pass through.
The index is also needed for WD17/27 family controllers also for LLF.
Ya gotta start (and end) somewhere.
If you simply block index with the 765 type FDC, you'll never get a
"sector not found" error--if you have a deadman timer, it'll expire.
--Chuck
10:23 p.m.
> WD style: no problem with index pulse timing
relative to data NEC765
> style: index pulse is necessary during LLF, but may need to be
> blocked during read/write, although a few of the newest drives may
> not be happy without index.
On Sat, 28 Nov 2015, Chuck Guzis wrote:
765/8272 are particularly bad in this respect
(they're blind for a full
millisecond or so) in contrast with 765A/8272A, which chopped the blind spot
by half.
In the 8272 days, I added a one-shot to delay the blind spot by a varying
amount, which solved the problem neatly, while still allowing the index to
pass through.
The index is also needed for WD17/27 family controllers also for LLF. Ya
gotta start (and end) somewhere.
Yep.
Need index for LLF, but not necessarily for read/write, albeit with a few
complications
If you simply block index with the 765 type FDC,
you'll never get a "sector
not found" error--if you have a deadman timer, it'll expire.
Exactly. It will time out, and get a time-out error instead of the
requested sector not found.
3093
days inactive
3096
days old
8 comments
6 participants
participants (6)
-
bqt＠update.uu.se -
cclist＠sydex.com -
cisin＠xenosoft.com -
jhfinedp3k＠compsys.to -
jsw＠ieee.org -
nf6x＠nf6x.net