If the Paula chip isn't using the Index Pulse that means it will randomly start reading the track and continue for one full rotation of the disk. That's another issue, aligning the sector data. That's more difficult.

I'm hoping that TSGui (track saver) will have more luck reading the disk or I will try the Chinon drive I have.

Well, the Amiga method to get sample mfm data using TSGui is completely unreliable. It failed. So I'll focus on the data read by TeraTerm. Not sure what format the data is in so I will use the unpack function to convert the 2-bit encoded format.

The index pulse was used only on some protected games. Normally it wasn't required.
If you don't see the 4489 sync word then the floppy data wasn't properly read.
But if you want to continue with the index pulse mechanism, then you've to manually check the 4489 sync word multiple times: start without shifting (to the right. Discarding the first bits) the data read, and if you don't find it then you've to shift one, then two times, etc., up to 15 times until you don't find it. If it doesn't work then there are major problems with dumping the floppy's content.

This is the current status of the Serial Disk Reader for AROS.

I was able to use TeraTerm to send the Arduino commands to seek & read track 0, head 0 which resulted in Amiga mfm data. I did the test three times, so I have three samples.

I didn't see the Amiga Sync Markers 0x4489 in the data so I at first thought that TeraTerm had failed. But after researching a bit more I think it succeeded. But the Amiga mfm data is actually 2-bit encoded.

I intend to write a small MfmDecoder test app to see how the data is encoded, then decode it. I'm trying to approach this from two sides. On the Amiga side "rawread" failed to return mfm data. Most likely that's because my Amiga 1200 has a modified Fujitsu floppy drive from Amiga Technologies. Perhaps it doesn't use an Index Pulse which rawread requires. I will try TSGui as well with the Fujitsu drive. I believe I also have a spare Chinon drive that I bought a few years ago. I paid a lot of money for it, so I assume it works.

It may seem that I'm a little bit nerdy when it comes to experimenting with hardware
such as the DrawBridge equipped usb floppy drive, but aren't all programmers and
tinkerers a little bit nerdy!?

I see it as a challenge, and in the case of the DrawBridge hardware & software it's
a huge challenge! It just at the edge of my abilities. That's why it's a challenge. But
I've always been interested in the technology behind spinning magnetic disks. I've
also written my own disk image software called "Disk Image Explorer" using discutils.
It's written entirely in C# which is in some ways very similar to c code but not c++.

My quest to read an Amiga DD Disk using AROS based software using Poseidon
Library continues! I believe I have all the pieces to the puzzle now. I have studied
the hardware & I have examined what software is needed. Here's some of what I
have discovered. Reading the mfm data from the disk using the Arduino seems to
be the relatively easy part! Decoding the mfm data & converting it to binary is the
hard part, but it has been done many times over the years so there are several
examples of how to do that. But the Arduino doesn't send mfm data by serial port.

Nope. I highly suspect that the Arduino which runs at 16Mhz is't quite capable of
sending 12,848 bytes or however much of mfm data across the usb to serial port.
Instead, Rob Smith used what he had. I'm sure he knew about Run Length Encoding.
Instead of straight mfm data it's encoded using the same 2-bit token encoding that
is used to read Amiga HD Disks because there is so much data streaming across the
serial connection, so the mfm data is also encoded to make it much smaller. The
encoded data stream requires a special Unpack function to re-inflate the mfm data.

I recently did an experiment to use TeraTerm to send the Arduino commands to
read a track of Amiga DD mfm data, at least I thought it was actual mfm data. In
the screenshot you can see the results. But the data that TeraTerm saved in the log
file as "binary" wasn't in mfm format. I suspect it is the 2-bit token encoding instead.
At first I thought TeraTerm had failed to receive the data from the Arduino because
I used software to scan the data looking for Amiga Sync Words (0x4489) but it didn't
find the Sync Words indicating the beginning of each of the Amiga sectors in the track.

