Etikett: Commodore DOS

När Commodore 64 läste en diskett var det inte bara datorn som arbetade. Diskettstationen hade nämligen en egen processor, ett eget minne och ett eget operativsystem. Commodore DOS gjorde därför den klassiska 1541-stationen till en liten dator i sig – en tekniskt ovanlig lösning som var både långsam, avancerad och långt före sin tid.

När en Commodore 64-användare skrev kommandot:

LOAD "*",8,1

började diskettstationen långsamt surra och knacka. Efter en stund laddades spelet eller programmet in i datorns minne. För användaren verkade det kanske som en vanlig filöverföring, men bakom ljuden dolde sig en ovanlig teknisk lösning.

Till skillnad från de flesta andra datorer under 1980-talet hade Commodores diskettstationer nämligen ett eget operativsystem, en egen processor och ett eget arbetsminne. Diskettstationen var därför inte bara en passiv lagringsenhet. Den var i praktiken en liten dator som kommunicerade med huvuddatorn.

Operativsystemet kallades Commodore DOS, eller CBM DOS.

Ett operativsystem utanför datorn

I många datorer laddades diskoperativsystemet in i datorns arbetsminne när det behövdes. Commodore valde en annan konstruktion.

CBM DOS låg permanent lagrat i ROM-kretsar inne i själva diskettstationen. Det kördes av en processor ur MOS 6502-familjen, samma processorfamilj som användes i många av tidens hemdatorer och spelkonsoler.

Det innebar att Commodore 64 egentligen kommunicerade med en separat dator varje gång den ville läsa eller skriva en fil.

Huvuddatorn skickade kommandon till diskettstationen, som själv:

• tolkade filnamnet
• letade upp filen på disketten
• läste rätt sektorer
• hanterade ledigt diskutrymme
• rapporterade eventuella fel
• skickade tillbaka informationen till datorn

Kommunikationen liknade därför mer ett enkelt nätverk mellan två datorer än en modern intern hårddiskanslutning.

Den intelligenta diskettstationen

Den mest kända Commodore-stationen var 1541, som ofta användes tillsammans med Commodore 64.

Stationen innehöll bland annat:

• en egen processor
• arbetsminne
• ROM med Commodore DOS
• elektronik för att styra läs- och skrivhuvudet
• buffertar för dataöverföring

Konstruktionen hade flera fördelar. Eftersom diskettstationen själv hanterade filsystemet behövde datorn inte känna till exakt hur informationen låg lagrad på disketten.

Det gjorde också systemet flexibelt. Commodore kunde använda olika typer av diskettstationer med samma datorfamilj, så länge stationerna förstod de kommandon som skickades över Commodores seriella buss.

Nackdelen var att kommunikationen ofta blev långsam. Commodore 1541 blev ökänd för sina långa laddningstider, särskilt när den användes med Commodore 64.

Därför blev så kallade fast loaders mycket populära. Program och instickskassetter som Epyx Fast Load, Action Replay och Final Cartridge ersatte delar av den vanliga kommunikationsmetoden och kunde ladda program betydligt snabbare.

En diskett med 144 filer

En vanlig 1541-formaterad diskett hade 35 spår och var enkelsidig. Den kunde innehålla högst omkring 144 filer.

Filsystemet hade inga underkataloger. Alla filer låg i samma gemensamma katalog, ungefär som om alla dokument på en modern dator måste placeras direkt på skrivbordet.

Filnamnen kunde vara högst 16 tecken långa.

Diskettens katalog låg på spår 18, ungefär mitt på skivans yta. Där lagrades bland annat:

• diskettens namn
• diskettens identitetskod
• filnamn
• filtyper
• filstorlekar
• information om vilka block som var lediga

För att visa innehållet på en diskett kunde användaren skriva:

LOAD "$",8
LIST

Diskettstationen skickade då katalogen till datorn som om den vore ett BASIC-program. Filstorleken användes som radnummer och filnamnet visades som text på raden.

Längst ned stod hur många block som fortfarande var lediga.

Metoden var smart, men hade en tydlig nackdel: när katalogen laddades in kunde det BASIC-program som redan låg i minnet skrivas över.

Senare tillbehör och versioner av BASIC införde därför särskilda katalogkommandon som kunde visa filerna utan att förstöra det program användaren arbetade med.

Fem olika filtyper

Commodore DOS använde flera filtyper med olika funktioner.

PRG – programfilen

Filtypen PRG användes framför allt för program, men kunde även innehålla annan data.

De två första bytevärdena i filen angav till vilken minnesadress innehållet skulle laddas. Detta gjorde det möjligt att lagra både BASIC-program och maskinkodsprogram.

Ett vanligt kommando var:

LOAD "PROGRAM",8,1

Den avslutande ettan betydde att programmet skulle laddas till den adress som fanns angiven i filen.

