1541-MDC

Dit is een project gebaseerd op de Commodore 1541-II maar met extra mogelijkheden en gemaakt op een eigen printplaat (PCB). "MDC" staat voor "Multi Data Carrier". In feite is dit project gebaseerd op twee eerdere, ook vernieuwde projecten van mij: 1541IDE8: an IDE hard disk drive (HDD) for your 1541 en 1541LPT and 1541Arduino: No more floppies anymore!. 1541IDE8 vervangt de floppydrive door een harddisk (HDD) of een Compact Flash kaart (CF). Bij 1541LPT levert een PC of een Arduino met SD kaart de data. Oorspronkelijk hadden beide projecten hun eigen nieuwe PCB. Maar bij nader inzien besloot ik de projecten te combineren in één PCB. De gebruiker kan nu kiezen voor welk project hij de PCB wilde gebruiken. Of zelfs een combinatie van beide, zie later.

Historie

Eind jaren '90 baarde de IDE64 om een IDE HDD op en Commodore 64 aan te sluiten relatief veel opzien want hij kostte "maar" 70 Dollar (voor mij toen veel geld). Een ander speler op de markt was CMD met een eigen HDD:

Wat die kostte weet ik niet meer maar in ieder geval zeker onbetaalbaar voor mij op dat moment.

Ik kon van iemand een IDE HDD lenen en de gedachte was: "Wat die Tsjechen kunnen, moet ik ook wel kunnen!". Ik heb toen contact met ze gezocht om te polsen wat zij over hun project wilden vertellen maar dat leverde niets op. Logisch, want zij wilden er aan verdienen.

Een soort gelijk project was GIDE van Tilmann Reh wat voor de Z80 bedoeld was. Wat heel belangrijk was dat het mij verklaarde hoe data van de 8-bits databus van Z80, dus ook 6510, naar de 16-bits bus van een IDE HDD te converteren en omgekeerd. Dat was in mij ogen relatief gemakkelijk en in één dag tijd had ik iets in elkaar geflanst. En het werkte ook nog.... bijna. Na het beschrijven en lezen van een sector waren er van de 512 bytes altijd zo'n twee of drie corrupt. Toch die Tsjechen eens gepolst en die zeiden dat zij dat probleem ook hadden en opgelost hadden met de CPLD op hun PCB. Het wat precies wilden ze uiteraard niet kwijt.

Na een paar dagen schoot mij de reden te binnen: De VIC (= video) chip moet zo nu en dan wat tijd aan het begin van de kloktijd voor de 6510 bietsen; we praten over zo'n 50 nanoseconden. Geen probleem voor de VIC en SID die daar op voorbereid waren maar wel voor de supersnelle HDD. Dus ik moest hem gewoon vertellen niet meteen aan de slag te gaan maar gewoon even te wachten. De meest eenvoudige en goedkoopste manier: een weerstand en een condensatortje. En de boel werkte! Totale kosten van mijn projectje: nog geen 10 gulden.

Ik ben met dit project niet verder gegaan want ik zag er geen toekomst in. Om met IDE64 en mijn interface te kunnen werken, MOET de software de data via de KERNAL ophalen. En wat doet een hoop software: deze installeert een snellader en haalt de data rechtstreeks van de floppydrive (FDD) op met turbo-snelheid. Alleen.... DE IDE64 en mijn interface worden op deze manier compleet over het hoofd gezien. Een oplossing was alle software die problemen met de IDE64 vertoonden aan te passen. Maar daar zag ik eigenlijk geen heil in. Bovengenoemde CMD-HDD bracht mij op het idee om de HDD niet aan de C64 te koppelen maar aan een 1541. Software die, om wat voor reden dan ook, de KERNAL omzeilden zou in principe nu wel kunnen werken. Dit project noemde ik 1541IDE.

Probleempje: ik moest op een gegeven moment, eind 1998, die HDD teruggeven dus moest ik naar een andere oplossing zoeken. Ik werkte al veel met PC's, zowel soft-als hardwarematig, in combinatie met mijn Commodores. Bijvoorbeeld software ontwikkelen op de PC en via de printerpoort en de userport overzetten op de C64 en dan op mijn 1541. Ik kreeg toen het idee om de HDD door een 6522 te vervangen en met deze 6522 verbinding met de printerpoort van de PC te maken: 1541LPT was geboren.

