Arduino-gebaseerde Amiga-floppylezer en -schrijver – Versie 2.2

Onderdelen en benodigdheden

Apps en online diensten

• Arduino IDE

Over dit project

Dit project voortbouwt op mijn eerdere schijflezer-project op create.arduino.cc.

Meer informatie: https://amiga.robsmithdev.co.uk

• Doel: Een eenvoudige, goedkope en open-source manier om data van en naar Amiga DD-floppies te lezen en te schrijven vanuit Windows 10.
• Oplossing: Een Arduino-sketch + een Windows-applicatie (porteerbaar naar andere OS's) die daadwerkelijk werkt!
• Waarom: Om data van deze schijven te bewaren voor de toekomst. Een gewone PC kan Amiga-schijven niet lezen/schrijven door de unieke schrijfwijze.

Data schrijven - Poging 1

Na het succesvol lezen van schijven wilde ik ze ook terug kunnen schrijven. Ik begon met de software: ADF-schijfbestanden omzetten naar MFM-data voor de interface. Ik voegde klassen toe om een ADF-schijf te lezen en alle sectoren als één track te coderen. Terwijl ik hier aan werkte, probeerde ik te achterhalen wat er mis was met mijn Amiga – immers, zonder echte hardware kon ik geen geschreven schijven testen.

Mijn A500+ had het klassieke probleem: de klokbatterij was uitgelekt. Ik verwijderde deze, schoonde het moederbord en de floppystation. Ik probeerde Retr0brite tegen vergelen. Na het herstellen van losse soldeerverbindingen bij de voedingsconnector was de Amiga weer operationeel.

Tijdens het programmeren ontdekte ik dat de /WRITE_GATE-pin LAAG getrokken moest worden voor het opstarten van de drive om schrijven in te schakelen. Pas dan was de write-protect-status leesbaar. Ook bleef de drive aan zolang /WRITE_GATE laag was.

Een Amiga-schrijft een hele track in één keer: 11×512 bytes (5638 bytes), na MFM-codering en AmigaDOS-formattering 14848 bytes. Dat past niet in de 2KB RAM of 1KB EEPROM van de Arduino. Ik probeerde byte-per-byte te sturen met een high-priority thread en 2M baud, maar de OS-latency maakte het onbetrouwbaar – data ging verloren.

Data schrijven - Poging 2

Software-stroomcontrole was te traag. Ik onderzocht hardware-stroomcontrole via de CTS/DTR-pinnen op de FTDI-breakout. De CTS-pin kon door de Arduino worden gestuurd en door de PC gebruikt voor flow control. Ik zette CTS op '1' (geen data) en '0' (data gewenst), zonder circulair buffer.

De PC kon nu bulk-bytes sturen, maar bytes gingen nog steeds verloren tijdens het schrijven. Waarschijnlijk stopt het veranderen van CTS de datastroom niet direct – de volgende byte was al onderweg.

Data schrijven - Poging 3

Ik wilde geen seriële interrupt (timingverstoring). Tussen het schrijven van bits zat er CPU-tijd in de wachlus. Ik controleerde tussen elk bit of er een extra byte was binnengekomen na CTS-high en bewaarde deze. Theorie: toen CTS omhoog ging, was de PC al bezig met de volgende byte – die kon niet gestopt worden. Ik hoefde dus maar één extra byte te bufferen.

Dit werkte: de Arduino schreef zonder dataverlies. Maar had het daadwerkelijk data geschreven? En was het geldig? Ik codeerde alle 80 tracks, maar de kop bewoog niet. Oplossing: /WRITE_GATE eerst HIGH trekken voor kopbeweging – logisch om per ongeluk schrijven te voorkomen.

Ik schreef een schijfbeeld en las het terug: niets gedetecteerd. De gegenereerde MFM-data was correct (gevalideerd met mijn decoder), dus het schrijfproces zelf was fout.

Data schrijven - Poging 4

Geen data leesbaar. Ik twijfelde over de /WRITE_DATA-pin: pulseren, togglen of raw waarde? Mijn implementatie pulseerde. Ik kon geen info vinden over de fysieke manipulatie. De read-head geeft een puls bij elke flux-reversaal. Ik probeerde: pin op bitwaarde zetten → niet werken. Togglen → niet werken.

Met een oscilloscoop testte ik het patroon 0xAA (binair 10101010) → perfecte blokgolf verwacht. Timing was perfect, maar elke ~12 bits zag ik een onverwachte "high"-periode. 12 bits is vreemd (8 bits per byte). Flow-control probleem? Mijnlus wachtte op bytes; toen CTS laag ging, was de volgende byte al onderweg.

Oplossing: na gebruik van de tweede byte, CTS kort laag en weer hoog trekken. Nu was de volgende byte al binnen bij de volgende lus. Resultaat: perfecte blokgolf.

Ik schreef een paar tracks en las terug. Data verscheen maar alleen op één kant van de schijf. Waarom? Ik realiseerde me dat /WRITE_GATE misschien de wis-kop activeerde. Als die laag blijft tijdens het draaien, wis je de schijf. Ik beperkte /WRITE_GATE tot alleen tijdens de daadwerkelijke schrijflus. Nu werkte het op beide kanten!

Echte ADF-image geschreven en teruggelezen: het werkte! Maar lezen duurde lang – geen MFM-fouten, maar sectoren werden moeizaam gevonden. Werkte het in een echte Amiga? Ik startte mijn gerepareerde A500+ en steek de schijf erin: opstarten → checksum-fout. Er werd iets geldigs geschreven, maar niet consistent.

Data lezen (opnieuw)

Ik was ontevreden over leeskwaliteit. De huidige methode was niet flexibel genoeg voor tijdsvariaties in pulsen. Nieuwe aanpak:

1. Synchroniseren op /INDEX-puls (handig voor testen).
2. In plaats van mijn oude methode: teller vrijlaten lopen (0-255), wachten op puls, tijd meten. Ideaal minimum: 32 (2 µs), maximum: 128 (drie nullen op rij in MFM). Max 4 combinaties.
3. Gemetene frequenties lieten pieken zien bij tellerwaarden ~52, 89, 120 (drive-specifiek). Formule: value = (COUNTER - 16) / 32, afgekapt 0-3. Elke 4 waarden = 1 byte.
4. MFM heeft nooit twee '1'en achter elkaar. Eerste waarde '0' → ongeldig, behandel als '01'. Decodering: 01→'01', 10→'001', 11→'0001'.

Resultaat: 100% succesvol op meerdere schijven. Zeer betrouwbare lezer. Minder retries, geen fase-analyse meer nodig. Statistische herstel was weinig effectief – slechte data was onherkenbaar.

Data schrijven - Poging 5

Nu kon ik geschreven data met hoge nauwkeurigheid verifiëren. Analyse van fouten: bits verschuifden soms. Oorzaak: seriële poortafhandeling en timeraanpak. Ik wachtte op timerwaarde 32, schreef bit, reset timer. Nieuwe methode: eerste bit bij 16, volgende bij 48 (16+32), 80 (16+32+32), etc. Timer2 (8-bit) loopt na 8 bits precies over → exact 500 kbps.

Seriële leescode geoptimaliseerd voor minimale cyclus. Windows-code uitgebreid met verificatie. Resultaat: ~95% tracks direct geverifieerd, rest 1x herschrijven. Schijf in Amiga: werkte perfect!

Data schrijven - Poging 6

Gebruikers rapporteerden nog steeds checksum-fouten in Amiga's, hoewel mijn software ze perfect las. Timing-probleem? Interrupt-gedreven schrijven onmogelijk (te weinig tijd). Ik keek naar de schrijflus: na een volle byte kon de code lussen naar de volgende byte voor dat de timer op 0 was overgelopen → eerste bit te vroeg. Kleine lus toegevoegd om dit te voorkomen.

Data schrijven - Poging 7

Veel rapporten over checksum-fouten. Ik dacht aan MFM-analyse, maar probleem was simpeler. XCopy Pro gaf foutcodes 4 en 6 (sector-headers en data). Niet alleen data-area. Ik keek naar padding rond tracks: post-track padding van 256 bytes naar 8 bytes verminderd → verificatie gaf massaal fouten. Dus: te weinig data geschreven.

Oplossing: Track Erase-commando toegevoegd aan Arduino: schrijf 0xAA-patroon over hele track, daarna mijn data. XCopy gaf 100% OK. Hopelijk dit probleem opgelost.

Diagnostiek

Veel feedback van gebruikers (werkend en niet werkend). Ingebouwde diagnostiekmodule met extra Arduino-commando's en testreeks om bedrading te valideren.

Wat komt er?

• Project is gratis en open-source onder GNU GPL v3. Geen commercieel misbruik – ik geef terug aan het beste platform waar ik ooit op werkte. Hoop dat anderen het verder ontwikkelen en delen.
• Huidige schrijfoplossing werkt niet op Arduino UNO zonder aparte FTDI/serial breakout. Volgende stap: werkend maken op UNO (mogelijk met 23K256 IC als track-buffer).
• Andere formaten: ADF werkt alleen voor AmigaDOS. Veel titels hebben custom copy protection / non-standaard sectoren. Ik heb nuttige info ontvangen, maar weinig testschijven.
• FDI-formaat (universeel, goed gedocumenteerd) probeert trackdata zo dicht mogelijk bij origineel op te slaan – lost bovenstaande issues op.
• Software Preservation Society / CAPS / IPF: gesloten, voelt als verkoop van hardware. Ik focus op FDI. Zorg: geen checksums voor validatie, maar ik heb ideeën.

Code

Arduino Sketch en Windows-applicatie broncode

https://github.com/RobSmithDev/ArduinoFloppyDiskReader

Schema's

Schakeling voor Arduino Pro Mini

Schakeling voor Arduino UNO