In het vorige artikel heb ik de belangrijkste beginnerspunten opgenoemd van de GoSDC-Atom. In deze aflevering ga ik wat dieper in op een aantal punten:

  • Werken met meerdere area’s
  • Overschrijven van bestanden
  • Random Access Files en maximale bestandsgrootte
  • Zelf tools en utilities toevoegen

Werken met meerdere area’s

Zodra een SD kaart met een grotere capaciteit dan 4GB gebruikt wordt maakt de Atom meerdere area’s aan op de fysieke SD-kaart. Alle area’s hebben een maximale grootte van 4GB, met uitzondering van de laatste area. Deze kan kleiner zijn als de fysieke opslagruimte niet voldoende groot is. We hebben als eindgebruiker (helaas) geen invloed op de afmetingen en dus het aantal area’s op de kaart. John Kortink vergelijkt de area’s met “logische SD kaarten”. Wanneer hij het over een “flash card” heeft in de handleiding dan bedoelt hij meestal een area.

Initialisatie (wat de kaart vereist voordat je æm leest of schrijft) gebeurt automatisch, dus sowieso na power up maar ook na elke BREAK (omdat de kaart gewisseld kan zijn). Direct na elke initialisatie bepaalt GoSDC de capaciteit van de kaart, en op basis daarvan de areas.

Voordat we een area kunnen gebruiken moeten we deze eerst formatteren. Als je iets wilt wegschrijven naar een ongeformatteerde area, zowel vanuit de Atom als met de gosdcio utility op een PC/Mac, dan volgt een foutmelding. Het formatteren is vrij eenvoudig te doen. Dit kan overigens alleen met de Atom:

Stap 1: selecteer de area met *SDCAREA n (waarbij n het nummer van de area is)
Stap 2: formatteer de area met *SDCTOOL SDCFO

Na het formatteren moet de Atom even gereset worden. Dus even op de <BREAK>-toets drukken. Je kunt daarna de area een zinvolle naam geven met het commando:

SDCTOOL SDCMOD AN <naam>

waarbij <naam> dus de gewenste naam is.

Als je met het commando

*SDCINFO

informatie over de GoSDC opvraagt dan krijg je de beschikbare area’s te zien. Bovenaan de lijst staan de X (systeem) en U (user) area’s. Daaronder komen de area’s op de SD kaart. Standaard hebben ze geen naam en dat is in de lijst te zien aan de lege naam achter de grootte. Bij een niet geformatteerde area staat er helemaal niets achter.

Overschrijven van bestanden

In de vorige Asterisk had ik geschreven dat een bestand dat met *DELETE wordt verwijderd, niet echt verwijderd wordt maar het wordt als zodanig gemarkeerd. Na verloop van tijd kunnen er dus behoorlijk wat verwijderde bestanden op de SD kaart staan.

Met de GoSDC heb je geen *COMPACT commando beschikbaar. Je kunt deze ruimte vrijmaken door een backup te maken van de betreffende area en deze daarna te formatteren en de backup terug te zetten.

Maar hoe zit het dan met het overschrijven van bestanden; wordt dan ook telkens het oude bestand als verwijderd gemarkeerd en een nieuw bestand aangemaakt? Navraag bij John leert dat het er aan ligt of een bestand via gosdcio op de kaart gezet is of door de Atom.

Zoals gebruikelijk bij opslagsystemen wordt er ook hier meer fysieke opslagruimte gebruikt dan daadwerkelijk nodig is. Bij bijvoorbeeld een diskette of harddisk heb je te maken met een sector. Als je een bestand van slechts één byte wegschrijft, dan is de totaal gebruikte ruimte één sector. Onder AtomDOS of DFS is dat dan 256 bytes. Een bestand van 257 bytes neemt twee sectoren (zijnde 512 bytes) in beslag.

