syzygy
Experienced Member
I have been trying to resurrect some M1 drives (see https://forum.vcfed.org/index.php?threads/resurrecting-model-1-floppy-drives-my-turn.1242850/). I made progress to the point that I wanted to start to attempt to read some old floppies.
I got a V4 Greaseweasel. Connection to the SA-400 drive [the original Tandy drive for the TRS-80 M1] was a little challenging. These drives have the shunts with no breaks on the drive select number. Instead, their cables remove the pins for signals, effectively letting the position on the cable determine the drive selected. Additionally, those cables are all edge card connectors. The Greaseweasel has a 34 pin socket and not an edge card. OK, no problem...I had plenty of old IBM cables and a few "universal" ones that had the 34 pin socket and two edge cards and sockets (I think these were for either 3.5 or 5.35). These are the old two-drive cables that have a flip in the cable for drive #0. By configuring the floppy as ds1, I can use the d1 connector as long as I tell Greaseweazel.
Now comes the reading and this is where I am at. First off (and this took a while to figure out), for me, the Greaseweasel needs to be reset after a full read attempt. At first, I thought I was dealing with a drive that had a heat issue such that subsequent reads were bombing even though the first cold read worked to some degree.
Now, how do I get Greaseweazle to understand that these are SS/SD 35 track and 10 sectors / track and 256 bytes/sector- right? That's what I remember and what some references agree with that.
Greaseweasel uses a diskdef.cfg file and, of course, there is no definition for these disks. So, I am trying to add one that works. Here it is:
To be thorough (mostly because I am flying blind), I am mostly using a Greaseweazle GUI in command line mode and with these options selected...
Using that configuration I can consistently read disks with these errors.
To be clear:
I can read a disk multiple times with this error pattern.
I have received this error pattern reading two different disks, one of which is a flippy.
The identifiable content (browsing through the .img file) is exactly what I would expected. Both sides of the flippy have a wordprocessing files (probably scriptsit or something) and I can recognize the text. The other disk is a Z-80 assembly file (likely MZal) and I remember the program because I wrote it some 40 years ago - yikes.
It could be an alignment problem - I don't know and I have never had a real alignment disk and it is premature, I think, to go there first. I can try another drive at some point, but I feel strongly that I have something wrong in the cfg - especially with the the gaps. Additionally, it is notable that T17, which hold the directory, is smashed on all three. I vaguely recall theat the sectors on T17 had some special properties - maybe some ID bytes that other sectors don't have?
Here are the defs from the cfg file...
# A disk definition is declared by "disk <name>"; scope extends to
# the matching "end". Each disk definition must contain the following:
# cyls: Number of cylinders (1-255)
# heads: Number of heads/sides (1-2)
# Also, optionally:
# step: Number of physical drive steps per image step (1-4)
#
# Each non-empty track in a disk requires a track definition:
# "tracks <track-list> <format>"
# Where:
# format ::= ibm.fm | ibm.mfm
# track-list ::= * | <track-range>[,<track-list>]
# track-range ::= <cylinder>[.<head>] | <cylinder>-<cylinder>[.<head>]
# cylinder ::= [0-9][0-9]*
# head ::= 0|1
# "*" means match all otherwise-unmatched tracks (ie. this is the default track
# definition). If no head is specified in a track-range, then all heads are
# assumed. Scope of a track definition extends to the matching "end".
#
# The ibm.fm and ibm.mfm formats accept the following parameters:
# secs: Number of sectors (0-256, default: 0)
# bps: Bytes per sector (128, 256, 512, 1024, 2048, 4096, 8192)
# List all sizes if the size varies (eg. see "ensoniq.mirage" below)
# iam: Index Address Mark (yes|no, default: yes)
# cskew: Sector skew per cylinder (0-255, default: 0)
# hskew: Sector skew per head (0-255, default: 0)
# interleave: Sector interleave, N:1 (1-255, default: 1)
# id: Sector ID (aka R) of logical first sector (0-255, default: 1)
# h: Head (aka H) byte value in each sector header (0-255: default: auto)
# gap1: Post-IAM Gap size (0-255, default: auto)
# gap2: Post-IDAM Gap size (0-255, default: auto)
# gap3: Post-DAM Gap size (0-255, default: auto)
# gap4a: Post-Index Gap size (0-255, default: auto)
# rate: Data rate in kbps (1-2000, default: auto)
# eg. 250kbps is MFM DD, 500kbps is MFM HD, 1000kbps is MFM ED
# rpm: Disk spin speed in RPM (1-2000, default: 300)
# img_bps: Bytes per sector in IMG file (short sectors are padded)
Again - flying blind and needing help. I can save in different formats than a .img - is there one that can be used with just the flux or something that can be analyzed further toward getting that .cfg written better?
Also, I am surprised that there is no existing cfg for these disks - too old I suspect or something...but I think I am not alone in needing one.
Finally, I did try using fluxengine software with the Greaseweazle V4because there is a blurb on how easily fluxengine can read this format https://cowlark.com/fluxengine/doc/disk-trs80.html .
The problem is that it seems only some things in the fluxengine software work with Greaseweazle hardware - I get that and I could get nowhere but syntax error hell trying the approach on that page.
Pretty long post I guess
I got a V4 Greaseweasel. Connection to the SA-400 drive [the original Tandy drive for the TRS-80 M1] was a little challenging. These drives have the shunts with no breaks on the drive select number. Instead, their cables remove the pins for signals, effectively letting the position on the cable determine the drive selected. Additionally, those cables are all edge card connectors. The Greaseweasel has a 34 pin socket and not an edge card. OK, no problem...I had plenty of old IBM cables and a few "universal" ones that had the 34 pin socket and two edge cards and sockets (I think these were for either 3.5 or 5.35). These are the old two-drive cables that have a flip in the cable for drive #0. By configuring the floppy as ds1, I can use the d1 connector as long as I tell Greaseweazel.
Now comes the reading and this is where I am at. First off (and this took a while to figure out), for me, the Greaseweasel needs to be reset after a full read attempt. At first, I thought I was dealing with a drive that had a heat issue such that subsequent reads were bombing even though the first cold read worked to some degree.
Now, how do I get Greaseweazle to understand that these are SS/SD 35 track and 10 sectors / track and 256 bytes/sector- right? That's what I remember and what some references agree with that.
Greaseweasel uses a diskdef.cfg file and, of course, there is no definition for these disks. So, I am trying to add one that works. Here it is:
To be thorough (mostly because I am flying blind), I am mostly using a Greaseweazle GUI in command line mode and with these options selected...
Using that configuration I can consistently read disks with these errors.
To be clear:
I can read a disk multiple times with this error pattern.
I have received this error pattern reading two different disks, one of which is a flippy.
The identifiable content (browsing through the .img file) is exactly what I would expected. Both sides of the flippy have a wordprocessing files (probably scriptsit or something) and I can recognize the text. The other disk is a Z-80 assembly file (likely MZal) and I remember the program because I wrote it some 40 years ago - yikes.
It could be an alignment problem - I don't know and I have never had a real alignment disk and it is premature, I think, to go there first. I can try another drive at some point, but I feel strongly that I have something wrong in the cfg - especially with the the gaps. Additionally, it is notable that T17, which hold the directory, is smashed on all three. I vaguely recall theat the sectors on T17 had some special properties - maybe some ID bytes that other sectors don't have?
Here are the defs from the cfg file...
# A disk definition is declared by "disk <name>"; scope extends to
# the matching "end". Each disk definition must contain the following:
# cyls: Number of cylinders (1-255)
# heads: Number of heads/sides (1-2)
# Also, optionally:
# step: Number of physical drive steps per image step (1-4)
#
# Each non-empty track in a disk requires a track definition:
# "tracks <track-list> <format>"
# Where:
# format ::= ibm.fm | ibm.mfm
# track-list ::= * | <track-range>[,<track-list>]
# track-range ::= <cylinder>[.<head>] | <cylinder>-<cylinder>[.<head>]
# cylinder ::= [0-9][0-9]*
# head ::= 0|1
# "*" means match all otherwise-unmatched tracks (ie. this is the default track
# definition). If no head is specified in a track-range, then all heads are
# assumed. Scope of a track definition extends to the matching "end".
#
# The ibm.fm and ibm.mfm formats accept the following parameters:
# secs: Number of sectors (0-256, default: 0)
# bps: Bytes per sector (128, 256, 512, 1024, 2048, 4096, 8192)
# List all sizes if the size varies (eg. see "ensoniq.mirage" below)
# iam: Index Address Mark (yes|no, default: yes)
# cskew: Sector skew per cylinder (0-255, default: 0)
# hskew: Sector skew per head (0-255, default: 0)
# interleave: Sector interleave, N:1 (1-255, default: 1)
# id: Sector ID (aka R) of logical first sector (0-255, default: 1)
# h: Head (aka H) byte value in each sector header (0-255: default: auto)
# gap1: Post-IAM Gap size (0-255, default: auto)
# gap2: Post-IDAM Gap size (0-255, default: auto)
# gap3: Post-DAM Gap size (0-255, default: auto)
# gap4a: Post-Index Gap size (0-255, default: auto)
# rate: Data rate in kbps (1-2000, default: auto)
# eg. 250kbps is MFM DD, 500kbps is MFM HD, 1000kbps is MFM ED
# rpm: Disk spin speed in RPM (1-2000, default: 300)
# img_bps: Bytes per sector in IMG file (short sectors are padded)
Again - flying blind and needing help. I can save in different formats than a .img - is there one that can be used with just the flux or something that can be analyzed further toward getting that .cfg written better?
Also, I am surprised that there is no existing cfg for these disks - too old I suspect or something...but I think I am not alone in needing one.
Finally, I did try using fluxengine software with the Greaseweazle V4because there is a blurb on how easily fluxengine can read this format https://cowlark.com/fluxengine/doc/disk-trs80.html .
The problem is that it seems only some things in the fluxengine software work with Greaseweazle hardware - I get that and I could get nowhere but syntax error hell trying the approach on that page.
Pretty long post I guess
