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

I can confirm that I've never experienced any slowdowns with VMware, even though I use

Usually, VMware is much better than VirtualBox: more solid e more supported.

AROS "native" in VirtualBox is very unstable. When I start the virtual machine after it being suspended I have to immediately restart or it will slow down to the point of being non usable! The mouse pointer gets very jerky and everything freezes till I can force a restart. After a fresh start I only have one chance to do testing. It's stable enough during a single session to get a little work done.

Because VirtualBox is so unstable I prefer to use AROS native x86 that I installed on one my mini PC's. It's very stable and it has no issues. But it has old system files and it won't run software compiled with the new Build System. So I will have to order some ssd's to install a newer AROS.

But I did learn something new. While trying to compile on my mini PC using GCC in the shell (my only option) there were many errors for the FTDI terminal program so I needed a way to send the output of the shell to a text file. Here's what I did...first type sh to convert to unix.

gcc ftdi_reader.c ftdi_reader -o >compile.log 2>&1

If you are interested here are some hardware photos of the DrawBridge Device (FTDI + Arduino).

This version of the PCB fits inside a common USB Floppy Disk Drive.

You purchase the DrawBridge & the USB Floppy Drive separately. Then you have to open the drive case & install the new PCB according to instructions on the device website.

I have a working DrawBridge equipped usb floppy drive if you would like the model number. Not all USB floppy drives will work though.

DrawBridge software can be compiled for Windows or Linux. Maybe in the near future AROS!

The DrawBridge equipped floppy drive can Read Amiga 68k disks to ADF. It can also Write ADF to disk.

For this project I have a good idea about how to move forward. The end goal is to be able to read/write Amiga disks using native AROS software along with DrawBridge. DrawBridge is the Amiga D.isk R.eader A.nd W.riter that acts like a Bridge using an Arduino controller.

Encouraged by the recent success in reading the Product Name using Poseidon Library I'd like to write a small interactive program to send and receive serial data using Poseidon Library API psd_ commands, mostly psdDoPipe.

The interactive shell program will allow me to send single byte commands to the Arduino to test some disk drive diagnostics. I have already done that on Windows 10 using TeraTerm with SerialIO.

These same psd commands are used in Poseidon Classes along with a Serial Bridge that translates SerialIO commands into psd commands. So that is one of my options. Write a Poseidon Class for FT232R to make the Drawbridge device into a serial device using standard AROS SerialIO commands. At the moment there's an error somewhere because it isn't binding.

Another key to the puzzle is to get the Drawbridge software to compile for AROS. Some parts may need to be modified to work correctly.

Lots of work to do!

The attached screenshot shows the Windows version of the command line program DrawBridge in action.