When using your arduino pico code I get the following error. Arduino 1.8.16, macOS 10.15.7, Greaseweazle v0.31

$ ./gw read --device /dev/cu.usbmodem14101 xxx ERROR: Greaseweazle firmware v1.0 is unsupported To perform an Update:

• Run "gw update" to install firmware v0.31

Brilliant piece of work (again).

Thank you John Luke

This updates the pinout to match the "rev C" prototype featherwing. Tested on Feather M4, but the Feather RP2040 pinout was also updated to match.

reading and writing both work with the new featherwing, and the write protect slide switch works (but fluxengine is bugged, at least at the 6 month old ref I'm using, and doesn't detect that the data wasn't written as long as it's in the correct format! This is the same if the WP tab of the drive is engaged or if the WP slide switch of the featherwing is engaged)

The standard feather pinouts were extracted to a header since repetition is bad. repetition is bad. is bad.

@ladyada

This adds support for the Apple II 5.25" floppy drives, as long as you've modified them to add a revolution sensor. Write protect is weird and untested. Writing is untested. Works with fluxengine pending a PR:

• https://github.com/davidgiven/fluxengine/pull/492

Capturing a track from index pulse to next index pulse will run into trouble when reading disks that are not index aligned, e.g. Amiga Disks. A sector might start before an the index and end after the index, flux transitions might be lost when the capture does not overlap.

Thank you for opening an issue on an Adafruit Arduino library repository. To improve the speed of resolution please review the following guidelines and common troubleshooting steps below before creating the issue:

• Do not use GitHub issues for troubleshooting projects and issues. Instead use the forums at http://forums.adafruit.com to ask questions and troubleshoot why something isn't working as expected. In many cases the problem is a common issue that you will more quickly receive help from the forum community. GitHub issues are meant for known defects in the code. If you don't know if there is a defect in the code then start with troubleshooting on the forum first.

• If following a tutorial or guide be sure you didn't miss a step. Carefully check all of the steps and commands to run have been followed. Consult the forum if you're unsure or have questions about steps in a guide/tutorial.

• For Arduino projects check these very common issues to ensure they don't apply:

  • For uploading sketches or communicating with the board make sure you're using a USB data cable and not a USB charge-only cable. It is sometimes very hard to tell the difference between a data and charge cable! Try using the cable with other devices or swapping to another cable to confirm it is not the problem.

  • Be sure you are supplying adequate power to the board. Check the specs of your board and plug in an external power supply. In many cases just plugging a board into your computer is not enough to power it and other peripherals.

  • Double check all soldering joints and connections. Flakey connections cause many mysterious problems. See the guide to excellent soldering for examples of good solder joints.

  • Ensure you are using an official Arduino or Adafruit board. We can't guarantee a clone board will have the same functionality and work as expected with this code and don't support them.

If you're sure this issue is a defect in the code and checked the steps above please fill in the following fields to provide enough troubleshooting information. You may delete the guideline and text above to just leave the following details:

• Arduino board: INSERT ARDUINO BOARD NAME/TYPE HERE

• Arduino IDE version (found in Arduino -> About Arduino menu): INSERT ARDUINO VERSION HERE

• List the steps to reproduce the problem below (if possible attach a sketch or copy the sketch code in too): LIST REPRO STEPS BELOW

