• Please review our updated Terms and Rules here

Guidance On Ripping Atari ST Disks with Greaseweazel

Parallax Abstraction

Parallax Abstraction

Member
Joined
Nov 20, 2023
Messages
19
Location
Almonte (Ottawa), Ontario, Canada
Hey everyone! I'm hoping some people in this awesome community might be able to provide me some guidance for a project I'm doing.

Backstory (skip this paragraph if it doesn't matter to you): I am slowly working at obtaining and archiving a series of monthly disks that were authored by the former National Capital Atari Users Group, here in Ottawa, Canada. They put out a ton of these for the Atari 8-bit and ST systems. They have loads of great community authored software and as far as I've been able to determine, have never been archived online. I recently found someone in town who has a bunch of their Atari ST disks. I've acquired a Greaseweazel and a new old stock 3.5" drive and am trying to rip them into a format that can be read by an emulator or written back to actual floppies.

As far as I can tell, all the disks I'm trying to rip are single sided and double density. Using Greaseweazel with the FluxMyFluffyFloppy GUI on Windows (though I have tried this with straight command line as well), I'm having no luck in getting disks to rip in a way that makes them usable. I've been using the "Atari ST 360kb DoubleDensity SingleSided (80 tracks)" template that comes with the GUI and have tried ripping to both MSA and ST formats. The following is the output I get when trying to rip to MSA format

Code: 
C:\COMSTUFF\greaseweazle-1.16.1\FluxMyFluffyFloppy>"C:\COMSTUFF\greaseweazle-
p=1 --revs=3 "C:\COMSTUFF\No Save\test.msa"
Reading c=0-79:h=0 revs=3
<trimming all but the last 5 tracks for brevity>
T75.0: Raw Flux (170493 flux in 768.90ms)
T76.0: Raw Flux (148015 flux in 770.07ms)
T77.0: Raw Flux (147813 flux in 769.95ms)
T78.0: Raw Flux (147845 flux in 769.94ms)
T79.0: Raw Flux (147937 flux in 770.03ms)
** FATAL ERROR:
MSA: Track 0.0 is not an IBM track: Maybe missing --format= option?

It actually reads the disk all the way to the end, but gives that error and when I try to mount the image in Hatari, I get an error that the drive isn't responding.

If I try to read the risk into ST format, I just get this error:

Code: 
C:\COMSTUFF\greaseweazle-1.16.1\FluxMyFluffyFloppy>"C:\COMSTUFF\greaseweazle-
p=1 --revs=3 "C:\COMSTUFF\No Save\test.st"
Reading c=0-79:h=0 revs=3
** FATAL ERROR:
Sector image requires a disk format to be specified

I think this might be a bug in the GUI application itself, but I tried it with GreaseweazleGUI as well and it doesn't give this error, but still doesn't rip.

If I try any of the other templates, I get a ton of "Ignoring unexpected sector" errors.

I haven't found a lot of answers searching around online, but I have read that ST disks can be a bit touchy to rip properly. Does anyone have any experience ripping these disks with a Greaseweazel and any advice on what I could potentially do here? I'm very into this archiving project and want to make sure I get it right.

Cheers! :)
 
Not tried with a greaseweazle because I have an ST and can copy to an image onto a GoTek. However I think the hint is in the error. It says "missing --format" and I agree.
You probably need "--format atarist.360". I would say it has found the bootsector, deduced its an MSDOS format disk, which it it almost is, then found out its not quite what it expected.
 
OK, so I found the problem that was generating the error when ripping to ST images and like you said, it was that missing switch. It turns out, there is a field in the GUI you can select that will enable that. However, when I try to rip a disk, I now get a ton of this:

Code: 
C:\COMSTUFF\greaseweazle-1.16.1\FluxMyFluffyFloppy>"C:\COMSTUFF\greaseweazle-
tracks=c=0-79:h=0:step=1 --revs=3 "C:\COMSTUFF\No Save\test.st"
Reading c=0-79:h=0 revs=3
Format atarist.360
T0.0: Ignoring unexpected sector C:1 H:0 R:9 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:4 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:1 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:2 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:5 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:7 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:3 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:8 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:6 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:9 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:4 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:1 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:2 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:5 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:7 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:3 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:8 N:2
T0.0: Ignoring unexpected sector C:1 H:0 R:6 N:2
T0.0: IBM MFM (0/9 sectors) from Raw Flux (140379 flux in 599.89ms)

