Arduino Amiga Floppy Disk Reader/Writer (V2.2)

Over dit project

Dit project zet het werk voort van mijn vorige schijflezerproject op https://create.arduino.cc/projecthub/projects/485582/

Ga voor meer informatie naar http://amiga.robsmithdev.co.uk

• Mijn doel: Om een ​​eenvoudige, goedkope en open source manier te creëren om gegevens van en naar Amiga DD diskettes te herstellen en te herschrijven vanuit Windows 10.

• Mijn oplossing: Een Arduino-schets + een Windows-toepassing (die kan worden overgezet naar andere O/S ) dat echt werkt!

• Waarom: Om gegevens van deze schijven voor de toekomst te bewaren. Ook kan een normale pc geen Amiga-schijven lezen/schrijven vanwege de manier waarop ze zijn geschreven.

Gegevens schrijven - Poging 1

Dus nadat ik met succes schijven had kunnen lezen, dacht ik dat als je het originele fysieke medium wilt behouden, je de schijven misschien weer terug wilt schrijven. Ik dacht dat ik dit in omgekeerde volgorde zou uitwerken, te beginnen met de software (d.w.z.:de ADF-schijfbestanden converteren naar MFM-gegevens voor de interface om op de een of andere manier te schrijven ).

Dus begon ik met het toevoegen van klassen om een ​​ADF-schijf te lezen en alle sectoren als één track te coderen. Wetende dat ik de gegevens die ik heb gemaakt mogelijk zou kunnen testen door ze terug te voeren in het decoderingsgedeelte, begon ik hieraan te werken. Terwijl ik hieraan werkte, besloot ik te proberen uit te zoeken wat er mis was met mijn Amiga. Ik kan tenslotte geen schijven testen die ik maak als ik niets echt heb om ze op te testen.

Toen ik mijn A500+ uit elkaar haalde, merkte ik dat hij een van de meest voorkomende problemen had gehad, de klokbatterij was overal gelekt. Dus ik desolde dit van het bord en begon het bord op te ruimen. Terwijl ik bezig was, trok ik de hele machine eruit en begon ik 20 jaar stof en vuil op te ruimen. Ik heb zelfs de diskettedrive uit elkaar gehaald om hem schoon te maken.

Tijdens het schoonmaken besloot ik dat het tijd was om van de vergeling af te komen, dus ik volgde de informatie over Retr0brite en probeerde het.

Ik controleerde toen alle verbindingen op het moederbord en vond een losse verbinding bij de stroomconnector, een paar aanpassingen met de soldeerbout en zo goed als nieuw. Ik wachtte tot ik tevreden was met het Retr0brite-proces voordat ik de computer weer in elkaar zette.

Ondertussen werkte ik verder aan de code voor het schrijven van schijven. Ik wilde de status van de schrijfbeveiligingslijn lezen, maar wat ik ook instelde, het leek de spanning niet te veranderen. Dus ik trok de schijf uit elkaar en volgde de sporen van de kleine schakelaars die de schrijfbeveiligingsstatus detecteren naar een klein IC. Op dit punt vermoedde ik dat de uitvoer waarschijnlijk alleen beschikbaar is als je daadwerkelijk gegevens wilt schrijven.

Na veel van experimenteren, ontdekte ik dat je de /WRITE_GATE pin LOW voordat u de schijf laat draaien om schrijven mogelijk te maken. Op dit punt zou u de schrijfbeveiligingsstatus kunnen verkrijgen. Ik merkte ook dat terwijl de /WRITE_GATE laag was, schakelde de drive niet meer uit zoals vroeger totdat die pin was teruggekeerd naar de standaard HIGH-status.

De Amiga zou in één keer een heel nummer schrijven. Een track in het geheugen is 11*512 bytes (5638 bytes), maar na MFM-codering en het correct invoeren van het AmigaDOS-formaat, komt de track uit op 14848 bytes. Nou, er is geen manier die past in de Arduino's 2k geheugen, noch de 1k EEPROM. Ik had een alternatieve methode nodig.

Ik besloot dat ik zou proberen de gegevens 1 byte per keer in een thread met hoge prioriteit te verzenden en te wachten op een antwoordbyte van de Arduino voordat ik de volgende verzend. Ik heb de baudrate gewijzigd in 2M om de vertraging tussen tekens te verminderen. Dit betekende dat het ongeveer 5,5 uSec kostte om elk personage te verzenden en 5,5 uSec om er een terug te ontvangen. De Arduino zou 8 bits moeten uitschrijven op 500 kHz, dus elke 16 uSec zou een nieuwe byte nodig hebben. Er zou dus tijd moeten zijn, ervan uitgaande dat de codelus strak genoeg is en het besturingssysteem het verzenden en ontvangen niet te veel vertraagt.