SEQ – sekventiella filer

SEQ var en enkel datafil som lästes från början till slut.

Den kunde exempelvis användas för:

• text
• dokument
• adressregister
• inställningar
• sparade data

Den liknade en vanlig text- eller datafil utan avancerad intern struktur.

REL – filer med direktåtkomst

REL, eller relativa filer, var mer avancerade.

De bestod av fasta poster som kunde nås direkt genom sitt postnummer. Ett program behövde därför inte läsa hela filen från början för att hitta en viss uppgift.

Det gjorde REL-filer användbara för exempelvis register och databaser.

USR – användardefinierade filer

USR var avsedd för data med ett användardefinierat innehåll.

Filtypen användes relativt sällan, men förekom bland annat i program som använde egna diskformat eller särskilda datastrukturer. Operativsystemet GEOS använde exempelvis USR-filer för vissa avancerade filformat.

DEL – raderade filer

DEL användes internt för raderade eller särskilt markerade katalogposter.

När en fil raderades försvann den inte alltid omedelbart från diskettens fysiska yta. Dess katalogpost och datablock markerades i stället som lediga och kunde senare skrivas över.

Det innebar att en raderad fil ibland kunde återställas, förutsatt att dess data ännu inte hade ersatts.

Principen liknar hur filräddning fortfarande fungerar på moderna lagringsmedier.

När en fil inte stängdes korrekt

Om en fil höll på att skrivas när datorn kraschade eller disketten togs ur, kunde filen lämnas i ett ofullständigt tillstånd.

I katalogen markerades den då ofta med en asterisk, exempelvis:

*SEQ

Sådana filer kallades ibland för splat files, poison files eller föräldralösa filer.

Problemet var att diskettens karta över använda och lediga block inte längre stämde överens med verkligheten. Det kunde i värsta fall leda till att två filer använde samma block eller att data skadades.

Commodore DOS hade därför kommandot VALIDATE, som gick igenom katalogen och byggde om kartan över ledigt utrymme.

På senare BASIC-versioner kallades motsvarande kommando ofta:

COLLECT

Funktionen kan jämföras med verktyg som CHKDSK i DOS och Windows.

Kommandokanalen

Diskettstationen styrdes genom en särskild kommunikationskanal som kallades kommandokanalen.

Den använde sekundäradress 15.

Ett BASIC-program kunde öppna kommandokanalen så här:

OPEN 1,8,15

Siffran 8 var normalt enhetsnumret för den första diskettstationen.

Genom kanalen kunde programmet skicka instruktioner som:

• formatera en diskett
• radera en fil
• byta namn på en fil
• kopiera en fil
• kontrollera disketten
• läsa felmeddelanden

Efter en operation kunde stationens status läsas tillbaka.

Ett normalt svar kunde se ut så här:

00,OK,00,00

Det betydde att inget fel hade inträffat.

Efter en omstart kunde en 1541-station i stället svara:

73,CBM DOS V2.6 1541,00,00

Detta fungerade både som ett statusmeddelande och som information om vilken DOS-version diskettstationen använde.

Numren i OPEN-kommandot

Ett typiskt kommando för att skapa en sekventiell fil kunde se ut så här:

OPEN 3,8,4,"0:ADDRESSBOOK,S,W"

Kommandot ser kryptiskt ut, men varje del hade en tydlig betydelse.

3 – filnummer

Filnumret användes av programmet i datorn för att identifiera den öppna filen.

Det motsvarar ungefär ett filhandtag eller en filidentifierare i moderna operativsystem.

Diskettstationen kände inte till detta nummer.

8 – enhetsnummer

Enhetsnumret berättade vilken fysisk enhet datorn skulle kommunicera med.

Den första diskettstationen använde normalt nummer 8. Ytterligare stationer kunde använda 9, 10 och så vidare.

4 – sekundäradress

Sekundäradressen angav vilken kommunikationskanal som skulle användas i diskettstationen.

Stationen kunde ha flera filer öppna samtidigt och använde sekundäradresserna för att skilja dem åt.

Kommandosträngen

Texten:

0:ADDRESSBOOK,S,W

talade om:

• att enhetens första drivmekanism skulle användas
• att filen skulle heta ADDRESSBOOK
• att filtypen var SEQ
• att filen skulle öppnas för skrivning

Systemet påminde på flera sätt om hur nätverksprotokoll och moderna lagringssystem skickar strukturerade kommandon till en separat styrenhet.

Den berömda Save-with-Replace-buggen

Commodore DOS kunde ersätta en befintlig fil genom att sätta ett snabel-a framför filnamnet:

SAVE "@MITT PROGRAM",8

Funktionen kallades Save-with-Replace.

