1 Feb
2021
1 Feb
'21
9:54 a.m.
Looking at the DEC Pro documentation there's some ambiguity I'm trying to figure
out.
The hard drive documentation talks about the "reduced write current" signal. In
one place it's explicitly described as relevant to the RD50 only. But later on in the
RD50/RD51 chapter the signal is described generally, without any indication that RD51
ignores it.
Does anyone know which is correct? If RD51 also uses it, how does the right value get
set? What IS the right value, anyway?
paul
1 Feb
1 Feb
10:36 a.m.
On Mon, Feb 1, 2021 at 10:54 AM Paul Koning via cctalk <
cctalk at classiccmp.org> wrote:
Looking at the DEC Pro documentation there's some
ambiguity I'm trying to
figure out.
The hard drive documentation talks about the "reduced write current"
signal. In one place it's explicitly described as relevant to the RD50
only. But later on in the RD50/RD51 chapter the signal is described
generally, without any indication that RD51 ignores it.
Does anyone know which is correct? If RD51 also uses it, how does the
right value get set? What IS the right value, anyway?
The RD51 was the ST-412 while the RD50 was the ST-506. There's a combined
OEM manual for these drives.
http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf which has
the answer. It's used in the ST406, but ignored in the ST-412. See Page 16
for the notes.
Based on that, I think it's pretty safe to say the RD50 needed it, but the
RD51 and newer did not.
Warner
11:14 a.m.
On Feb 1, 2021, at 1:36 PM, Warner Losh <imp at
bsdimp.com> wrote:
On Mon, Feb 1, 2021 at 10:54 AM Paul Koning via cctalk <cctalk at classiccmp.org>
wrote:
Looking at the DEC Pro documentation there's some ambiguity I'm trying to figure
out.
The hard drive documentation talks about the "reduced write current" signal.
In one place it's explicitly described as relevant to the RD50 only. But later on in
the RD50/RD51 chapter the signal is described generally, without any indication that RD51
ignores it.
Does anyone know which is correct? If RD51 also uses it, how does the right value get
set? What IS the right value, anyway?
The RD51 was the ST-412 while the RD50 was the ST-506. There's a combined OEM manual
for these drives. http://www.bitsavers.org/pdf/seagate/ST412_OEMmanual_Apr82.pdf which has
the answer. It's used in the ST406, but ignored in the ST-412. See Page 16 for the
notes.
Based on that, I think it's pretty safe to say the RD50 needed it, but the RD51 and
newer did not.
Great information, thanks!
I've now tracked down analogous manuals for all Pro drives except for the RD53, I
don't know what kind of drive that is.
Learned some other interesting things. The Pro technical manual says the write precomp
register should be set to do precomp starting at cylinder 256 for the RD52. That's
correct for the Quantum model (8 head). It's wrong for the Atasi, which is the other
"RD52" variant mentioned in the manual; its documentation says it should be
cylinder 320. And the CDC RD52, mentioned in internal documents (I don't know if it
shipped) is a CDC Wren, which has a strange rule: precomp "recommended for all
cylinders, required for cylinder > 128".
paul
11:24 a.m.
On Feb 1, 2021, at 2:17 PM, Dennis Boone via cctalk
<cctalk at classiccmp.org> wrote:
Thanks. RD54 isn't supported on the Pro as far as I know, too many cylinders. RD53
is at the exact upper limit of what the Pro controller can address.
I realized I also don't know the RD31 and RD32.
paul
I've now tracked down analogous manuals for
all Pro drives except for
the RD53, I don't know what kind of drive that is.
I believe:
RD53 Micropolis 1325 71 MB
RD54 Maxtor XT2190 159 MB 
11:32 a.m.
I realized I also don't know the RD31 and RD32.
The rest of the list I found long ago is:
RD31 Seagate ST-225 20 MB
RD32 Seagate ST-251 42 MB
RD51 Seagate ST-412 10 MB
RD52 Quantum Q540 31 MB
It's clearly incomplete, as you found there were two different devices
used for one of th RD models.
De
11:36 a.m.
On Feb 1, 2021, at 2:32 PM, Dennis Boone via cctalk
<cctalk at classiccmp.org> wrote:
Excellent.
The Pro technical manual clearly mentions two RD52 variants, the other one is an Atasi
3046. And the rumored CDC RD52 is a 9415-36 ("Wren I").
paul
I realized I also don't know the RD31 and
RD32.
The rest of the list I found long ago is:
RD31 Seagate ST-225 20 MB
RD32 Seagate ST-251 42 MB
RD51 Seagate ST-412 10 MB
RD52 Quantum Q540 31 MB
It's clearly incomplete, as you found there were two different devices
used for one of th RD models.
De 
2:35 p.m.
New subject: Greaseweazle
https://github.com/keirf/Greaseweazle
I heard about this today and I'm surprised I hadn't heard about it
on this list before.
Flux reading and writing from all sizes of floppy?
Anyone here using one? I'd love to get it working for 8 inch,
5 1/4, 3 1/2 drives here in my shop.
- John
2:51 p.m.
New subject: Greaseweazle
I have one, been trying to get it going for a bit now with an 8" shugart
SA801. I am now just struggling to get power to the shugart, need a few
commercial AMP mate-n-lok connectors and some new caps for the shugart
supply I have that gave up the ghost.
Seems neat, but I am very much learning disk archival still. I did get
HT-11 online, my RX01/02 imaging pipeline is great :)
-Eric
On Mon, Feb 1, 2021, 4:41 PM John Foust via cctalk <cctalk at classiccmp.org>
wrote:
https://github.com/keirf/Greaseweazle
Anyone here using one? I'd love to get it working for 8 inch,
5 1/4, 3 1/2 drives here in my shop.
2:58 p.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, John Foust via cctalk wrote:
https://github.com/keirf/Greaseweazle
I heard about this today and I'm surprised I hadn't heard about it
on this list before.
Flux reading and writing from all sizes of floppy?
Anyone here using one? I'd love to get it working for 8 inch,
5 1/4, 3 1/2 drives here in my shop.
I've got one (F7+ Lightning version) and I've used it with 5.25" and
8"
disks. I've got plans to use it with 8" disks, but I've not done it yet.
You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html
in order to use it with the GW.
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
3:28 p.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, John Foust via cctalk wrote:
>
> https://github.com/keirf/Greaseweazle
>
> I heard about this today and I'm surprised I hadn't heard about it
> on this list before.
>
> Flux reading and writing from all sizes of floppy?
>
> Anyone here using one? I'd love to get it working for 8 inch,
> 5 1/4, 3 1/2 drives here in my shop.
>
On Mon, 1 Feb 2021, geneb via cctalk wrote:
I've got one (F7+ Lightning version) and I've
used it with 5.25" and 8"
disks. I've got plans to use it with 8" disks, but I've not done it yet.
You'll need to get the FDADAP from here: http://www.dbit.com/fdadap.html in
order to use it with the GW.
If you are READing 8" disks, and ONLY READing, then you can get away with
a simpler caable. The main time that you might need the fdadap is for
TG43 for writing. But, the fdadap is a convenient way to not have to make
a cable.
It looks promising.
The docs on the website are a little thin. It could use some instructions
written for somebody who has never seen it before.
For example,
" type gw -h to see available commands" could certainly stand to be
expanded to list the commands, and provide discussion of what each
one does. Even if it is "obvious".
The examples for Specifying Tracks were not bad, but could use some
beginner support, such as explaining that heads are 0,1 and a 40 track
drive numbers from 0-39, not 1-40, etc.
Documentation should also always include a list of EVERY error
code, with a more detailed explanation of what each one actually means.
And, some explanations of how to tell whether you need to do double
stepping, including what the incorrect results will look like if you get
it wrong.
Including what the resulting file will look like for trying to read an
unformatted track.
Explanation of FM, MFM, and GCR encoding, or at least pointers to places
where those are discussed.
But, it is not the worst example that I have ever seen of:
"It doesn't need any documentation. Just run the program. The menus in
the program tell you everything that you could need to know."
With XenoCopy, I found that I needed to include a
Quick Start
A Tutorial
A Reference
Even with that, an enormous amount of handholding was needed. Including,
of course, answers to questions of HOW-TO do thing that the program
clearly stated it could not do, such as reading Apple 5.25" disks without
additional hardware.
2 Feb
2 Feb
12:44 a.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, Fred Cisin wrote:
If you are READing 8" disks, and ONLY READing,
then you can get away with a
simpler caable. The main time that you might need the fdadap is for TG43 for
writing. But, the fdadap is a convenient way to not have to make a cable.
You only need the TG43 signal for old drives. All the 8" drives that I
use with a PC or BeagleBone (with a modified mfmreader software) don't
need this signal.
Christian
1 Feb
1 Feb
3:24 p.m.
New subject: Greaseweazle
On 2/1/21 2:35 PM, John Foust via cctalk wrote:
https://github.com/keirf/Greaseweazle
I heard about this today and I'm surprised I hadn't heard about it
on this list before.
Flux reading and writing from all sizes of floppy?
Anyone here using one? I'd love to get it working for 8 inch,
5 1/4, 3 1/2 drives here in my shop.
- John
Eric Schlaepfer built a version with buffering and 5" and 8"
connectors.
There is a fair amount of churn as what they want the hardware to be
and the project is siloed because of their insistence on using farcebook
for communications.
4:13 p.m.
New subject: Greaseweazle
On 2/1/21 3:24 PM, Al Kossow via cctalk wrote:
Eric Schlaepfer built a version with buffering and
5" and 8" connectors.
There is a fair amount of churn as what they want the hardware to be
and the project is siloed because of their insistence on using farcebook
for communications.
Early on, I built one with buffering and played with it (I already had
the parts in my hellbox), but I prefer to use a more capable MCU to to
my work (i.e. not an STM32F1, but STM32F407). More memory, faster
clocks; I could probably do hard disks with it, by just adding the
differential buffers and writing some firmware. Not a whole lot of
difference in cost, either--$10 for a 407 board with clock/calendar,
SDHC SDIO,etc.
There's also a similar implementation using a very inexpensive Cypress
PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable).
It's what I've been saying for years--just about any moderately capable
modern MCU can do the job. After all the Gotek emulator uses a nearly
obsolescent STM32F107 or 105 MCU. The "blue pill" STM32F103 is quite a
bit more capable.
Glad people finally tumbled to this.
--Chuck
5:24 p.m.
New subject: Greaseweazle
At 06:15 PM 2/1/2021, Al Kossow via cctalk wrote:
On 2/1/21 4:13 PM, Chuck Guzis via cctalk wrote:
What aspects are they missing?
- John
any moderately capable
modern MCU can do the job.
and it is the software and the knowledge of what you need to do when
recovering media in volume these guys have no clue about
5:54 p.m.
New subject: Greaseweazle
On 2/1/21 5:24 PM, John Foust via cctalk wrote:
What aspects are they missing?
The workflow of 'squirt across a bitstream from the whole disk, let the PC
chew on it and maybe it's right' is fundamentally wrong
It may work on clean media but you are guaranteed of getting garbage after the
head clogs at some point during the march across the disk.
6:17 p.m.
New subject: Greaseweazle
At 07:54 PM 2/1/2021, Al Kossow via cctalk wrote:
The workflow of 'squirt across a bitstream from the
whole disk, let the PC
chew on it and maybe it's right' is fundamentally wrong
It may work on clean media but you are guaranteed of getting garbage after the
head clogs at some point during the march across the disk.
Hmm, OK... So a dirty media problem eventually goops the head...
Are you saying a flux recorder should have a better way of detecting that problem?
And stop earlier?
- John
6:22 p.m.
New subject: Greaseweazle
On 2/1/21 6:17 PM, John Foust via cctalk wrote:
Are you saying a flux recorder should have a better
way of detecting that problem?
Yes, the way they do it now if you have one shot at recovering a disk you are sure to
fail.
Imagedisk, even though it spends way too much time with the heads spinning on the media
at
least does real-time retries. the problem is you also need to be able to stop and
assemble a complete image by splicing together multiple partial attempts.
10:02 p.m.
New subject: Greaseweazle
There is also Kryoflux: https://kryoflux.com/
It works well for me even with the copy protected disks ImageDisk can't
copy with.
Tom Hunter
On Tue, Feb 2, 2021 at 10:23 AM Al Kossow via cctalk <cctalk at classiccmp.org>
wrote:
On 2/1/21 6:17 PM, John Foust via cctalk wrote:
Are you saying a flux recorder should have a
better way of detecting
that problem?
Yes, the way they do it now if you have one shot at recovering a disk you
are sure to fail.
Imagedisk, even though it spends way too much time with the heads spinning
on the media at
least does real-time retries. the problem is you also need to be able to
stop and
assemble a complete image by splicing together multiple partial attempts.
10:57 p.m.
New subject: Greaseweazle
On 2/1/2021 10:02 PM, Tom Hunter via cctalk wrote:
It works well for me even with the copy protected
disks ImageDisk can't
copy with.
The biggest problem imaging programs had trouble with was how to
duplicate whatever errors were on the disk (as in abnormal patterns)
when making a copy.
I had the best luck with nearly everything with a package called
copywright (I think).? Big claim to fame was preserving the bit count on
the track and spacing when writing.
Simple software rarely bothered to do that.? They could stretch the
image to fit each track.
Unless the copy "protector" looked at a way to fit to a generic disk
with little variability in the manufacturing, the copy schemes didn't
have a lot of other tricks once many of the weird crap was tried and
defeated.
I work for a company which sold a database program which actually was
defeated by that after they fooled a lot of other programs.
good to hear that Greasweazle works for that.? I have one from Keir
Fraser who does a good job of supporting it.
Also FWIW, Facebook sucks etc. blah blah, but you can make a fairly low
information account and join.? FB works happily with adblock plus, and
anti tracking for cookies turned up high, and I have a lot of utility
machines, one can be rigged to allow FB use w/o any of the pain.? At
this writing there are 1192 members there.
Of course all the questions that any media backup, archival, copy, etc.
are generating is there, but there is no embargo on the information.?
The group is private mainly to keep out the rif raf who spam.
I have several groups I manage and do the same.? Better to block the
membership being ad hoc than having to watch it if you want to keep it
spam and bullshit free.
thanks
Jim
2 Feb
2 Feb
12:03 a.m.
New subject: Greaseweazle
I have a Greaseweazle F7+, and I have an fdadap as well (and a Shugart
8" drive), a 5 1/4" drive (my main target, the 8" follows), and 3.5"
drives (not really a target - the 3.5" HD floppies are mostly
unreadable anyway).
So, I'm ready to go.. except that due to sleep deprivation I managed
to dump my 5 1/4" floppy cable (the one with an edge connector), in a
"what's this?" moment late at night (had to move, sort, pack, dump a
lot of stuff). I had spent time to get that cable.. argh. So, edge
connectors etc. have arrived on a slow boat, I've got all the parts
but I have yet to connect it all and start testing the thing.
And yes that FB thing is annoying. There's no way I will go there
(it's blocked anyway, on the network level here). Fortunately there is
some documentation floating around elsewhere too.
2:32 a.m.
New subject: Greaseweazle
On 2/1/21 10:57 PM, jim stephens via cctalk wrote:
Of course all the questions that any media backup,
archival, copy, etc. are generating is there, but there is no embargo on the information.
The group is private
So someone should mirror it.
I'm not having anything to do with Facebook.
3:12 a.m.
New subject: Greaseweazle
On 2/1/21 10:57 PM, jim stephens via cctalk wrote:
The biggest problem imaging programs had trouble with
was how to duplicate whatever errors were on the disk (as in abnormal patterns) when
making a copy.
Copy protection is just a pain in the ass.
A tiny, tiny fraction of what I work with has any and
I'm very happy it is mostly used on consumer computers
which are being archived by others so I don't have to.
3:17 a.m.
New subject: Greaseweazle
On 2/2/21 3:12 AM, Al Kossow via cctalk wrote:
A tiny, tiny fraction of what I work with has any and
I'm very happy it is mostly used on consumer computers
which are being archived by others so I don't have to.
A great example is this little Apple II nightmare
https://twitter.com/bitsavers/status/1353909647833358337
3 Feb
3 Feb
3:03 a.m.
New subject: Greaseweazle
On Tue, 2 Feb 2021, Al Kossow wrote:
Copy protection is just a pain in the ass.
A tiny, tiny fraction of what I work with has any and
I'm very happy it is mostly used on consumer computers
which are being archived by others so I don't have to.
:-))
This is also my attitude. I just don't care about fancy copy protection
schemes, it is not my domain.
Christian
2 Feb
2 Feb
12:55 a.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, Al Kossow wrote:
Imagedisk, even though it spends way too much time
with the heads
spinning on the media at least does real-time retries. the problem is
you also need to be able to stop and assemble a complete image by
splicing together multiple partial attempts.
Well, isn't that logical? ;-)
I do this with my Linux implementation of IMD, and I do this with my
floppy version of the mfmreader: immediately abort an operation when there
are noises coming from the media, clean, restart at one/two cylinders
before the forced abort, etc. and then "splice" together the individual
read attempts.
You can't do real-time retries when reading at the flux level if you have
no idea of the format. So often, it's better to sample a disk several
times in case that the later processing reveals bad sectors. So often
enough you can get an error free image produced from several samples.
The toughest part of course is the "PLL" that you need in software to lock
to the bit rate.
Christian
2:52 a.m.
New subject: Greaseweazle
On 2/2/21 2:28 AM, Al Kossow via cctalk wrote:
On 2/2/21 12:55 AM, Christian Corti via cctalk wrote:
> I do this with my Linux implementation of IMD, and I do this with my floppy version
of the mfmreader
Do you make these available online?
I found your version of IMD here ftp://computermuseum.informatik.uni-stuttgart.de/utils
not under source control.
I hate the fact that there are dozens of siloed projects in this problem space.
3:03 a.m.
New subject: Greaseweazle
On 2/2/21 2:54 AM, Al Kossow via cctalk wrote:
On 2/2/21 2:52 AM, Al Kossow via cctalk wrote:
and before IMD there was Eric's DMK imager, which is what I used before Dave's
program
http://dmklib.brouhaha.com/
which was compatible with Catweasel DMKs
I hate the fact that there are dozens of siloed
projects in this problem space.
Including cctlk. There is actually a medialab channel on the cctlk discord
3:08 a.m.
New subject: Greaseweazle
On 2/2/21 3:03 AM, Al Kossow via cctalk wrote:
On 2/2/21 2:54 AM, Al Kossow via cctalk wrote:
great.. the DMK spec link there is 404
a version appears to be in here
https://github.com/lutris/openmsx/blob/master/doc/DMK-Format-Details.txt
On 2/2/21 2:52 AM, Al Kossow via cctalk wrote:
and before IMD there was Eric's DMK imager, which is what I used before Dave's
program
http://dmklib.brouhaha.com/
which was compatible with Catweasel DMKs
I hate the fact that there are dozens of siloed
projects in this problem space.
Including cctlk. There is actually a medialab channel on the cctlk discord
3 Feb
3 Feb
3 a.m.
New subject: Greaseweazle
On Tue, 2 Feb 2021, Al Kossow wrote:
Do you make these available online?
I found your version of IMD here
ftp://computermuseum.informatik.uni-stuttgart.de/utils
not under source control.
Ups, I see that this is a very old version. I'll update this with my
current version and I'll write some notes on the usage etc. But it will
need some time, the source is on my PC at work and currently doing home
office.
I hate the fact that there are dozens of siloed
projects in this problem
space.
Yes, me too. It started several years ago as a "quick" way of imaging
floppys on my PC that obviously is Linux only. But now, I think I could
just publish it and have everyone play with it :-)
Christian
2 Feb
2 Feb
6:32 a.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, Al Kossow via cctalk wrote:
On 2/1/21 4:13 PM, Chuck Guzis via cctalk wrote:
How about helping out instead of bitching from the sidelines?
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
any moderately capable
modern MCU can do the job.
and it is the software and the knowledge of what you need to do when
recovering media in volume these guys have no clue about 
1 Feb
1 Feb
5:07 p.m.
New subject: Greaseweazle
On 02/02/2021 00:13, Chuck Guzis via cctalk wrote:
There's also a similar implementation using a very inexpensive Cypress
PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable).
That would presumably be the FluxEngine
(http://cowlark.com/fluxengine/index.html).
I have the PSOC and I've loaded up the firmware. Now I just need to wire
some parts together (PSU+floppy) and I can give it a quick whirl.
It's what I've been saying for years--just
about any moderately capable
modern MCU can do the job. After all the Gotek emulator uses a nearly
obsolescent STM32F107 or 105 MCU. The "blue pill" STM32F103 is quite a
bit more capable.
Glad people finally tumbled to this.
Indeed. The important part is that someone's written some firmware. Oh,
and it's cheap too, of course.
Antonio
--
Antonio Carlini
antonio at acarlini.com
5:18 p.m.
New subject: Greaseweazle
On Feb 1, 2021, at 5:07 PM, Antonio Carlini via cctalk <cctalk at classiccmp.org>
wrote:
Indeed. The important part is that someone's written some firmware. Oh, and it's
cheap too, of course.
And that it's something available for the community to work with and improve, rather
than something where people are hoping to profit off archival ventures.
-- Chris
2 Feb
2 Feb
6:36 a.m.
New subject: Greaseweazle
On Mon, 1 Feb 2021, Chris Hanson via cctalk wrote:
On Feb 1, 2021, at 5:07 PM, Antonio Carlini via cctalk
<cctalk at classiccmp.org> wrote:
*cough*kryoflux*cough*
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
Indeed. The important part is that someone's written some firmware. Oh, and it's
cheap too, of course.
And that it's something available for the community to work with and improve, rather
than something where people are hoping to profit off archival ventures.
4:11 p.m.
New subject: Greaseweazle
On Tue, Feb 2, 2021 at 2:08 AM Antonio Carlini via cctalk
<cctalk at classiccmp.org> wrote:
On 02/02/2021 00:13, Chuck Guzis via cctalk wrote:
I've used the FluxEngine to read 3.5 inch, 5.25 inch and 8 inch floppies.
I've used the GreasleWeazle to read 5.25 inch floppies so far.
I haven't tried either of them to write floppies yet.
The main difference in workflow is that the gw software only writes
one type of format - SCP, so you will need another tool to convert to
raw or a different format, if you can't use scp directly.
Currently, the thing I find most interesting right now is that the
FluxEngine software can use GreaseWeazle hardware (supposedly for most
things) - I haven't tested that yet.
--
Regards,
Torfinn Ingolfsen
There's also a similar implementation using a very inexpensive Cypress
PSOC 6 ARM card that mounts on a 3.5" floppy connector (no cable).
That would presumably be the FluxEngine
(http://cowlark.com/fluxengine/index.html).
3 Feb
3 Feb
1:43 a.m.
New subject: Winchester SA1004 file recovering
Hello everyone,
in Italy in 1981 there was an explosion in creating new machines following
the introduction of microprocessors.
I have several "General Processor T-Model" machines that used CP / M 2.2
operating system.
Here you can see the photos of the 1st acquisition
https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3775.jpg (this is a
master machine with modified CP/M system that provides shared resources via
rs232 to two slave machines) and the 2nd acquisition
https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3430.jpg (these are
two compositions: a machine with CP/M system with a pair of BASF 6104 drives
and a second machine with an HD + FD 8" box and a further box with a pair of
REMEX RFD4000 8" drives).
The machines of the second acquisition were in a better condition.
A very dear friend first read in raw mode a 10MB Winchester hard disk model
Shugard SA1004 from which the files were correctly extracted and then set up
a test bench from which you can see in this video the complete system
operating with the HD ed il controller Shugart SASI SA1403:
https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0
The problem arose later when we tried to extract the raw file from the 10MB
Winchester hard disk model Shugard SA1004 of the 1st acquisition in the same
way. Visually, the hard disk had certainly suffered atmospheric damage, but
the electronic boards were functioning correctly.
Despite we having attempted different readings (even using cards from the
first hard disk), using the same FLUXengine card
(http://cowlark.com/fluxengine/doc/building.html) the raw file still does
not present the Hard Disk directory, instead we read the information of the
files present but there may be bad bytes in these files and in the rest of
the disk as well.
Unfortunately this content is unique in its kind and we would like at least
to extract the operating system and/or the files of its initialization in
order to be able to correctly reproduce the functioning of this system.
The last option would be to take the hard drive to a clean room hoping that
the hard drive platters are not scratched.
Any suggestion?
Enrico - Pisa (ITALY)
2:04 a.m.
New subject: R: Winchester SA1004 file recovering
Correct addess of the video test:
https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0
The email cuts the link address to the video file. please join the first
with the second piece and paste it in your browser.
Enrico
3:17 a.m.
New subject: Winchester SA1004 file recovering
On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:
Any suggestion?
I believe Dave G's MFM
emulator has an option to support the SA1000.
I have one in stock for a future project to try to extract data from
SA-1000's in DSD floppy / 8" drive subsystems.
https://www.pdp8.net/mfm/mfm.shtml
info is there about the SA-1000.
If you are having problems because the drives are dead, this won't
help.? It will inhale the contents and with
luck you can extract data.
I know with the ST-506 configuration of his hardware, you can then use
the emulator to replace the SA-1000.
If you need to recover the data, you may be out of luck, but if you need
a "working" SA-1000 and can format
it from utilities, then this may help.
thanks
Jim
5:36 a.m.
New subject: R: Winchester SA1004 file recovering
It's a bit very expensive to shipping a SA-1000 from U.S. to Italy....
almost over than 200 USD
-----Messaggio originale-----
Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di jim stephens
via cctech
Inviato: mercoled? 3 febbraio 2021 12:18
A: Enrico email.it via cctalk
Oggetto: Re: Winchester SA1004 file recovering
On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:
Any suggestion?
I believe Dave G's MFM
emulator has an option to support the SA1000.
I have one in stock for a future project to try to extract data from
SA-1000's in DSD floppy / 8" drive subsystems.
https://www.pdp8.net/mfm/mfm.shtml
info is there about the SA-1000.
If you are having problems because the drives are dead, this won't
help.? It will inhale the contents and with
luck you can extract data.
I know with the ST-506 configuration of his hardware, you can then use
the emulator to replace the SA-1000.
If you need to recover the data, you may be out of luck, but if you need
a "working" SA-1000 and can format
it from utilities, then this may help.
thanks
Jim
4:41 p.m.
New subject: R: Winchester SA1004 file recovering
He offers everything from the $15 bare board up.? Next step up is doing
the surface mount chips for you at $3.50, etc.
I'd do the bare board.? I can attest that the mfm emulator will work.?
I've not one the SA-1000 might have to work with him to do it
yourself.?? I recall he offered a kit option on that, and I had him
build it up.
thanks
Jim
On 2/3/2021 5:36 AM, Enrico email.it via cctalk wrote:
It's a bit very expensive to shipping a SA-1000
from U.S. to Italy....
almost over than 200 USD
-----Messaggio originale-----
Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di jim stephens
via cctech
Inviato: mercoled? 3 febbraio 2021 12:18
A: Enrico email.it via cctalk
Oggetto: Re: Winchester SA1004 file recovering
On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:
Any suggestion?
I believe Dave G's MFM
emulator has an option to support the SA1000.
I have one in stock for a future project to try to extract data from
SA-1000's in DSD floppy / 8" drive subsystems.
https://www.pdp8.net/mfm/mfm.shtml
info is there about the SA-1000.
If you are having problems because the drives are dead, this won't
help.? It will inhale the contents and with
luck you can extract data.
I know with the ST-506 configuration of his hardware, you can then use
the emulator to replace the SA-1000.
If you need to recover the data, you may be out of luck, but if you need
a "working" SA-1000 and can format
it from utilities, then this may help.
thanks
Jim
4:44 p.m.
New subject: Winchester SA1004 file recovering
On Wed, Feb 03, 2021 at 10:43:48AM +0100, Enrico email.it wrote:
A very dear friend first read in raw mode a 10MB Winchester hard disk model
Shugard SA1004 from which the files were correctly extracted and then set up
a test bench from which you can see in this video the complete system
operating with the HD ed il controller Shugart SASI SA1403:
https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0
Despite we having attempted different readings (even using cards from the
first hard disk), using the same FLUXengine card
(http://cowlark.com/fluxengine/doc/building.html) the raw file still does
not present the Hard Disk directory, instead we read the information of the
files present but there may be bad bytes in these files and in the rest of
the disk as well.
I have only heard of FLUXengine being used for floppies. Can it handle
hard drives? I hadn't heard of other boards that can read MFM hard drives
other than mine http://www.pdp8online.com/mfm/.
Other than the drive being faulty the biggest reason reading fails is
the heads are no longer on track. You can tell that by looking at a histogram
of the flux transition timing for a track. If they show peaks with
good nulls between them the data is likely recoverable. If they don't
you have to do something to shift the head position.
Example histogram from by unit for ST506 type drive.
https://groups.google.com/g/mfm-discuss/c/kjKez8vfapU/m/4XamyQJgCAAJ
The SA1004 is a stepper drive. Some people have had success on other stepper
drives with putting some rotation force or drag on the stepper to shift the
heads. Creating a microstepper driver would give better control.
May be able to say more if you provide more information on what you have
done and checked to try to recover the contents.
11:25 p.m.
New subject: Winchester SA1004 file recovering
The simplest thing, if you can locate one, is to find a WD1000/WD1001
controller board and hook it to a PC. Chances are overwhelming that it
was used to write the SA100x in the first place.
My first 5150 hard drive used such a setup--an SA1002, a WD1001 and a
very small hand-wired ISA card for interface. I think I still have the
interface card somewhere.
--Chuck
4 Feb
4 Feb
10:30 a.m.
New subject: R: Winchester SA1004 file recovering
I wish apologize me. the work was done by a dear friend and I had mistakenly
understood that he had used the Fluxengine card instead he used this card
http://www.pdp8online.com/mfm/ with add-on daughter card interfacing with
the SASI controller SA-1403. Since, despite repeated readings, we are not
able to correctly extract the data from the second Winchester Hard Disk, we
will probably operate by trying to rely on someone able to intervene on the
platters of the SA-1004 Hard Disk, hoping to be able to recover as much as
possible.
Enrico
-----Messaggio originale-----
Da: cctech [mailto:cctech-bounces at classiccmp.org] Per conto di David
Gesswein via cctech
Inviato: gioved? 4 febbraio 2021 01:45
A: cctech at classiccmp.org
Oggetto: Re: Winchester SA1004 file recovering
On Wed, Feb 03, 2021 at 10:43:48AM +0100, Enrico email.it wrote:
A very dear friend first read in raw mode a 10MB Winchester hard disk
model
Shugard SA1004 from which the files were correctly
extracted and then set
up
a test bench from which you can see in this video the
complete system
operating with the HD ed il controller Shugart SASI SA1403:
https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0
Despite we having attempted different readings (even using cards from the
first hard disk), using the same FLUXengine card
(http://cowlark.com/fluxengine/doc/building.html) the raw file still does
not present the Hard Disk directory, instead we read the information of
the
files present but there may be bad bytes in these
files and in the rest of
the disk as well.
I have only heard of FLUXengine being used for floppies. Can it handle
hard drives? I hadn't heard of other boards that can read MFM hard drives
other than mine http://www.pdp8online.com/mfm/.
Other than the drive being faulty the biggest reason reading fails is
the heads are no longer on track. You can tell that by looking at a
histogram
of the flux transition timing for a track. If they show peaks with
good nulls between them the data is likely recoverable. If they don't
you have to do something to shift the head position.
Example histogram from by unit for ST506 type drive.
https://groups.google.com/g/mfm-discuss/c/kjKez8vfapU/m/4XamyQJgCAAJ
The SA1004 is a stepper drive. Some people have had success on other stepper
drives with putting some rotation force or drag on the stepper to shift the
heads. Creating a microstepper driver would give better control.
May be able to say more if you provide more information on what you have
done and checked to try to recover the contents.
1368
days inactive
1371
days old
46 comments
18 participants
participants (18)
-
a.carlini＠ntlworld.com -
aek＠bitsavers.org -
cc＠informatik.uni-stuttgart.de -
cclist＠sydex.com -
ccth6600＠gmail.com -
cisin＠xenosoft.com -
cmhanson＠eschatologist.net -
djg＠pdp8online.com -
drb＠msu.edu -
enrico.lazzerini＠email.it -
geneb＠deltasoft.com -
imp＠bsdimp.com -
jfoust＠threedee.com -
jwsmail＠jwsss.com -
kspt.tor＠gmail.com -
mooreericnyc＠gmail.com -
paulkoning＠comcast.net -
tingox＠gmail.com