It does that for basically every sector of the disk and needless to say, that image definitely doesn't work either. Though interestingly enough, when I try to load it in Hatari, it doesn't give an error, it just shows as accessing the drive for a few seconds and then nothing happens.

The weird saga continues.
 
Unfortunately I don't have any Atari ST disks to test. These are single-sided 3.5" double density disks? It's possible that the disk data is bad, but it's also possible that you're not reading the data correctly.

gw read --format=atarist.360 "C:\COMSTUFF\No Save\test.hfe"

By specifying --format=atarist.360 the greaseweazel should be able to ascertain the tracks for you. You're going to get an hfe image which is flux data that you'll be able to convert to an st image afterwords.

If specifying --format isn't enough you can add --tracks=c=0-79:h=0:step=1 to be more specific. --revs=3 if it can't figure out the rpms for some reason.

Then once you have the hfe file, load it into HxCFloppyEmulator (https://hxc2001.com/floppy_drive_emulator/ should run on Windows) and export to an .st or .msa file.
 
jscipione said:
gw read --format=atarist.360 "C:\COMSTUFF\No Save\test.hfe"

By specifying --format=atarist.360 the greaseweazel should be able to ascertain the tracks for you. You're going to get an hfe image which is flux data that you'll be able to convert to an st image afterwords.

If specifying --format isn't enough you can add --tracks=c=0-79:h=0:step=1 to be more specific. --revs=3 if it can't figure out the rpms for some reason.
Click to expand...
Sadly, this didn't seem to work either. I tried both variants of the commands you provided and got the same string of errors with each sector that I got my using my GUI utility. HxCFloppyEmulator didn't throw an error when I tried to load the image and would export it to both ST and MSA formats, it appeared to succeed, but this time both formats just cause Hatari to spin its virtual drives briefly with nothing happening in the end. I also get Found 0 sectors of 720 (0%) at the end of the GW.exe output, indicating it's not able to find any sectors.

I tried with several other double density disks and got the same behaviour with all of them. I'll keep experimenting, but I feel there's something simple here that I'm just not seeing. I'll also try copying a couple of PC formatted disks I have and see if they work better, just as a comparison.
 
VeryVon said:
You could also give fluxengine a go. It's compatible with a gw. Suggest use the GUI to get started as creating a config w/ the usb settings is a bit hairy in the config, but automatically done by the gui exe.

Click to expand...
I've heard of FlexEngine, but for some reason, I thought that was its own separate tool that didn't work with the GW. I still investigate and let people know! Thank you kindly.
 
Oh boy, another roadblock. I installed FluxEngine and it talked to my GW out of the box, which was nice. I read one of the double-density disks I have and got this result.

fluxengine-gui_4tetWvzSUq.png

However, while I can save the flux data, clicking the save image button results in an error saying "This format cannot be saved." That's with an 80 track drive selected and the atarti format with 360K. Just about the most unhelpful error ever. 🤣 I think my next step is trying with a PC disk to make sure everything's working right so I'll do that and check back after.
 
Chuck(G) said:
Aren't ST floppies plain old 9x512 tracks? Any PC legacy controller should be able to handle them.
Click to expand...
I will say it was common practice to format Atari disks with non-standard sectors and tracks to squeeze extra space out of them. So 81 tracks was common. I seem to remember some had 10 sectors...
 
Yeah, the one thing I'm quickly learning is that Atari ST disks are freakin' weird. I haven't had a chance to try with a PC disk yet, but I hope to do so this evening. Once I validate that my GW is working 100%, then I can dive down this rabbit hole some more.
 
g4ugm said:
I will say it was common practice to format Atari disks with non-standard sectors and tracks to squeeze extra space out of them. So 81 tracks was common. I seem to remember some had 10 sectors...
Click to expand...
Sure, but the hardware (WD177x, IIRC) was just a bog-standard MFM floppy controller. Not beyond the reach of a PCs 765-based FDC. Nothing really strange like a Macintosh 400K floppy.
 
Chuck(G) said:
Sure, but the hardware (WD177x, IIRC) was just a bog-standard MFM floppy controller. Not beyond the reach of a PCs 765-based FDC. Nothing really strange like a Macintosh 400K floppy.
Click to expand...
No, nothing strange, well except for the the usually copy protection tricks, but you do have to talk directly to the controller. DOS gets totally messed up and confused...
 
Hey everyone.

Last week got crazy and I didn't get a chance to test things until tonight. Short version: I think I have a problem with my GW setup as a whole.

I attempted to rip multiple high-density PC game disks, and also a C64 5.25" disk and neither worked. When I tried to rip the 3.5" disks, I got a ton of this repeated over and over:

Code: 
Unknown mark 42
T78.0: Ignoring unexpected sector C:79 H:0 R:10 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:17 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:1 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:18 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:13 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:14 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:15 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:16 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:11 N:2
T78.0: Ignoring unexpected sector C:79 H:0 R:12 N:2
T78.0: IBM MFM (0/18 sectors) from Raw Flux (1624582 flux in 3996.94ms) (Retry
T78.0: Giving up: 18 sectors missing

I was beginning to think the new old stock 3.5" drive I bought maybe just couldn't handle this. But when I tried to rip a Commodore disk on my Teac FD-55GFR, I got a ton of this:

Code: 
T39.0: Commodore GCR (0/17 sectors) from Raw Flux (502036 flux in 2715.55ms)
<snipped for brevity>
T39.0: Ignoring unexpected sector C:21 S:7 ID:4145
T39.0: Ignoring unexpected sector C:21 S:8 ID:4145
T39.0: Ignoring unexpected sector C:21 S:9 ID:4145
T39.0: Ignoring unexpected sector C:21 S:10 ID:4145
T39.0: Ignoring unexpected sector C:21 S:11 ID:4145
T39.0: Ignoring unexpected sector C:21 S:12 ID:4145
T39.0: Ignoring unexpected sector C:21 S:13 ID:4145
T39.0: Ignoring unexpected sector C:21 S:14 ID:4145
T39.0: Ignoring unexpected sector C:21 S:15 ID:4145
T39.0: Ignoring unexpected sector C:21 S:16 ID:4145
T39.0: Ignoring unexpected sector C:21 S:17 ID:4145
T39.0: Ignoring unexpected sector C:21 S:18 ID:4145
T39.0: Commodore GCR (0/17 sectors) from Raw Flux (675055 flux in 3652.45ms)
T39.0: Giving up: 17 sectors missing

Followed by a bunch of this for track 40 on:

Code: 
T40.0: WARNING: Out of range for for format 'commodore.1541': No format

This despite using the Commodore C64 170kb SingleSided template.

All of this is making me think that there's another issue going on here. Does anyone know what this could be a symptom of? The only thing I'm thinking is that perhaps the floppy cable I'm using (it's a twisted one) is defective. A friend gave it to me and said he thought it worked, but wasn't sure. I could procure another one online, but before I do that, I was just curious if people here had any thoughts on what could be happening.

Thanks again!
 
The Atari ST disks are freeware so they definitely don't have copy protection. Not 100% sure about the Commodore disk (it's a copy of Pinball Construction Set, original disk), but I'm pretty sure the PC disk didn't have any either. I can find another to test with though. I don't have any spare cables about, but it looks like I can get a new one on eBay for cheap-ish. Might have to try that.

EDIT 1: I had a "backup" copy of Pinball Construcftion Set that I got with the copy I bought and...same thing. Looking more like the new cable's the way to go.

EDIT 2: Ayyyy, I'm at my 10 posts! Can finally change my avatar. :)
 
Last edited:
I've got a new cable on the way from CablesOnline.com via eBay. Bloody $30CAD after shipping for a cable I once I had a small bin of (seems like shipping a gain of sand runs you at least $20 these days), but it's brand new so I can be sure it's known good. It'll be a few days before it arrives, but I'm hoping this will sort things out. I'll report back as always.
 
You must log in or register to reply here.
Back
Top