• Please review our updated Terms and Rules here

Guidance On Ripping Atari ST Disks with Greaseweazel

Hey all. Well, despite the vendor only being like 10 hours drive away, it took a long while for my new floppy cable to arrive. And the result? Zero improvement. Still can't rip a disk in either of the drives without a flood of errors.

Has anyone here potentially run into something like this before? I'm pulling my hair out and with GW's lacking documentation, there isn't much in the way of troubleshooting available. I'll likely post something in the project's GitHub forum, but I'm hoping maybe I'm missing something simple here that someone might know.

Thanks!
 
My Ver 1.15 of GW has a floppy configuration file for the various floppy's. Your Posting shows
GW version 1.16. I didn't VERIFY the GW diskdefs.cfg file for 1.16 as you can do that.

You know the floppy's are Atari ST types so you need to find out which one of the following
definitions is correct. ie 90, 360, 400, 440, 720, 800, or 880. This can be selected in
"FluxMyFluffyFloppy" under Format Spec: diskdefs.cfg (then select from the pulldown menu),
or from the command line as --format=atarist.800 as an example.

Code:
disk atari.90
    cyls = 40
    heads = 1
    tracks * ibm.fm
        secs = 18
        bps = 128
        iam = yes
        gap1 = 6
        gap3 = 17
        id = 1
        cskew = 3
        rate = 130
    end
end

disk atarist.360
    cyls = 80
    heads = 1
    tracks * ibm.mfm
        secs = 9
        bps = 512
        gap3 = 84
        rate = 250
        iam = no
        cskew = 2
    end
end

disk atarist.400
    cyls = 80
    heads = 1
    tracks * ibm.mfm
        secs = 10
        bps = 512
        gap3 = 30
        rate = 250
        iam = no
    end
end

disk atarist.440
    cyls = 80
    heads = 1
    tracks * ibm.mfm
        secs = 11
        bps = 512
        gap3 = 3
        rate = 261
        iam = no
    end
end

disk atarist.720
    cyls = 80
    heads = 2
    tracks * ibm.mfm
        secs = 9
        bps = 512
        gap3 = 84
        rate = 250
        iam = no
        cskew = 4
        hskew = 2
    end
end

disk atarist.800
    cyls = 80
    heads = 2
    tracks * ibm.mfm
        secs = 10
        bps = 512
        gap3 = 30
        rate = 250
        iam = no
    end
end

disk atarist.880
    cyls = 80
    heads = 2
    tracks * ibm.mfm
        secs = 11
        bps = 512
        gap3 = 3
        rate = 261
        iam = no
    end
end


Larry
 
Yeah, I'm not 100% on the format of all these ST disks, but the problem seems to be more global. If I try to rip a simple 1.44MB DOS disk or a Commodore 64 disk from the 5.25" drive I also have, I get the same result. This doesn't seem to be able to rip anything properly at the moment, which is really confusing to me.
 
Yeah, I got some other disks to be sure, but they all seem to be failing utterly. There isn't really a dedicated Greaseweazel forum I know of beyond the Discussions section on the project's GitHub page. I might post something there and see if anyone has insights. I suppose the board I bought could be defective, but I'd be surprised if that's the case.
 
Hey everyone.

