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

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.

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

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

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!

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.

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.

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 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.

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.

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.