Hiernaast de originele 1541-II met in het midden de derde 6522 met daaraan de kabel die, via een verlengkabel, aan de printerpoort van de PC wordt aangesloten. Rechtsboven, nog binnen de kast, zie twee 7-segments LEDS welke aan de vrije poort A van de eerste 6522 zijn aangesloten en wel om debuggen ven de nieuwe KERNAL te vereenvoudigen.

Een nieuwe KERNAL

De 1541 kan natuurlijk niets met die extra 6522 en dus moest deze natuurlijk aangepast worden. Maar wat moest ik veranderen? Het basisidee was simpel:
- Primair: zoek alle routines welke zich bezighouden met de hardware van de FDD en vertaal deze naar routines die de derde 6522 aansturen.
- Secundair: zoek routines die zich niet bezighouden met de hardware maar er toch invloed op hebben.

Dit laatste klinkt wat vaag, is het ook, en ik kan daarom het beste meteen met een voorbeeld komen. Commodore gebruikt GCR (Group Code Recording) om data op een floppy op te slaan. Het hoe en waarom ga ik hier verder niet op in. Maar onze 6522-LPT combinatie heeft GCR absoluut niet nodig en kan dus overgeslagen worden.
Nu wilde ik niet alleen FDD gerelateerde routines vervangen maar ook een aantal interne commando's uitbreiden. Ik zou graag vanuit de C64 willen zien welke "floppies" op de PC beschikbaar zijn en desnoods vanaf de C64 een floppy kunnen "wisselen". En daarvoor is extra ruimte nodig. Die zou te krijgen zijn door die niet-nodige routines te verwijderen zoals boven genoemde GCR routines..

Een kleine tegenvaller: ik dacht dat de source codes van 1541 al op internet te vinden waren maar dat bleek dus niet zo te zijn. Wel scans van diverse boeken maar niet als tekst. Dit was de start om mijn eigen disassembler te maken, de KERNAl te disassembleren en van commentaar te voorzien.

Ik verwijderde dus alle routines die niet nodig waren, verving FDD routines door HDD routines en schoof de boel in elkaar zodat ik aan de onderkant ruimte had voor mijn eigen commando's. Het lukte mij uiteindelijk en begon aan het testen. Alles werkte prima, ik had zelfs JiffyDOS met succes geïntegreerd, totdat ik er een KCS Powercartridge in de C64 stopte en deze binnen de kortste keren crashte. Om een lang verhaal kort te maken, de KCS cartridge maakt rechtstreeks gebruik van routines van De KERNAL. Welke precies, weet ik nu nog steeds niet. En omdat ik de originele routines verschoven had, vond de KCS een stuk willekeurige data waar die niets mee kon en dus ermee ophield.

Ik was ondertussen overgestapt op de 1541-II met als hoofdreden: gemakkelijker te hacken. Bij de 1541 moest ik elke keer twee EPROMs programmeren, bij de 1541-II maar één. Nu gebruikte Commodore of een echte 16 KB 27128 EPROM of een compatible PROM (deze is niet herprogrammeerbaar). Het idee was:
- De 27128 door een 32 KB 27256 te vervangen.
- Daarvoor is nodig een verbinding op de print door te snijden.
- Het nu vrije pinnetje met adreslijn A14 te verbinden.
- De software strategie compleet te wijzigen.
Dat laatste hield in dat ik weer begon met de originele source en dan alleen een jump opdracht op de plaats zette waar de originele routine moest worden gewijzigd. De jump leidde dan naar het tweede deel van de EPROM waar dan de vervangende routine stond. Deze wijziging was relatief weinig werk maar het belangrijkste was dat de KCS Power cartridge nu wel werkte. Ik kon nu met een gerust hart mijn eigen toepassingen invoegen.

Compatibiliteit