For those of you waiting for an update (I'm sure you are legion), I've got some good news, that comes with some annoying news for me. A friend of mine found an old Panasonic 3.5" drive he had lying around and wouldn't you know it, that works a jig. I was able to rip one of the NCAUG Atari ST disks I want to archive and get it to boot in an emulator!

hatari_XelOjbgCGh.png

The new old stock drive I bought apparently is either defective or just isn't up for working with the Greaseweazel. It was a much more "modern" drive (says on the box that it'll work with Windows Vista) and has no branding (though the model number indicated it's a Bytecc BT-145), so I'm guessing it's just not up to the job. At least I only paid $15 for it.

However, my Teac FD55-GFR is still a no go and is still giving me the same issues I posted above. The theory I currently have is that the drive is possibly not jumpered correctly. I've spent a while searching various forms of documentation, and even ended up on an old post from this forum originally, but everything is text and I'm unable to reliably determine how the drive is currently configured and how it should be configured to work with the GW. I've attached a photo I took of the PCB of my drive, showing how the jumpers are currently set. Is anyone potentially able to provide some guidance here? I'm clinging to the hope that with some jumper changes, I might finally have these demons excised.

If that issue is better suited to a new thread, let me know, but I didn't want to clog things up.

Thanks everyone for your help.
 

Attachments

  • PXL_20240108_041037902.jpg
    PXL_20240108_041037902.jpg
    2.6 MB · Views: 4
Last edited:
I'm curious if you are using an IBM style twisted cable (10-16) with your Greaseweazle?
I always use a Straight through cable and strap the Floppy Drive as DS0 in a
DS{0..3} configuration.


Larry
 
I'm curious if you are using an IBM style twisted cable (10-16) with your Greaseweazle?
I always use a Straight through cable and strap the Floppy Drive as DS0 in a
DS{0..3} configuration.


Larry

Hey Larry. I actually just replied to your DM. :) I am using a twisted cable as that's what I had on hand, plus I'm running two drives. Do you know what jumper config I'd need to make that work? I'm hoping that's all I need to get this sucker working.
 
I have that same style of light blue PCB Teac FD55-GFR and I can tell you there are two jumpers you need to worry about. 1 is the cross on the left to select the drive ID. Assuming you are using a standard PC floppy cable with a twist DS1 as you have it set is correct. The other jumper of concern is the I jumper just below the drive select cross on the left. If you are trying to read 360k disks on that 1.2MB drive, setting the I jumper will slow down the rotation rate making it possible to read certain 360k disks that need the slower rotation rate. Theoretically they should work at the faster rate too but that’s why the I jumper is there.

Other than that, theres not much to say other than I know for a fact that this drive can work with a grease weasel.
 
So, based on what you're seeing in the image, the drive should be jumpered right for a twisted cable configuration? I have only tried to rip Commodore and Atari disks with the Teac so far, but those shouldn't require the lower RPM should they? I think I have some PC 1.2MB disks around I can try it with.

Yeah, this drive absolutely should work. I bought this drive specifically because it's considered one of the most versatile for using with a GW. The seller said it was tested and it probably was, but likely just in a regular PC doing nothing special. The behaviour I'm getting out of it is basically exactly what the first BYTECC 3.5" drive I tried was doing until I replaced it with an older drive, which is really pushing me in the direction of this being a config issue, rather than a fault with the drive.
 
Welp, I put the drive on the end of the ribbon cable (past the twist) on its own as per Larry's advice and I'm getting basically the same results. It communicates and you can hear it spinning and the head moving, but this is all I get as output when I try to rip anything:

