Vi gjør det lettere å forstå hvor begrensede klassiske datamaskiner og konsoller var.
Alle skjønner at en klassisk datamaskin som en Commodore 64 har forferdelig lite minne og lagringskapasitet, sammenlignet med dagens plattformer. Selv en typisk mobiltelefon har nesten uendelig mye mer minne enn en typisk datamaskin eller konsoll fra den første halvdelen av åttitallet. Men når man skriver at Commodore 64 hadde 64 kilobytes med internminne (RAM) – hva betyr faktisk det i praksis? Hvor mye er egentlig 64 kilobytes?
Det skal jeg forsøke å forklare i denne artikkelen.
Du har sikkert hørt at datamaskiner kommuniserer og lagrer informasjon ved hjelp av nuller og ett-tall. I utgangspunktet skulle en tro det er temmelig vrient å formidle noe som helst når man bare har to muligheter å velge mellom, men som vanlig har folk kommet opp med finurlige løsninger som utvider mulighetene betraktelig. Noen av disse løsningene er langt eldre enn de elektroniske datamaskinene er.
Det er rekkefølgen som teller
Tenk deg en lyspære. Den kan være av (0) eller på (1). Ved å skru av og på lyspæren i spesifikke sekvenser, kan du bruke den til å kommunisere. Om ikke annet, bør de fleste av oss vite hvordan man ved hjelp av lysblink og Morse-kode kan få andres oppmerksomhet om man trenger det. Om du vet at tre korte lysglimt representerer bokstaven S og tre lange representerer bokstaven O, kan du få lyspæren din til å stave SOS – «jeg trenger hjelp!».
Datamaskinens nuller og ett-tall sier med andre ord fint lite hvis man leser dem ett og ett, men når de settes sammen i system, så kan de si veldig mye.
| Merk: Når jeg skriver at én byte er åtte bits, er det fordi dette har blitt standarden med årene. Men i datamaskinens barndom var det ikke slik, og det finnes stormaskin-systemer der én byte er mindre enn åtte bits (som seks bits eller syv bits). Det er ingen regel som sier at én byte må bestå av åtte bits. Tidligere brukte man begrepet octet om en byte med åtte bits.
Merk 2: Det finnes også enkelte datasystemer der én bit har tre mulige verdier (-1, 0 og 1), ikke bare to. Hovedsaklig er det her snakk om obskure, sovjetiske stormaskiner, men enkelte mener at fremtidens datamaskiner kan følge denne modellen. Merk 3: For full forvirring – begrepet «kilobyte» kan referere til både 1000 bytes (1 kB) og 1024 bytes (1 KB). I tilfellene diskutert her, er det 1024 bytes som gjelder. Dette kalles også 1 kibibyte. |
Det er her begrepene «bits» og «bytes» kommer inn i bildet. En enkelt 0 eller 1 (eller i realiteten, ett enkelt tilfelle av «av» eller «på») kalles en «bit». Hvis man setter åtte «bits» sammen, får man én «byte». En byte er altså en samling åtte nuller og ett-tall etter hverandre – 01101101 for eksempel.
Hvis du prøver alle mulige kombinasjoner av åtte ett-tall og nuller, finner du ut at det er 256 av dem. Det betyr altså at ved å sette sammen tallene i ulike konfigurasjoner, kan du ved hjelp av én «byte» representere et hvilket som helst tall fra og med 0 til og med 255.
Tallene kan så brukes til å representere andre ting igjen, slik som tegn eller piksler på skjermen.
På åttitallet var det vanligst å måle lagringskapasitet i antall «kilobytes». En kilobyte er i dette tilfellet 1024 bytes (eller det som kalles en kibibyte). Altså: 1024 individuelle tall mellom 0 og 255. Internminnet til Commodore 64 har plass til 64 slike kilobytes. Uten å komplisere det for mye, betyr det at Commodore 64 har plass til cirka 65 500 individuelle tall mellom 0 og 255 i minnet sitt, samtidig. Hvis man tenker at hvert tall kan representere ett tegn, betyr det at man har plass til omtrent 65 500 tegn i minnet til en Commodore 64.
For å sette det i perspektiv: Denne teksten er alene på omtrent 13 500 tegn. Om teksten hadde vært bare fem ganger så lang, så hadde tegnene den består av fylt opp hele minnet til en Commodore 64, og enda litt til.
Det sier forhåpentligvis litt om hvor lite Commodore 64-minnet er, og hvor mye effektive spillutviklere får ut av den lille plassen.
| Kjempemorsom fakta: Minnet til en Commodore 64 er delt inn i 65 535 separate posisjoner (addresser), som altså hver kan ha en verdi mellom 0 og 255. Noen av disse posisjonene har spesifikke, faste bruksområder, mens andre kan brukes fritt. BASIC-kommandoene POKE og PEEK lar deg henholdsvis skrive til og lese fra individuelle minneposisjoner.
Når du skriver POKE 53281,0 – som enhver Commodore 64-veteran vil gjenkjenne som en kommando man kan skrive inn for å gi bakgrunnen sort farge, sier du til datamaskinen at minneposisjon 53281 skal ha verdien 0. I BASIC er denne minneposisjonen dedikert til akkurat bakgrunnsfargen på skjermen, og ingenting annet. Tallene 0-15 representerer hvert en av maskinens 16 forskjellige farger, og bakgrunnsfargen endres automatisk når tallet i posisjon 53281 endres. Her er en oversikt over alle posisjonene i maskinens minne, og hva de brukes til. |
Det er mer komplisert enn som så
Maskinen trenger også en viss porsjon av minnet for å kjøre essensielle rutiner, og mye av minnet er i tillegg dedikert til spesifikke systemer, så det er ikke slik at et spill kan gjøre nytte av hele minnet. Når en Commodore 64 starter, tar programmeringsspråket BASIC opp en god porsjon av minnet, og man vil kun ha 38 911 bytes ledig for BASIC-programmer. Det er veldig lite, noe alle som har prøvd å lage tekstbaserte spill i BASIC kan skrive under på. Spill og andre programmer kan heldigvis spyle BASIC ut av minnet, og dermed bruke plassen BASIC ellers ville tatt opp for mer matnyttige ting som musikk og grafikk.
Et Commodore 64-spill kan altså aldri bruke mer enn i underkant av 64 kilobytes med minne samtidig. Det betyr ikke at det ikke kan være større enn 64 kilobytes – på samme måte som moderne spill, kan også Commodore 64-spill laste inn ny data underveis samtidig som gammel data slettes. Men der et moderne spill gjør dette via lynrask harddisk eller (ikke like lynrask) Blu-ray, bruker Commodore 64 en smertefullt langsom diskettstasjon eller en helt usannsynlig forferdelig langsom kassettspiller. Sistnevnte er også avhengig at informasjonen ligger i rett sekvens, siden den ikke automatisk kan spole frem og tilbake for å finne akkurat de riktige filene.
Typiske Commodore 64-spill for det europeiske markedet ble lansert på kassett. Det vanligste var da at hele spillet lastet inn i én omgang, noe som altså begrenset størrelsen til godt under 64 kilobytes. Alternativet var at individuelle brett lastet inn i sekvens (da var det ofte slik at hvis du først hadde nådd nivå to i et spill, gikk du ikke tilbake til det første igjen før du startet spillet på nytt). Større rollespill, eventyrspill og strategispill, som var avhengige av å dynamisk laste inn masse små filer underveis, kom derfor kun ut på diskett. Men selv en standard 5,25-tommers diskett hadde kun plass til 170 kilobytes på hver side.
Hva så med andre plattformer?
På konsoller, som Nintendo Entertainment System, er situasjonen litt bedre. De brukte nemlig kun elektroniske kassetter («cartridges»), som i praksis fungerer som dagens minnekort (bare at de var voldsomt mye større, rent fysisk, og samtidig hadde enormt mye mindre lagringsplass). Dermed kunne de laste inn ny data så raskt at brukeren ikke la merke til det – en betydelig fordel, som gjorde at det begrensede minnet ikke var et like stort problem som på plattformer som Commodore 64.
Ikke bare det, men de elektroniske kassettene kunne ha ekstra elektronikk for å på den måten forbedre konsollens egenskaper på en rekke forskjellige måter. Så når jeg skriver at NES har så lite som 2 kilobytes med arbeidsminne og 2 kilobytes med grafikkminne, så sier ikke det så veldig mye. Ikke bare kan konsollen lynraskt flytte informasjon fra den elektroniske kassetten til minnet, men de elektroniske kassettene kan inkludere ekstra minne som konsollen så kan bruke. Med andre ord kan man si at mengden minne en NES har, avhenger av hvilket spill som står i. Kassettene kom forøvrig også i forskjellig størrelse – de minste var på 8 kilobytes, og de aller største var på hele én megabyte.
Apples første Macintosh hadde 128 kilobytes med minne – bare dobbelt så mye som en Commodore 64, altså (og like mye som Commodore 128). Neste modell fikk litt mer fornuftige 512 kilobytes. Den første Amiga-modellen, Amiga 1000 hadde kun 256 kilobytes med minne, så heller ikke her er det snakk om enorme mengder. Amiga 500 hadde 512 kilobytes, og det ble etter hvert vanlig å oppgradere denne til å ha én hel megabyte med RAM. Det er altså 1024 kilobytes. Dette var standard i Amiga 600, mens Amiga 1200 hadde hele 2 MB RAM. Disse kunne igjen oppgraderes – min egen fikk etter hvert 16 MB ekstra minne.
Den første PlayStation-konsollen hadde overraskende nok bare 2 MB hovedminne, men det hjalp at den også hadde 1 MB med videominne. PlayStation 2 hadde totalt 36 MB (der 4 MB var lynraskt eDRAM). På PC-siden har disse tallene alltid vært flytende, siden man generelt har så mye RAM i en PC som man føler man har råd til å putte i den. Jeg skal overlate til noen andre å skrive om EMS, XMS og alle disse begrepene som gjorde PC-konfigurering på åtti- og det tidlige nittitallet til et eneste stort mareritt.
I dag snakker vi normalt om gigabytes når det er snakk om arbeidsminne – én gigabyte er altså tusen megabytes. Du kan selv regne på hvor mange Commodore 64-minner det går inn i minnet på datamaskinen din.
Hva betyr tallene i en byte?
For moro skyld, skal jeg nå forklare hvordan du kan finne tallverdien til en «byte». Det er nemlig ganske lett, og et veldig kult party-triks (kanskje ikke, men det er artig å kunne).
Det sentrale her er posisjonene til de individuelle tallene, og hva disse igjen representerer. Det er altså åtte posisjoner, som hver kan ha tallet 0 eller 1 i seg. Fra høyre(!) representerer de individuelle posisjonene følgende tall: 1, 2, 4, 8, 16, 32, 64 og 128. Altså: 00000001 representerer tallet 1. 0000010 representerer tallet 2. 00000100 representer tallet 4. 00001000 representerer tallet 8. Og så videre.
Så kommer det finurlige: Ved å legge sammen ulike kombinasjoner av tallene 1, 2, 4, 8, 16, 32, 64 og 128, kan vi komme frem til alle enkelttall opp til 255. I tillegg har vi 0, som vi enkelt representerer ved å ikke legge inn noen ett-tall overhodet.
Så hva med den tilfeldige «byten» jeg skrev helt i starten av teksten – 01101101?
Jo, her ser vi at det er ett-tall i posisjonene som representerer følgende tall: 1, 4, 8, 32 og 64. Plusser man disse tallene sammen, blir summen 109. Så: 01101101 betyr 109. Med penn og papir eller hoderegning, kan du altså gjøre akkurat det samme en datamaskin gjør når den forvandler ett-tall og nuller til informasjon den kan bruke.
Så kan du selvsagt ta det ett steg videre, og konvertere tallene til tegn og bokstaver via for eksempel den tradisjonelle ASCII-standarden. ASCII-verdien 109 står for «m». Greit å vite hvis du spiller et virkelig djevelsk eventyrspill, for eksempel.
Men hva betyr «8-bit», «16-bit», og så videre?
Dette er litt på siden av temaet for artikkelen, men du har garantert hørt at plattformer som Commodore 64, Nintendo Entertainment System, ZX Spectrum og Sega Master System er «8-bits»-plattformer, mens Amiga 500, Super Nintendo Entertainment System og Sega Mega Drive er «16-bits»-plattformer. PC-er fra nittitallet, og konsoller som Sony PlayStation og Amiga CD32, er 32-bits. Og i dag er det meste 64-bits. Eller, det burde i alle fall være det.
En typisk 8-bits-plattform har en hovedprosessor som kan drive utregninger med åtte bits samtidig. Altså det samme som én byte – åtte individuelle tall mellom 0 og 255. Skal den arbeide med større verdier, må den altså bytte ut og inn informasjon dynamisk – ikke spesielt effektivt, men selv en 8-bits-prosessor er et regnebeist sammenlignet med vår egen hjerne, så den kan gjøre flere tusen slike kalkulasjoner i sekundet.
En 16-bits-plattform har en hovedprosessor som kan naturlig nok drive utregninger med 16 bits samtidig, altså dobbelt så mange som en 8-bits-prosessor kan. I utgangspunktet kan man derfor tenke seg at den har dobbel kapasitet, men det er ikke så enkelt. For betegnelsene 8-bits og 16-bits sier ingenting om hvor raskt prosessoren klarer å bytte ut tallene den jobber med. I teorien kan en 8-bits-prosessor arbeide raskere enn en 16-bits-prosessor, selv om den er mindre effektiv.
I tillegg er det ikke sånn at alle plattformer er «rene» – en Amiga 500 klassifiseres vanligvis som en 16-bits-plattform, men prosessoren er egentlig en 32-bits-prosessor. Dessuten består disse maskinene selvsagt også av massevis av andre komponenter som avgjør ytelse og egenskaper.
Det er med andre ord ikke supernyttig å klassifisere plattformer etter «bits», da det ikke sier spesielt mye om de faktiske egenskapene deres. Det kan til og med være direkte misvisende, siden enkelte plattformer i praksis er hybrider. Samtidig markerer spesielt overgangen fra 8-bits-plattformer til 16-bitsplattformer et enormt generasjonshopp i spillmaskinenes utvikling, av en hel bråte forskjellige grunner, så på akkurat det området er det greit å bruke betegnelsene for å skille generasjonene.
Om toppbildet: Jeg lagde bare et lite C64-program for å ploppe ut tilfeldige tall i bolker på åtte, og tok så bilde av skjermen mens det kjørte. Hvem trenger Shutterstock og Gettyimages? Ikke vi (for vi har ikke råd til arkivbilder, og må lage C64-programmer i stedet).
Takk til Mats Lindh for hjelp med artikkelen.