davidgiven / fluxengine Goto Github PK

I got a warning when I built the firmware with PSoC Creator:

Warning-1366: Setup time violation found in a path from clock ( CyBUS_CLK ) to clock ( CyBUS_CLK ).

but I went ahead and programmed it into the FluxEngine anyway

Hi, I can format a few 800k Mac disks and send them to you :-)

Remember how old PCs would grind their disk drives on startup, as they do disk seeks? This tells me that drives support seeking, and track 0 detection, even with no disk in the drive. This should allow us to detect whether drives are attached to the bus. This is particularly valuable as it would allow a single drive to be treated as drive 0, regardless of whether the FluxEngine is attached in piggyback mode or PC drive cable mode, and avoid the nasty numbering issue we currently have.

Right now sector images are handled in a pretty crude way, just being sector x side x track raw images. This is good enough when reading, as the geometry is autodetected from the physical media but it's not good enough when writing --- e.g. the Brother writer will want to know whether to write a 40 track or 80 track disk.

There are, however, a jillion different non-raw disk formats. (.TD0, .IMD, .RAW, .DSK, .DMK, .IMG...) Maybe I should support something like libdsk to abstract over these.

Hello David,

http://cowlark.com/fluxengine/doc/disk-zilogmcz.html

Based on your website I have to say the following:

if a sector is received by the OS at all, it's guaranteed to be valid.

This is only true if the image was generated by a perfectly error free floppy disk.
Or produced synthetically.

The reason for my request:
Jon Hales from the Center of Computing History asked me for help with the analysis of Zilog RIO floppy disks.
He gave me some binary images that were created with your help.
I wrote a tool for him with which he can analyze these images at the file system level.
Including the extraction of files to the PC.
These images contain 128byte data + 4byte pointers (132byte/sector total) per sector.
No CRC.

Jon informed me that some disks are in poor condition and not all sectors could be read cleanly.

While writing and testing the tool, I found many sectors that contained only zeros
(132 zero bytes) even though they were part of regular files.
Since this can not logically occur on Zilog RIO,
I define these sectors as bad sectors in my tool and provide a synthetic CRC error.

In the deeper analysis of the file system on the floppy disks,
I found sectors that looked good at first glance,
but on closer examination contained data errors.
For example, Non-ASCII characters in text files
(text files in RIO are plain text files 7-bit ASCII)
or sectors with pointers pointing to addresses outside the disk geometry.
Bit or byte errors in binary files can not be easy
be recognized automatically or by looking through the eyes.

For this analysis work would be the control option through the original CRC field
important. I (and Jon) can not trust any file that we extract from the images.

Regards
Ralf
http://rio.early8bitz.de

I'd like to suggest a potential alternative to the Cypress board: My USB Floppy Adapter
It uses the same STM32F103C8T6 as those ubiquitous $2 breakout boards.
The 5V-tolerant IOs of that 3.3V part are used in open-drain mode with external pull-up resistors to 5V.

The thing is that I identified that chip as probably capable enough, built the board, but did not find the time to write the firmware for it.
So far, I can only move the drive head, blink the drive LED and check the TRK0 pin.
The original plan was to use one of the chip's DMA channels to bit-bang the data line from/to a ring buffer at about 4MHz and simultaneously use the 72MHz Cortex M3 core to pre-/post-process the data and then transmit it via full-speed USB.

Since you have more experience with the software-part: Would you consider this approach realistic?

EDIT: There are libraries for the STM32F103C8T6 that let it act like USB mass storage, a virtual COM port or both. Ideally, one could send a description of the disc layout to the virtual COM port and then access the drive as regular mass storage.

Hi,

I was testing imaging a disk using fluxengine read ibm.

I have a feeling that the disk was detected to be of a higher density (ED?) than it really is. Maybe I am just mistaken. I expected an image size of 1.440 KB. SVG shows 20 sectors but summary says 33 sectors.

The candidate (it is pretty difficult to take a decent close-up photo of a floppy disk):

Console output:

Autodetecting output geometry
H.SS Tracks --->
0. 0 ................................................................................
0. 1 ........................................X.......................................
0. 2 ................................................................................
0. 3 ................................................................................
0. 4 ................................................................................
0. 5 ................................................................................
0. 6 ................................................................................
0. 7 ................................................................................
0. 8 ................................................................................
0. 9 ................................................................................
0.10 ................................................................................
0.11 ................................................................................
0.12 ................................................................................
0.13 ................................................................................
0.14 ................................................................................
0.15 ................................................................................
0.16 ................................................................................
0.17 ................................................................................
0.18 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.19 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.20 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.21 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.22 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.23 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.24 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.25 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.26 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.27 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.28 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.29 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.30 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.31 ................................................................................
0.32 ................................................................................
1. 0 ................................................................................
1. 1 ................................................................................
1. 2 ................................................................................
1. 3 ................................................................................
1. 4 ................................................................................
1. 5 ................................................................................
1. 6 ................................................................................
1. 7 ................................................................................
1. 8 ................................................................................
1. 9 ................................................................................
1.10 ................................................................................
1.11 ................................................................................
1.12 ................................................................................
1.13 ................................................................................
1.14 ................................................................................
1.15 ................................................................................
1.16 ................................................................................
1.17 ................................................................................
1.18 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.19 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.20 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.21 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.22 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.23 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.24 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.25 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.26 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.27 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.28 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.29 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.30 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1.31 ................................................................................
1.32 ................................................................................
Good sectors: 3199/5280 (60%)
Missing sectors: 2081/5280 (39%)
Bad sectors: 0/5280 (0%)
writing 80 tracks, 2 heads, 33 sectors, 512 bytes per sector, 2640 kB total

SVG and Flux:

promise0908.svg.txt
promise.flux.rename.txt

Most Apple and Mac emulators expect disk images to be either in the DiskCopy 4.2 format, or in a raw format.