In hoeverre was 1541LPT compatibel met de originele 1541? Verassend goed. De enige software waarvan ik van te voren wist dat die niet zou werken was die software die op een of andere manier de FDD rechtstreeks zou manipuleren door rechtstreeks de tweede 6522 zou programmeren. Dat bleken diverse diskeditors en een paar turboloaders te zijn. Programma's die zich alleen bemoeiden met de eerste 6522, lees: communicatieprotocol, hadden nergens last van. Hieronder vielen o.a. JiffyDOS en EXOS V3. SpeedDOS heb ik, eerlijk gezegd, nooit getest.

Terug naar 1541IDE

In 2007 begon ik mij weer voor 1541IDE te interesseren. Hoofdreden: ik kreeg allerlei IDE drives van afgedankte PCs. De vraag was, welke interface zou ik voor mijn project gebruiken?

Voor de hand liggend was natuurlijk de 16-bits interface zoals gebruikt dor GIDE. Maar hier zat een nadeel aan verbonden. Een harddisksector is 512 bytes groot. Een Commodore floppysector was maar 256 byte groot. Prima, dan passen er toch twee Commodore sectoren op een PC sector? Maar..... Om een Commodore sector te lezen moer ik er in feite twee lezen want als je een PC sector wilt lezen, moeten alle 512 bytes gelezen worden. OK, gewoon een kwestie van die helft bewaren die je echt nodig hebt.

Maar in het schrijven van een sector, daar zit het venijn. We moeten namelijk 512 bytes wegschrijven. Dus moeten we eerst de betreffende PC sector inlezen om te weten wat er op de andere Commodore sector staat en vervolgens de sector waar we aan gewerkt hebben plus die ander weer wegschrijven. Dat kost als eerste gewoon meer tijd. Maar het probleem zit hem in het geheugen. De 1541 heeft maar 2 KB aan geheugen en het is mogelijk dat op een gegeven moment al dat geheugen in gebruik is. Waar moet ik die extra sector in wegschrijven?

Het bleek ook dat ik o.a. een aantal HDD gerelateerde zaken, de disk parameters, in het geheugen moest opslaan. M.a.w. ik had extra geheugen nodig, niet veel, maar toch. Het meest simpele was een tweede 2 KB SRAM op de originele te solderen muv. de selectlijnen. Die soldeerde ik aan een vrije uitgang van de 74LS42 welke ook de andere RAM en 6522s selecteerde. Deze hack leverde maar 1 KB extra op maar dat was ruim voldoende voor mij toepassing.

FYI: ik heb een hack gemaakt voor de volle 2 KB maar deze was, achteraf gezien, de extra moeite uiteindelijk niet waard. Deze hack maakte gebruik van een ongebruikte AND poort. Duidelijk zijn de geplastificeerde koperdraadjes te zien welke naar de diverse ICs leiden.

OK, dus met dat extra geheugen heb ik in feite ook mijn "extra sector" probleem opgelost. En toch heb ik voor een andere oplossing gekozen. De eigenlijke I/O van een IDE HDD is maar 8-bits. Alleen de data wordt 16-bits overgedragen. Ik besloot de hoogste 8 bitjes van de databus te negeren. Een consequentie was wel dat ik de helft van de opslagcapaciteit kwijt was maar de helft van 1,6 GB is 800 MB en dat is nog steeds zo'n 5000 Commodore floppies. Maar daar stond tegenover dat a) de boel veel sneller werd en b) ik veel minder ICs nodig had. Theoretisch nog maar één IC maar na een ongelukje met een kapotte voeding besloot ik er toch nog twee buffers aan toe te voegen. Alles wat dus nog maar nodig was:

Op bovenstaande foto is de derde 6522 verwijderd. Op de eerdere foto waar de derde 6522 voor 1541LPT nog wel in het voetje zit, is boven de kast nog een 6522 met nog eens vier 7-segments LEDs te zien. Deze kon nu hier geplaatst worden hetgeen het debuggen nog meer vereenvoudigde. Helemaal rechts is de CF kaart te zien die ik toentertijd op het laatst gebruikte.

Uitbreidingen van de KERNAL

