Hello --- I have a similar project based around a PSoC5 board: http://cowlark.com/fluxengine

I'm very much wanting to ditch the expensive and very closed source PSoC5 development board in favour of different hardware; I'd looked at the Blue Pill and didn't think it was powerful enough. So I'm really surprised to see that you're doing exactly what I wanted!

How does the Greaseweazle (nice name, BTW) work? I see you're using the DMA engine to accumulate samples and then the CPU is sending them via USB --- but where's the DMA engine getting them from? My concern with the STM32 is that I didn't see any hardware that would time pulses for me, but the CPU wasn't powerful enough to service an interrupt for every pulse. Have you found a way to repurpose some hardware component? If so, what are you doing for sample playback for write support?

And isn't the STM32 a 3.3V device? Are you having any problems there?

I do a dump of a C64 disk with the default settings and GW 0.18. Then i try to convert the .scp to .flux with fluxengine. I get an „scp file corrupt“ error message.

Doing the same dump with GW 0.17 does not make any problems.

The A2R format is an unresolved format used by the Applesauce imaging hardware. Being able to read and write A2R would allow use of Greaseweazle with the Applesauce hardware or software.

The WOZ format is a resolved format also used by Applesauce. Supporting it would also be great, as many emulators support it.

The format specification for A2R is at https://applesaucefdc.com/a2r/.
The format specification for WOZ is at https://applesaucefdc.com/woz/.

An MIT-licensed Python package for handling A2R is at https://github.com/a2-4am/a2rchery.
An MIT-licensed Python package for handling WOZ is at https://github.com/a2-4am/wozardry.

The code in passport.py may also be useful for implementing this: https://github.com/a2-4am/passport.py

Not an issue, but another for your gallery

** Blinky Test **
** Keir Fraser <[email protected]>
** https://github.com/keirf/Greaseweazle
Serial = 39a5:000b:120e:4c30:4a38:004e
Flash Size  = 64kB
Device ID = 0x0410
Revision  = 0x2003
**WARNING**: 10xx8/B device returned valid IDCODE! Fake?
Testing I2C1... OK
Testing I2C2... OK
Testing SPI1... OK
Testing SPI2... OK
Testing TIM1... OK
Testing TIM2... OK
Testing TIM3... OK
Testing TIM4... OK
DMA Test #1... OK
DMA Test #2... OK
DMA Test #3... OK
DMA Test #4... OK
Testing 64kB Flash... OK
Enable TIM4 IRQ... .OK
Testing 20kB SRAM (endless loop).........

U1 should be
U1 | LQFP144 | STM32F730Z8T6
instead of
U1 | LQFP64 | STM32F730R8

https://github.com/keirf/Greaseweazle/wiki/F7-Lightning-Assembly

DENSel on Pin 2 of the floppy cable is an input for 5.25" drives and can be configured as input or output on some 3.5" drives.
In the schematics for the F7_11 model DENSel is marked as an input (like INDEX). In the sources it is configured as an output, but I could not find a piece of code using that pin. Moreover it seems also that the protocol has no way of communicating DENSel.
My TEAC FD-55GFR refuses to read DD disks and does fine with HD ones. In theory I guess, one could just read a DD disk in HD mode and throw away every other track. But possibly the drive can do better than that if it knows that it is supposed to read a DD disk.
Is there any update in the pipeline or should I implement it myself?

On the F1 board, the power and data pins are a little close for using a shrouded/keyed 34-pin data connector.

In my build, the key that protrudes inward on the FDD power cable catches the edge of the shroud.

With some bending you can force the power connection, but an additional 2mm of space between the power and data pins would give plenty of space to keep the two from interfering.

Here are the parts I used:

• Shrouded 34-pin connector
• Berg 4-pin connector