In order to work on the mfm data I will write a new test program "MfmDecoder" but
I still need some good mfm data that corresponds to the Amiga DD Disk that I'm
using for testing. The disk is from TLAS (Turle Lightning Amiga Software). I bought
a lot of Amiga software from them in the past before they went out of business. I've
discovered a possible solution - I can use "rawread" for Amiga 68k to read an Amiga
DD Disk on my Amiga 1200. But rawread is much like transdisk. It can bypass the
built-in Amiga mfm decoding used with trackdisk.device. Instead it reads the disk
then saves raw mfm data to a file. It can read a single Track (11 sectors) or it can
read the entire Amiga Disk & save all the mfm data to a "binary" file for testing.

This project is going well. I've been doing a lot of research & testing the last couple of weeks. I developed the methods to use Poseidon Library psd commands to send/receive data. Now I'm at the hardware level, studying the ATMega & FT232PL chip specifications to get a better idea of how they process the data.

One key difference is that the FTDI chip operates by USB 2.0 protocol. It has a really small buffer & it transfers 64 byte USB packets at a time, but it attaches 2 status bytes at the beginning of each packet so it only sends 62 actual data bytes. The Windows & Linux FTDI drivers remove the 2 ftdi status bytes from the data packets automatically. But since I'm implementing the driver for AROS I have to account for & remove the 2 ftdi status bytes every time.

I've started writing the read track functions & the code needed to decode & convert Amiga mfm data. I don't intend to re-write all the code needed to read/write Amiga Disks. But rather I want to write enough to show that Poseidon Library can do it & at the same time get a good idea of what the hardware & software is doing. I do intend to attempt to compile the original DrawBridge software and adapt it to AROS. But it's written in C++ which I barely understand. So I have to know what it's trying to do beforehand. :-)

I've learned a lot about the hardware & how data is stored on floppy disks.

I'm going to attempt to compile the c++ DrawBridge application for AROS x86_64 on AROS One.

Since my ftdi_disk_reader successfully setup the Serial Connection Paraters & baud I added that in SerialIO.cpp to use Poseidon.

The results for reading the drive rpm in TeraTerm can be seen in the screenshot.

Notice that I'm using Notepad to write the single byte commands then copy/paste in
the TeraTerm Window. I will explain what each character command does.

After sending each command the Arduino will respond with a ' 1 ' that it received it.
The first command is ' + ' turn on the drive motor and spin the disk (Amiga disk must be inserted in drive).

The first ' 1' means command received - the activity light comes on the DrawBridge Floppy Drive &
the drive starts to spin.

The second command is ' P ' which requests that the Arduino perform the Drive RPM Test while the
disk is spinning. It replies ' 1 ' followed by ' 300.75 ' which is the drive rpm calculation based on the
sync pulses received for about 5 rotations. The Amiga DD Disk spins at about 300 rpm which is
about 5 rps (rotations per second). It takes almost a full second, which is a long time in computer time,
for the results to appear in the TeraTerm Window. After the data is received it's ok to turn of the drive motor.

The last command is ' - ' because gotta turn off the drive motor or it will keep spinning...

The Arduino replied with a ' 1 ' and the disk activity light goes off and the drive spins down to a stop.

That's the sequence to measure the drive rpm using Arduino commands for the DrawBridge Device.

Currently the SerialDiskReader can turn on the drive motor, request the drive rpm & turn off the drive.
It's almost working. It's important to be able for the DiskReader to turn on/off the disk motor. That's
because most of the main functionality such as seeking a track, reading a track, etc require that the
disk is spinning. So, we are almost there!

Here is my current status for this project which has been ongoing since I first
compiled the orginal c++ code for Windows 10 in late 2023 to early 2024.

Although there are probably more powerful serial terrminal applications
available, TeraTerm 5 has proven to be both powerful and easy to use. I
use it for testing and verification of the Arduino commands and I can see
the response strings the Arduino sends back across the serial COM port.