Tanken var att användaren skulle kunna spara en ny version av en fil utan att först radera den gamla. Men under vissa omständigheter kunde kommandot skada diskettens innehåll.

Under flera år diskuterades det om felet verkligen existerade. Vissa hävdade att problemet berodde på användarna, dåliga disketter eller felaktiga program.

Så småningom kunde tekniskt kunniga programmerare visa att buggen var verklig.

Orsaken fanns i äldre programkod som hade utvecklats för Commodores diskettstationer med två enheter. När koden anpassades till 1541, som bara hade en enda drivmekanism, blev delar av den gamla logiken kvar.

Under vissa förhållanden skapades därför en sorts osynlig eller ”fantomartad” andra enhet i programvaran. Detta kunde leda till felaktig minneshantering och att förvrängd information skrevs till disketten.

Buggen rättades senare i nyare modeller och ROM-versioner, bland annat i 1541-II och vissa versioner av 1571.

Diskettstationen kunde köra egna program

Eftersom Commodores diskettstationer hade egna processorer kunde de göra mer än att bara läsa och skriva filer.

Commodore DOS innehöll kommandon för att:

• läsa från stationens minne
• skriva till stationens minne
• köra kod i diskettstationens processor
• läsa och skriva enskilda diskblock
• flytta läs- och skrivhuvudet
• förändra filsystemet på låg nivå

Detta gjorde systemet mycket kraftfullt, men öppnade också för kreativa lösningar.

Programmerare kunde ladda specialkod direkt till diskettstationen. Den kunde exempelvis användas för snabbare dataöverföring, kopieringsskydd, ovanliga diskformat eller avancerade demoeffekter.

Samma tekniska frihet utnyttjades både av kommersiella spelutvecklare och av den framväxande demoscenen.

Kreativa kataloger och dolda data

Eftersom katalogen kunde manipuleras direkt skapade programmerare ofta visuella effekter i diskettens fillista.

De kunde lägga in:

• skiljelinjer
• rubriker
• meddelanden
• tomma rader
• låsta filer
• poster som inte gick att ladda normalt

Vissa använde specialtecken eller nollbyte i filnamnen för att förvirra BASIC eller göra filer svårare att visa och kopiera.

En katalog kunde därför fungera som mer än en enkel fillista. Den kunde bli en startsida, en meny eller ett slags digitalt visitkort.

Detta var särskilt vanligt bland spelutvecklare, crackergrupper och demoscenprogrammerare.

Flera versioner av Commodore DOS

Commodore DOS utvecklades under många år och användes i ett stort antal stationer.

Några viktiga versioner var:

• DOS 1.0 för Commodore 2040 och 3040
• DOS 2.0 för Commodore 4040
• DOS 2.6 för 1540 och 1541
• DOS 3.0 för 1570 och 1571
• DOS 3.1 för den inbyggda 1571-stationen i C128DCR
• DOS 10.0 för 1581-stationen

Den överlägset mest kända versionen var DOS 2.6, eftersom den användes i Commodore 1541 och därmed blev en del av miljontals Commodore 64-system.

1581-stationen var betydligt modernare och använde 3,5-tumsdisketter. Dess DOS-version fick numret 10.0 och stödde ett annorlunda diskformat med större lagringskapacitet.

Ett tidigt distribuerat datorsystem

Commodore DOS kan beskrivas som ett tidigt exempel på ett distribuerat datorsystem.

Arbetet var uppdelat mellan två självständiga enheter:

Datorn ansvarade för:

• användarens program
• BASIC
• bildskärm och tangentbord
• programmets logik

Diskettstationen ansvarade för:

• filsystemet
• diskläsning och skrivning
• katalogen
• felkontroll
• diskkommandon

I moderna datorer finns liknande principer i avancerade hårddiskar, SSD-enheter, nätverkslagring och smarta styrenheter. Dessa innehåller egna processorer och egen programvara som hanterar information innan den skickas till huvuddatorn.

På så sätt var Commodores lösning både gammaldags och långt före sin tid.

Mer än bara ett DOS

Commodore DOS var inte ett komplett operativsystem för hela datorn på samma sätt som MS-DOS, Windows eller Linux.

Det styrde inte skärmen, tangentbordet eller användarens program. Dess uppgift var framför allt att hantera lagringsenheten och dess filer.

Trots detta var systemet tekniskt avancerat.

Det gav diskettstationen en ovanligt självständig roll och gjorde det möjligt för programmerare att experimentera direkt med dess hårdvara.

Systemet var ibland långsamt, hade flera egenheter och innehöll några allvarliga buggar. Men det bidrog också till den särpräglade datorkultur som växte fram runt Commodore 64.

För många användare var det knackande ljudet från en 1541-station bara ett tecken på att ett spel höll på att laddas.

I själva verket var det ljudet från en liten dator som arbetade.