The Apple Disk ][ produces a flux transition whenever the WRDATA signal has a transition, rather than on only one edge. This needs different low-level writing code than a PC drive.

We can implement it later for samd51 or bitbang if needed.

The original version was tested on HW but the compatible version hasn't been tested yet.

This improves compatibility with genuine GW hardware, and improves (but doesn't fix; is it a g64conv track numbering bug?) decoding flippy disks with g64conv. It also provided an opportunity to learn how to use the 2nd core on RP2040, bonus for me!

When adding internal debug prints to GW host software, a multi-track capture from genuine GW hardware consists of a partial revolution, followed by several full revolutions. These are sampled without gaps, so software like g64conv which likes to stitch 'index-hole insensitive' formats across the gap can do as it likes; it's advised of (but ignores) the locations where the index was seen:

 Total: 232202 samples, 594.17ms
 Revolution 0: 93.06ms
 Revolution 1: 166.87ms
 Revolution 2: 166.87ms
 Revolution 3: 166.87ms 

Prior to this change, a capture from Adafruit_Floppy's GW-compatible firmware was shown as

 Total: 120485 samples, 652.35ms
 Revolution 0: 0.00ms
 Revolution 1: 162.34ms
 Revolution 2: 55.11ms
 Revolution 3: 162.17ms
 Revolution 4: 55.28ms
 Revolution 5: 162.12ms

where there was an always-empty first revolution, then an alternation between a full and a partial revolution. (a 6th, partial revolution may have been discarded internally in GW before this message was printed)

After this, a capture from an RP2040 with the GW-compatible firmware is shown essentially the same as genuine GW.

However, there does seem to be a problem introduced here. With this firmware, GW will sometimes fail to decode any sector but the first, randomly on some tracks of a floppy. The problem moves around but occurs with probability >1/100, so most full disk captures are affected. The resulting sector map looks like:

Cyl-> 0         1         2         3         4         5         6         7         
H. S: 01234567890123456789012345678901234567890123456789012345678901234567890123456789
0. 0: ................................................................................
0. 1: ...............X............X...................................................
0. 2: ...............X............X...................................................
0. 3: ...............X............X...................................................
0. 4: ...............X............X...................................................
0. 5: ...............X............X...................................................
0. 6: ...............X............X...................................................
0. 7: ...............X............X...................................................
0. 8: ...............X............X...................................................
0. 9: ...............X............X...................................................
0.10: ...............X............X...................................................
0.11: ...............X............X...................................................
0.12: ...............X............X...................................................
0.13: ...............X............X...................................................
0.14: ...............X............X...................................................

Also, continuous capture would need to be implemented for samd51 before this PR should be accepted.

The performance on non-overclocked RP2040 from CircuitPython is marginal, but allowing an additional spindle revolution makes it >99.9% (now reads a 1.44MB commercial disk 100% full surface over multiple tests)

Because the read_track loop usually terminates as soon as all sectors are successfully read, this doesn't decrease read speed unless a sector CRC was missed on the first read.

Typical output, on a Feather M4 with the Floppy Featherwing and a 5.25" 1.2MB floppy (which only has 15 sectors per track, not 18, so the partial track validity is expected):

its time for a nice floppy transfer!
Waiting for index pulse...Found!
Seeking track...Going to track 0
Going to track 0

done!
Captured 15 sectors
Validity: VVVVVVVVVVVVVVV???
0000 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 01 01 00 02 e0 00 60 09 f9 07 00 0f 00 02 00 00 00 00 00
0020 00 00 00 00 00 00 29 14 24 27 17 4e 4f 20 4e 41 4d 45 20 20 20 20 46 41 54 31 32 20 20 20 fa 33
0040 c0 8e d0 bc 00 7c 16 07 bb 78 00 36 c5 37 1e 56 16 53 bf 3e 7c b9 0b 00 fc f3 a4 06 1f c6 45 fe
0060 0f 8b 0e 18 7c 88 4d f9 89 47 02 c7 07 3e 7c fb cd 13 72 79 33 c0 39 06 13 7c 74 08 8b 0e 13 7c
0080 89 0e 20 7c a0 10 7c f7 26 16 7c 03 06 1c 7c 13 16 1e 7c 03 06 0e 7c 83 d2 00 a3 50 7c 89 16 52
00a0 7c a3 49 7c 89 16 4b 7c b8 20 00 f7 26 11 7c 8b 1e 0b 7c 03 c3 48 f7 f3 01 06 49 7c 83 16 4b 7c
00c0 00 bb 00 05 8b 16 52 7c a1 50 7c e8 92 00 72 1d b0 01 e8 ac 00 72 16 8b fb b9 0b 00 be e6 7d f3
00e0 a6 75 0a 8d 7f 20 b9 0b 00 f3 a6 74 18 be 9e 7d e8 5f 00 33 c0 cd 16 5e 1f 8f 04 8f 44 02 cd 19
0100 58 58 58 eb e8 8b 47 1a 48 48 8a 1e 0d 7c 32 ff f7 e3 03 06 49 7c 13 16 4b 7c bb 00 07 b9 03 00
0120 50 52 51 e8 3a 00 72 d8 b0 01 e8 54 00 59 5a 58 72 bb 05 01 00 83 d2 00 03 1e 0b 7c e2 e2 8a 2e
0140 15 7c 8a 16 24 7c 8b 1e 49 7c a1 4b 7c ea 00 00 70 00 ac 0a c0 74 29 b4 0e bb 07 00 cd 10 eb f2
0160 3b 16 18 7c 73 19 f7 36 18 7c fe c2 88 16 4f 7c 33 d2 f7 36 1a 7c 88 16 25 7c a3 4d 7c f8 c3 f9
0180 c3 b4 02 8b 16 4d 7c b1 06 d2 e6 0a 36 4f 7c 8b ca 86 e9 8a 16 24 7c 8a 36 25 7c cd 13 c3 0d 0a
01a0 4e 6f 6e 2d 53 79 73 74 65 6d 20 64 69 73 6b 20 6f 72 20 64 69 73 6b 20 65 72 72 6f 72 0d 0a 52
01c0 65 70 6c 61 63 65 20 61 6e 64 20 70 72 65 73 73 20 61 6e 79 20 6b 65 79 20 77 68 65 6e 20 72 65
01e0 61 64 79 0d 0a 00 49 4f 20 20 20 20 20 20 53 59 53 4d 53 44 4f 53 20 20 20 53 59 53 00 00 55 aa

It's hoped that this code will also be used in CircuitPython via submodule; it's a lightly modified version of the code I was already using.

I didn't use/test RP2040. Probably it'll need a little bit of work.

FsBlockDeviceInterface v2 API changes are

• rename read/write Block --> read/write Sector
• end() return type is void (previously bool)
• add isBusy() and sectorCount()

also fix warnings while I am at it

GW and FluxEngine folks agreed that it is better to just always use the drive's native step, and FluxEngine has started fixing things internally so that this works better than when I first implemented the "why not both" approach. Only the "3" bustype is allocated now in the GW protocol.

We can decide if we want to keep the step_mode at all, since its only intended user was the GW-compatible firmware.

There are people in the world that would like to have this available to pull their arrangements off of Roland's proprietary floppies. I have the schematics and pin outs. It is similar to the Apple II interfaces. I will contribute as much as possible if this is feasible.

It appears that specialty operations, such as using g64conv to convert the second side of a flippy disk from a two-sided .scp of the disk taken from the top side, may require operation similar to the genuine greaseweazel hardware: capture multiple revolutions without gaps.

the current implementation in this repo simply captures 3 different copies of the same track, from one falling index pulse to the next.

Making a change like this has a big impact on the structure of the code. A ping-pong buffer system could be adopted, so that flux is entering buffer A and then buffer B; once buffer A is filled, it can be transmitted over USB. Probably rp2040 is forced to go interrupt based to enable this, which we want to do anyway.

I don't have any proof that this is why my flippy-floppy dump didn't work; there are also g64conv bugs—with the geniune greaseweazel scp file, the directory data which should be on track 18 is on track 14 of the resulting g64 file! but it is intact. (track 18 sectors 0 and 1). By contrast, my rips with feather rp2040 to scp do not have track 18 sector 0, but do have track 18 sector 1 (again, transposed incorrectly to track 14 by g64conv). I know the flip side reads correctly because it happens to have two index windows and can be flipped in a standard PC 5.25 drive (teac).

https://hackaday.com/2019/01/24/cool-tools-a-little-filesystem-that-keeps-your-bits-on-lock/ https://github.com/littlefs-project/littlefs

On top of the basic drive I/O routines it might be useful to implement littlefs, a filesystem made for microcontrollers. AFAIK all you need to do to port it is to provide it with implementations of a few functions for reading/writing/syncing blocks.

The filesystem is simple and light weight, far more robust than FAT, and every operation is atomic.

Thank you for making this.

Will you emulate a floppy drive too?

I have an old Korg N364 synthesizer with a broken drive. Would be nice to mount a Pico instead, perhaps with extra flash. or sdcard reader.

It's a Matsushita EME-216 KR according to the service manual - but some have 34 pin floppy drives.

https://en.wikipedia.org/wiki/Floppy_disk_hardware_emulator http://hxc2001.free.fr/floppy_drive_emulator/ https://github.com/keirf/FlashFloppy

The density pin is used differently depending on the manufacturer, some use it as an output to signal the media type (mostly teac drives) some use it as an input to switch the rpm (300/360) when using HD media (e.g. Sony 920), and at some it is NC. Detecting the media type can only be done by counting the transitions when reading a track. Or when writing a track by firstly trying to write a HD track and reading it back while counting the transitions, a DD disk will return much less transitions than written. And another problem is that all HD drives change the sensitivity/write strength of the head depending on the sensor for the HD hole of a disk, so that a DD image written to a HD disk will fail. Covering the HD hole will circumvent this issue.