Dit was een complete, volslagen mislukking. De hele lees-/schrijfcyclus duurde veel te lang, veel meer dan één omwenteling van de schijf. De Arduino-kant was waarschijnlijk snel genoeg, maar het besturingssysteem reageerde niet genoeg. Het lezen van schijven werkt omdat het besturingssysteem (Windows in mijn geval) de binnenkomende gegevens zou bufferen, maar bij schrijven zou Windows alles in één keer verzenden, maar omdat de snelheid waarmee ik verzend veel sneller is dan de Arduino het nodig heeft, gegevens zouden verloren gaan. Dit was de reden waarom ik heb gekozen voor dit wederzijdse erkenningsproces.

Gegevens schrijven - Poging 2

Software flow control voor deze applicatie was gewoon niet snel genoeg. Ik besloot om hardware flow control te onderzoeken. Ik heb gemerkt dat er op het FTDI-breakoutboard een CTS- en DTR-pin is. Deze staan ​​voor Clear To Send en Gereed voor dataterminal . Ik merkte dat terwijl het breakout-bord was aangesloten, het Arduino-bord de CTS met GND verbond.

Ik wist ook niet in welke richting deze pinnen waren, maar na wat experimenteren ontdekte ik dat de CTS-pin kon worden gesignaleerd door de Arduino en door de pc kon worden gebruikt om de stroom te regelen. Normaal gesproken wordt dit gedaan met behulp van een circulaire buffer, maar in mijn geval kon ik dit niet toestaan, dus ik zette het gewoon op '1' als ik geen gegevens wil, en '0' terwijl ik dat wel wil.

Dit betekende nu dat ik het besturingssysteem kon vragen om de bytes in bulk te verzenden als één stuk, en te hopen dat het allemaal op kernelniveau werd afgehandeld, zodat het niet zou worden onderbroken.

Ik had een binnenlus die elk bit van de 8 bits uitvoerde, maar besloot dat het waarschijnlijk beter was qua timing om het in plaats daarvan in 8 sets opdrachten te ontrafelen.

Dit werkte niet. Als ik de code liet lopen zonder het schijfschrijfgedeelte daadwerkelijk uit te voeren, dan werden alle bytes correct ontvangen, maar bij het uitvoeren van de code gebeurde dit niet en gingen de ontvangen bytes verloren.

Ik vermoedde dat het veranderen van de status van de CTX-lijn de gegevensstroom niet onmiddellijk stopte en dat de computer nog steeds een of twee tekens zou kunnen verzenden. Mogelijk was tegen de tijd dat ik de CTX-regel had gesignaleerd, deze al bezig met het verzenden van het volgende teken.

Gegevens schrijven - Poging 3

Ik wilde geen seriële onderbreking hebben, omdat ik niet wilde dat de schrijftijden vervormd zouden worden. Ik realiseerde me dat tussen het schrijven van elk bit naar de diskettedrive een aantal CPU-cycli in de volgende while-lus zouden zitten. Ik besloot om tussen elke bit-write te controleren of er nog een byte was ontvangen sinds CTX hoog was en deze op te slaan.

Mijn theorie was dat toen je CTX verhoogde, de computer waarschijnlijk al bezig was met het verzenden van de volgende byte en omdat je hem niet halverwege de stream kunt stoppen, zou het de helft na deze zijn. Dit betekent dat ik tijdens de lus slechts één extra byte hoef te controleren en deze te gebruiken als deze wordt gevonden in plaats van opnieuw naar de seriële poort te kijken.

Dus dit leek te werken en de Arduino voltooide het schrijven zonder gegevens van de computer te verliezen. De enige vragen waren nu:heeft het daadwerkelijk gegevens geschreven, en zo ja, is deze geldig?

Op dat moment had ik nog maar één track gecodeerd, dus besloot ik het hele algoritme uit te voeren om alle 80 tracks te coderen. Er gebeurde iets vreemds. De aandrijfkop bewoog helemaal niet. Bij het lezen deed hij dat nog wel, maar niet bij het schrijven.