Wat ik op de HDD opsloeg waren de toen al bekende D64 images. Voor de jongeren onder ons: het was mogelijk om de diverse Commodore drives rechtstreeks op de printerpoort van een PC aan te sluiten. Met programma's als Star Commander kon men niet alleen alle sectoren van een floppy disk lezen en op de PC opslaan maar ze ook weer (op een andere floppy) terugschrijven.

Ik moest dus bedenken hoe ik deze images op de HDD opsloeg en tevens een manier bedenken om een inhoudsopgave van al deze images te maken. Nu heeft een 1541 floppy 683 sectoren. Maar er bestaat ook een algemeen erkende versie met 40 sectoren en deze versie heeft 768 sectoren. Hexadecimaal is dat $300 en dit vereenvoudigt het rekenwerk in assembler aanzienlijk. De ruimte voor het eerste image, dus de eerste 768 sectoren van de HDD, werden gereserveerd voor de directory van de images. Aangezien ik alleen 16 bytes voor de header van de floppy reserveerde, kon ik dus zo'n 12000 images in deze directory registreren. 12000 images zijn equivalent aan een 4,8 GB HDD. Bij grotere HDDs werden gewoon meer images aan het begin van de HDD gereserveerd.

Uitbreidingen van de KERNAL die niet naar buiten zijn gebracht

16 MB
Tijdens het laden van een bestand geven de eerste twee bytes op een Commodore sector aan waar de volgende sector te vinden is. Bij de laatste sector is het eerste byte $FF en het tweede geeft aan hoeveel bytes op deze sector nog bij het te laden bestand horen. Theoretisch kan men zo met floppies tot zo'n 16 MB kunnen werken. In dit geval geen floppies maar images. Ik had dan wel een grotere BAM nodig, een tabel waar werd bijgehouden welke sectoren in gebruik waren, en een grotere directory. Maar hoeveel sectoren reserveer je voor een directory? Dat heb ik opgelost door de boel flexibel te maken: is de directory vol? Dan plak er nog een sector aan.

Subdirectories
Een disk van 16 MB is leuk maar bleek, zonder subdirectories, onwerkbaar te zijn. Dus daar heb ik ook aan gewerkt.

Compact Flash kaart
In het begin gebruikte ik alleen echte harddisken want ik had nergens een Compact Flash kaart (CF) voor nodig. Maar op een gegeven moment kreeg ik er een cadeau, "maar" 32 MB, maar toch zeer interessant. Het eerste voordeel: een stuk lichter en hanteerbaarder dan een HDD. Het tweede voordeel: een CF kan ook in 8-bits mode werken. Dit betekent o.a. dat ik van de volledige capaciteit gebruik kan maken zonder de extra benodigde ICs. Maar dat was, toen, voor de toekomst.

Gebruik van floppy en HDD
De eerste uitdaging voor de 1541IDE was: hoe vul ik de HDD met images? Dit werd in eerste instantie opgelost door een tweede 1541 aan de C64 te koppelen en er vervolgens een kopieerprogramma er op los te laten. Door de extra 16 KB aan EPROM had ik wel erg veel ruimte voor uitbreidingen en ik kreeg het idee om de FDD weer aan te sluiten en de software aan te passen zodat ik zowel van de FDD als HDD gebruik kon maken. Dit werkte prima.

