• Please review our updated Terms and Rules here

Greaseweazle Woes....

bladamson

Veteran Member
Joined
Nov 11, 2018
Messages
986
Location
Appalachia
Using Fluxengine, I can read prodos disks and they work in Linapple. I can read dos3.3 and raw order disks, but they don't work in Linapple.

Writing back fails with a buffer underflow error from the Greaseweazle, regardless of prodos or dos3.3 order (or raw order).

Reading and writing various PC and CP/M formats works fine.

The 'weazle is a v4 and the drive is a Teac FD-55BR. Cable is straight shugart. Drive is strapped for DS0 and properly terminated. OS is Devuan Stable AMD64. Fluxengine client software version is latest dev release from github as of last night.

Any advice? Details and procedure in linked video. Thanks folks.

 
Last edited:
I've never had any real luck writing Apple II disks with a flux level device and PC drive. The GCR encoding is way outside what most PC floppy drives expect, so some drives may filter that out as "noise".

Other obstacles include the fact that Apple II disks are not index aligned, so each track must be realigned before writing.

Even if you manage to read a flux image from a disk that successfully decodes, it will contain a lot of flux level "noise". That is probably what is causing the buffer underflow error.

So, you can't (and really shouldn't anyway) write an unprocessed flux dump back to a disk. It should be converted to a sector image and then converted back to a flux dump - which will now be noise free and index aligned. But even that never works for me. I once got a specific disk image to write by converting a NIB image to flux format, but only that specific image ever worked and I still have no idea why.
 
I am converting it to a sector image when I read. Maybe I should convert that to a flux dump and then write that instead of trying to have fluxengine convert it on the fly.

All I know is, the people at adafruit are doing it with their "greaseweazle compatible" hardware and fluxengine:

Maybe their hardware is just different enough from the GW that it works for them and not for me. Unfortunately I don't think they've released that stuff to the public yet, or I'd get one of theirs.

I can still write write disks with adtpro on the IIgs, and then boot them on the IIe, but it's a pain. I'll have to get it working for C64 disks at some point too, as I have no other way to write them.
 
Last edited:
If you can't get this worked out, then I suggest keeping an eye on the AppleSauce FDC. It allows you to connect real Apple floppy drives (both Apple ][ and Macintosh) in addition to standard PC drives for flux level imagine. The only downside is that the client is currently macOS only. However, the author has stated that he has plans to port the client to Windows and Linux. But if you already have access to a Mac (or even a Hackintosh), then it might be worth checking out right now. I wonder if it'd work under a VM. :unsure:

The author has also introduced a new image format for Macintosh disks called .MOOF, designed specifically to work with copy protected disks This format is fully documented and has already seen support with hardware emulators like the FloppyEmu. I'm not sure if it's supported in any software emulators yet like Basilisk. However, it does enable you to have disk images with the copy protection intact, so people (including me) have started uploading copy protected games and software that hitherto have never been uploaded before. It's a lot of fun. :)
 
I got it figured out. It was a combination of needing to use a USB2 port (as USB1 lacked bandwidth to stream the flux back to the 'weazle fast enough) and having to be really picky about drives.

 
I had the same experience trying to write a protected mac400 image with Fluxengine (Dev release) and a Greaseweazle F1. Failed with either a buffer overflow of Verify error on write. I spoke with David Given, the Fluxengine developer and he sought I do some graphs of the drive ~us response, which I did and the result was ok. I have a NOS Samsing PC drive and USB 3.0 port. Might try 2.0 as you've said.
 
I was able to do this with the GreaseWeazle with a Apple PC 5.25 Drive (A9M0110) using the commands on Windows 11:

cd "C:\Program Files (x86)\Cowlark Technologies\FluxEngine"

.\fluxengine.exe read apple2 40track_drive --usb.greaseweazle.port=COM3 --usb.greaseweazle.bus_type=SHUGART -o test.img --prodos --drive.high_density=0

.\fluxengine.exe write apple2 40track_drive --usb.greaseweazle.port=COM3 --usb.greaseweazle.bus_type=SHUGART -i test.img --prodos --drive.high_density=0

I don't know if it matters for ht high_density parameter because the below worked as well.

.\fluxengine.exe write apple2 40track_drive --usb.greaseweazle.port=COM3 --usb.greaseweazle.bus_type=SHUGART -i test.img --prodos --drive.high_density=1

.\fluxengine.exe read apple2 40track_drive --usb.greaseweazle.port=COM3 --usb.greaseweazle.bus_type=SHUGART -o test.img --prodos --drive.high_density=1

I tried this in the UI on OSX and in the UI in Windows 11 and I could never get the UI to work. I could not find a command line tool for OSX but I was able to use the command line tool in PowerShell on Windows 11.

Would be nice to find a command line tool for OSX.

Gary
 
Using Fluxengine, I can read prodos disks and they work in Linapple. I can read dos3.3 and raw order disks, but they don't work in Linapple.

Writing back fails with a buffer underflow error from the Greaseweazle, regardless of prodos or dos3.3 order (or raw order).

Reading and writing various PC and CP/M formats works fine.

The 'weazle is a v4 and the drive is a Teac FD-55BR. Cable is straight shugart. Drive is strapped for DS0 and properly terminated. OS is Devuan Stable AMD64. Fluxengine client software version is latest dev release from github as of last night.

Any advice? Details and procedure in linked video. Thanks folks.

The Greaseweazle group on FB has had a similar question about underflow and it is to do with the USB bandwidth coming from the GW to the host PC. There mustn't be any relay hubs or excess cable and maybe USB 3.0 might be better it's reported.
 
Back
Top