C:\COMSTUFF\Greaseweazle>gw read --tracks=c=0-1 --format=commodore.1541 name.img
Reading c=0-1:h=0 revs=1.1
Format commodore.1541
T0.0: Commodore GCR (0/21 sectors) from Raw Flux (51061 flux in 183.62ms)
T0.0: Commodore GCR (0/21 sectors) from Raw Flux (218545 flux in 785.68ms) (Retry #1.1)
T0.0: Commodore GCR (0/21 sectors) from Raw Flux (383666 flux in 1379.15ms) (Retry #1.2)
T0.0: Commodore GCR (0/21 sectors) from Raw Flux (548767 flux in 1972.53ms) (Retry #1.3)
T0.0: Giving up: 21 sectors missing
T1.0: Commodore GCR (0/21 sectors) from Raw Flux (41753 flux in 183.62ms)
T1.0: Commodore GCR (0/21 sectors) from Raw Flux (164730 flux in 724.65ms) (Retry #1.1)
T1.0: Commodore GCR (0/21 sectors) from Raw Flux (304890 flux in 1341.19ms) (Retry #1.2)
T1.0: Commodore GCR (0/21 sectors) from Raw Flux (443006 flux in 1948.80ms) (Retry #1.3)
T1.0: Giving up: 21 sectors missing
Cyl-> 0
H. S: 01
0. 0: XX
0. 1: XX
0. 2: XX
0. 3: XX
0. 4: XX
0. 5: XX
0. 6: XX
0. 7: XX
0. 8: XX
0. 9: XX
0.10: XX
0.11: XX
0.12: XX
0.13: XX
0.14: XX
0.15: XX
0.16: XX
0.17: XX
0.18: XX
0.19: XX
0.20: XX
Found 0 sectors of 42 (0%)

That output was from a simple attempt to rip two tracks of a known good C64 disk. I'm really at a loss here. 5.25" drives are becoming increasingly unobtanium and it was hard just to find this one at a reasonable price. A friend says he has an old Commodore PC that has a drive in it he's willing to remove and lend me, though he has no idea if it works. I'll see if I can get that from him to test, but if anyone has other ideas, I'm more than open to them.
 
I searched my commands strings to find what I had used on Kaypro images.
I typically create *.SCP images because I can also write them with my
Supercard Pro. Why don't you give this command a try and see what it does?

3.5" Floppy
$ gw read --tracks c=0-79:h=0-1 --format=commodore.1541 name1.scp

360 Floppy on a 1.2M Floppy Drive
$ gw read --tracks c=0-39:h=0-1:step=2 --format=commodore.1541 name2.scp

1.2M Floppy on a 1.2M Floppy Drive
$ gw read --tracks c=0-79:h=0-1:step=1 --format=commodore.1541 name3.scp

Larry
 
Yes you are jumpered correctly, I only mention I jumper for old 360k dos floppy disks. For Atari ST you’re safe with the normal rotation rate (and encoding).

Are you absolutely positive that is not a 1-sided disks? Some c64 disks are one sided, I’ve heard…
 
Do you have any DOS disks you can test to see if the drive is working and reading disks? You can type 'gw rpm' to tell if the greaseweazel is communicating with the drive for things like cabling. If all is well it will spin for a bit. The drive should be connected after the twist so it's the "A:" drive but that probably doesn't matter too much. There's no reason it shouldn't work, other than the drive's not working or bad disk. You may have to clean the heads. There's two ways to do this, the "right" way, open it up, carefully clean with q-tip and alcohol, or the "quick" way which is to put a disk you don't care about in the drive and run 'gw clean' a few times. Once you are there, you should be able to figure out the exact command you need for the disk format.
 
So I believe I've got the issue largely resolved. I was talking to the GW author on GitHub and he pointed out that when ripping C64 disks in a drive like this, you need to specify double-stepping in the command line as it's ripping a 40 track disk on an 80 track drive. Selecting the C64 profile in an application like FluxMyFluffyFloppy does not specify these settings. I was able to rip a couple of disks this way and one of them did boot up in a C64 emulator, though it got stuck at a logo screen, which I think is just a result of copy protection.

I have to say, for as incredibly powerful as the GW is and for as great a device as it is, it's kind of amazing to me how little documentation there is out there for getting started with it. This has gotten me thinking of making some "Getting started with common formats on a GW" type videos I might attempt for my YouTube channel once I play around with this some more.

But at least for now, I can successfully rip the NCAUG Atari ST disks I wanted (the original reason I got a GW) and I think I'm now equipped for when I hopefully eventually find the NCAUG 8-bit collections on 5.25" disks.

I want to thank everyone here immensely for their help and efforts. Everyone's been very welcoming and patient and it's nice to see there are still some cool Internet communities like this. I'll be sticking around for sure and will post when I get my NCAUG archive up and running.

Cheers everyone! :)
 
Aren't ST floppies plain old 9x512 tracks? Any PC legacy controller should be able to handle them.
Yes, that is almost true.

If you have a PC which has such a legacy disk controller (means: no usb floppy drive) you can do diskimages just with the internal 3.5 inch floppy drive of the PC. If the diskettes have been formatted eveb by TOS 1.04 and newer, then MS-DOS and Windows can access the files without any issue as ST just uses FAT file format like MS-DOS. Older TOS versions did a wrong "media descriptor byte" in the boot sector of the floppy which confuses MS-DOS and Windows, that's all.

The standard image format for ST disks is *.st and *.msa. *.ST is similar as *.TD0, *.IMG, *.IMD, *.720 and so on on PC, means a raw sector by sector copy of the disks. *.msa is a compressioned version to save some space. Please note also, that there is a 3rd disk image format for ST, that is *.STX, this one was done to store copy protected disks with it's sector errors, but I don't know how to create them and it's impossible to write them back to a real diskette anymore. Also floppy emulators like HxC and Gotek (HxC- or Flashfloppy firmware) can not support these. STX image format is only useable in some ST emulators like STeem. Original HxC floppy hardware needs to convert ST and MSA images into HFE raw format before using, Gotek can use ST directly. MSA can be converted into ST.

For the sector layout the ST disks are the same as on PC by default, means one or two sides, 80 tracks, 9 sectors of 512 bytes. But there can be "high formatted" disks of up to 82 tracks and/or 10 or even 11 sectors per track & side. Most PC mfm controllers are able to also read 10 sectors, but less of the PC mfm controllers are able to read the 11 sectors format as this one is quite tricky and non standard, it uses radically shortened sector headers, gap bytes between the sectors, shorter sector checksums, shorter sync bytes and some tricky interleave. Even on ST one needs special formatting software to create such disks of 10, 11 sectors per track and up to 82 tracks. But TOS itself has no problem to read and write them if they have been formatted by extra program.

To create the ST or MSA disk images there are several solutions:

1. on ST itself, use JayMSA : http://jaysoft.atariportal.cz/
2. on PC running MS-DOS, use makedisk.exe : http://emulatari.free.fr/zip/makedisk_v15.zip
3. on PC running Windows 2000 up to 11 , use floimg : https://atari.8bitchip.info/floimgd.php

Please note that 2+3 don't support USB floppy, it needs PC legacy floppy controller and drive!

Please note also, that copy protected disks mostly can not be imaged using these tools as these copy protections are based on special prepared disk sectors which MFM controller can not read/write correctly. For these you really would need greazewazle or kyroflux - or Amiga running Xcopy in NIBBLE mode to make 1:1 copy to disk or hxc/gotek ADF (!) image.

Please note also, that in the ATARI community ST and MSA are the mostly used image formats, there are tons of download webistes available with these. But not the ones which could be created by teledisk, imd, winimage, dd and others on PC (MS-DOS, Windows, Linux). Diskimages of the greazeweazle or kyroflux RAW formats are very unpopular in the ST scene as they need a lot of space and they are unneccessary for unprotected disks, most users have such an adapter so they can not write them back to disk and no floppy image too can use them with standard floppy controller (even on ST) and no ST emulator can support them.
 
I've also read about folks replacing the WD1772 controller with a selected WD1772(?) and running said controller as high density (500Kbps). Apparently runs as hot as a two-buck pistol but can be made to handle HD media, given the right drive (HD capable) software, etc.
 
I've also read about folks replacing the WD1772 controller with a selected WD1772(?) and running said controller as high density (500Kbps). Apparently runs as hot as a two-buck pistol but can be made to handle HD media, given the right drive (HD capable) software, etc.
Yes, true, they are the 1772-02-02, while operating, they can be clocked at 16 MHz and can read HD diskettes, even overformatted ones with 20 or 22 sectors is possible using the same tricks as for 10 and 11. There is some logics required that the 1772 switch to 16 Mhz: HD signal from floppy drive (from the HD hole sensor) and drive select. But make sure that they clock down to 8 Mhz when drive select is off for cooling. Even better also switch back to DD while step signal to cool down the chip while track change between read write operations. Or better use the ATARI AJAX controller, this is a 1772 clone which is stable enough to run even at 32 MHz (ED). But they are rare and expensive.

But to be honest, there is no game, demo or application disk for St from proffessionals, public domain or demo scene in HD format. This only made sense for data transfer between ST/TT/Falcon and PC. Today there are much better / faster / bigger capacity possibilities for data transfer between these two worlds than floppy disk.
 
Forgot to mention that back in the day, I was a registered ST developer; donated all my material (a large box full of 3-ring stuff to some Atari group in Chicago. Doubtless that's been recycled by now.
 
Yes, that is almost true.

If you have a PC which has such a legacy disk controller (means: no usb floppy drive) you can do diskimages just with the internal 3.5 inch floppy drive of the PC. If the diskettes have been formatted eveb by TOS 1.04 and newer, then MS-DOS and Windows can access the files without any issue as ST just uses FAT file format like MS-DOS. Older TOS versions did a wrong "media descriptor byte" in the boot sector of the floppy which confuses MS-DOS and Windows, that's all.

The standard image format for ST disks is *.st and *.msa. *.ST is similar as *.TD0, *.IMG, *.IMD, *.720 and so on on PC, means a raw sector by sector copy of the disks. *.msa is a compressioned version to save some space. Please note also, that there is a 3rd disk image format for ST, that is *.STX, this one was done to store copy protected disks with it's sector errors, but I don't know how to create them and it's impossible to write them back to a real diskette anymore. Also floppy emulators like HxC and Gotek (HxC- or Flashfloppy firmware) can not support these. STX image format is only useable in some ST emulators like STeem. Original HxC floppy hardware needs to convert ST and MSA images into HFE raw format before using, Gotek can use ST directly. MSA can be converted into ST.

For the sector layout the ST disks are the same as on PC by default, means one or two sides, 80 tracks, 9 sectors of 512 bytes. But there can be "high formatted" disks of up to 82 tracks and/or 10 or even 11 sectors per track & side. Most PC mfm controllers are able to also read 10 sectors, but less of the PC mfm controllers are able to read the 11 sectors format as this one is quite tricky and non standard, it uses radically shortened sector headers, gap bytes between the sectors, shorter sector checksums, shorter sync bytes and some tricky interleave. Even on ST one needs special formatting software to create such disks of 10, 11 sectors per track and up to 82 tracks. But TOS itself has no problem to read and write them if they have been formatted by extra program.

To create the ST or MSA disk images there are several solutions:

1. on ST itself, use JayMSA : http://jaysoft.atariportal.cz/
2. on PC running MS-DOS, use makedisk.exe : http://emulatari.free.fr/zip/makedisk_v15.zip
3. on PC running Windows 2000 up to 11 , use floimg : https://atari.8bitchip.info/floimgd.php

Please note that 2+3 don't support USB floppy, it needs PC legacy floppy controller and drive!

Please note also, that copy protected disks mostly can not be imaged using these tools as these copy protections are based on special prepared disk sectors which MFM controller can not read/write correctly. For these you really would need greazewazle or kyroflux - or Amiga running Xcopy in NIBBLE mode to make 1:1 copy to disk or hxc/gotek ADF (!) image.

Please note also, that in the ATARI community ST and MSA are the mostly used image formats, there are tons of download webistes available with these. But not the ones which could be created by teledisk, imd, winimage, dd and others on PC (MS-DOS, Windows, Linux). Diskimages of the greazeweazle or kyroflux RAW formats are very unpopular in the ST scene as they need a lot of space and they are unneccessary for unprotected disks, most users have such an adapter so they can not write them back to disk and no floppy image too can use them with standard floppy controller (even on ST) and no ST emulator can support them.

Hello! Is there a way to determine if a disk is copy-protected?
 
Back
Top