De “sectoren” of blokken op de SD kaart zijn 512 bytes groot. Een bestand dat vanuit een PC of Mac met gosdcio geplaatst wordt, wordt ook in deze blokgrootte opgeslagen. Een programma van 6 kB zal dus in 12 blokken van 512 bytes opgeslagen worden. Maar een bestand dat met de Atom weggeschreven wordt, wordt in blokken van 256 kB weggezet. Zowat elk programma of bestand zal dus 256 kB opslagruimte nodig hebben als dit vanuit de Atom op de SD kaart geplaatst is.

Indien nu een “PC” bestand gewijzigd wordt en groeit dan zal het originele bestand inderdaad verwijderd worden en er wordt een nieuw bestand aangemaakt dat ook een blokgrootte krijgt van 256 kB. Dit vervangen (delete gevolgd door create) gebeurt bij elke save of open for output, ongeacht groeien, maar alleen als de file allocatie kleiner is dan 256 KB, Een file van b.v. 1 MB die je met GoSDCio hebt geplaatst blijft gewoon waar ie is (en kan na een FOUT dus ook gewoon groeien van 0 bytes naar 1 MB). Als een “Atom” bestand gewijzigd wordt dan is er vanwege die 256 kB blokgrootte voldoende ruimte om te groeien. In dat geval wordt het originele bestand overschreven.

Random Access Files

Echte Random Access Files bestaan eigenlijk niet op de Atom onder COS. Namelijk de belangrijkste functie die kenmerkend is voor een Random Access File is dat je een pointer (PTR) kunt plaatsen om op een willekeurige plek in het bestand. Vandaar natuurlijk de naam Random Access. Voor een Atom zou Sequential Access File een betere benaming zijn.

Als je een database record wegschrijft van bijvoorbeeld een adressenbestand met de volgende structuur:

naam: 64 bytes
adres: 64 bytes
postcode: 6 bytes
plaats: 32 bytes
telefoon: 10 bytes
email: 80 bytes

Dan is dat record 256 bytes lang. Als in het adressenbestand 100 adressen staan dan zou je de naam van het 68e adres als volgt direct kunnen benaderen met

F=FIN “ADRESFILE”
PTR F=17152
SGET F, $N

Het getal 17408 komt vanwege 67 * 256 (het eerste adres-record staat namelijk op 0 * 256). Echter, Atom COS heeft de functie PTR niet geïmplementeerd. Dus om daar het 68e adres te lezen moet je eerst de voorafgaande 67 adres-records inlezen en negeren. Aangezien GoSDC een vrijwel 1-op-1 vervanger is van de Atom COS werkt deze op dezelfde wijze en heeft dus de Random Access Files niet beter geïmplementeerd. Enerzijds een gemiste kans, anderzijds wordt dit type bestanden vrijwel niet gebruikt in Atom-programma’s, dus niet echt onoverkomelijk.

Met onderstaand programma heb ik de maximale bestandsgrootte eens bepaald (de uitkomst zal u overigens niet verbazen): 

10 F=FOUT "BIGFILE"
20 FOR X=0 TO 4294836225
30 PUT F,X
40 NEXT X
50 SHUT F
60 END

Elke waarde van X wordt weggeschreven als 32 bits getal (vandaar ook 4294836225, dat is 2^32). Bij X = 65536 volgt een foutmelding. Dat is niet verwonderlijk want als je 65536 getallen van 4 bytes hebt weggeschreven dan heb je 262144 bytes in het bestand gezet. En dat is omgerekend 256 kilobyte. Komt dat getal u bekend voor?

Ter vergelijking, op een C90 cassette past met een tape snelheid van 300 baud iets van 158 kB, met 1200 baud past zo’n 632 kB.