Ik ontdekte dat om de aandrijfkop heen en weer te bewegen, je eerst de /WRITE GATE-pin moest optillen, ik vermoedde dat dit ook nodig was om het oppervlak te veranderen. Nadat ik code had toegevoegd om dit te doen, bewoog de schijfkop zoals verwacht. Dit was logisch en zou voorkomen dat er per ongeluk nummers worden geschreven terwijl het hoofd wordt verplaatst.

Dus op dit punt schreef ik een schijfkopie die ik eerder had gemaakt en probeerde deze vervolgens terug te lezen. Er was niets te ontdekken! Ofwel de gegevens die ik had geschreven waren ongeldig, of de manier waarop ik ze schreef was verkeerd.

Ik besloot de gecodeerde MFM-sectorgegevens die ik aan het maken was, in te voeren in mijn sectordecoderingsalgoritme dat door de lezer werd gebruikt om te valideren dat wat ik aan het genereren was correct en geldig was, en dat was het ook. Er was duidelijk iets mis met de manier waarop ik de gegevens naar de schijf aan het schrijven was.

Gegevens schrijven - Poging 4

Omdat er geen gegevens correct werden gelezen, besloot ik een paar verschillende benaderingen te proberen. Ik wist niet zeker of de /WRITE DATA-pin moet worden gepulseerd (en zo ja, hoe lang), moet worden omgeschakeld of gewoon moet worden ingesteld op de waarde voor onbewerkte gegevens. Mijn huidige implementatie pulseerde de pin. Ik had online geen informatie kunnen vinden over hoe de schrijfpin fysiek zou worden gemanipuleerd tijdens het schrijven.

De leeskop zou ons een puls sturen elke keer dat er een fluxomkering is. Ik besloot de implementatie te wijzigen, zodat WRITE DATA gewoon was ingesteld op de waarde van het bit. Dat werkte ook niet. Dus ik heb de code gewijzigd om de huidige status van de pin te wijzigen. Nog steeds geen geluk.

Het is duidelijk dat een van deze benaderingen de juiste moet zijn geweest. Dus besloot ik de vertrouwde oscilloscoop weer tevoorschijn te halen om te kijken wat er aan de hand was. Ik besloot om het MFM-patroon 0xAA continu naar elke byte op een track te schrijven. 0xAA in binair is B10010010, dus dit zou me een perfecte blokgolf geven die ik zou kunnen controleren op de vereiste frequentie.

Als het geen perfecte blokgolf op de gewenste frequentie zag, dan wist ik dat er een soort timingprobleem moest zijn.

Ik heb de scoop aangesloten, maar was verrast om te zien dat de timings waren perfect. Omdat ik een oude scoop was, kon ik echter niet meer dan een paar pulsen zien. De scope had deze prachtige x10 "mag"-modus. Als je erop drukt, wordt de tijdbasis met 10 vergroot, maar wat nog belangrijker is, is dat je door alle gegevens kunt scrollen, net zoals op een moderne digitale scoop.

Hier klopte iets niet. Het leek erop dat ik om de 12 bits een periode kreeg van slechts "hoog" .

Ofwel waren de gegevens die ik aan het verzenden was op de een of andere manier ongeldig, of er was iets dat elke 12 bits een pauze in het schrijfproces veroorzaakte. 12 is een vreemd getal aangezien er maar 8 bits in een byte zitten.

Nadat ik hierover had nagedacht, vroeg ik me af of ik terug was met een probleem met de stroomregeling. De manier waarop ik de lus had ontworpen, was om eventuele verdwaalde extra bytes op te scheppen die werden ontvangen nadat we erop hadden gewacht. Maar het was niet intelligent genoeg om het wachten om de andere byte te voorkomen. Ik had twee keuzes, verplaats iets in een interrupt, of patch de lus.

Ik besloot eerst de manier waarop de lus werkte te corrigeren. Het probleem was het gevolg van een vertraging veroorzaakt door het wachten op de volgende byte van de computer. Als we CTX verlaagden en op een byte wachtten, was er tegen de tijd dat we CTX weer verhoogden, al een andere byte onderweg.

Ik verander de lus zodat wanneer de tweede ontvangen byte was gebruikt, de Arduino de CTS even laag en dan weer hoog trok om een ​​ander karakter te laten verzenden. Dit betekende dat we bij de volgende lus de volgende byte al zouden hebben ontvangen, dus wachten was niet nodig.

Het testen hiervan leverde een perfecte blokgolf op:

Dit betekende dat alle timing voor het schrijven van een nummer perfect was, het kwam gewoon neer op de werkelijke gegevens die werden geschreven. Ik besloot dit een paar tracks en kanten te laten lopen, en het dan terug te lezen om te zien of het correct was geschreven. Ik was de /WRITE_DATA-pin aan het instellen op de overeenkomstige bitwaarde van de ontvangen gegevens.

Bij het teruglezen van de gegevens leek het alsof er niets gecodeerd was, maar toen sprong ik naar de andere kant van de schijf. En ja hoor, daar was mijn patroon. Ik wist niet waarom het maar naar één kant van de schijf was geschreven.

Na enig nadenken begon ik me af te vragen of de /WRITE GATE-pin niet echt werkte zoals ik dacht dat het deed. Het kwam voor dat door de pin laag te trekken, de wiskop op de schijf mogelijk wordt geactiveerd. Als dit het geval was, zou ik dit alleen moeten doen als ik aan het schrijven was, anders krijg ik misschien ruis op de schijf terwijl deze draait en wordt gewist.

Ik heb alle code zo veranderd dat de /WRITE GATE alleen werd gebruikt bij het starten van de drive, en later alleen letterlijk tijdens de schrijflus. Dat werkte! Ik was nu gegevens aan het schrijven naar beide kanten van de schijf!

Dus ik probeerde het opnieuw met een echte ADF-schijfkopie en liet het voltooien. Ik heb toen het lezersgedeelte gebruikt om te zien of ik het terug kon lezen. Het werkte! Maar om de een of andere reden kostte het nogal wat tijd om deze schijf terug te lezen. Ik kreeg geen MFM-fouten, maar ik had moeite om alle sectoren te vinden.

Ik had nu twee mogelijkheden om naar te kijken:ten eerste, als de gegevens daadwerkelijk op tijd genoeg waren geschreven; en ten tweede, zou de schijf echt werken in een echte Amiga?

Te opgewonden met het idee dat ik misschien een schijf had geschreven, startte ik de werkt nu . op A500+ en plaats de schijf erin. Even later startte de schijf op en vertoonde toen de beroemde checksum-foutmelding. Dus ik schreef iets geldig, maar het was niet consistent.

Ik besloot dat het zinloos was om naar een schijf te schrijven, tenzij ik de gegevens met een veel nauwkeurigere snelheid kon teruglezen.

Gegevens (opnieuw) lezen

Ik wilde de leeskwaliteit verbeteren omdat ik niet tevreden was met de huidige implementatie. De huidige implementatie liet niet genoeg flexibiliteit toe voor de pulsen om op enigszins vreemde tijden aan te komen. Ik had een nieuwe aanpak nodig.

Ten eerste besloot ik dat ik de meting ging synchroniseren met de /INDEX-puls. Het is niet vereist door de Amiga, maar kan later van pas komen voor mij bij het testen, schrijven en lezen.

Verschillende mensen in de opmerkingen bij de eerste helft van dit project suggereerden dat ik de timing tussen pulsen zou moeten opnemen in plaats van de methode die ik had geïmplementeerd. Het enige probleem hiermee was om deze gegevens snel genoeg naar de pc te krijgen. Als ik voor elke bit een byte zou sturen, zou ik gemakkelijk de maximale 2M baud kunnen overschrijden.

Ik besloot dat het het beste zou zijn om te proberen de gegevens een beetje te begrijpen. Dus besloot ik de teller die ik oorspronkelijk gebruikte vrij te laten lopen, tot 255. Ik plaatste de code toen in een lus, wachtend op een puls en dat dit punt zag hoeveel tijd er was verstreken.

In een ideale situatie zou de laagst mogelijke minimumwaarde 32 zijn (overeenkomend met 2 uSec). Met MFM kon je maximaal drie nullen achter elkaar hebben, dus het maximum dat deze waarde zou moeten bereiken was 128. Dit betekende dat er maximaal 4 mogelijke combinaties achter elkaar waren.

Ik heb verschillende schijven gesampled om te zien waar de meeste van deze frequenties lagen, en de resultaten zijn hieronder te zien:

Als ik dit bekijk, vind ik het merendeel van de punten rond een teller van 52, 89 en 120. Deze waren echter enigszins specifiek voor mijn rijstijl en daarom geen goede richtlijn. Na wat experimenteren heb ik de volgende formule gebruikt:value =(COUNTER - 16) / 32 . Wanneer geknipt tussen 0 en 3 gaf dit me de output die ik nodig had. Elke 4 hiervan en ik zou een byte kunnen wegschrijven.