The DiskCopy 4.2 format is described here: https://wiki.68kmla.org/DiskCopy_4.2_format_specification
It is basically [Header] [512 x 10 x Sides x 80] [12 x 10 x Sides x 80], with some checksums and padding.

The raw format throws away the 12-byte "tags" and has no header and is simply [512 x 10 x Sides x 80]. Unfortunately it is not a good idea to throw away the tags for preservation purposes, as they contain data useful for reconstruction of a damaged filesystem with Mac disks, and are essential for operation with Lisa disks.

EDIT: The WOZ format (#86) supports 3.5" disk images and emulators will likely start supporting it soon. Support from Mac emulators is likely to be hit-or-miss because many do not properly emulate an Apple floppy controller.

Hi!

I'm afraid I'm not that experienced building stuff with make, and I could use some directions in the process of building the client software. Currently it's just one paragraph. First I attempted compiling on an older mac with El Capitan, but it looks like this needed something newer. Then I attempted it with Mojave and it seems it worked, but after typing make I can't find any binaries anywhere. My intention is to move these binaries to the older machine to check out if this worked. Later I'd like to build this on Windows, but I have no idea how to even start.

I believe it would be handy to have tagged commits, so that Github interprets them as releases, and it would be cool if they also included precompiled binaries to give people the chance of skipping all this process.

My brother @bgottula and I have been working through a bunch of our grandmother's old writings recently, many of which were preserved on ancient 120K Brother WP floppies. We decided to give FluxEngine a try before spending $100 on a KryoFlux or SuperCard Pro, and in a surprisingly short amount of time this weekend we managed to make loads of progress, with lots of success!

We did run into one fairly major issue while getting things set up, though. Any client operation that involved an actual drive command would do nothing, and then around 3 seconds later, the client program would exit with a libusb error message indicating device removal.

I was able to trace this behavior back to the watchdog timer expiring, which would cause the microcontroller to reboot, and therefore trigger a USB device removal and re-enumeration.

Using the debugger on the firmware, along with some multimeter probing of pins and trial-and-error modifications of things, I ultimately found that the firmware was getting stuck waiting for the drive to do stuff (e.g. waiting for the index interrupt after ostensibly starting the spindle motor), and the reason why the drive wasn't doing stuff is that the drive select and motor enable lines were being operated inversely from how they ought to have been.

In the PSoC Creator schematic, there's a demux coming off of MOTOR_REG, controlled by DRIVE_REG. The pair of NOT gates on the demux's output lines could be removed to fix things up.

(The hack I actually did, which was slightly different, but which ought to be equivalent, and which was still effective at making the firmware behave properly, was to shove a new NOT gate in between DRIVE_REG and the demux control line input. But that's a bit silly and sloppy.)

Bear in mind that we were working with just a single-FDC-connector cable and an individual drive, so I wouldn't be able to tell you if our fix breaks something for dual-drive setups. But it at least appears to be a pretty straightforward drive-selection-being-wired-up-backwards situation.

"Sourcing a different microcontroller. The PSoC5 is a great thing to work with, but it’s disappointingly proprietary and the toolchain only works on Windows. It’d be nice to support something easier to work with. I need a 5V microcontroller (which unfortunately rules out Arduinos) with at least seventeen GPIO pins in a row. As non-PSoC5 microcontrollers won’t have the FPGA soft logic, that also means I’d most likely need to bitbang the floppy drive, so speed is important. If you have any recommendations, please get in touch."

I think the stm32 bluepill has enough GPIOs, here it says it has 32 GPIOs:

https://os.mbed.com/users/hudakz/code/STM32F103C8T6_Hello/

It runs in 3.3V, I guess it would be possible to run in 5V as well, to be checked.

...so in the case where the sector header can be read but not the sector data, we know how big the data would have been; this fixes an issue with LDBS export where sometimes sectors are reported as the wrong length (because LDBS won't let you specify the free-form sector length as zero).

Hi again,
today I want get new images from my bother disks.
Software told me "Error: your FluxEngine firmware is at version 4 but the client is for version 5; please upgrade"

So I downloaded the thing for PSoC Creator, update components, clean and build the project.

main.c: In function 'cmd_set_drive':
main.c:573:44: error: 'struct set_drive_frame' has no member named 'high_density'
current_drive_flags = f->drive | (f->high_density<<1);
^
The command 'arm-none-eabi-gcc.exe' failed with exit code '1'.
--------------- Rebuild Failed: 03/24/2019 16:29:42 ---------------

Did I anything wrong?

These weird spiral-track drives are used by various old machines. They look simple to support, given enough assistance with the hardware, so let's give it a try.

Hi,

this is my first soldering project for computer ever.
All of your great project was descripted fine and step by step - I'm ready to start reading old disks at Win10 now.

You wrote:

6. Insert a scratch disk and do .obj/fe-rpm from the shell.

But what shell?
Could you explain me, please?

So I'm trying to read a ND aka Norsk Data format 17b floppy (the floppy itself is a normal 5.25 inch DS, HD 1.2MB floppy) using the fe-readibm command so that I can capture the flux information into a file. I'm using this command:
$ ../.obj/fe-readibm --output nd-525-210523g02-xx-02d.img --write-flux=nd-525-210523g02-xx-02d.flux
but it fails with an error
46.0: 162 ms in 102144 bytes (629 kB/s)
1.00 us clock; 20279 bytes encoded; 32 records
terminate called after throwing an instance of 'std::out_of_range'
what(): byte access out of range
Aborted
the floppy drive I am using is a Teac FD-55GFR floppy, and I have verified that it reads IBM formatted floppies ok.
ND format 17b has 1024 bytes per sector, 8 sectors per track, 77 tracks and is DS/DD.
When I read such a floppy on a FreeBSD machine, I set parameters with the fdcontrol command first,
# fdcontrol -f 1232 /dev/fd1
view settings
# fdcontrol -vF /dev/fd1
/dev/fd1: 1232 KB media type
Format: 8,1024,0xff,0x35,77,500,2,0x74,1,0,+mfm
Sector size: 1024
Sectors/track: 8
Heads/cylinder: 2
Cylinders/disk: 77
Transfer rate: 500 kbps
Sector gap: 53
Format gap: 116
Interleave: 1
Side offset: 0
Flags <MFM>

then read with the dd command like so
$ dd if=/dev/fd1 of=./test.image bs=1024
1232+0 records in
1232+0 records out
1261568 bytes transferred in 230.765575 secs (5467 bytes/sec)

Back to the fluxengine. Is this the correct way to capture the flux file of an unknown format?

I am trying to dump several Acorn Archimedes 3.5" disks for use in an emulator. I don't have physical hardware to test the condition of the disks, but did have some limited success getting data from them using OmniFlop on an old laptop.

I have built a flux engine, tied GND on the board to one of the two GND connectors on the floppy power cable. Power to the drive is via a PC power supply with ATX pins "jumped".

I've built the firmware from master and programmed the board. I'm using the latest provided windows "fluxengine" build.

I'm reading the disks as follows, during which the drive appears to make all the right noises.
fluxengine read adfs -s :d=0 -o victorian-4.img --write-flux=victorian-4.flux

Doing so yields this:

Reading from: :d=0:s=0-1:t=0-79
Writing a copy of the flux to victorian-4.flux
0.0: 196 ms in 68800 bytes
5 retries remaining
0.0: 196 ms in 69440 bytes
4 retries remaining
0.0: 196 ms in 69056 bytes
3 retries remaining
0.0: 196 ms in 68992 bytes
2 retries remaining
0.0: 196 ms in 68864 bytes
1 retries remaining
0.0: 196 ms in 69184 bytes
giving up
0 bytes decoded.
0.1: 196 ms in 70720 bytes
5 retries remaining
0.1: 196 ms in 70464 bytes
4 retries remaining
0.1: 196 ms in 69952 bytes
3 retries remaining
0.1: 196 ms in 70656 bytes
2 retries remaining
0.1: 196 ms in 70336 bytes
1 retries remaining
0.1: 196 ms in 70400 bytes
giving up
0 bytes decoded.
.. etc...

Ultimately resulting in

H.SS Tracks --->
No sectors in output; skipping analysis
0 tracks, 0 heads, 0 sectors, 0 bytes per sector, 0 kB total

I'm unsure where I'm going wrong. Disk drive is a TEAC FD-235HG.

Issue is likely user error, but would appreciate some assistance in finding where I'm going wrong.

I have my PSoC5 ready to go, but I haven’t sourced a drives yet. I have an old Shuttle XPC that’d work great for this application. It’ll fit separate drives, but things would be cramped and I’d like to use the 3.5 bay for a media reader. I think the 5.25 and 3.5 drives are completely separate electronically on the FD-505, but it’s been a while since I owned one. Any insight?

I have a large and growing collection of 120 and 240k Brother disks. I also write drivers for the FC5025 flux reader (http://www.deviceside.com/fc5025.html). I'd love to help with your Brother support.

Avid collector of all things old-Mac here. Also an amateur digital archivist, which is how I stumbled across FluxEngine (your Reddit marketing (tm) worked).

I've ordered the board and got it all assembled, and have successfully imaged a couple of PC disks (getting 869 kB/s on the bandwidth-side so I'm living dangerously!). But what I'm really after is better support for 800k Mac images, both read and (in an ideal world) write.

I have setup a Macintosh Classic II which can read/write both 1.44MB "standard PC" and 800k (definetely not standard) disks. And 400k single-sided too. I also have a USB floppy drive and an iBook G4, allowing me to transfer files to the Macintosh Classic II. And, of course, I have a FluxEngine, allowing me to image disks.

So, basically, my question is: how can I help? I'm happy to image disks, test disks, etc...* if it will potentially lead to better support for these old Mac disks - as many as you like, for as long as you like**. I'd love to see a time where FluxEngine is able to both read and write 800k Mac images that are also compatible with the various emulators such as Mini vMac and SheepShaver (both of which I also have setup and available for testing).

*One thing that, right now, is more difficult for me to do is to take an 800k disk image and write it onto a disk. This is because Disk Copy (disk image writing program on older Macs) is very picky about what sort of disk images it handles, usually limiting it to ones it created that have the correct resource fork data (don't get me started). So while I can easily copy files onto 800k disks, making 800k disks on the Macintosh Classic II is difficult right now. Having said that, if that's what you need, then I'll try and work out some way of doing it!

**Subject to the hardware playing nicely! I went through several 800k disks before I found one that formatted successfully, and the Classic II plays up sometimes. But hey, that's part of the fun!

Please add code for displaying

• the number of seconds needed to read all tracks and process the disk
• the sum of the number of retries after bad sectors were found

Also the percentages in the summary should at least have one decimal place.

Thx!

Right now most errors (such as the drive not responding, for whatever reason) aren't handled at all on the board; we just hang until the watchdog timer restarts the board. Which works, but it's very inelegant. This should be better.

Hi David,

After assembling and flashing FluxEngine successfully I wanted to give you some feedback regarding the documentation:

For a start, the documentation you have written is very good and clear!

A few remarks:

• Although optional an FDD cable could be named in your bill of materials.
• FDD cables and their (some of their) existing variants could be illustrated and explained a tiny bit more by using pictures or descriptions or just links to other web pages explaining them. Not all users are older than the hardware they use (I am) so the nature of a floppy cable is not something everybody knows. Although I had my first PC in the 90s I forgot a lot about floppy cables.
• I was missing a section that describes how one can use two or more disk drives on one cable. Either from the cabling point of view or the device numbering when using the CLI tool.
• I was missing a section where the pin assignment between the Cypress pin headers and the backside of the disk drive is illustrated by a picture. This could be useful for users who want to solder their own cable for whatever reasons.
• I found that the additional GND pin connection is absolutely mandatory for my FluxBox to spring into life. If this is technically correct I would recommend that you emphasize that in the text. For me avoiding "different potentials" sounds like "will maybe look into that next week".
• The Assembly Instruction section shows the pins but the Connecting information are on a different page. The connecting page is not reachable via the "next page" link from the building page.

Hi David,

I called FlugEngine with
fluxengine read ibm --retries=10 --revolutions=2 --output="mydisk.d81"

I learned now that obviously I am not free to choose any arbitrary output file name extension. That is ok for me (d81 could be added later at some point).

What I found unusual is that the error message "Error: unrecognised image filename extension" is issued after all tracks of the disk were read. I would prefer to get it in the beginning before reading the tracks on the disk starts.

Cheers,
Henning

I can't read the AppleII disk:
`fe-readapple2.exe -s :t=0-79x2:s=0
66.0: 419 ms in 137984 bytes
63 records, 32 sectors; 4.10us clock;
Failed to read sector 12 (bad checksum);
5 retries remaining
66.0: 419 ms in 137984 bytes
0 [main] fe-readapple2 1380 cygwin_exception::open_stackdumpfile: Dumping stack trace to fe-readapple2.exe.stackdump'

Each time on different track.

Is it USB speed problem?
fe-testbulktransport.exe Transferred 1048576 bytes in 1401 (730 kB/s)
I have trying on Lenovo T480s USB 3.0 port.

Also I have warning: "sta.M0019:Warning-1366: Setup time violation found in a path from clock.."
`

No problem to read this disk with same USB port by KryoFlux :-(

Question for you regarding a Brother 240k disk I've got here. I am able to scrape off a little good information from the disk, but the sector report looks really hairy. Is it possible/likely that this is an example of a misaligned disk that would have required microstepping back in the day, do you think?

H.SS Tracks --->
0. 0 .?XXXXXBXXXB.XXXX..?.XXXXXXXBX..XXXXXXXXXBBXXXX.B?.XXXXXBXXXXXXXX.?.XX.BBBXXX.
0. 1 .?XXXXBXXXXBX?XXXX..XXXXBXXXXX..BXXXXXXXXX?BXXXX.?BBXXXXBXXXXXXXXXXXBXX.BBBXX.
0. 2 .?BXXX?BXXXX.XXXXB..BXXXXXXXBX..XXXX?XBXX.XXXXX.X..XXX?BXXXX?.XXXXB.XXXX.?XXX.
0. 3 .?XXXXXBXXXBXBXXXX...XXXXXXXX.B.XXXXXBXXXXX?XXXX.X.BXXXXXXXXXBXXXXXX.X....XXX.
0. 4 .BXXXXX.XXXB.XXXXB...XXXXXXXBX.XXXXXXX?XX.XXXXXXX.?..XX?XXXXXXBXXX.?XXX..XXXX.
0. 5 .?BXXXXXXXXX.?XXXX.?.XXXXXXXB.B.XXXXXBXXXXBXXXX..X.XXXXXXXXXX?BXX.?.XX.X?.XXX.
0. 6 .?XXXXXXBXXXXBXXXB..BBXXXXXXB..?BXXXXXBXXXXXXXXX..XBXX?XXXXXXXBXXXB?.XX.?.XXX.
0. 7 .?XXXXXXBXXB.XXXXX..BXXXXXXXBX..XXXXXXXXXXXXXXX.XB.XXXXXXBXXXBXX.XX.XX.B..XXX.
0. 8 .XXXXXXXXXXBXXXXXX..XXXXXXXXXXB.BXXXXBXXX?XBXXXB.B.BXXXXXXXXX?BXBXXBXB....XXB.
0. 9 .?XXXXBXXXXB.?XXXB...XXXXXXXBX.BXXXXXXXXX.XXBXX.B..BXXXBXXXXBXXXXXB?XXX...XXX.
0.10 .XXXXX?.XXXBXBXXXB...XXXXXXXB.?.XXXXXBXXXXXXXXXX.X.XXXXXBXXXXXXXBXX.XX.X..XXX.
0.11 .BXXXXXXXXXBXBXXXB..XXXXXXXXXX.BXXXXXXXXX.XBXXXX..B.XXXXXXXXBXXXXXBX..X...XXX.
Good sectors: 195/936 (20%)
Missing sectors: 634/936 (67%)
Bad sectors: 107/936 (11%)
78 tracks, 1 heads, 12 sectors, 256 bytes per sector, 234 kB total

I am unable to build it on windows.
Installed cygwin and the 3 mentioned packages but get an error.

$ make
meson .obj
process_begin: CreateProcess(NULL, python3 C:\cygwin64\bin\meson .obj, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [.obj/build.ninja] Error 2

This is just to document USB-related info to see if there is any patterns to it.

The first machine is a ASRock BeeBox-S 7100U, the machine has 2 x USB 3.1 Gen1 ports on the back, and 1 x USB 3.1 Gen1 port + 1 x USB 3.1 Gen2 (Type C) port on the front. The machine runs Debian 9.8, with kernel

tingo@kg-bsbox:~$ uname -a
Linux kg-bsbox 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux

I haven't tested the USB type C port (yet) as I don't have a cable or adapter for it.
Tested with FluxEngine firmware and client from the 'hd' branch.
No matter which port I plug the FluxEngine into, it attaches to a (logical) usb 2.0 controller inside the machine. Example:

tingo@kg-bsbox:~$ lsusb -d 1209:6e00
Bus 001 Device 044: ID 1209:6e00 InterBiometrics 

tingo@kg-bsbox:~$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/12p, 480M
    |__ Port 1: Dev 44, If 0, Class=Vendor Specific Class, Driver=, 12M
    |__ Port 3: Dev 31, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 32, If 0, Class=Hub, Driver=hub/4p, 12M
            |__ Port 3: Dev 36, If 0, Class=Hub, Driver=hub/4p, 12M
            |__ Port 1: Dev 39, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 40, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 40, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 35, If 0, Class=Hub, Driver=hub/4p, 12M
        |__ Port 4: Dev 33, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 4: Dev 33, If 1, Class=Human Interface Device, Driver=usbhid, 480M
    |__ Port 4: Dev 8, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 4: Dev 8, If 0, Class=Wireless, Driver=btusb, 12M

Bulktransport speeds varies a bit.
FluxEngine connected to the bottom usb port on the back of the machine

tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1191 (859 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1159 (882 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1146 (893 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1174 (871 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1185 (863 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1165 (878 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1156 (885 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1172 (873 kB/s)

FluxEngine connected to the top usb port on the back of the machine

tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1166 (877 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1182 (865 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1173 (872 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1152 (888 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1151 (889 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1185 (864 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1172 (873 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1198 (854 kB/s)

FluxEngine connected to the usb 3.1 Gen1 port on the front of the machine

tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1145 (893 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1145 (894 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1154 (886 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1145 (893 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1142 (896 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1149 (891 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1146 (893 kB/s)
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-testbulktransport
Transferred 1048576 bytes in 1140 (897 kB/s)

but still below the required 942 kB/s required for reading a 5.25 inch, 1232 kB disk

Impact of this issue is unclear, maybe only a display issue (cosmetic).

s=0

In summary chart, dots are in section with head 1, not in section with head 0.

C:\Users\hp\Downloads\fluxengine(1)>fluxengine.exe read ibm -o "test4.d81" --revolutions=3 -s":d=0:t=17,19:s=0"
Reading from: :d=0:s=0:t=17,19
 17.0: 588 ms in 227456 bytes
       60 records, 30 sectors; 1.99us clock (503kHz);
       logical track 17.1; 5120 bytes decoded.
 19.0: 588 ms in 227520 bytes
       60 records, 30 sectors; 1.99us clock (502kHz);
       logical track 19.1; 5120 bytes decoded.
Autodetecting output geometry
H.SS Tracks --->
0. 0 XXXXXXXXXXXXXXXXXXXX
0. 1 XXXXXXXXXXXXXXXXXXXX
0. 2 XXXXXXXXXXXXXXXXXXXX
0. 3 XXXXXXXXXXXXXXXXXXXX
0. 4 XXXXXXXXXXXXXXXXXXXX
0. 5 XXXXXXXXXXXXXXXXXXXX
0. 6 XXXXXXXXXXXXXXXXXXXX
0. 7 XXXXXXXXXXXXXXXXXXXX
0. 8 XXXXXXXXXXXXXXXXXXXX
0. 9 XXXXXXXXXXXXXXXXXXXX
1. 0 XXXXXXXXXXXXXXXXX.X.
1. 1 XXXXXXXXXXXXXXXXX.X.
1. 2 XXXXXXXXXXXXXXXXX.X.
1. 3 XXXXXXXXXXXXXXXXX.X.
1. 4 XXXXXXXXXXXXXXXXX.X.
1. 5 XXXXXXXXXXXXXXXXX.X.
1. 6 XXXXXXXXXXXXXXXXX.X.
1. 7 XXXXXXXXXXXXXXXXX.X.
1. 8 XXXXXXXXXXXXXXXXX.X.
1. 9 XXXXXXXXXXXXXXXXX.X.
Good sectors: 20/400 (5%)
Missing sectors: 380/400 (95%)
Bad sectors: 0/400 (0%)
writing 20 tracks, 2 heads, 10 sectors, 512 bytes per sector, 200 kB total

s=1

Here the head shown is 0.

C:\Users\hp\Downloads\fluxengine(1)>fluxengine.exe read ibm -o "test4.d81" --revolutions=3 -s":d=0:t=17,19:s=1"
Reading from: :d=0:s=1:t=17,19
 17.1: 588 ms in 227584 bytes
       60 records, 30 sectors; 2.00us clock (500kHz);
       logical track 17.0; 5120 bytes decoded.
 19.1: 588 ms in 227584 bytes
       60 records, 30 sectors; 1.99us clock (502kHz);
       logical track 19.0; 5120 bytes decoded.
Autodetecting output geometry
H.SS Tracks --->
0. 0 XXXXXXXXXXXXXXXXX.X.
0. 1 XXXXXXXXXXXXXXXXX.X.
0. 2 XXXXXXXXXXXXXXXXX.X.
0. 3 XXXXXXXXXXXXXXXXX.X.
0. 4 XXXXXXXXXXXXXXXXX.X.
0. 5 XXXXXXXXXXXXXXXXX.X.
0. 6 XXXXXXXXXXXXXXXXX.X.
0. 7 XXXXXXXXXXXXXXXXX.X.
0. 8 XXXXXXXXXXXXXXXXX.X.
0. 9 XXXXXXXXXXXXXXXXX.X.
Good sectors: 20/200 (10%)
Missing sectors: 180/200 (90%)
Bad sectors: 0/200 (0%)
writing 20 tracks, 1 heads, 10 sectors, 512 bytes per sector, 100 kB total

Hi David,

Now this is the kind of issue nobody wants to read on his own project's bugtracker because there's not much more to be done than reading, shrugging and sighing. ;-)

With best intentions I tried to run FluxEngine on my AMD Ryzen box (ASUS Prime X370-PRO, Ryzen 1700, Nvidia GTX 1060). I had issues whenever USB bulk transfer is required. I tried different USB cables and different USB ports.

• fluxengine command displays help normal.
• fluxengine rpm command runs normal.
• fluxengine read ibm results either in "USB underrun" or "Error: bad USB reply"
• fluxengine testbulktransport returns as last line: "Error: data transfer corrupted"

Error messages are copied from Linux on the box, but beware:

On this box I have Ubuntu 18.04 amd64 and I also have Windows 10 64bit. So I was able to test the FluxEngine on both OSses. That's why I think the issue is related to my hardware or my hardware configurations (have to check UEFI settings).

The same FluxEngine works fine on my Lenovo Notebook with Windows 10. On The notebook I get 750 KB/s according to fluxengine testbulktransport.

On the problematic X370 box I only seem to get 600-670KB/s.

I'm not asking for a solution, I just wanted to document that I have a problem here. Maybe in a week's time I will stumble across the solution - then I will document it here.

On Linux the FluxEngine is compiled locally, on Windows I used the latest experimental binary.

Dmesg on Linux shows me:

[    1.420892] usb 3-2: new full-speed USB device number 2 using xhci_hcd
[    1.839696] usb 3-2: New USB device found, idVendor=1209, idProduct=6e00, bcdDevice= 0.01
[    1.839698] usb 3-2: New USB device strings: Mfr=2, Product=1, SerialNumber=128
[    1.839699] usb 3-2: Product: FluxEngine
[    1.839700] usb 3-2: Manufacturer: Cowlark Technologies
[    1.839701] usb 3-2: SerialNumber: xxxxxxxxxxxxxxxxxxxxxx

On Linux, I also tried to update libusb-1.0.0 packages to more recent versions. Syslog and dmesg don't show any obvious thing. All I can see while I'm issueing FluxEngine commands is:

Aug 22 19:19:37 ryzentux upowerd[1386]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.2/0000:03:04.0/0000:07:00.0/usb3/3-2/3-2:1.0
Aug 22 19:19:39 ryzentux upowerd[1386]: unhandled action 'unbind' on /sys/devices/pci0000:00/0000:00:01.3/0000:02:00.2/0000:03:04.0/0000:07:00.0/usb3/3-2/3-2:1.0

But the issue also occurs on Windows 10.

My current ideas are:

• It could be related to USB power management of my system or maybe related to several different USB chips I have on my mainboard.
• Electric problem due to floppy being powered by PSU of the box and also connected to box via USB.

Right now, if you kill the client while the device is doing something, then part of an incoming packet stays in the buffer and both ends get confused as we can't tell where commands start. The current solution is to power cycle the FluxEngine. This needs a cleaner solution.

When building on OSX I get the following error message:

meson.build:183:0: ERROR: File tests/kryoflux.cc does not exist.

If I remove the line from meson.build then everything seems to build. Is the file missing from the tests or is this not needed anymore?

Thanks,

-Pete

Hi David,
I'm trying to program my CY8CKIT-059. I'm running Win10 64bit and have Cygwin installed that a freind help me some time back to install and to run a script file. Thats the extent of my Cygwin/Linux knowledge. I've installed the Cypress software and it appears to see my CY8CKIT-059.
I open your fluxengine-master.zip file and copied/extracted the fluxengine-master folder the folder where I use Cygwin from.
I your Building the Harware instructions you say "When you’re ready, open the FluxEngine.cydsn/FluxEngine.cywrk workspace, pick ‘Program’ from the menu," but there is NO FluxEngine.cywrk file, only FluxEngine.cydwr and FluxEngine.cyprj and a few other files. If I type bash FluxEngine.cyprj all I get is a very long stream of "no such directory". Is bash the right way to start these ? What am I be doing wrong ? Any help appreciated :)
I'm hoping to image a heap of 5.25" and 3.5" Microbee floppies. These are 40 or 80 track CP/M disks and I have imaged some of them successfully with an old PC and Dave Dunfields Imagedisk program.
Thanks, Alan

I pulled the most recent osx branch (and also the master branch) - and now fe-readbrother is giving me floating point errors of some sort:

$ .obj/fe-readbrother -s /tmp/240k/
Reading from: /tmp/240k/:d=0:s=0:t=0-81
  0.0: 1086 ms in 143504 bytes
       0.00 us clock; Floating point exception: 8
$

Doing --just-read is working ok:

$ .obj/fe-readbrother --just-read -s /tmp/240k/
Reading from: /tmp/240k/:d=0:s=0:t=0-81
  0.0: 1086 ms in 143504 bytes
  1.0: 1097 ms in 148946 bytes
...
  80.0: 1139 ms in 99020 bytes
  81.0: 1139 ms in 96609 bytes
--just-read specified, halting now
$

Is it still successful for you? Using code from yesterday, I got actual results.

Hello. I'm trying to build the client under FreeBSD, but the process fails, like this:
'''
tingo@kg-core1$ make
meson .obj
The Meson build system
Version: 0.49.2
Source dir: /zs/tingo/personal/projects/PSoC/fluxengine
Build dir: /zs/tingo/personal/projects/PSoC/fluxengine/.obj
Build type: native build
Project name: fluxclient
Project version: undefined
Native C++ compiler: c++ (clang 6.0.1 "FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/local/bin/pkg-config (1.6.0)
Dependency libusb-1.0 found: YES 1.0.13
Dependency sqlite3 found: YES 3.27.1
Dependency zlib found: YES 1.2.10
Build targets in project: 47
Found ninja-1.8.2 at /usr/local/bin/ninja
ninja: Entering directory `.obj'
[17/129] Compiling C++ object 'fluxreaderlib@sha/lib_fluxreader_sqlitefluxreader.cc.o'.
FAILED: fluxreaderlib@sha/lib_fluxreader_sqlitefluxreader.cc.o
c++ -Ifluxreaderlib@sha -I. -I.. -I../lib -I../dep/fmt -I../lib/stream -Xclang -fcolor-diagnostics -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -g --std=c++14 -fPIC -MD -MQ 'fluxreaderlib@sha/lib_fluxreader_sqlitefluxreader.cc.o' -MF 'fluxreaderlib@sha/lib_fluxreader_sqlitefluxreader.cc.o.d' -o 'fluxreaderlib@sha/lib_fluxreader_sqlitefluxreader.cc.o' -c ../lib/fluxreader/sqlitefluxreader.cc
In file included from ../lib/fluxreader/sqlitefluxreader.cc:3:
../lib/sql.h:4:10: fatal error: 'sqlite3.h' file not found
#include <sqlite3.h>
^~~~~~~~~~~
1 error generated.
[18/129] Compiling C++ object 'fluxreaderlib@sha/lib_fluxreader_hardwarefluxreader.cc.o'.
../lib/fluxreader/hardwarefluxreader.cc:44:14: warning: private field '_revolutions' is not used [-Wunused-private-field]
unsigned _revolutions;
^
1 warning generated.
[22/129] Compiling C++ object 'decoderlib@sha/lib_decoders_decoders.cc.o'.
ninja: build stopped: subcommand failed.
*** Error code 1

Stop.
make: stopped in /zs/tingo/personal/projects/PSoC/fluxengine
'''
in FreeBSD, third-party files end up under /usr/local, so sqlite3.h is /usr/local/include/sqlite3.h
Unfortunately, I'm not familiar enough with meson / ninja to suggest a fix for this.
Details:
'''
tingo@kg-core1$ uname -a
FreeBSD kg-core1.kg4.no 11.2-STABLE FreeBSD 11.2-STABLE #0 r342545: Thu Dec 27 00:29:46 CET 2018 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
'''

The Applesauce project (https://applesaucefdc.com) is a robust system for imaging Apple and Macintosh disks using the original drives. It uses a new format called WOZ for processed Apple II images. It also uses a format called A2R for flux images.

Both formats are specified here:
https://applesaucefdc.com/a2r/
https://applesaucefdc.com/woz/

Additionally, there is a Slack discussion board where the project (and working with Apple II and Macintosh disks and disk images in general) is discussed, which may be joined here: http://apple2.gs:3000

It would be great to support these formats, as they are quickly becoming the go-to for Apple II.

Example images in multiple formats may be found on the Internet Archive:
https://archive.org/details/flux_capacity

I would like to help out with making LIF disk readable/writeable. This would make my old HP logic analyzer project easier as well.

This page has a good breakdown on the disk formatting.

I just have no idea where to go from there on modifying an existing format file. Currently, if I dump an IBM image I can convert it to LIF via lifutils on Linux but I have no way of writing them back to the disk.

I have a set of coco disks... OS9, RSDOS, SSDD and DSDD along with 31/4" disks as well and would like to help...

I only get a green light on the floppy drive, along with "Error: failed to receive command reply: No such device (it may have been disconnected)"
(had to run under sudo aswell, otherwise it just gave me "Error: cannot find the FluxEngine (is it plugged in?)")
...im not even sure if this thing is getting power, as it seems to do the same thing without GND and VCC connected to the power ports... ive tried a not-fpga supply, aswell.
Floppy drive model is Sony MPF920.
Tested in both usb 3 and 2 ports on 2 diffrent computers, respectively running fedora twenty-whatever-is-the-latest and opensuse leap ihavenoideaalsothelatestone.

Edit: i put in a floppy for funsies to see what would happen, i can hear something happening in the floppy drive, thats for sure. (still same error though...)

Any help would be appreciated!

(oh, and as reward... or something... for helping me out, i have a looot of amiga floppies waiting to be dumped, so we could get those tested to see if they actually work. thats the whole goal of me doing this anyway, hehe. i also have some macintosh floppies, dunno if theyre modern ones or not though...)

I’ve found a reference on the Compucolor physical format, which is… very primitive. It’s literally RS232 spewed onto the disk, with no encoding scheme at all, which means that if you write zeros, you get no flux transitions. (At least there’s a start and stop bit.) http://www.compucolor.org/tech.html Other than that it does contain normal sector IDs.

Without the ability to correctly read long sequences with no flux transitions, FluxEngine can’t decode these.

Hi,

If somebody opens an issue regarding a specific disk format, one would think:

1. This person owns the original disk drive (CBM 1581).
2. This person owns genuine media (3.5" disks) that was intended for the disk drive.
3. In the century where this disk drive was released there was a high number of commercial software on the market containing disks for this specific disk drive.

In my case all three assumptions are sadly wrong. But because of a little private project I'm working on I'm trying to learn about and work with disks for 1581. So how can I contribute?

For a start, I used the latest Windows-Build of FluxEngine with a standard 3.5" PC drive to read different disks and I am able to read different formats all right (Amiga DD, IBM HD).

Yesterday I used an old PC from 2002 running Debian 10 i386 with a built-in 3.5" PC drive connected to the mainboard. I took a DD disk and put a d81-Image onto the disk with the goal to create a "genuine" disk which would be readable in a genuine Commodore 1581 disk drive.

I am optimistic that this attempt was successful. At least I was able to create a new d81-image by dd-ing the real disk back onto my Linux HDD. That image then had the same hash (md5sum) as the original image.

My impression is that the disk I created could not at all be read with fluxengine read ibm: I got and endless amount of checksum errors displayed from fluxengine.

I assume there is some difference between standard IBM format and 1581 format. To make it easier to spot that difference I will try to summarize all I know about the format:

To enforce the 1581 format on my Linux OS I used fdutils and had do the following:

mknod /dev/fd0cbm1581 b 2 124
setfdprm /dev/fd0cbm1581 DD DS sect=10 cyl=80 swapsides
floppycontrol /dev/fd0 -A 31,7,8,4,25,28,22,21

Regarding the parameters, please also compare
https://github.com/Distrotech/fdutils/blob/master/src/mediaprm
Quote:

#Commodore 1581 (the 3 1/2 drive of the Commodore 128)
"CBM1581":
DS DD sect=10 cyl=80 ssize=512 fmt_gap=35 gap=12 swapsides

Afterwards I was able to format the DD disk like this:
fdformat /dev/fd0cbm1581

Finally I used dd to put the d81 image on the real disk.

My assumption is that parameters like gap-related stuff or "swapsides" is not yet right when calling "fluxengine read ibm". Or even the sect=10 instead of sect=9.

This is as much info as I can give at the moment. I am happy to add more once I learn more.

I find myself doing my Kryoflux stream reads, and then ctrl-C'ing them because I see it retrying 5 times to read the same file. No sense doing that. So if we find ourselves reading a flux stream off of a disk file, retries should always be 0.

I build the firmware (in debug mode) it programmed without any problems.

When connection the USB-micro side, it's starting to connect and disconnect continuously.

I'm new to this and not sure what else you need. Let me know.

If you still need C64 disks, I can send some to you (from Germany)

Hi!

I'm building the client under OS X El Capitán. I've installed the dependencies but it looks like there's a problem in the code. Here's the error:

../lib/decoders/fluxmapreader.cc:207:32: error: variable length array of non-POD element type 'Fluxmap::Position'

And here is the full output after running make

meson .obj
The Meson build system
Version: 0.50.1
Source dir: /Users/leandrinux/Dev/fluxengine-master
Build dir: /Users/leandrinux/Dev/fluxengine-master/.obj
Build type: native build
Project name: fluxclient
Project version: undefined
Native C compiler: cc (clang 8.0.0 "Apple LLVM version 8.0.0 (clang-800.0.42.1)")
Native C++ compiler: c++ (clang 8.0.0 "Apple LLVM version 8.0.0 (clang-800.0.42.1)")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/local/bin/pkg-config (0.29.2)
Dependency libusb-1.0 found: YES 1.0.22
Dependency sqlite3 found: YES 3.8.10.2
Dependency zlib found: YES 1.2.5
Build targets in project: 56
Found ninja-1.9.0.git.kitware.dyndep-1.jobserver-1 at /usr/local/bin/ninja
ninja: Entering directory `.obj'
[25/154] Compiling C++ object 'fluxsourcelib@sha/lib_fluxsource_hardwarefluxsource.cc.o'.
../lib/fluxsource/hardwarefluxsource.cc:54:14: warning: private field '_revolutions' is not used [-Wunused-private-field]
    unsigned _revolutions;
             ^
1 warning generated.
[30/154] Compiling C++ object 'fluxsourcelib@sha/lib_fluxsource_kryoflux.cc.o'.
../lib/fluxsource/kryoflux.cc:173:24: warning: comparison of unsigned expression >= 0 is always true [-Wtautological-compare]
                if ((b >= 0x00) && (b <= 0x07))
                     ~ ^  ~~~~
1 warning generated.
[38/154] Compiling C++ object 'decoderlib@sha/lib_decoders_fluxmapreader.cc.o'.
FAILED: decoderlib@sha/lib_decoders_fluxmapreader.cc.o 
c++ -Idecoderlib@sha -I. -I.. -I../dep/fmt -I../lib -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -g --std=c++14 -MD -MQ 'decoderlib@sha/lib_decoders_fluxmapreader.cc.o' -MF 'decoderlib@sha/lib_decoders_fluxmapreader.cc.o.d' -o 'decoderlib@sha/lib_decoders_fluxmapreader.cc.o' -c ../lib/decoders/fluxmapreader.cc
../lib/decoders/fluxmapreader.cc:207:32: error: variable length array of non-POD element type 'Fluxmap::Position'
    Fluxmap::Position positions[intervalCount+1];
                               ^
In file included from ../lib/decoders/fluxmapreader.cc:3:
../lib/decoders/fluxmapreader.h:112:20: warning: private field '_fluxmap' is not used [-Wunused-private-field]
    const Fluxmap& _fluxmap;
                   ^
1 warning and 1 error generated.
[40/154] Compiling C++ object 'readerlib@sha/lib_reader.cc.o'.
ninja: build stopped: subcommand failed.
make: *** [all] Error 1

My logic analyser has finally arrived and I've determined that the sampler is, indeed, dropping pulses. Top row is what FluxEngine's sampler is producing, the bottom row is what the logic analyser sees.

This one's from a Mac 800kB disk, but this shows up on the ND 17b disks too (and probably lots more). I have no idea why it's not showing up more. We're reading both HD and DD disks quite happily in other formats.

The instructions seem to suggest that you can power the floppy drive from the PSoC board. Is that really correct? When I do this it doesn't seem like the floppy is really powering on.

Is the other option to provide an external 5V supply and make sure to tie the ground of that supply to the ground of the PSoC?

Thanks,

-Pete

As far as I understand, to use this one, needs firmware that has to be built using a non-free compiler. What would be needed to eliminate this dependency? Support for alternative hardware as in issue #5 ? Anything else? Is there a free alternative for the existing hardware?

Philipp

Now I've started extract files from brother 120k disks.

My goal is to convert the extracted files to Richtext with the correct formatings.

To examine this I write a text on WP-1, save the text on disk - read the disk by fluxEngine into my PC and export the files with the brother120tool.

I find out, the extracted files are cut on false position, because I defined a "Headnote" and a "Footnote" - these blocks are before the maintext...

At the start of .img-file there is the directory. Are the 2 bytes at offset 10 (dec.), 26, 42, .. for the position on disk, where the document starts? Track/sector maybe? How to find out then the offset inside the image?

I have a test setup with a Teac FD-55GFR floppy drive and FluxEngine. This setup reads and decodes IBM formatted DD floppies just fine (all those floppies have a hub ring).
However, decoding of HD formatted floppies fails. Example:
tingo@kg-bsbox:~/personal/projects/psoc/fluxengine/tmp$ ../.obj/fe-readibm -s 525-RPS-dos.flux -o 525-RPS-dos.img
I have also tried the three most likely candidates from --show-clock-histogram but it still fails. I'll send you the flux file.