En toen ging het mis :(
Wat of hoe het misging weet ik nu nog steeds niet maar ik heb op een gegeven moment blijkbaar een verkeerde directory gewist. Ik was ondertussen ook met een ander project bezig, CBM-HD, een parallel project om de PET/CBM series van een HDD te voorzien en toen ik de vergissing opmerkte bleken zelfs de back-ups al niet meer de laatste versies te hebben. Ik had nog wel oudere versies, namelijk die ik op CD had gebrand. Op een gegeven moment was ik overgestapt om via mijn netwerk back-ups op andere PCs te maken. Misschien sneller en gemakkelijker maar.... Wat ook nog een rol speelde was dat er een ander project furore aan het maken was: 1541Ultimate. En daar kwam wat later SD2IEC bij en toen vond ik het wel welletjes.

2024

Begin dit jaar was ik gewoon aan het kijken wat ik zo allemaal in het verleden had gedaan en vroeg me af of ik nog iets aan die oude projecten kon doen. Met 1541LPT leek in eerste instantie niets te beginnen want welke laptop of PC heeft nog een printerpoort? Maar ik was onlangs ook met een Arduino aan de slag gegaan en een Arduino met een SD kaart zou een leuke en vooral kleine vervanger van de PC kunnen zijn. Zeker als ik die in plaats van de FDD in de kast van de 1541-II kon inbouwen.
Vroeger was het laten maken van printplaten in verhouding tot het nut ervan, in mij ogen althans, veel te duur. Maar dat is nu anders. Dus het idee ontstond om een eigen print hiervoor te ontwerpen.

Dit leidde er toen ook toe om dat voor 1541IDE te doen, in eerste instantie "just for the fun of it". Maar toen viel mijn oog op een CF die in mijn "werk PC-XT" stak en toen werd het meteen wat interessanter: een uitwisselbaar medium!

Maar toen ik op het punt stond beide printplaten te bestellen, kreeg ik het idee ze te combineren en wel zodanig dat dezelfde printplaat voor beide projecten te gebruiken was. Hoofdreden: als ik ze bij JLCPCB bestel, krijg ik er altijd vijf. FYI: maken en bezorgen in dit geval 30 Euro. Het resultaat:

Deze print is nog niet klaar, er moeten nog wat LEDs en weerstanden op gesoldeerd worden. De lege plek is voor de GAL bedoeld welke nog geprogrammeerd moet worden. Helaas bevat deze twee kleine foutjes. De meest duidelijke is de tekst "1541-IDE". Dit had uiteraard "1541-MDC" moeten zijn. De andere is de plaatsing van wat weerstanden en LEDs rechtsboven. Als ik die wat meer naar boven had geplaatst, had ik er een connector met uitwerp haken kunnen plaatsen.

Ik ben ondertussen begonnen weer alle documentatie en source codes bij elkaar te schrapen. Tijdens dit werk was ik wel over bovengenoemde uitspraak "een uitwisselbaar medium!" aan het nadenken. Ik bedoelde niet het uitwisselen van bestanden met ander 1541IDE drives maar met een PC. Nu kan ik twee dingen doen:
- Ik schrijf een programma dat images rechtstreeks op de CF wegschrijft volgens mijn bovengenoemde structuur.

- Ik schrijf de images weg volgens FAT32, zoals Windows dat normalerwijze zou doen.
Onder DOS zou het rechtstreeks beschrijven van sectoren van CF niet zo'n probleem zijn maar onder Windows wel. Ik heb nog een Commodore 386SX staan die CF aankan en onder DOS 6.22 draait maar dan moet ik eerst de images van mijn VMESX server op die 386SX krijgen.

Ik zou die kleine 1 MHZ 6502 misschien kunnen leren hoe met FAT32 om te gaan maar behalve het tijdsverlies dat ontstaat door de omgang met 512 bytes sectoren, is er ook nog tijdsverlies door die overhead van FAT32.

Wat dan wel? Brainwave: sluit een CF en een Arduino aan! De SD kaart van de Arduino wordt uitwisselbaar. De Arduino weet met FAT32 om te gaan dus daar hoef ik mij niet druk over te maken. Wat ik nu moet doen is een routine te schrijven die images van de Arduino leest en deze naar de CF schrijft en uiteraard omgekeerd. Aangezien het de Arduino is die de communicatie met de PC verzorgt, hoeft de CF niet uitwisselbaar te zijn en kan dus verborgen blijven binnen in de kast. En om tijdsverlies te mijden, blijft de CF in 16-bits mode werken. Op bovenstaande foto is te zien dat ik ondertussen iets beter dan een CF kaart heb gevonden: geen kabel en converterstuk meer nodig.

En waar vindt ik de tijd voor dit alles? Met een beetje geluk ga ik in maart 2026 met pensioen :)

Artikel geschreven door Ruud Baltissen