Het kwam bij me op dat omdat je geen twee '1's samen in een MFM-gecodeerde bitstroom kon hebben, ik veilig kon aannemen dat alles voor de eerste waarde ongeldig was en zou kunnen worden behandeld als een andere '01'-reeks. Het volgende deel was het uitpakken van deze gegevens zodra ze door de pc zijn ontvangen en terugzetten in MFM-gegevens. Dit was eenvoudig, aangezien 00 niet kon gebeuren, een 01 betekende schrijf '01', een 10 betekende schrijf '001' en een 11 betekende schrijf '0001'. Ik heb dit geprobeerd en tot mijn verbazing waren mijn resultaten 100% succesvol. Ik heb het ook met nog een paar schijven geprobeerd, 100%! Ik had nu een zeer betrouwbare schijflezer.

Omdat deze nieuwe aanpak veel toleranter is voor de gegevens van de schijf, had ik geen fase-analyse of zoveel nieuwe pogingen meer nodig. De meeste van mijn schijven lezen nu perfect. Sommigen hadden een paar pogingen nodig, maar kwamen er uiteindelijk wel. Het laatste deel was om de gegevens statistisch te analyseren en te kijken of ze konden worden gerepareerd, maar 99% van de tijd dat slechte gegevens binnenkwamen, waren volledig onherkenbaar en dus was er weinig hulp.

Gegevens schrijven - Poging 5

Nu ik kon verifiëren wat ik had geschreven met hoge nauwkeurigheid, betekende dit dat het testen van de schrijver veel gemakkelijker zou zijn.

Ik begon de code te analyseren om te zien wat er mis ging. Ik schreef een 0x55-reeks naar een heel nummer en las het vervolgens weer in. Van tijd tot tijd was er een beetje verschoven in de gegevens die terugkwamen, wat betekende dat er een soort timingprobleem was bij het schrijven.

Het bleek dat dit deels kwam door de manier waarop ik met de seriële poort omging, en deels door het gebruik van de timer. Ik wachtte tot de timer de waarde 32 had bereikt, schreef het bit en stelde het vervolgens opnieuw in. Ik heb het veranderd zodat ik de timertellerwaarde niet hoefde te wijzigen.

Ik zou het eerste bit schrijven wanneer de teller 16 bereikte, dan het volgende wanneer het 48 (16+32) bereikte, en het volgende wanneer het 80 (16+32+32) bereikte, enzovoort. Timer2 is slechts 8-bit en keert terug naar nul na de 8e bit, precies wanneer we het nodig hadden. Dit betekende dat zolang we het bit met de vereiste timerwaarde zouden schrijven, we precies op 500 kbps zouden zitten.

Ik heb ook gekeken hoe ik de gegevens van de seriële poort aan het lezen was. Dit werd tussen elke bit gelezen, maar dit moest ook zo kort mogelijk zijn. Na wat experimenteren heb ik het kortste werkblok bereikt.

Nadat ik de Windows-code had gewijzigd om verificatie te ondersteunen, was ik nu klaar om het opnieuw te proberen. Deze keer wist ik dat als de schijf goed geverifieerd zou zijn, hij goed zou moeten werken in de Amiga.

Dus ik probeerde een andere schijf weg te schrijven. Met verifiëren duurde het langer. Met het nieuwe algoritme doorstond ongeveer 95% van de tracks de eerste keer de verificatie, terwijl alleen de resterende 5% nog een keer opnieuw moest worden geschreven. Ik was hier blij mee en stopte de schijf in de Amiga. Het werkte perfect!

Gegevens schrijven - Poging 6

Na wat feedback van enkele mensen die dit hebben gebruikt, was het duidelijk dat zelfs met verifiëren op de schijf niet altijd volledig leesbare schijven produceerden. De software kon ze perfect teruglezen, maar de Amiga-computers rapporteerden hier en daar een paar checksum-fouten.

Ik keek nog een keer naar de code, vroeg me af of het een timingprobleem was en keek of het kon worden gemaakt om onderbroken te worden, maar helaas met de kleine hoeveelheid tijd tussen elk bit is er gewoon niet genoeg tijd met onderbrekingen om bereik dit met behoud van de registers die u wijzigt enz.