So far I setup the serial connection parameters including 2000000 baud
(2 Mega Baud which is outrageously fast!). I used Poseidon Library psd
commands same as the psd commands in the USB-to-Serial classes in
Poseidon already, to get the psd device based on Vendor ProductID &
VendorID. Based on the device I setup the Serial Write_Pipe/Read_Pipe.
The Pipe structures are needed to send and receive the Serial Data.

The first thing the SerialDiskReader has to do is attempt to sync and
request the firmware version number from the Arduino. That's because
some advanced features are only available for version 1.9 and above.
That first task has been completed. The version of my ATmega328P is
"V1,91" which I suppose is the same as "V1.91" outside of Europe.

The second task was to test the disk drive hardware by turning on the
drive motor and spinning up the disk. Then measure drive rpm which
is an advanced feature available for the Arduino V1.9 and above.

I wrote a few small functions to accomplish this. I was pleasantly
surprised to see the drive activity light come on as the drive began
to spin the disk. Hower, although I did the same test on TeraTerm,
I forgot that I need to wait a whole second before receiving the
serial data for the drive rpm from the Arduino. It needs time to
allow the disk to spin about 5 rotations to get the sync pulses to
calculate an average rotations per minute based on that data.

After turning on the drive motor I tried to read the rpm data
immediately, no wonder my program returned zero bytes for
the rpm data. I thought it had failed and the program froze
so I ended the program and started it again in the shell. But
to my surprise instead of printing the Version String which I
expected it instead printed what looked like the rpm string.

Obviously, I didn't wait a full second to receive the data so
that was my mistake, easy to fix. Second, it did actually do
the rpm test and send the data to the serial port but later.
Although I had ended my shell program the Arduino had
received it's command and it was dutifully doing its thing!
The DrawBridge Device was still connected to my PC and
when the rpm data was ready the Arduino sent it to the
serial port. But by that time I had closed my program &
restarted it. When my program tried to read the Version
it got the rpm data instead that was waiting to be read.

I learned a few takeaways from that exchange...wait for
the data to be available at the serial port and maybe put
a timeout to test the port for data and be prepared to
read small packets (1024 bytes) at a time & assemble
them into a complete buffer at the end. These things
are needed to receive high-speed mfm data across
the serial port connection. That's the next step. I have
no doubt the transaction of receiving the mfm data
from reading an Amiga Track, (track0, head0) will be
successful. Keeping that in mind I'm jumping ahead
to start processing & coverting the mfm data to the
standard binary to write to a binary file. I'll use my
trusted TeraTerm for that, hopefully. Looking at the
data in HxD Hex Editor I should see the Amiga Sync
Markers for the beginning of each Amiga Secotor.

I know this has all been done before! Yes, I am going
to re-invent the wheel by writing my own DiskReader!
Rob Smith invented the DrawBridge hardware & it is
working great! I'm writing AROS software to use it to
read Amiga Disks. When I hopefully reach that goal
then AROS will have surely come a long way from its
roots in the Amiga 68k days till the present. It will be
a first for AROS to be able to finally read Amiga Disks!

I hope it all works as expected. :-)

Here are some words of encouragement from Rob Smith from his blog about DrawBridge.

"When I started this project I hadn’t got a clue how the floppy drive worked,
and even less how the data was encoded onto them."

https://amiga.rob...uk/history

Well, I don't have time to figure out how to do a blog or article so here is my article...

Last night I was working on the Disk Reader. I was attempting to get the drive rpm data. My first few attempts failed. But I know why. I'll get it working this weekend.

I'm already working on the next phase of the project & that is decoding an Amiga track full of mfm data, converting it to binary to write to disk. Reading the mfm data will come later. But first I want to write my functions to process the data.

Apparently I can use TeraTerm to send Arduino commands to the DrawBridge Device for it to read the current track & send the mfm data. TeraTerm will collect the mfm data & save it a file as Hexadecimal data. So I can use the raw mfm data to test decoding functions on AROS.

Also, I wrote an article about the SerialDiskReader. I'll post it later.