(Not a big deal, but thought I'd pass the info along in case you rev the F1.)

Today I imaged a 3.5" HD DOS 1.44MB floppy disk with my GW. The resultant SCP file is 74 MB in size. I don't know about SCP disk images but I assume this is normal?

Is there some conversion tool I can use to convert the MFM floppy SCP image to say a DSK (CPCEMU) disk image or a RAW file containing only the sector data? or other disk images?

As standard 40T DS DD disks use a data rate of 250 KHz can the SCP image of a SCP floppy disk created from a 40T drive be written back to an 80T 1.2Mb drive (with double step)?

As we know the standard HD 5.25" drives spin at 360 RPM where as the 40T at 300 RPM and that the floppy controller in PCs increase the clock rate when writing the data to compensate and creates the correct data rate.

Is there an option to write a 40T disk image read from a 80T 1.2Mb drive back to a standard 40T drive or could an option be added for it?

I have a board that has output buffers that inverts the output states to the floppy. (the inputs are unchanged). I'm using a Blue pill.

I've made this simple change in src/floppy.c:

/* staticmem: default GW code
#define write_pin(pin, level) \
    gpio_write_pin(gpio_##pin, pin_##pin, level ? O_TRUE : O_FALSE)
*/

/* staticmem: inverted logic */
#define write_pin(pin, level) \
    gpio_write_pin(gpio_##pin, pin_##pin, level ? O_FALSE : O_TRUE)

I suspect though I also need some other changes?

I have tried to image same Atari ST disk with 7 different drives:
SONY MFP-F11W-5DU (SONY8903)
SONY MFP-F11W-U0 (SONY9002)
TEAC FD-235HF A110-U5 (TEAC0302)
ALPS DF354H090F (ALPS0324)
NEC FD1231H (NEC9911)
MITSUMI D359T3 (MTS)
SAMSUNG SFD-321B (SAM0210)

Two first drives are original DD drives from Atari ST computers, latter ones are generic PC HD drives.
http://tzok.eu/ftp/mydisk.rar

Best non-Atari drive seem to be Samsung. The Alps drive was a factory new unit. Image made with Teac unit seems to be damaged.

Single-sided .scp images created by the Greaseweazle tool seem to have half the expected values in the start_track and end_track header fields (offsets 6 and 7).

A 42-track image containing only the first side has 41 in the end_track field. Opening this image in v2.10 of the official SCP software (using Function->Analyzer/Editor, then Read button) shows only 21 tracks available when using the track slider in the bottom-right.

Hex-editing the image to change end_track to 81 (using a value in the full 0 to 165 range) gives the expected behaviour in the official SCP software. The specification is a bit unclear on how this value should be treated for single-sided images, but since the author's software seems to expect the full range value then I think it needs changing.

I have a (several actually) F1 BP Greaseweazle boards running v0.15. I'm trying to get it to version 0.18, but I can't seem to get the update command to work. If I use the gw.py from v0.15, it says:
** Bootloader v0.15 [F1], Host Tools v0.15 ../Greaseweazle-v0.16/Greaseweazle-F1-v0.16.hex: No match for hardware type 1

The same goes for v0.17 and v0.18 .hex files.
If I try to use the v0.16 gw.py, I get:
** Bootloader v0.15 [F1], Host Tools v0.16 ** FATAL ERROR: unpack requires a buffer of 2 bytes

The same happens for the v0.17 and v0.18 gw commands with their respecitve .hex files.

Other than breaking out the st-link v2 device, what's the path forward here? Am I doing something strange? Machine here is Fedora F31 and GW otherwise works fine.

Hi,

the file /scripts/greaseweazle/version.py seems to be missing in the repository. It is only available in the snapshot .zip archives.
If you just clone the repo, it won't work unless you manually copy the version.py from the .zip.

Did I miss something, or is it a bug?

Cheers

P.S.: Awesome work. Really impressive! 👍

I'm running an upto date LinuxMint system. I'm having issues running the following:

staticmem@asrock:~/Builds_64/Greaseweazle-0.7/scripts
$ python gw.py read --ecyl=39 --single-sided mydisk.scp /dev/ttyACM0
File "gw.py", line 20
print("Actions: ", end="")
^
SyntaxError: invalid syntax

I don't have pip3 on this computer but have: pip, pip2 and pip2.7.

sudo apt install python3
python3 is already the newest version (3.6.7-1~18.04)

sudo pip3 install crcmod pyserial
env: ‘pip3’: No such file or directory

From what I read pip3 is only provided in customised versions of python3?

Is this pip3 issue the problem or something else?

When using 5.25" drive, some revolutions instead of 14.4mln ticks (200ms) take only 262k ticks. It's exactly the 3.6ms - /INDEX pulse width. I have a theory why it happens.

Reading Track 19.1...14373680 ticks, 38315 samples
14373072 ticks, 38316 samples
14373112 ticks, 38316 samples
Reading Track 20.0...262496 ticks, 705 samples
14112480 ticks, 37519 samples
262592 ticks, 705 samples

Being making disk reading hw/sw myself, I've noticed that index impulse, when returning back from 0 to 1, sometimes make sporadic jumps back to 0. Like it's prolonged under capacitor with some noise influence. So personally I made "timeout" value to avoid these "too short rotations" (by skipping first 10ms after /INDEX is received). I hope you will fix that.

And by the way, I found that my 5.25" is making no stepping actions until I attach analyzer to /DIR or /STEP pin. I measured voltage, and it was 5.25v, pulsing down to 0.3v. So obviously it was even higher without analyzer. Voltage adjustment doesn't help much :(
And powering off STM32 without powering off 5.25" drive first, with diskette in the drive - is VERY bad idea, because signals (specially WGATE) become floated, and EM field screws diskette at the spot where heads stopped.

Unlike the Read, Write, Reset and Update commands.

The following FluxEngine ticket (davidgiven/fluxengine#170) includes code for an efficient k-median algorithm for automatically assigning flux values to one of k (automatically determined) clusters. It shows promise in:
(a) retrieving correct band assignments for warped/damaged flux values
(b) automatic base clock detection (something GW completely lacks right now)

The code is GPL but the author is prepared to consider cross-licensing to allow inclusion in GW.

I have sourced a couple of the STM32 Bluepill's from different sources and they have all failed the 2Hz Blinky test. All have communicated correctly at 115200 baud and seem to function in all other respects OK.

The problem I have is the blink rate itself. The documentation in STM32 fakes area states
"Greaseweazle includes a Blinky test firmware in the alt/ subfolder. When written to a correct and working Blue Pill board, this firmware will flash the PC13 LED on and off at approximately 2Hz (ie. toggles every 500ms)."

Flashing on and off at 2Hz would give a toggle rate of 250mS not 500mS. At a toggle rate of 500mS would indicate that PC13 LED would be off for 500mS and then on for 500mS this would be a 1Hz flashing (10 flashes in ten seconds) which is precisely what I'm getting not the 2Hz (which would be 20 flashes in 10 seconds).
So what is correct? Should PC13 toggle it's state every 500mS or every 250mS?

Brad

Hi,
I just build the Greaseweazel board and used an adapter board for this. Flashing the software was no problem and the device gets recognized on my Windows 10 system. I also can read and write disks with the software, but reading does not work. To test the device, I used the DSKA0000.hfe from the HxC floppy emulator software and wrote it to a 3.5" disk. After that, I checked that the disk is readable with an USB floppy drive and it works fine. However, when I read it back, the HFE file is not readable in the HxC floppy emulator software. Also writing it back to a 3.5" disk and testing it with the USB drive does not work.
I used the simple command "gw.exe read test.hfe" to read the disk on my system.
Do you have any ideas or a hint for my what might cause the problem? I have attached the hfe file that I read back on my system (it should contain the DSKA0000.hfe content).
testhfe.zip

When reading a DD disk in an HD drive, every other track is garbage. Only reading every other track with gw.py saves half the time while reading and importing into HxC also is more than twice as fast, since analyzing broken tracks takes quite some time.
I have attached a simple 4-line patch to read.py, which adds "--dstep" as an option.

patch.zip

When writing a file, gw.py does not check to see if it exists before attempting to open it. If it does not exist, this gives a long python error message which may not be very clear to non-programmers.

gw.py should check for the existance of the file to write and, if it is missing, display an error message to stderr.

Original report by Matti Immonen on Facebook is failure to load Hybris (SPS IPF 1457) on a stock A500 with TEAC FD-235F-161-U after writing the IPF to disk using GW v0.15 and a Sony MPF920 drive. Many other IPFs (including the slightly tricky Xenon 2, SPS IPF 2234) loaded fine on the same test system. Additionally, an earlier conversion of the IPF to HFE (using HxC tools) loaded fine on the same test system using FlashFloppy/Gotek.

The cause is apparently the use of custom sync words with MFM-invalid sequences of zeroes. Matti wrote the IPF to several disks, some of which worked somewhat better than others (but none actually load 100%). He then dumped those disks to SCP using Greaseweazle on the offending Amiga TEAC drive (images: https://drive.google.com/open?id=1JDF0_ZVL4W9BbjqyK2F1Z6dhITRtIUef).

The offending SCP images do not load properly in emulation, and analysis with Disk-Utilities indicates bad tracks. The following tracks in file Teac_Hybris_bad_disk.scp are unloadable: 3.1 (5412), 4.1 (5241), 6.0 (a429), 14.1 (5412), 15.0 (5241), 16.0 (a429), 17.0 (2541), 19.1 (2541), 30.0 (2541), 44.1 (a425), 50.0 (5412), 62.1 (2541).

The bad syncs are: 5412 (3), 5241 (2), 2541 (4), a429 (2), a425 (1).

Take Track 3.1 with sync 5412 = 0101 0100 0001 0010, which has an MFM-illegal sequence of five zeroes. This is a flux interval of 12us. Cowlark Fluxengine author reports problems at around 10us (ref http://cowlark.com/fluxengine/doc/technical.html). Searching for the sync word manually in Disk-Utilities we find 5592 = 0101 0101 1001 0010: Two bits in the five-zero sequence have been flipped! Note that syncs 5241 and 2541 are similarly afflicted with a five-zero sequence in their 41 byte.

Take Track 6.0 with sync a429 = 1010 0100 0010 1001, which has an illegal sequence of four zeroes (flux interval 10us). Searching manually in Disk-Utilities we find sync a5a9 = 1010 0101 1010 1001: Again two-adjacent bits in the four-zero sequence have been flipped! Further, we can print the exact flux intervals in the bad sync word (ns): 3950, 6000, 3525, 2375, 3825, 3825, 6000. Note the expected interval 10000 has been split into 3525+2375+3825 by the drive.

I note since v0.16 there is a now a Greaseweazle WIN executable. The Wiki Software-Installation page does not show the traditional method to install Python modules under Windows. Before v0.16 I expect this was documented but the Wiki only reflects the latest release?

https://github.com/keirf/Greaseweazle/wiki/Software-Installation

Case in point is the installation of the "bitarray" Python module. Can this be added to the Wiki?

Compilation fails with:

/usr/lib/gcc/arm-none-eabi/6.3.1/include/stdint.h:9:26: fatal error: stdint.h: No such file or directory
 # include_next <stdint.h>
                          ^

Which is a bit confusing.
Adding the package libnewlib-arm-none-eabi solves the problem.

running
gw update --bootloader
gives the following:
** Bootloader v0.16 [F1], Host Tools v0.17
Greaseweazle is in Firmware Update Mode:
The only available action is "update" of main firmware
Remove the Update Jumper for normal operation

Greaseweazle will randomly hang on reading from a PC drive.

Here is the traceback when python is broken out of using CTRL-C:

`

C:\Users\monideth\Downloads\Greaseweazle\Greaseweazle-v0.1>C:\Users\monideth\AppData\Local\Programs\Python\Python37\python gw.py read x-copy.scp COM14

Reading Track 18.0...Traceback (most recent call last):
File "gw.py", line 345, in
main(sys.argv)
File "gw.py", line 339, in main
actionsargs.action
File "gw.py", line 213, in read
flux = read_flux(args.revs)
File "gw.py", line 154, in read_flux
x += ser.read(1)
File "C:\Users\monideth\AppData\Local\Programs\Python\Python37\lib\site-packages\serial\serialwin32.py", line 290, in read
True)
KeyboardInterrupt

`

Above is for a Python 3.7 64-bit environment, but have also tried in a Python 3.7 32-bit environment, on the same machine which is Windows 10 64-bit.

This is also after increasing the timeout in gw.py:

parser.add_argument("device", timeout="5")

Is the stm32f103ret6 supported?

I've got a 5.25" floppy that's producing an empty SCP file (others are working)... Did a kryoflux dump just to make sure that it's actually got something on it and I haven't wiped it by mistake! I've uploaded it here (bcpl-sag-kryo and scp):
https://drive.google.com/open?id=1DghUX-RZHiZ5gKnVT8VmsotsdAvuJNUI
I've stuck 1k pullups on the inputs now, if that's relevant :)

I want to assign a static value for the Greaseweazle under Linux. When I run these commands I see the following values. Which one of the Vendor and Products is the actual GW application and what is the other one for?

$ udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) | grep -i idvendor
ATTRS{idVendor}=="1209"
ATTRS{idVendor}=="1d6b"

$ udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) | grep -i idproduct
ATTRS{idProduct}=="0001"
ATTRS{idProduct}=="0002"

On a side note re Wiki:
https://github.com/keirf/Greaseweazle/wiki/Firmware-Update
Should it be "python3" and not "python" ? I believe that later gave me an error.

I've tried to create a Windows executable using the Makefile under Linux using:
make windist

First I installed "cx_Freeze":
python3 -m pip install cx_Freeze --upgrade

It reports:
cp -a Greaseweazle-v0.20/scripts/build/exe.win*/* Greaseweazle-v0.20/
cp: cannot stat 'Greaseweazle-v0.20/scripts/build/exe.win*/*': No such file or directory
Makefile:74: recipe for target 'windist' failed
make[1]: *** [windist] Error 1

Although it fails it appears to create a Linux gw binary file instead which appears to work (shows commands):
./Greaseweazle-v0.20/scripts/build/exe.linux-x86_64-3.6/gw

If I then edit the Makefile to read:
cp -a $(PROJ)-$(VER)/scripts/build/exe.linux-x86_64-3.6/* $(PROJ)-$(VER)/
I get a bit further:

cp: cannot stat 'Greaseweazle-v0.20/lib/bitarray/VCRUNTIME140.DLL': No such file or directory

What else is required to build the Windows binary? Having it build the Linux binary is nice though but need the EXE.

It would be nice to have an option to test how many tracks drive can read (KryoFlux has such option), and also I wonder if it would be possible to try to detect disk geometry.

Hi Keir,

As requested, a ticket to remind you to update the Greaseweazle Models page!:

https://github.com/keirf/Greaseweazle/wiki/Greaseweazle-Models

to show the various models and differences.

Thank you.

One of the advantages of reading (suitably readable) MFM disks with an old PC FDC is that you know, immediately, if a read of a block is good because the expected format is detected in HW, and various checksums/CRC are validated.

GW could do this, if the controlling software was linked to your libdisk library.

Support could be further enhanced with file-level aware utilities, or for alternate GW things (like 9track or HDD access) in the future.

I'd love to see support for streaming the captured data to another analysis process, that could inform the code in this repo to attempt specific block/track/etc retries -- or even a pause so the operator can clean the media/heads for retry attempts.

Sony F920, 3.5" HD drive (this does work fine with the F1 hardware), reads of high density and standard density disks are resulting in 8kb SCP files. See attached.
test2.zip

following up from the recent facebook thrread:
https://www.facebook.com/groups/greaseweazle/2750806445004959/?comment_id=2750883304997273&reply_comment_id=2752710231481247&notif_id=1581587463243708&notif_t=group_comment

i have been trying to dump some macintosh floppy disks with an f7 greaseweasle:

the first is a 400k mfs disk with a bootable copy of system 5, this is not a factory copied disk, i made a copy of the original using the macintosh native disk imager, Diskcopy4.2

the second disk is an 800k HFS floppy formatted on a real macintosh classic, and approximately half filled with random program files.

i am sure that the disks are mfs and HFS respectively because the macintosh system utility "disk first aid" can verify the hfs disk, and refuses to verify the mfs disk complaining that it is not an HFS disk.

i have confirmed the disks as working on a 1990 macintosh classic.

with my greaseweasle f7 i was able to copy and write a 1.44mb mac hfs disk which then sucessfully booted the macintosh, so i can be fairly certain that my greaseweasle is ok, and my drive is functioning normally.

after initailly trying to dump and write the disks with the greaseweasle without sucesses, it was suggested that i try some different drives, because there is some evidence to suggest that some PC floppy drives are unable to read these disks.

i have dumped the disks using the following drives:

two pc floppy drives,
two amiga drives, (these drives might not be in excellent condition)

files too big to upload to github so link to google drive: https://drive.google.com/open?id=1mZ2rfp9uUsUztSIU5kN5Z7xDuQiCdZgS

Under Windows 7 x64 I can't access the Greaseweazle device. I get error:

File "D:\Program Files\Greaseweazle\scripts\greaseweazle\tools\util.py", line
71, in find_port
    raise serial.SerialException('Could not auto-detect Greaseweazle device')
serial.serialutil.SerialException: Could not auto-detect Greaseweazle device

Under Windows 10 x64 it works, but unless I try to use Zadig to install WinUSB (CDC) driver. It works only until is detected as USB Serial Device (COM9). When I use Zadig it is detected as Greaseweazle (COM9) but no longer works.

I'm using Python 3.7 (Anaconda).

Greaseweazle is a good tool that works well. great.
The only problem is the writing end point.

Since the track write always ends on INDEX, the sectors above INDEX are broken.
So,the write end point should be the write noise that appears first from INDEX.

For HW variations and default settings it would be nice to have an optional INI style file. If not present then use defaults as normal. If present then apply the settings. i.e: default drive. Interface HW variations.

Sony F920 HD 3.5" floppy drive, having to specify "drive 0" on a straight through cable otherwise I get "No Index"

This is the board: (It's maked as a backpill, which you specificially mention)

https://robotdyn.com/diaphragm-mini-pump-for-liquid-12v.html
and pinout:
https://robotdyn.com/pub/media/0G-00005692==STM32F103C8T6-STM32MiniSystem/DOCS/PINOUT==0G-00005692==STM32F103C8T6-STM32MiniSystem.jpg

I found a generic bluepill pinout:
https://idyl.io/wp-content/uploads/2018/07/stm32f103-pinout-diagram.png

And it seems to be the same.

I quite like the build quality of these manufacturers. They seem to be a step above the usual Chinese made dirt cheap boards.

Hello! Sorry for my English... I'm Korean.

First of all, Thank you so much!

So many Korean people whose hobbies are collecting retro IBM-PC are glad to meet your project!
(I'm vice manager of online-community for "DOS/win3.1")

Your core theme of the project is Shugart, but IBM-PC format doesn't seem to be out of your interest... T.T

I know 5.25 shugart pin-out is different from that of 5.25 IBM.

So that?? 2DD 5.25 360KB ibm-pc formatted diskette does not working using greaseweazle. It means reading and writing does not operate well...

Error Message shown as bellow,
"Greaseweazle v0.11 [F1], Host Tools v0.11
Reading Track 0.0...Command Failed: Seek: Track 0 not found"

360KB 2DD formatted diskettes don't work with both 5.25 2HD and 2D drives.
(But 2HD 5.25 1.2MB IBM-PC formatted diskettes do work well with 5.25 1.2MB 2HD floppy drive.)

So I have question for you, weather 360KB 2D IBM-PC format is not your intetest yet or I did something wrong...

If 5.25 2D 360KB IBM-PC format works good with greaseweazle, So many Korean people will be very grateful to you.

I want to use a "Blue Pill" with Dupont direct wiring on a Epson SD-600 5.25 Floppy drive.
I can read disks, but the disk analyze shows multiple errors (see dump).

When i connect the same Epson drive with a STM32 "Blue Pill" adapter board and a floppy flat cable the result is fine (see dump).

I can not find out what makes the difference.

Hi!

I would like to ask whether there is any chance that your firmware might work with my custom board design from early 2018.

It uses the same STM32F103C8T6 and plugs into the back of the drive. Unfortunately, I never found the time to write proper firmware for it.

The pinout is:

I have to ask how you came up with the name for this project, I've googled it but no obvious answers, sorry if it's been mentioned before but I've seen nothing that explains it.

Hi,

As a user of FluxEngine and AmigaArduinoFloppyDiskReaderWriter I stumbled upon Greaseweazle and find this a very interesting project. By coincidence, I have started working on Python scripts myself a couple of weeks ago to interface AmigaArduinoFloppyDiskReaderWriter via serial connection to decode disks with IBM-style sectors.

If you are interested, you can find my python code here:
https://github.com/hpingel/pyaccess1581

The code contains an IBM sector parser in Python - I don't know if this is in the scope of your project. I also do CRC calcs and am not using crcmod any more but instead binascii.crc_hqx as I need binascii anyway and it doesn't need to be installed via pip.

The most interesting file for sector decoding should be:
https://github.com/hpingel/pyAccess1581/blob/master/access1581/imager.py

Serial communication is done here:
https://github.com/hpingel/pyAccess1581/blob/master/access1581/arduinointerface.py

Disk formats are described here:
https://github.com/hpingel/pyAccess1581/blob/master/access1581/diskformats.py

Maybe this is interesting for you.

Cheers,
Henning

I have a bunch of old drives (like everyone else) and they've been unused for decades. I've cleaned them and greased the worm and sliders, but they are still stiff (probably junky grease hidden inside of the bearings). If I move them manually--hard to do, messy, and possibly risky--I can get them to start seeking properly, but it's quite time consuming.

Would it be possible to add a head stepper exercise mode where it just steps the head to --ecyl and back to track 0? Optionally a 'count' option for the # of times to do it (0 being forever). Or I could just wrap it in a script if that doesn't fit into your vision of gw.py.

Thank you.

https://www.facebook.com/groups/greaseweazle/permalink/3198408880244711/

Seems some interest for a clean option.
Revolutions = 0
No output file

3.5" cleaning disks recommended for 30 second's.
Wonder if a prompt to re-apply isopropyl proceed / cancel? To try evenly wear on the disk?

Since converting C64 .scp dumps to emulator-supported formats (.g64 or .d64) requires other tools and does not work very well, it would be nice to directly support a format which the most common C64 emulator supports. P64 files are described in the manual of the VICE emulator as "lowlevel NRZI flux pulse disk image files".
The specification is here:
https://vice-emu.sourceforge.io/vice_16.html#SEC300

Reference implementations can be found at
https://github.com/BeRo1985/micro64disktool/blob/master/src/DiskImageP64.pas
and
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/diskimage/fsimage-p64.c
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/lib/p64/

I bought a STM32F103C8T6 from China on ebay. On close examination, the description says

4-16MHz crystal.

and in fact has a 4 MHz instead of an 8 MHz crystal. The blinky test succeeds nicely, but only at half speed (output at 57600 baud).