Ik keek toen terug naar de schrijfcode. Er is een kleine kans dat nadat een volledige byte is geschreven, de code terug kan zijn gegaan om de volgende byte te schrijven voordat de timer terug naar 0 was overgelopen, waardoor het eerste bit vroeg kon worden geschreven.

Ik heb een kleine lus toegevoegd om ervoor te zorgen dat dit niet kan gebeuren, wat dit hopelijk zal oplossen voor iedereen die dit probleem heeft.

Gegevens schrijven - Poging 7

Nadat ik veel meldingen had gekregen van checksum-fouten voor geschreven schijven, begon ik het te onderzoeken. Ik dacht eerst dat ik naar de MFM-gegevens van de schijf moest kijken, maar het probleem was eigenlijk veel eenvoudiger

Kijkend naar XCopy Pro om de checksum-fouten te zien, rapporteerde het codes 4 en 6, wat betekent checksum-fouten in de sectorheaders en datagebieden. Als het alleen het gegevensgebied was geweest, had ik aangenomen dat het puur iets te maken had met het schrijven van de laatste paar stukjes van de track, maar dat was niet zo.

Ik begon te kijken naar de schrijfcode en de opvulling die ik rond elke track had, en vroeg me af of ik het begin van een track af en toe aan het overschrijven was, dus heb ik de opvulling na de track enorm verlaagd van 256 bytes naar 8. Tot mijn verbazing was mijn verificatie schopte er toen een hoop fouten uit.

Dit deed me afvragen of het eigenlijke probleem is dat ik niet genoeg gegevens schrijf. Ik begon met het toevoegen van een Track Erase-opdracht aan de Arduino die het 0xAA-patroon naar de hele track zou schrijven en daarna mijn track zou schrijven. Tot mijn verbazing gaf XCopy het een 100% duim omhoog. Dus hopelijk is dat probleem daarmee verholpen.

Diagnostiek

Ik heb veel feedback gekregen van mensen die dit project met succes hebben gemaakt, zowel volledig werkend als niet werkend. Ik besloot dat ik een diagnostische module in de code zou inbouwen om iedereen te helpen die de hunne niet aan het werk kan krijgen.

De diagnostische optie bestaat uit een paar extra opdrachten die de Arduino moet verwerken en een hele reeks gebeurtenissen die worden doorlopen om ervoor te zorgen dat alles correct is aangesloten.

Dus wat nu?

Het hele project is gratis en open source onder GNU General Public License V3. Als we enige hoop willen hebben op het behoud van de Amiga, dan moeten we elkaar niet beroven voor het voorrecht. En bovendien wil ik iets terugdoen voor het beste platform waar ik ooit aan heb gewerkt. Ik hoop ook dat mensen dit zullen ontwikkelen en verder zullen ontwikkelen en blijven delen.

De huidige schrijfoplossing is geen optie op de Arduino UNO, tenzij je een apart FTDI/seriële breakout-bord gebruikt, dus mijn volgende taken zijn om het daarop te laten werken (mogelijk met behulp van de 23K256 IC om het spoor te bufferen voordat het naar de schijf).

Ik wil nog naar andere formaten kijken. ADF-bestanden zijn goed, maar ze werken alleen voor AmigaDOS-geformatteerde schijven. Er zijn veel titels met aangepaste kopieerbeveiliging en niet-standaard sectorindelingen die eenvoudigweg niet door deze indeling kunnen worden ondersteund. Ik heb hierover zeer nuttige informatie ontvangen, maar heb momenteel niet veel schijven om mee te testen.

Volgens Wikipedia is er nog een ander schijfbestandsformaat, het FDI-formaat. Een universeel formaat, dat is goed gedocumenteerd. Het voordeel van dit formaat is dat het probeert de trackgegevens zo dicht mogelijk bij het origineel op te slaan, dus hopelijk worden de bovenstaande problemen opgelost!

Ik kwam ook de Software Preservation Society tegen, met name CAPS (formeel de Classic Amiga Preservation Society ) en hun IPF-formaat. Na een beetje lezen was ik erg teleurgesteld; het is allemaal gesloten en het voelde alsof ze dit formaat gewoon gebruikten om hun schijfleeshardware te verkopen.

Dus mijn focus zal liggen op het FDI-formaat. Mijn enige zorg hier is met gegevensintegriteit. Er zijn geen checksums voor mij om te controleren of de read geldig was, maar ik heb een paar ideeën om dat op te lossen!

Schema's

Circuit voor Arduino Pro Mini Circuit voor Arduino UNO