Vergelijken we dit even met Atom DOS, dan kunnen bestanden tot ca. 100 kB groot zijn en heb je wel de mogelijkheid om met PTR een pointer te verplaatsen om snel het juiste record op te vragen. Ook met de AtoMMC werkt dat prima. Bovenstaand programma heb ik twee dagen laten draaien op een Atom op 4 MHz. Er is in die tijd ruim 98MB aan data weggeschreven. Echter, de PTR is een 24-bits (3 bytes) getal. Dat beperkt de maximale grootte om een bestand als random access file te gebruiken tot 16 MB.

Allemaal indrukwekkende getallen, 256 kB, 98MB, 16MB… Echter in de praktijk zijn dit soort grote bestanden niet gebruikelijk voor een Atom. De grootste databestanden die gebruikt worden zijn voor (het filmpje van) het Dragon Liar spel (14,5 MB plus meerdere databestanden variërend van 60 kB tot 9 MB) en de tekstdemo van StarTrek (2,2 MB). Deze programma’s vereisen overigens wel wat meer hardware, vooral extra geheugen en de StarTrek demo is specifiek voor de Godil video vervanging geschreven. De waarden van 256 kB resp. 16 MB kun je dus beschouwen als informatief, het zijn echt geen beperkingen voor de Atom.

Tools en Utilities toevoegen

Als je gebruik maakt van de extra ROM socket dan heb je de mogelijkheid om een ROM (automatisch) te laden. Voor socket 21 zou je dan de Floating Point ROM kunnen laden. Daar is weinig variatie in. Echter, in socket 24, kun je kiezen uit de diverse ROMs die in de loop der jaren ontwikkeld zijn. Je kunt ook hier maar één ROM tegelijk laden. Het is handig om deze in de area U te plaatsen omdat deze area altijd aanwezig is, onafhankelijk van de geplaatste SD-kaart. De stappen vanaf SDCA2A zijn dus optioneel als je een area op de SD-kaart gebruikt.

  • Verzamel de ROMs die je zou willen gebruiken op je PC/Mac
  • Zorg voor een lege area op de SD kaart
  • Kopieer de ROMs een voor een naar de SD kaart met het commando:
    sudo gosdcio -d/dev/disk2 -c “ADD UE 105 GAGSROM”
    hierbij dient het getal (105) uniek te zijn en te liggen tussen 0 en 255. De naam (GAGSROM) is de bestandsnaam op de PC/Mac. Om te kopiëren naar een andere area voeg je de parameter -a<n> toe, bijvoorbeeld -a2 voor de tweede area.
  • Als je alle ROMs naar de kaart gekopieerd hebt plaats je de kaart terug in de GoSDC
  • Start dan het kopieerprogramma om bestanden tussen twee area’s te kopiëren:
    SDCTOOL SDCA2A
  • In het menu kies je als bron-area de area waar je de ROMs op gezet hebt. Als doel-area kies je U.
  • Tenslotte kun je het kopiëren vanuit het menu starten

Als de ROMs in area U staan dan kun je met *SDCCONFIG UENR <n> aangeven welke ROM bij de start van de Atom automatisch geladen wordt. Conform bovenstaande voorbeelden zal met *SDCCONFIG UENR 105 dus de GAGSROM geladen worden bij het aanzetten van de Atom. Dit werkt ook echt alleen maar bij het aanzetten; <BREAK> of <CTRL>+<BREAK> is niet voldoende.

Er is blijkbaar ook een ongedocumenteerde optie om een ROM te laden zonder opnieuw op te starten. Als je namelijk vanuit het Atom Software Archief de optie kiest om een ROM te laden dan blijkt dat te werken. Zelfs zonder ook maar op <BREAK> te drukken. Dit betreft dus code, die John daarvoor aan het Atom Software Archive heeft toegevoegd, die direct praat met de GoSDC hardware. Voor ons blijft dat een ongedocumenteerde call.

Hiermee sluit ik dit artikel af. In een volgende aflevering wil ik wat dieper in gaan op het zelf schrijven van commando’s of utilities die opgeslagen kunnen worden op de SD-kaart.