I'm not a spokesman for this product. But the price of the DrawBridge USB Floppy PCB with a new USB cable is only 25 Euros. Rob Smith makes these by hand.

https://amiga.rob...uk/waiting

The SerialDiskReader is not just a fancy way of getting a version string.

It's a framework for writing & reading data for interaction with a DrawBridge Device ( USB Floppy).

It's a Basic Device Driver. I can tell the Arduino to do what I want it to do. The next part of the program is to do an RPM Test.

To do the test the device must be connected and an Amiga Disk is inserted. I send a '+' command to Start Drive Motor & Spin the Disk. Then 'p' to request RPM Test. Then wait for the result. It should be 10 bytes in length & it should look like this: oo1300.19). The first 2 bytes are FTDI control bytes to be removed. The 1300.19 is the response. The '1' indicates the command was received. 300.19 is the disk speed measured in rpm's.

I've already done the test in TeraTerm. So I'm sure it works! :-)

Here is the source code that I used to establish contact with the Arduino Controller. It uses psd commands.

The purpose of this test program to provide proof of concept that it is possible to use Poseidon to read an Amiga Floppy Disk.

After a track has been successfully read and stored in a binary file that part is complete. Then I can go back and complete the serialft232r.class by adding the psd commands to add a serial bridge make it a serial connection. That how classes are.

Success! I established contact with the Arduino Controller (aka DrawBridge) using Poseidon Library.

I used psd comnands to get the device based on Product ID & VendorID. Then I used FTDI commands to set baud & flow control plus 8-in-1 required by DrawBridge communication.

Once the Ep_In & Ep_Out pipes were established I could write data to the port. I sent the 'xR?' command which requests the firmware version.

In the screenshot you see it returned 9 bytes. The first two bytes are FTDI control bytes that should be removed from any data returned. The actual version is "1V1,9". Not sure what the last 2 bytes are, but maybe they are feature flags that are part of the version string. But if you look at the TeraTerm image you can see the same version string. The 1 at the beginning means the Arduino received the command. The string is 1V1,9 just like the AROS screenshot.

Now that we've setup the Poseidon psd pipes & made contact by sending & receiving data, the fun begins. Let's read a track of an Amiga Disk receiving the mfm data that we convert to binary to save to a file on the local hard disk.

P.S. - I've solved the mystery of the version string. The actual version is V1.91 but the Windows command line DrawBridge app is 2.8.25 so it appends it to be V1.9.25 which makes since for compatibility. The last byte " ) " seems to be a serial carriage return " r " that's added.

Over the weekend I spent some time with TeraTerm in Windows 10 & Python 3 script in Linux. I was testing the USBtoSerial connection with the DrawBridge Equipped Floppy Drive. Windows saw it as COM4. Linux saw it as ttyUSB0. ;-)

It amazes me that Rob Smith figured this all out just a few years ago! He used an arduino controller to read the flux data from an Amiga disk.

I'm just walking in his footsteps, trying to piece together how he did all that, one step at a time. :-)

Some day AROS will be able to read and write Amiga Floppy Disks!

What should we name the new serial disk reader? Maybe something easy, QuickDraw (Disk Reader And Writer).

Amazing work @miker1264

Here is the other sources but I don't know how to compile them.

Mostly I'm having a problem with the mmakefile.src. It doesn't seem to be correct.

There are only three main files in the library.

Anyone with more programming experience than me, please help.
I need to compile ftdi library for aros x86-64.

The archive libftdi-master.zip is the Linux sources.
The archive libftdi-0.20_master.zip is the axfgroup libftdi sources.

I've never compiled an aros library before.

After doing some research for this project I don't believe a Poseidon Class is needed.

If we can simply compile the Linux sources for libftdi we already have libusb for AROS.

Using libftdi which relies on libusb & Poseidon it is then possible to read the raw mfm data directly from each track using ftdi commands & the needed Arduino commands.

Decode the mfm data into binary data then write to file.

One step at a time. :-)