|
Hardware og daglig brug Udseende At strømforsyningen var ekstern sparede en masse plads og minimerede problemer med støj. Så vidt jeg husker, skulle de to båndoptagerstik være forbundet med ledninger til tilsvarende stik på båndoptageren, når man gemte programmer. Når man modsvarende skulle indlæse programmer skulle den ene af ledningerne trækkes ud i den ene ende. Ellers virkede det ikke. Sådan var det bare, og det var ikke min båndoptager, som var speciel. At der var udgang til tv og ikke en rigtig computermonitor gjorde maskinen billigere. De fleste havde et ekstra tv et sted, om end det godt kunne være, at det var i sort/hvid. En monitor var uforholdsmæssig dyr den gang, og så kunne den jo netop kun bruges til computeren. Der var en lille indbygget højttaler i bunden nederst i højre side. Lyd på en Spectrum blev først på et meget sent tidspunkt noget som var værd at skrive hjem om. Der var nemlig kun en enkelt lydkanal, ingen dedikeret lyd-chip, og kun nogle meget primitive funktioner i rom´en til lyd.
Der var ikke nogen form for køling, og det kunne godt være lidt af et problem. Det store problem lå i, at rom´en kunne blive så varm, at den rent faktisk tog skade. Jeg fik rom´en skiftet to gange, fordi den havde fået "varmesyge". I praksis kunne det opleves ved, at rom´en fejladresserede, når den blev blot en lille smule varm (efter 3-4 minutter). Det kunne fx ses, når man spille Galaxian, ved at sprites blev "hængende" og ikke blev fjernet fra skærmen igen som de burde.
Hukommelsen De første 16 K (adresse 0 til 16383) var rom. Her lå hele BASIC-delen og alt hvad der havde med I/O at gøre. Det lyder måske fantastik, at det kunne lade sig gøre på 16 K, og det bliver egentlig ikke mindre fantastisk af, at det faktisk kun var de første 15 K, som blev benyttet. Der lå over 1 K fri! Dem som havde virkelig check på "det der", brændte gerne deres egen rom (med en EPROM-brænder), hvor de udnyttede det ledige kilo til fx at indbygge "turbo"-load/save! og diverse cracking-utilities! Samtidig rettede de også nogle af de fejl, som havde indsneget sig i rom´en.
Efter de første 16 K kom skærmbilledet. Det startede ved adresse 16384 (4000 hex) og fortsatte til 22527. Derefter var der frem til adresse 23295 attributter (farver i skærmbilledet). Opbygning af skærmbilleder kunne rent faktisk gøres ved at tildele en bestemt adresse en værdi, hvorefter resultatet blev vist på skærmen øjeblikkeligt, ved at 8 pixler tændte eller slukkede, alt afhængigt af hvilken værdi mellem 0 og 255 man havde brugt.
Området mellem 23296 og 23551 fungerede som skrivebuffer, og frem til 23733 var der systemvariable. Resten af hukommelsen, frem til 65536 (FFFF hex), var fri til programmer. Det giver vist omkring 41802 byte at gøre godt med, eller ikke engang 41 K!
Skæmbilledet Tastaturet Til daglig blev det gerne omtalt som et viskelædertastatur. Tasterne havde faktisk nogenlunde samme "konsistens" som små viskelædre – lidt i i retning af, hvad man vistnok stadig kan finde på nogle (måske lidt ældre) lommeregnere. Det var meget underligt at trykke på tasterne. Der var en noget irregulær gang. Først virkede det som om, der var lidt modstand i tasten, men pludselig gav den efter, hvorefter der var en kort og underlig blød afslutning. Den korrekte tekniske betegnelse for den slags tastatur er vist et gummimembramtastatur.
Man kan sige mange ting om en Spectrums tastatur, men der var én ting det var godt til, og det var til at kontrollere spil vha., i stedet for vha. et joystick. Jeg har aldrig hørt om nogen der spillede på en Commodore 64 vha. tastaturet. Alt foregik der vist med et joystick. Det var også muligt at bruge joystick på en Spectrum, men der var flere ting som talte imod. For det første var det forholdsvist dyrt at investere i et joystick. Der var på en Spectrum intet indbygget stik til et joystick, så først skulle man have et interface, hvorpå der var et stik. Men den væsentligste grund var nok, at tastaturet blot var ufatteligt godt til at spille med. Den lille og forholdsvis smalle, tynde kasse gjorde, at hænderne kunne ligge på en afslappet, ja, nærmest ergonomisk korrekt (!) måde, hen over tastaturet. Tasterne var jo temmelig bløde, så selv efter flere timers spil blev man ikke øm i fingrene. Der var heller ingen generende kanter eller lignende.
Den dag i dag bruger jeg stadig tastatur til at spille med på min pc, og vil til en hver tid indlade mig på en diskussion om hvad der er bedst og hurtigst – tastatur eller joystick. På en Spectrum var det helt klart tastaturet.
Det var en tid før det havde nogen praktisk betydning, hvor meget man havde bevæget joysticket. Hvis man bevægede det til venstre, kørte det man styrede til venstre, og hvor hurtigt man havde gjort det eller hvor meget man havde bevæget det, havde ingen praktisk betydning. Venstre var venstre, og gerne skulle man bevæge joysticket helt i bund, før der kom en reaktion på skærmen. Når man pludselig skulle i en anden retning, fx højre, så skulle man bevæge joysticket fra én yderstilling til en anden yderstilling. Det tog tid og nedsatte reaktionstiden. Selv hvis man på forhånd vidste, at man øjeblikket efter skulle flytte joysticket, så havde man en forholdsvis lang reaktionstid.
I modsætning hertil stod tastaturet. Fysisk skulle man bevæge tasterne langt mindre i forhold til et joystick. Hvis man fx styrede noget i en retning (fx højre), og vidste, at man kort derefter skulle lave to retningsskift (fx først op og derefter venstre), så trykkede man de to taster ned samtidig med, at man fortsat styrede mod højre. Man kunne derved lave to retningsskift lynhurtigt efter hinanden, ved blot at slippe tasterne i korrekt rækkefølge. At det i det hele taget kunne lade sig gøre skyldtes, at det var de færreste programmer, som var lavet til at kunne tage imod input fra to taster ad gangen (!)
Der var mange spil, hvor man ikke selv kunne definere hvilke taster, man ønskede at bruge til hvad, men hvor de i stedet var forudprogrammerede til noget brugbart. Jeg mener at huske, at der fandtes nogle enkelte spil (fx Sabre Wulf), som jeg ikke kunne finde ud af at spille, fordi jeg benyttede mig af tastaturet. Det var vist fordi tasterne var prædefinerede til et eller anden idiotisk indstilling (QWER til venstre-højre-op-ned eller lignende). Sådan var de fleste Ultimate-spil i begyndelsen. De fleste andre spil havde dog nogle fornuftige foruddefinerede taster, og ofte var det de samme fra spil til spil. Man kan derfor gerne genkende en gammel Speccy-gamer, der spiller på en pc vha. tastaturet, på, at piletasterne hurtigt bliver droppet til fordel for fx o/p til venstre/højre og q/a til op/ned.
Periferienheder Det var en forholdsvis stor blok hardware, som ikke sad direkte bag på maskinen, men var lavet som en flad pakke som skulle ligge under maskinen. Når den var monteret blev hele maskinen vippet fremover ligesom man kan gøre med et almindeligt tastatur (dog noget mere). Interface 1 gav primært mulighed for at tilslutte microdrives, som var Sinclairs "masselagringsmedie". I praksis var det en lille kassette hvori der lå et bånd i en uendelig løkke, der "emulerede" diskettedrev! Der var fuld direkte adgang (modsat et normalt kassettebånd hvor der var sekventiel adgang) og hurtig programindlæsning (kunne indlæse et typisk 48 K program på 9 sekunder). Hver kassette kunne lagre 85 K, og der kunne tilsluttes op til otte microdrives til et interface.
Microdrives fik hurtigt et rygte som værende upålidelige. Et af de tekniske problemer var, at det i praksis var en vis opstartstid førend der kunne læses fra båndet. Når man satte en kassette i drevet begyndte drevet dog at prøve at læse fra det med det samme, uden at det var kommet op i fart! Det gav visse problemer, og først på et forholdsvist sent tidspunkt blev problemet løse. Prisen var heller ikke med Sinclair. Fx var tomme kassetter med en pris på 5 £ ved fremkomsten ubehageligt dyre. Prisen blev dog halveret i 1985, og samtidig tilbød Sinclair gratis kopiering af kassetter til producenter af spil og programmer. Der var dog ikke så mange producenter som så fidusen, eftersom et tomt bånd inklusive kopiering kun kostede 50 pence.
I Interface 1 var der også et RS-232 interface indbygget, hvortil man kunne koble fx en printer eller et modem. Det var en elendig implementering af et sådan interface, som kun tillod envejskommunikation. Det kan i dag virke underligt, at noget så simpelt som et serielstik skulle være ekstraudstyk, men husk så lige på, at det på den originale IBM PC fra året før (1981) såmænd også var ekstraudstyr. Læg i øvrigt mærke til skiftet i terminologi. I dag snakker vi om seriel og parallelstik (lidt endnu), men den gang kaldte man dem udelukkende for et RS-232- eller et Centronics-interface! Den sidste feature i Interface 1 var ZX Net! Det var et reelt netværk (100 Kbit/s transferrate), hvor det var muligt at sammenkoble op til 64 Spectrum´er ved at daisy-chain´ne dem sammen. Der blev dog aldrig udbredt, for der kom aldrig nogle spil eller programmer som understøttede brug af netværk!
Interface 2 var udelukkende en konsol til brug for spil. Det havde plads til to joysticks og en rom-cartridge på toppen. Spil på cartridge til Spectrum blev dog heller aldrig noget hit, og Interface 2 var forsinket og dyrt (20 £) da det endelig kom. Andre producenter af udvidelsesudstyr til Spectrum havde for længst lanceret joystickinterfaces og skabt deres egne standarder herfor. De fleste interfaces fungerede ved, at man satte en konsol ind bag i maskinen, og så kunne man sætte to joysticks i ovenpå. Det krævede dog, at det enkelte spil understøttede de enkelte producenters interfacestandarder! Det var selvfølgelig langt fra alle spil som understøttede alt, men typisk blev mindst en 3-4 stykke understøttet. En måde at overkomme kompabilitetsproblemet på var at bruge et af de joystickinterfaces der ikke krævede understøttelse i software, men i stedet mappede de enkelte taster på tastaturet til joysticket! For hver funktion på joysticket (fx 4 retninger og to knapper) var der en ledning med et hanstik, og så havde man en plade med et hunstik for hver tast, arrangeret nogenlunde som tasterne tilsvarende var placeret på tastaturet. Hvis man spillede forskellige spil med forskellige (faste) tastaturindstillinger, skulle man på denne måde flytte rundt på ledningerne hver gang man skiftede spil!
ZX-skriveren Papiret som skulle bruges, var noget specielt papir med en tyk grålig belægning, som var følsomt overfor gnister. Når en lille metaltråd blev ført forbi papiret, og der samtidig blev sat spænding til, opstod der en gnist, der igen medførte at der blev lavet et lille svedent sort mærke på papiret. I virkeligheden var der blevet brændt et lille mærke i papirets specielle overfladebelægning. På den måde blev en udskrift opbygget, pixel for pixel.
Når man tænker lidt over det, kan man kun prise sig lykkelig over, at den slags teknologi er forsvundet. Dengang virkede det dog ikke helt så akavet, og der fandtes et forholdsvist stort marked for printere, som vi i dag vil se med stor undren på. En billig 9-nåls printer som fx en OKI Microline 80 (der var meget udbredt) kunne man måske være heldig at finde til omkring 1000-1500,- kr – vel at mærke brugt. Dertil skulle man så lægge prisen for et interface for i det hele taget at kunne slutte den til. Derfor fandtes der også billigere alternativer, men det var nogle underlige små indretninger med atypiske papirstørrelser, som jeg i dag tænker tilbage på som en slags forvoksede bónprintere. Nyprisen for en ZX-skriver var vist omkring 1000,- kr., men jeg købte en brugt til omkring 200-300,- kr. For overhovedet at få den til at skrive banerne ordentligt, måtte jeg skille den ad og rense den, og blandt andet rette de to små metaltråde, som sad monteret på et roterende gummibånd, til.
Kassettebåndoptageren At benytte en kassebåndoptager som lagringsmedie er ikke helt så brugervenligt sammenlignet med fx et diskettedrev. Der er nemlig ikke noget filsystem på et kassettebånd. Data er blot lyd, som ligger på båndet der, hvor man har optaget det. Ved at sætte et bånd i en båndoptager kan man derfor ikke danne sig noget overblik over, hvad der egentlig ligger på det pågældende bånd. Af samme årsag er man nødt til, på båndets omslag eller på et stykke papir, at skrive, hvad der ligger af data de forskellige steder på båndet, og så notere sig hvad tælleren står på, når man står ved starten af programmet!
Hvis man ville gemme fx et BASIC-program, som man havde programmeret, skrev man save "filnavn", trykkede på "record" og "play" på båndoptageren, hvorefter den begyndte at optage, og satte derefter hele processen i sving ved at trykke på retur på tastaturet. Når man skulle indlæse et program skrev man det modsatte – load "filnavn", trykkede på "play" på båndoptagen og derefter retur på tastaturet. I praksis skrev man dog blot load "" uden at anføre programnavn, for så ville den indlæses det første program som det fandt (starten af), og det var gerne det som var tilfældet. Inden da skulle man have sørget for at have spolet frem til der, hvor man mente programmet startede. Hvis man brugte et 90-minutters bånd, hvilket af hensyn til økonomien var ganske normalt, skulle man typisk spole helt tilbage til båndets start, nulstille tælleren, og derefter spole frem til der hvor programmet lå. Hvis man havde mere end 1 bånd var det fuldstændig uholdbart at prøve at holde styr på, hvad tælleren stod på ved skift mellem båndene. Alt i alt kunne den slags godt tage rigtig meget tid. Man kunne måske have brugt bånd, hvor der kun kunne være 1 spil på hver side, men det var der ligesom ikke økonomi i.
At modtage data som lyd fra en kassettebåndoptager kan sammenlignes med at modtage data via en fax eller et modem. Modparten kan ikke bare begynde at sende og så forvente, at man uden videre var klar til at modtage eller i det hele taget forstår, hvad det er der foregår. På en eller anden måde skal de to enheder synkronisere. Både et modem og en fax indikerer overfor modparten, at nu er der ved at ske noget, ved blandt andet at udsende nogle høje hyletoner, der derefter efterfølges af egentlig data.
Sådan fungerede det også med en Spectrum. Man skulle igennem adskillige hyletoner og korte stykker data, før den egentlige indlæsning af data begyndte. Først kom der en meget lang hyletone med en lille klump data. Den blev efterfulgt af en kortere hyletone og yderligere en kort klump data. Derefter kom der en lang hyletone, og så kom selv programmet. Men det var ikke slut med det. Når programmet var indlæst, skulle der også afsluttes med tre sekvenser af lange hyletoner med tilhørende korte dataklumper.
Når jeg så detaljeret kan redegøre for hvorledes det lød, når man indlæste et program, er det selvfølgelig fordi, at jeg har siddet og hørt på det tusindvis af gange. Når man indlæste et program, kunne man samtidig høre det over båndoptagerens indbyggede højttaler. Samtidig blev lyden konverteret til signaler, som blev vist i kanten omkring skærmbilledet. Hyletonerne blev vist som rød/blå vandrette striber, og data som mindre gul/blå striber. De rød/blå striber rullede pænt over skærmen i brede baner, mens de gul/blå blev vist som uordentlig småt krimskrams.
Jeg tror aldrig det gik fuldstændig op for mig, hvorledes det der med de rullende striber skulle forstås. Hvor hurtigt de rullede, og i det hele taget hvilken retning de rullede, kunne nemlig afhænge af en række ting. Det der påvirkede dem mest var toneindstillingen. Man kunne få det til at gå helt galt med synkroniseringen, hvis man lave den for dyb eller lys. Hastigheden, hvormed båndet blev afspillet, var vist det der påvirkede hvor hurtigt striberne rullede. Jeg tror nok, at det var meningen, at det skulle rulle nogenlunde stille og roligt nedad. Hvis en båndopgaver kørte blot en lille smule for hurtigt eller langsomt (i forhold til den båndoptager hvor båndet var blevet optaget på), kunne det straks ses på striberne. Hvis man havde lånt et bånd der var optaget på en båndoptager, som kørte alt for langsomt eller hurtigt, kunne det være helt umuligt at få indlæst programmer fra det.
Det gik jo mildest taget heller ikke alt for hurtigt. Ud fra manualen kunne man læse, at data blev overført med 1200 baud! Hvis man prøvede efter fandt man endog vist nok ud af, at det i praksis var nede omkring 1100 baud. Det tog typisk lige omkring 4 minutter at indlæse et spil på 48 K (inklusive skærmbillede). Det var faktisk hurtigt nok i de fleste tilfælde, og der kom aldrig de tusindvis af produkter til at speede hele processen om som der gjorde til Commodore 64. Det skyldtes nok, at en Commodore 64 kassettebåndoptager som standard kun kørte 300 baud (og en "1541" diskettestation 1200 baud!), så her var det indlysende, at der hurtigt måtte hjælpemidler til, i form af en eller anden form for "turbo-load". I praksis implementerede man rutiner i software der gjorde, at et spil kunne indlæses ved dobbelt hastighed eller lignende. Det kom også til Spectrum, men det var først en gang i 86/87 at det begyndte at blive normalt.
BASIC-programmering Af hver producent blev der udviklet en BASIC-fortolker, og det var på ingen måde muligt at flytte programmer fra maskine til maskine. Spectrums BASIC var modsat andre datamaters nogenlunde til at have med at gøre. Anderledes stod det til for fx Commodore 64, der var berygtet for den dårlige BASIC, hvor det for en udenforstående så ud som om, at der næste ikke fandtes andet en PEEK- og POKE-kommandoer.
Det kan i dag virke mærkeligt, at et programmeringssprog var indbygget i maskinen, og at der i det hele taget blev lagt så vægt på, at der skulle medfølge et programmeringssprog. Nu skal man lige huske, at der var meget begrænset hukommelse i maskinen, og at det derfor ikke var attraktivt eller i det hele taget praktisk muligt, at udvikle programmer meget ud over simple spil. Den var mest til leg, og hvad man ville have derudover måtte man lave selv. Derudover var opfattelsen af edb dengang, at det at lære noget om edb var ensbetydende med at lære at programmere! Da jeg fx havde datalære i folkeskolen (starten af 80´erne), gik faget kort og godt ud på at lære at programmere BASIC.
Hvis man indlod sig på BASIC-programmering blev man udsat for yderligere en Spectrum special feature. De fleste af sprogets elementer stod direkte på tasterne! Hvis man ville forsøge sig med et klassisk "Hello World" program, så trykkede man først på p-tasten. Derved blev der skrevet "print" på skærmen. Så skulle man have fat i et gåseøje, og så trykkede derfor shift-p. Derefter kunne man skive "Hello world" på normal vis, for til sidste at slutte af med et gåseøje. Det var både lidt belastende og lidt smart. Belastende fordi man ikke bare kunne skrive tingene. Lidt smart, fordi man samtidig med at man programmerede, fik syntakskontrolleret sin kode.
Crackning Men hvem fjernede egentlig ting i spil som var indlagt for at forhindre kopiering? Det gjorde de såkaldte "crackere" selvfølgelig, som var vores allesammens helte dengang. Ordet cracker lægger op til, at der et eller andet som skal "knækkes", nemlig en kode. Koden kunne fx være en talkombination man skulle indtaste for at komme til at spille et spil. Koden stod normalt i brugsanvisningen til spillet, men det var praktisk umuligt og uønskeligt at distribuere programdokumentation sammen med spillene (når vi altså snakker "uformelle" distributionskanaler). Så cracking gik altså ud på at fjerne den slags kedelige faciliteter fra spillene.
De fleste crackere arbejdede sammen i grupper. Disse gruppe havde det med at sætte deres præg på de programmer de havde cracket, fx ved at indskrive deres navn et eller andet sted i programmet, eller ved at indlægge specielle frontends i form af skærmbilleder med primitiv animation eller lignende. At fjerne koder var ikke helt ligetil. For det første skulle man være rimeligt ferm til assembler. Derudover kunne producenterne finde på at være så "onde", at de gjorde en del ud af at sløre det sted i spillet, som indeholdt den programstump, som fx kontrollerede, at en bestemt kode var blevet indtastes. Så der kunne sagtens være masser af udfordringer i at knække koder.
Et af de sidste antikopieringstiltag der kom frem (i min tid) hed lens-lock (det første spil med lens-lock var "Elite"). Det bestod af en lille stykke acryl eller lignende som var facetskåret. På skærmen blev der vist en kode som umiddelbart var ulæseligt, men når man holdt sit lens-lock op foran et bestemt område på skærmen (faktisk helt oppe på glasset), blev det udsnit af skærmbilledet man kunne se igennem "låsen" brudt på en særlig måde pga. den specielle slibning, og den tidligere ulæselige kode fremstod nu som normal tekst. Derefter skulle man så indtaste koden. Jeg har aldrig prøvet lens-lock, og kan kun forestille mig hvilke praktiske problemer det har medført, hvis man fx brugte et 24" tv (der var det største normale tv dengang), og ens lens-lock var lavet til brug på et 14" tv. Den slags idioti blev selvfølgelig cracket og fjernet med det samme
Kopiering af spil Når man skulle kopiere et program kunne man selvfølgelig prøve med den primitive metode, som bestod i at kopiere fra bånd til bånd. Det blev man hurtigt træt af, for en Spectrum var forholdsvist følsom overfor bånd- og optagekvalitet, og hvilken båndoptager den var optaget på! Tonehovederne kunne stå forskelligt, man måtte ikke have skruet for meget op, og tonekontrollen skulle gerne stå i en eller anden midterstilling. Hvis der opstod fejl under indlæsning af et program kunne man tydeligt høre det, fordi lydniveauet faldt brat og betydeligt idet maskinen opgav indlæsningen. Der var ingen form for styring af båndoptagerens start-, stop- eller optagefunktioner, så den kørte lystigt videre indtil man trykkede på stopknappen.
Til at kopiere måtte man derfor benytte et kopiprogram. Problemet var, at praktisk taget alle programmer fyldte hele hukommelsen. Derfor var der ikke plads til et kopiprogram. Finten var så, at kopiprogrammet kunne ligge i skræmhukommelsen! Først indlæste man kopiprogrammet. Eftersom det lå i skærmhukommelsen, blev koden præsenteret som tilfældige pixler på skærmen. Samtidig var det selvfølgelig umuligt at bruge skærmbilledet til normal tekst endsige grafik. For ikke at sidde og glo på noget intetsigende krimskrams, blev farveattibutterne, der ikke blev udnyttet til kode, brugt til at farvelægge skærmbilledet i matricer af 8 x 8 pixler. Med det kunne forfatteren så fx skrive sine initialer med vha. store barnlige bogstaver. De to nederste linier på skærmbilledet, linie 23 og 24, som det i øvrigt ikke var muligt at udnytte under normale omstændigheder, blev brugt til at vise de mulige kommandoer (load, save o.l.). Derefter indlæste man programmet, skiftede bånd, trykkede på "save" og ventede på, at programmet blev gemt igen. Så var den kopi lavet.
Der hvor det blev specielt, var når programmet fyldte mere end der kunne være i hukommelsen. Tit bestod et program af et skærmbillede der først blev indlæst separat, hvorefter resten af programmet fulgte. I princippet var det to uafhængige indlæsninger, hvor den anden indlæsning ikke blev påvirket af udstrækningen af pausen mellem indlæsningerne. Det var let nok at kopier den slags programmer ved at gøre det i to tempi. Sværere blev det straks, når både skærmbillede og program blev indlæst i eet langt 48 kilobyte langt program. Så var gode råd dyre, men de var der! Først blev kopiprogrammet indlæst. Derefter blev programmet, fx et spil, indlæst, men kun for at kopiprogrammet kunne finde ud af, hvor mange byte spillet fyldte, hvorfor det ikke blev lagret i hukommelsen. Spillets størrelse og en eller anden slutværdi skulle man notere, hvorved spillet skulle indlæses en gang til. Inden indlæsningen angav man størrelse og slutværdi til kopiprogrammet. Det fulde spil blev derefter indlæst med brug af skærmhukommelsen, hvorved kopiprogrammet selvfølgelig blev slettet. Et eller andet sted lå der dog en rutine på nogle få byte, som kunne starte "save" funktionen. Når spillet var færdigindlæst, hvilket man identificerede ved, at der ikke længere kom støj fra båndoptageren og var blåt/gult krimskrams i rammen omkring skærmbilledet, skiftede man bånd, trykkede på "record", og trykkede derefter på en bestemt tast på tastaturet. Derved blev spillet gemt i sin fulde længde. Efter at det var blevet gemt nulstilledes maskinen, og kopiprogrammet kunne genindlæses, og man var klar til næste kopi! Hele processen tog omkring 12-14 minutter.
Copyright 1998 Søren Tjørnov.
|