11 Aug
2015
11 Aug
'15
8:27 p.m.
Here at the museum I'm evaluating the use of a SuperCard Pro
(http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate 8"
floppies from various machines. It's not technically supported (the manual states
that it *should* work but has not been tested, etc.) The disks I'm reading are
nothing exotic (They're standard double-density, double-sided disks with an IBM format
-- I could use a PC and ImageDisk to do the job, but the SuperCard is very convenient, in
theory...)
Thus far I've been successful in creating images of floppies, but less successful in
writing them back out. Thus far I've tried a pair of Shugart 851s and a Qume
QumeTrack 842. I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with
cabling and the TG43 signals. (And the 851s are jumpered properly for the TG43 signal, as
far as I can tell). I've also tried a variety of media (Verbatim, Maxell) with the
same results (though the position of the bad data varies from attempt to attempt).
The issue is that upon reading back a disk that has been written via the SuperCard, data
is fine up until about cylinder 60, at which point bad sectors start appearing more and
more frequently (though most of the data is still OK). I tried disabling TG43 just to see
if it made a difference, and it does - with TG43 disabled sectors written past cylinder 43
read back as garbage.
I'm running short of ideas. Anyone else have any experience with this combo? Any
suggestions on troubleshooting tips?
Thanks,
Josh
Sr. Vintage Software Engineer
Living Computer Museum
www.livingcomputermuseum.org<http://www.livingcomputermuseum.org>
11 Aug
11 Aug
8:38 p.m.
On Tue, Aug 11, 2015 at 6:27 PM, Josh Dersch
<JoshD at livingcomputermuseum.org> wrote:
The issue is that upon reading back a disk that has
been written via the SuperCard, data is fine up until about cylinder 60, at which point
bad sectors start appearing more and more frequently (though most of the data is still
OK). I tried disabling TG43 just to see if it made a difference, and it does - with TG43
disabled sectors written past cylinder 43 read back as garbage.
The SuperCard is apparently not using a suitable amount of write
precompensation for the drives you're using.
8:42 p.m.
On 08/11/2015 05:27 PM, Josh Dersch wrote:
The issue is that upon reading back a disk that has
been written via
the SuperCard, data is fine up until about cylinder 60, at which
point bad sectors start appearing more and more frequently (though
most of the data is still OK). I tried disabling TG43 just to see if
it made a difference, and it does - with TG43 disabled sectors
written past cylinder 43 read back as garbage.
I'm running short of ideas. Anyone else have any experience with
this combo? Any suggestions on troubleshooting tips?
So what does the software do to compensate for bit crowding/shifting
when writing to the inner cylinders? That is, what sort of write
precompensation does it perform?
--Chuck
8:53 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: Tuesday, August 11, 2015 5:42 PM
To: General at classiccmp.org; Discussion@
Subject: Re: Writing 8" floppies with SuperCard Pro
On 08/11/2015 05:27 PM, Josh Dersch wrote:
> The issue is that upon reading back a disk that
has been written via
> the SuperCard, data is fine up until about cylinder 60, at which point
> bad sectors start appearing more and more frequently (though most of
> the data is still OK). I tried disabling TG43 just to see if it made
> a difference, and it does - with TG43 disabled sectors written past
> cylinder 43 read back as garbage.
>
> I'm running short of ideas. Anyone else have any experience with this
> combo? Any suggestions on troubleshooting tips?
So what does the software do to compensate for bit
crowding/shifting
when writing to the inner cylinders? That is, what sort of write
precompensation does it perform?
Absolutely no idea -- the manual isn't particularly technical and the SDK mentions
nothing. I'll see if there's anything to be dug up in this regard. (Thanks also
to Eric for suggesting this problem...)
- Josh
--Chuck
9:35 p.m.
On 8/11/15 5:53 PM, Josh Dersch wrote:
Absolutely no idea -- the manual isn't
particularly technical and the SDK mentions nothing. I'll see if there's anything
to be dug up in this regard. (Thanks also to Eric for suggesting this problem...)
- Josh
You may want to try asking on the supercard board. the developer seems like a reasonable
guy.
I just picked up a card recently as well.
10:24 p.m.
On 08/11/2015 05:53 PM, Josh Dersch wrote:
Absolutely no idea -- the manual isn't
particularly technical and
the SDK mentions nothing. I'll see if there's anything to be dug up
in this regard. (Thanks also to Eric for suggesting this
problem...)
There should certainly be enough horsepower there to do just about
anything. The cheap Chinese emulators use a little STM32F0 ARM Cortex
M0 family MCU--dirt-cheap. There's a bit of logic to perform level
shifting and OC interface, but that's about it. If you encode/decode
MFM data on the fly, 32K is more than enough for track storage at 500Khz
and a little buffering. Some years back, I did an emulator using a
ATMega162 DIP and some external SRAMm running at 8MHz. Still more than
enough, but a little tighter in coding. The Chinese ones get away cheap
because the format and encoding is predetermined.
But back to write precompensation. The general theory is this.
Outer tracks have lower linear bit densities than inner ones because
they're longer from index to index. (Would you rather run a race on the
inside or the outside track?) Thus, bits (or rather changes in
direction of magnetization) are closer together. Depending on head
construction and track width, adjacent bits can be shifted via
interference from the nominal bit timing window (yes, that means a bit
already written can be shifted away from its nominal window timing
center even though you put it there originally).
So, the scheme is to "write with history". That is, a shift register is
used to remember what was last written, what you're currently writing
and then what's about to be written--and the write signal shifted a few
hundred nanoseconds "early" or "late" (or not at all) according to
current, past and future data, which produces a train that's closer to
optimal.
All of which explains why the results with no precompensation get worse
the shorter the track gets.
Another approach is to use "zoned" recording, where the disk is divided
into zones of varying bit density, according to how close to the hub
they are. You may be familiar with this with the Victor 9000 or early
Mac floppy drives, but the technique is much older than floppies.
Hope this helps,
Chuck
12 Aug
12 Aug
1:11 p.m.
Thanks for the detailed description (and thanks to everyone else for their input!). That
all makes sense. The firmware for the SuperCard Pro is closed source (which is kind of a
bummer) so I can't look at it to see what it's doing. I've posted a message
on the CBMStuff Forum and we'll see what the creators say.
Thanks!
- Josh
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chuck Guzis
Sent: Tuesday, August 11, 2015 7:25 PM
To: General at classiccmp.org; Discussion@
Subject: Re: Writing 8" floppies with SuperCard Pro
On 08/11/2015 05:53 PM, Josh Dersch wrote:
Absolutely no idea -- the manual isn't
particularly technical and the
SDK mentions nothing. I'll see if there's anything to be dug up in
this regard. (Thanks also to Eric for suggesting this
problem...)
There should certainly be enough horsepower there to do just about anything. The cheap
Chinese emulators use a little STM32F0 ARM Cortex
M0 family MCU--dirt-cheap. There's a bit of logic to perform level shifting and OC
interface, but that's about it. If you encode/decode MFM data on the fly, 32K is more
than enough for track storage at 500Khz and a little buffering. Some years back, I did an
emulator using a
ATMega162 DIP and some external SRAMm running at 8MHz. Still more than enough, but a
little tighter in coding. The Chinese ones get away cheap because the format and encoding
is predetermined.
But back to write precompensation. The general theory is this.
Outer tracks have lower linear bit densities than inner ones because they're longer
from index to index. (Would you rather run a race on the inside or the outside track?)
Thus, bits (or rather changes in direction of magnetization) are closer together.
Depending on head construction and track width, adjacent bits can be shifted via
interference from the nominal bit timing window (yes, that means a bit already written can
be shifted away from its nominal window timing center even though you put it there
originally).
So, the scheme is to "write with history". That is, a shift register is used to
remember what was last written, what you're currently writing and then what's
about to be written--and the write signal shifted a few hundred nanoseconds
"early" or "late" (or not at all) according to current, past and
future data, which produces a train that's closer to optimal.
All of which explains why the results with no precompensation get worse the shorter the
track gets.
Another approach is to use "zoned" recording, where the disk is divided into
zones of varying bit density, according to how close to the hub they are. You may be
familiar with this with the Victor 9000 or early Mac floppy drives, but the technique is
much older than floppies.
Hope this helps,
Chuck
11 Aug
11 Aug
9:38 p.m.
Looks interesting - kind of like a catweasel using a USB bus instead of
a PCI bus.
I have only used my catweasel for reading, but in theory it could write
as well.
As for floppy emulators on the drive side, I have an SD HxC Floppy
emulator (www.lotharek.pl) which I am currently using with an Altos
8000-2 to test it (just booted successfully for the first time today).
One can write to it as a floppy drive, too, which I have done - a way to
capture an image using a running system.
Aside from the write pre-comp thing which you seem to have in hand (and
which is generally handled by the *drive*, not the controller, i.e., the
bit timing from the controller does not change, as far as I know), one
other thing you should check is to make sure that you have your
termination in place on the drive, otherwise it can mess things up on
writes.
I am presuming that your SuperCard properly terminates the *read* lines
(RawData# in particular, and, if the drive has its own data separator
and you can use it from the SuperCard Pro, SepData# and SepClk#, as
well) - otherwise that could be an issue, too. I see a few SMD
components in the photo, but unless they are hiding under the board, I
didn't see any components placed near the connector where one might
expect termination. I'd be really surprised if the designers forgot
that, but it never hurts to ask, just in case.
JRJ
On 8/11/2015 7:27 PM, Josh Dersch wrote:
Here at the museum I'm evaluating the use of a
SuperCard Pro (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate
8" floppies from various machines. It's not technically supported (the manual
states that it *should* work but has not been tested, etc.) The disks I'm reading are
nothing exotic (They're standard double-density, double-sided disks with an IBM format
-- I could use a PC and ImageDisk to do the job, but the SuperCard is very convenient, in
theory...)
Thus far I've been successful in creating images of floppies, but less successful in
writing them back out. Thus far I've tried a pair of Shugart 851s and a Qume
QumeTrack 842. I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with
cabling and the TG43 signals. (And the 851s are jumpered properly for the TG43 signal, as
far as I can tell). I've also tried a variety of media (Verbatim, Maxell) with the
same results (though the position of the bad data varies from attempt to attempt).
The issue is that upon reading back a disk that has been written via the SuperCard, data
is fine up until about cylinder 60, at which point bad sectors start appearing more and
more frequently (though most of the data is still OK). I tried disabling TG43 just to see
if it made a difference, and it does - with TG43 disabled sectors written past cylinder 43
read back as garbage.
I'm running short of ideas. Anyone else have any experience with this combo? Any
suggestions on troubleshooting tips?
Thanks,
Josh
Sr. Vintage Software Engineer
Living Computer Museum
www.livingcomputermuseum.org<http://www.livingcomputermuseum.org>
12 Aug
12 Aug
5:05 a.m.
On Tue, 11 Aug 2015, Jay Jaeger wrote:
Aside from the write pre-comp thing which you seem to
have in hand (and
which is generally handled by the *drive*, not the controller, i.e., the
bit timing from the controller does not change, as far as I know), one
Au contraire.
Write precompensation is entirely handled by the controller.
The drive has absolutely no idea of what it records or reads.
(We're talking about floppy disk drives, not intelligent hard disks with
integrated encoder/decoder and PLL like SMD or ESDI)
Christian
9:26 a.m.
You and I were thinking of two different things: I was thinking of the
reduced write current on the inside tracks, and you were thinking of
changing the bit timing. On the latter point, I was incorrect.
For reduced write current, all the controller does is to tell the drive
whether or not it is on an inside track, the drive handles the rest. I
note that the pin used for this varies from drive to drive. On a
Shugart 850, this is on pin 2. On a Siemens FDD 100-8, this is on pin
16, so this is something that the original correspondent should check
for each of his/her drives.
The Shugart 801 does not seem to have this feature. Also, there is a
model of the FDD 100-8C, which counts the tracks ON ITS OWN, and DOES
handle this automatically, and that is where I got confused. There are
also some 5" drives which do this, e.g. the Tandon 848, either using a
signal from the controller (on pin 2) or on their own.
Then, when this reduced write current signal is active-low, the drive
reduces the write current. This is the "TRK 43" signal that the
correspondent actually referred to. Most of my 8" floppy experience was
with the single-density FD1771, which does NOT change the bit timing,
and ONLY has this "TG43" signal.
But, you are also right in that the later controllers, e.g., the FD
1791, for example, also provide two additional signals, "EARLY" and
"LATE" for write precompensation. As you point out, these signals do
not go to the drive, but instead are typically used inside the
controller to change the timing of the write pulses.
The correspondent should probably check with the SuperCard Pro folks to
make sure BOTH have been implemented. It is quite possible neither have.
On 8/12/2015 4:05 AM, Christian Corti wrote:
On Tue, 11 Aug 2015, Jay Jaeger wrote:
Aside from the write pre-comp thing which you
seem to have in hand (and
which is generally handled by the *drive*, not the controller, i.e., the
bit timing from the controller does not change, as far as I know), one
Au contraire.
Write precompensation is entirely handled by the controller. The drive
has absolutely no idea of what it records or reads.
(We're talking about floppy disk drives, not intelligent hard disks with
integrated encoder/decoder and PLL like SMD or ESDI)
Christian
10:30 a.m.
On 8/12/15 6:26 AM, Jay Jaeger wrote:
The correspondent should probably check with the
SuperCard Pro folks to
make sure BOTH have been implemented. It is quite possible neither have.
I know Philip ran into this with writing real media with his Diskferret. You
can find a discussion about it in the archives (well, actually, you can't).
Which reminds me..
The archive have never come back to http://www.classiccmp.org/lists.html
I should have been more diligent with archiving them on my own, and now have
a couple year hole in my local copy.
11 Aug
11 Aug
9:47 p.m.
On Wed, 12 Aug 2015, Josh Dersch wrote:
Thus far I've been successful in creating images
of floppies, but less
successful in writing them back out. Thus far I've tried a pair of
Shugart 851s and a Qume QumeTrack 842. I'm using a DBit FDADAP
I agreee with Eric and Chuck.
A quick experiment, . . .
Howzbout take one of those images, and instead of writitng to an 8" drive,
try writing it to a 1.2M 5.25" drive.
12 Aug
12 Aug
10:55 a.m.
Josh Dersch wrote:
Here at the museum I'm evaluating the use of a
SuperCard Pro (http://www.cbmstuff.com/proddetail.php?prod=SCP) to archive and duplicate
8" floppies from various machines. It's not technically supported (the manual
states that it *should* work but has not been tested, etc.) The disks I'm reading are
nothing exotic (They're standard double-density, double-sided disks with an IBM format
-- I could use a PC and ImageDisk to do the job, but the SuperCard is very convenient, in
theory...)
Thus far I've been successful in creating images of floppies, but less successful in
writing them back out. Thus far I've tried a pair of Shugart 851s and a Qume
QumeTrack 842. I'm using a DBit FDADAP (http://www.dbit.com/fdadap.html) to deal with
cabling and the TG43 signals. (And the 851s are jumpered properly for the TG43 signal, as
far as I can tell). I've also tried a variety of media (Verbatim, Maxell) with the
same results (though the position of the bad data varies from attempt to attempt).
The issue is that upon reading back a disk that has been written via the SuperCard, data
is fine up until about cylinder 60, at which point bad sectors start appearing more and
more frequently (though most of the data is still OK). I tried disabling TG43 just to see
if it made a difference, and it does - with TG43 disabled sectors written past cylinder 43
read back as garbage.
I'm running short of ideas. Anyone else have any experience with this combo? Any
suggestions on troubleshooting tips?
I doubt that this suggestion will help, but it might be
useful for what are called RX03 compatible media.
The RX02 drive from DEC was emulated in hardware
by DSD (Data Systems Design). DSD Produced a
drive which was named the DSD 880/30 which consisted
of 3 * RL02 internal drives and a single floppy drive which
could read IBM Single Density and DEC Double Density
floppy media. The DEC names for those two floppy media
were RX01 and RX02. The actual DEC RX02 drive was
able to read in both Single Density and Double density modes.
In the case of the DEC RX01 and DEC RX02 drives, they
were both Single Sided. Further DEC did at one point intend
to support a Double Sided drive which I understand was to
be called the DEC RX03, but it was never released that I
ever heard about. The software support was specifically
included in V04.00 of RT-11 in the file DY.MAC, but was
probably never tested since the code was incorrect. By
V05.00 of RT-11, DY.MAC no longer contained the extra
code to support Double Sided media.
DSD extended the support and the DSD 880/30 contained
an RX03 compatible drive which could read Double Density
Double Sided media. What I don't know is IF the physical
characteristics of the Double Density media which DEC and
DSD supported are identical to the Double Density physical
characteristics of the floppy media to which you refer as having
"an IBM format" since I have never encountered any floppy
media from IBM other than Single Sided / Single Density.
To make matters simple IF the floppy media which you have
are compatible with DEC RX02 Double Density format, then
with the DSD RX03 floppy drive, I extended the DY.MAC
file for RT-11 and it now supports reading a Double Sided /
Double Density floppy mounted in a DSD RX03 drive. If
you can manage to locate a DSD 880/30 and controller to
run on a DEC PDP-11/73 with RT-11, then I can make the
DYX.SYS device driver available. To first make sure that
everything will work with the DSD 880/30, you can test your
floppy to see if a DEC RX02 can at least read the first side of
your floppy.
Please let me know if you know the answer to if your Double
Sided / Double Density floppy media are DEC RX02 compatible
on at least the first side. If that is true, then the DSD 880/30
drive will probably be able to read both sides very easily.
If you have any questions, please ask.
Jerome Fine
3301
days inactive
3301
days old
12 comments
8 participants
participants (8)
-
aek＠bitsavers.org -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
cisin＠xenosoft.com -
cube1＠charter.net -
jhfinedp3k＠compsys.to -
JoshD＠LivingComputerMuseum.org -
spacewar＠gmail.com