Sucessfully read ATARI ST DD Disks (720 MBytes, 820 mBytes, 930 MBytes )

[kollokollo]

Just as a feedback: I have rebuilt the project with an Arduino Nano, using the builtin ttyUSB it offers. It worked. I could read complete Tracks information from my old ATARI ST disks. I have written a script (for linux) to extrackt the sectors from the tracks and also to check the integrity of the data (using CRC16 checks). This way, I was able to write Disk.img files which can be simply mounted with the standard Linux command "mount" (using the FAT file system driver). The surprise: I could even produce images from disks with uncommon formats (10, or 11 sectors per track, instead of 9), which I could not even produce in the early days (2002) with a buildin PC floppy drive. Great!

However, I like also to read 1.4MBytes HD disks, since I think the modification to the Arduinos firmware would be minimal.

Take this as an improvement proposal:

1. In the diagnostics code, measure the timings of the read bits to determine if it is a DD or HD disk.
2. Allow a Setting: DD or HD.
3. Apply different timing boundaries cuts/checks for DD and HD disks, and adjust the amount of data per track which need to be read. (80/111 for SD and DD, 40/55 for HD)

That already would be all (for reading). This way, also standard PC-Floppies could be read. And then this would be an universal floppy controller for (nearly) all existing formats.

[hpingel]

Great! Please have a look here too: https://github.com/hpingel/pyAccess1581

Similar spin off of mine.

[hpingel]

For reading disks you can get away without listening to CTS state. For writing disks the 16MHz hardware solution relies on CTS state changes. It is unclear to me if the Nano can do this in software as compared to separate FTDI dongle.

[hpingel]

IMHO it could be potentially possible to read HD disks on the 16 MHz hardware but it would make much more sense to switch over to a faster microcontroller also with more RAM to possibly cache a track.

[kollokollo]

I have already modified the Arduino Firmware and can already read tracks from HD disks. However, the chance of CRC-Errors are quite high, so it takes forever to get a track where all 18 Sectors are OK. But maybe with a bit of tweeking with the timing parameters that could be improved. See my fork of the repository, it is in the "new" branch. I think, the measurement function could automatically detect the disk type, but this is still a TODO....

[kollokollo]

I have not tried writing to disk with the Arduino Nano. Maybe later I give it a try.

[hpingel]

Have you also tried Fluxengine? I recommend Fluxengine without saying it's the only approach one should take. I enjoy playing with both solutions.

I personally find the software of Fluxengine very clever. When developing for the 16Mhz Arduino with Robert's approach I can additionally do a cross-check / debugging with Fluxengine to rule out some problems.

http://cowlark.com/fluxengine/

[hpingel]

I personally started to think it would be much easier to implement stuff on a faster micro controller that might even have the same price as an Arduino Mini Micro Nano. Robert's sketch might still be easy to port.

I don't like the dependency to the CTS pin.

Fluxengine uses this Cypress board with the same Cortex M3 CPU used on the "Bluepill". Then there would be Teensy 3.x (more expensive) options. I am also playing with a Teensy 4.0 from time to time.

[kollokollo]

With the latest release the measurement function 'M' can now automatically detect HD disks.

[hpingel]

I am not familiar with the Atari Sector markers and structure. If it is the same as with IBM/DOS disks A1/FE/FB then this is already implemented in my Python scripts in my repository. In that case it would be fairly simple to add Atari format to my tool if you are interested.

Please See: https://github.com/hpingel/pyAccess1581/blob/master/access1581/diskformats.py

[kollokollo]

The Track format is the same as for IBM/DOS. However, ATARI ST Floppy could be formatted with up to 82 Tracks and up to 11 Sectors per track. Also the boot sector was different by one byte, which caused PC/DOS not to be able to read them, but vice versa it worked (DOS formatted disks could be used by Atari).

Thank you for the link. I did not know about this tool. Now it is too late. i am all fine with my solution.

[hpingel]

I am absolutely happy about any other person who is interested in tinkering and tweaking floppy disk readers like the great one that Robert has come up with. There are not that many people out there digging in old documents that describe the old track/sector secrets.

I am absolutely curious on your changes to the sketch and I will test your changes when I find time. I also had a look at your Basic code - am I right that you have created the BASIC interpreter yourself for this Basic dialect? If you invented your own BASIC language flavour - of course you want to use it when coding tools!

I also have done some tweaks to the sketch which are yet unpublished. But they are more regarding making it run on an Arduino Pro Micro.

If I could interest you in testing my Python code I would be more than happy to create an experimental git branch where reading Atari disks would be enabled. I don't have any Atari hardware or disks so it's hard for me to test it myself.

Currently I am working on writing tracks to disk in Python but the written data on the disk is only "similar" to the original data... Not good enough yet and I don't know if I will get it to work with Python. Reading disks works quite well with Python.

My project is nearly as young as yours. I started in August and spent as much of my spare time as I could dedicate to understand floppy disks and disk drives - it took me months to grasp the basics.

[kollokollo]

I am not expecting anyone using my BASIC code. But thats what I am familiar with (GFA-BASIC / ATARI ST). Basically I am done with the project. I just wanted to read out old ATARi Disks I have recently found. That worked and so I can just publish my changes to the Arduino Firmware and my scripts.

For further improvements: Detecting SD Disks would be also easy. Decoding the Data as FM instead of MFM would also be easy in that case. But I do not have any such disks anymore. The firmware ist really fine and need only consmetic improvements. Wrtiing an operating system driver (e.g. for linux) would be straigt forward, but some effort. But I really liked this low level Hardware ansatz. Do everything in clever Software.

Another thing: To recover damaged Disks: Read the damaged track several times and analyze a statistics on the bit pattern, maybe most of the sectors could be repaired this way, so one can restore the Disk image.

[hpingel]

The statistical recovery concept is already part of Robert's C++ code. I just think the methods are unused.