Sinclair ZX80 40 års jubilæum
Sinclair ZX80 er en af de virkelige pionerer, den første maskine i Storbritanien - og formodentligt også Europa, som som var tilgængelig for "almindelige mennesker". Maskinen kunne erhverves for under 100 £ og hvis du havde mod på at lodde selv kunne den fåes til 79£.
Maskinen var meget begrænset, med kun 1 Kilobyte hukommelse var det meget begrænset hvad den kunne bruges til. Men for mange var den gateway-drugget der ledte til større maskiner, og for Sinclair viste det vejen der resulterede i en lang serie af hjemmecomputere bygget på Z80 processoren.
I denne her video fejlrer jeg de 40år ved at teste en ZX80'er jeg, meget modigt, har købt som "untested" på EBay :-)
- emailE-mail
- linkKopier link
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
- Sortér efter chevron_right
- Trådet debat
Re: Micro Men</p>
<p>Mange tak for tip</p>
<p>Har lige set filmen gratis her:
Velbekomme. Jeg tror også den er tilgængelig på YouTube.
Der er mere her, hvor man åbenbart også skulle kunne se Chris Curry, Steve Furber og Hermann Hauser se filmen Micro Men:http://www.computinghistory.org.uk/news/55409/
PS: Og man kan i øvrigt læse en masse om BBCs Computer Literacy Program her:https://clp.bbcrewind.co.uk/
Mange tak for tip
Har lige set filmen gratis her:https://archive.org/details/MicroMen720p2009
Fantastisk ;-)
Tingene var lidt sjovere dengang.
Ja, nu kan alle computere stort set det samme -- nogle er måske lidt hurtigere end andre, har mere lager, eller større grafikkort. Men de kan allesammen køre de samme programmer -- og bruge de samme 117 programmeringssprog. Dengang havde hver computer sin egen dialekt af BASIC, fra de ret primitive (f.eks. Commodore) til mere avancerede med struktureret programmering og grafikfunktioner til at tegne linjer, trekanter, firkanter, osv. (f.eks. BBC BASIC). Og man havde mere direkte adgang til skærmlager osv, så man kunne lave assemblerrutiner til hurtig grafik. Nu er det hele gemt under 7 abstraktionslag.
Jeg vil ikke sige, at det absolut var bedre dengang -- tvært imod -- men det var mere interessant. Der var en slags pionerånd over hele hjemmecomputerverdenen.
Hvis man er interesseret i hvad der skete dengang, så kan jeg varmt anbefale TV-filmen Micro Men https://www.imdb.com/title/tt1459467/
Den handler bl.a. om Clive Sinclair, men også om hans konkurrenter hos Acorn, som jo endte med at vinde kontrakten med BBC.
Andre nævnte Acorn Atom, som var min egen første 'rigtige' computer (hvis man da ikke tæller en programmerbar lommeregner, for jeg havde en TI-59 før det).
Tingene var lidt sjovere dengang. Jeg kan stadig huske en computermesse i Forum, hvor man kunne prøve alle de forskellige hjemmecomputere, såsom ZX80/81 (og vist også Spectrum), Oric, Lynx, Amstrad osv. osv.
Han arbejdede på Danfoss ;-)
For mange år siden købte min far en computer på sit arbejde, hvor han og kollegerne købte stort ind sammen, de valgte en Lambda computer der er en ZX81 klon
Et skud i tågen: Arbejdede han på NKT elektronik i Brøndby ?
Der er forskel på, hvordan brugerprogrammer skrives og hvordan programmer til flyvemaskiner, raketter, osv. skrives. Typisk har sidstnævnte meget præcise specifikationer, og der anvendes formel verifikation i stor stil.
Der er selvfølgelig også fejl i software til fly m.m. Et eksempel var Boeing 747 Max, hvor styrtene skyldtes fejl i software. Men det skyldtes ikke dårlige programmører m.m., men at ledelsen havde bestemt, at man ville overføre softwaren fra tidligere 747-modeller atort set uændret, selv om del del parametre var skiftet. Det var for at undgå den dyre og langsomme godkendelsesprocedure, som nye flymodeller skal igennem. Så ved at kalde det en lille variant af en allerede godkendt model, kunne de slippe. Men forskellene var ikke så små endda.
Et lignende problem havde Ariane 5 raketten. Her brugte man også softwaren fra tidligere Ariane-modeller, men da motorerne var kraftigere, fik man overflow i nogle beregninger, der ikke gav overlow tidligere.
Moralen er: Du skal kun springe verifikationen over , hvis du er helt sikker på, at ingen parametre har ændret sig.
Jeg vil vove den påstand, at hvis man skulle lave Apolloprogrammet fra scratch i dag, og plørede alt softwaren sammen på samme måde som man gør nu om dage, så ville man aldrig nå til månen.
Der er forskel på, hvordan brugerprogrammer skrives og hvordan programmer til flyvemaskiner, raketter, osv. skrives. Typisk har sidstnævnte meget præcise specifikationer, og der anvendes formel verifikation i stor stil. Så kvaliteten er ikke ringere end i 1969, selv om programmerne er meget større end dengang.
Det, der giver mange fejl i "almindelige" programmer, er primært tre ting:
- Upræcise specifikationer, der har det med at ændre sig hele tiden under udviklingsforløbet.
- At det koster mange penge at lave formel verifikation og testing på det niveau, som rumindustrien kræver.
- Kontrakter på software har ikke tilstrækkeligt høje krav til fejlfri kode. Det hænger lidt sammen med punkt 2.
Det bliver jo nok svært bare at få de nødvendige komponenter nu om dage, for at lave en simpel maskine med noget der minder om en 8080/Z80/6502, ram og romkredse, samt div i/o, så man 100% kan forstå alle byggeklodserne.
Arduino er meget populært. Chippen har godt nok en smule rom og ram indbygget, men derudover er der ikke meget. Intet operativsystem.
Man kan også få billige FPGA udviklingskits. Så er man på helt bar bund :-)
Og endelig så er alle de chips du nævner faktisk stadig tilgængelige.
Helt enig med dig. Personer fra den gamle "østblok" er ofte meget veluddannede, og ikke forvendt med at der er ressourcer nok. De er gode til at tænke sig om inden de laver noget.Jeg har ikke lyst til at nævne specifikke uddannelser, men jeg oplever at de kandidater jeg møder fra Ukraine+Rusland er dygtigere når det handler om core software udvikling.
Det har formodentligt været AMD 2901. Det var den dominerende bit slice. 74181 var en rå ALU uden registre.16-bit CPU med 4x4-bit slice kerner
Der er magi i systemet. Et niveau ned er instruktionssættet (kodning i assembler). Laget der under er mikroprogrammeringen af chippen. Under det igen kommer biblioteket af logiske funktioner og længere nede transistorerne og halvleder teknologien. Man kan ikke være specialist på alle områder. Dette gør at man er nødt til at erkende hvor dybt man går ned f.eks. til instruktionssæt. Det er også en rigtigt god ide at kunne gå mindst et trin længere ned, end det trin man selv arbejder på. Jeg kan huske tilbage fra min studietid at jeg, efter at have konstrueret med transistorer, var frustreret over at jeg ikke kunne forstå de indre detaljer i en operationsforstærker. Her måtte jeg erkende at dette var en byggeblok, at ækvivalentdiagrammet ikke nødvendigtvis viste hele sandheden men at man skulle abstrahere til at det var en byggeblok.Jeg tror det var Christian Nobel der skrev at der ikke må være noget magi i systemet. Det er jeg ganske enig i. Hvis man skal lave IT på højt niveau så skal man forstå hvad der sker.
Jeg kan som "dinosaur" lige så vel spørge hvorfor du ikke har lært at opbygge en processorkerne med 74181 eller bitslice og mikroprogrammeret de enkelte instruktioner?
He he he ... hvor ved du fra at jeg ikke har lært det? Måske er jeg også en af dunosaurne?
Jeg kan ærligt talt, ikke huske om det var en 74181 vi brugte, men vi designede og byggede en 16-bit CPU med 4x4-bit slice kerner. Nu er det mange år siden men jeg husker at vores 2 stage instruction pipelining var et sted hvor vi skulle redesigne skidtet i flere omgange for at få det til at virke. Men som jeg husker det endte vi med at få skidtet til at køre ganske hurtigt (om end lidt ustabilt) ...
Hvorfor skal de lære det hvis de ikke har brug for det, heller ikke som baggrundsviden.
Jeg tror det var Christian Nobel der skrev at der ikke må være noget magi i systemet. Det er jeg ganske enig i. Hvis man skal lave IT på højt niveau så skal man forstå hvad der sker. Et godt eksempel på hvor den underliggende arkitektur kryber op i abstraktionsniveauet er parallel-computing. Her er man selv i sprog som Java/C# nødt til at forstå hvad der sker i maskinen med Numa, cache-coherency hvis man laver noget der kræver virkelig høj performance.
Hvor er det man ikke lærer det? Jeg synes da, at jeg har haft den slags både på datamatiker og ingeniørstudie?
Men der er selvfølgelig mange uddannelser.
Jeg har ikke lyst til at nævne specifikke uddannelser, men jeg oplever at de kandidater jeg møder fra Ukraine+Rusland er dygtigere når det handler om core software udvikling. Det er min helt personlige holdning ... den reflekterer på ingen måde min arbejdsplads.
<em>...tid der nok kunne være brugt mere fornuftigt ... fx. på at gå i skole :-)</em></p>
<p>Du lærte en hel del af denne øvelse som du nok har haft brug for i livet...
Jeg kan se på min egen søn hvor meget tid der kræves på eksperimenter når man lige begynder på software udvikling. Det meste fører ingen veje men han bliver lige så stille klogere af det hele.
Nej, det var det ikke, den var sjov at arbejde med men der skulle også bruges lang tid på trivialiteter og anvendelsesmulighederne var begrænsede.
Det er jeg ganske enig i.
Jeg vil vove den påstand, at hvis man skulle lave Apolloprogrammet fra scratch i dag, og plørede alt softwaren sammen på samme måde som man gør nu om dage, så ville man aldrig nå til månen.
Risikoen er at man ville forvente meget mere og at man ville forsøge at gøre det hele mere sikkert fordi man kunne. Det er i sidste ende IT branchens store problem: Vi forsøger at gabe over meget mere end vi kan. Men hvis målet var at lave en AGC hvor det var ok at fejl blev rapporteret blot som 1201 på et hex-display, så kunne vi nok lave det hurtigt.
Du kan sige at det var simple maskiner, men det er nok i virkeligheden de begrænsede (færdigstrikkede) anvendelsesmuligheder som du kalder det, der er hele basis for den dannelse mange udviklere har.Nej, det var det ikke, den var sjov at arbejde med men der skulle også bruges lang tid på trivialiteter og anvendelsesmulighederne var begrænsede.
Som mange andre har skrevet her, det er nemt nok at pløre en "Hello World" sammen under et framework, og ende med en 15MB fil, men mulighederne for fejl er astronomiske.
Hvis man skal blive god til et håndværk, så er man (og det har ikke noget med pladderromantik at gøre) nødt til at lære det nedefra.
Jeg vil vove den påstand, at hvis man skulle lave Apolloprogrammet fra scratch i dag, og plørede alt softwaren sammen på samme måde som man gør nu om dage, så ville man aldrig nå til månen.
Nej, det var det ikke, den var sjov at arbejde med men der skulle også bruges lang tid på trivialiteter og anvendelsesmulighederne var begrænsede.
Der er altså sket meget på 40 år.....
Du lærte en hel del af denne øvelse som du nok har haft brug for i livet......tid der nok kunne være brugt mere fornuftigt ... fx. på at gå i skole :-)
Svaret er både ja og nej. Hvorfor skal de lære det hvis de ikke har brug for det, heller ikke som baggrundsviden. Jeg kan som "dinosaur" lige så vel spørge hvorfor du ikke har lært at opbygge en processorkerne med 74181 eller bitslice og mikroprogrammeret de enkelte instruktioner? Svaret er formodentligt, det var der ikke brug for. Du kunne få noget der skjulte/håndterede den kompleksitet. Allerede den gang arbejdede man at hæve abstraktionsniveauet, lige som man gør i dag. Virkligheden er at selve processorkernen i dag kan så meget mere, selv med lidt lager. Der er ikke et marked for en rå microprocessor. Du kan lige så godt integrere de ydre enheder ind i den. Det har man gjort siden Intel 8048. For de aller fleste dækkes deres behov af de programmeringsgrænseflader / API'er der stilles til rådighed eller ved at de kan tilgå byggeblokke der kan løse deres problem. Det er vigtigt at tærsklen ikke er for høj og at de ret hurtigt kan se resultater. Ellers går man kold. Hvis man endelig vil ned i "nitty gritty details" så kan man kaste sig over Atmels, nu Microchips, ATTiny microcontrollere. Får ned til 32 byte RAM og 512 byte flash, i et 6 benet hus. Sidder selv lige nu med et projekt med en ATTiny 2313 med 128 byte RAM og 2 kbyte flash. Programmeret i 'C'.at man så også har lært det basale i hvordan maskinkode fungere, hvordan en CPU er opbygget,
For mange år siden købte min far en computer på sit arbejde, hvor han og kollegerne købte stort ind sammen, de valgte en Lambda computer der er en ZX81 klon (markant anderledes tastatur med grønne gummi-taster)
Det var meningen at det skulle være en gave til min bror og jeg, men da brormand ikke brændte for programmering og at jeg derimod synes at det var spændende at indtaste programmer fra tyske computerblade, så endte det med at blive min computer
Lambda computeren kunne ikke rigtigt noget, med mindre at man programmerede det selv, i starten var det spændende at indtaste og spille diverse spil, primært Basic-programmer, men også noget i assembler, jeg lærte meget af at indtaste andres programmer - senere forsøgte jeg at løse små problemstillinger i hverdagen
Computeren blev opgraderet med et hukommelsesmodul da jeg let kunne lave et program der ramte loftet, det blev til mange timer med Lambda, men den døde til sidst da visse taster, hvis man ramte dem på en bestemt måde, resatte computeren
Så købte jeg en ZX Spectrum, det var en naturlig opgradering, da jeg kunne fortsætte med basic programmering (og der kunne anskaffes fantastiske programmer og spil) - kronen på værket var da jeg i gymnasiet lavede et program til at terpe faste vendinger i fransk, da det var et fag som jeg havde svært ved og helt havde opgivet at forstå grammatikken, jeg lavede et program som kunne gemmes sammen med 30 faste vendinger på fransk og dansk, jeg kunne under opstart vælge at indtaste på dansk eller fransk, programmet udvalgte 20 ud af de 30 vendinger per runde, jeg fik en statistik på rigtige/forkerte efter endt runde, når jeg havde alle rigtige hver gang, kunne jeg gå videre med næste sæt af faste vendinger – på den måde lykkedes det at gå fra et 6-tal til 8 i karakter
Min kære gamle Lambda computer endte også med at være starten på en IT-karriere, det har været en fantastisk rejse med en helt ung industri i starten af 80’erne, der har taget gigantiske skridt hvert år siden da
Har ikke kunnet nære mig, jeg har bestilt en moderne version af ZX spectrum på Kickstarter, den leveres indenfor 1-2 måneder, efter flere års ventetid, glæder mig som det lille barn jeg også er ?
ZX Spectrum Nexthttps://www.kickstarter.com/projects/1835143999/zx-spectrum-nexthttp://www.specnext.com/
Jeg brugte meget tid på at omskrive fin Pascal kode til maskinkode ... tid der nok kunne være brugt mere fornuftigt ... fx. på at gå i skole :-)
Det vækker minder, for den vogn var jeg også med på. I mit tilfælde dog som oftest for at få det til at virke i et TSR program.
Jeg kunne til gengæld godt ønske mig at når man træder ud af en IT-uddannelses institution hvor man er blevet teoretisk mester i højniveausprog, at man så også har lært det basale i hvordan maskinkode fungere, hvordan en CPU er opbygget, hvordan virker ethernet, etc. Men jeg mener ikke alle behøver at vide den slags, hvorimod jeg mener alle skal lære hvad code er.
Hvor er det man ikke lærer det? Jeg synes da, at jeg har haft den slags både på datamatiker og ingeniørstudie? Men der er selvfølgelig mange uddannelser.
https://en.wikibooks.org/wiki/Z80_Assembly/Hello_World
Takker for artiklen, det var et dejligt gensyn!
Thumbs up, tak for dagens smilebånd ;-Dtid der nok kunne være brugt mere fornuftigt ... fx. på at gå i skole :-)
Og så kommer vi tilbage til den fortolkbare Basic fil, som ligger lige oven på jernet.
Jeg tror det ender på ca. 25 bytes hvis det laves til en .com fil til MSDOS. Så kan man jo så diskutere om OS og BIOS regnes med i tallet (ZX'erne havde også ROM med BASIC/whatever man kalder det).
Det mener jeg ikke man kan sige, for Scratch er et framework som kører på en anden computer (og hov, lige skal installeres på den først), hvor resultatet i form af en binær fil skal uploades til micro:bit'en, hvorimod Basic fortolkeren direkte taler med selve jernets assembler/mikrokode.
Til at forstå hvad kode er synes jeg det er fint. Som tidligere beskrevet så faldt de fleste fra dengang i 70'erne og 80'erne fordi indlæringskurven var for stejl. Det er en lykke for samfundet at man ikke længere skal på kursus i tekstbehandling og at børn helt ned til 4-5 års alderen kan lave simpel kode. IT er blevet meget simplere og det er godt. Fordi vi har skjult det komplekse i libraries og operativsystemer.
Jeg kunne til gengæld godt ønske mig at når man træder ud af en IT-uddannelses institution hvor man er blevet teoretisk mester i højniveausprog, at man så også har lært det basale i hvordan maskinkode fungere, hvordan en CPU er opbygget, hvordan virker ethernet, etc. Men jeg mener ikke alle behøver at vide den slags, hvorimod jeg mener alle skal lære hvad code er.
Jeg var desværre ikke blandt de rige, der havde råd til den eksterne udvidelse af RAM, men følte det mere som en udfordring end en begrænsning.
Jeg tror alle fra den tid rendte ind i begrænsningerne det ene eller andet sted. Jeg kan huske at jeg senere lavede et tekstbehandlingsprogram til MSDOS til at skrive stile og fysikrapporter i. Det var i PolyPascal hvor max. var 64Kb code (fraregnet "overlays"). Jeg brugte meget tid på at omskrive fin Pascal kode til maskinkode ... tid der nok kunne være brugt mere fornuftigt ... fx. på at gå i skole :-)
Sådan set ikke uenig, der er stadig den underliggende "emulator", så på den måde er det ikke ideelt, men dog lettere forståeligt.Jeg indrømmer, at det ser spændende ud, og det er nogle gode tanker der ligger bag. Det er dog stadig en avanceret og kompliceret arkitektur, med en overliggende BASIC-fortolker.
Det bliver jo nok svært bare at få de nødvendige komponenter nu om dage, for at lave en simpel maskine med noget der minder om en 8080/Z80/6502, ram og romkredse, samt div i/o, så man 100% kan forstå alle byggeklodserne.
Og i det spil ser jeg også er problem med de fleste moderne processorer, nemlig at man for at spare ben har multiplekset rigtig meget, hvilket gør det meget sværere lige at gå til.
Men ja, jeg tror der kunne vindes meget forståelse med en Back-to-Basic(s) undervisningscomputer, og reelt gruer jeg faktisk for hvordan tingene ser ud om 20-30 år, når de "digitalt indfødte" nu også skal være dem der faktisk laver tingene.
Jeg indrømmer, at det ser spændende ud, og det er nogle gode tanker der ligger bag. Det er dog stadig en avanceret og kompliceret arkitektur, med en overliggende BASIC-fortolker.Og så har den den store fordel at programmer kan gemmes på SD kort, og man kan lege med blinkende lysdioder mv., for dermed at få en meget tættere tilgang til jernet.
En af fordelene ved ZX80 var, at også den underliggende arkitektur var simpel, og ikke mindst simpel at tilgå og lege med. Det gav dem, der interesserede sig for hvordan en computer fungerede, mulighed for at lege og forstå, på en måde, som stort set ikke er set før eller siden.
Man kunne lave avancerede selvmodificerende programmer, så man kunne genbruge hukommelse, man kunne optimere sin kode, ved at manipulere processoren direkte, man kunne stjæle hukommelse fra "operativsystemet", og mange andre tricks.
At arbejde på ZX80 og ZX81 gav mig viden om komprimeringsalgoritmer, så jeg kunne have mest mulig data i hukommelsen, viden om programmering i maskinkode, og ikke mindst viden om optimering af kode til den tilgængelige hukommelse.
Jeg var desværre ikke blandt de rige, der havde råd til den eksterne udvidelse af RAM, men følte det mere som en udfordring end en begrænsning.(til fx. ram-udvidelse ... 1K RAM var aldrig nok)
Det mener jeg ikke man kan sige, for Scratch er et framework som kører på en anden computer (og hov, lige skal installeres på den først), hvor resultatet i form af en binær fil skal uploades til micro:bit'en, hvorimod Basic fortolkeren direkte taler med selve jernets assembler/mikrokode.Abstraktionsniveauet er ca. det samme som i ZX80 Basic. Og når det handler om at komme igang så er nemt det samme som godt.
Tag bare hvad der står på micro:bit's hjemmeside:
"Du kan forbinde den til Scratch og bygge kreative projekter, som på magisk vis forbinder den digitale verden med den fysiske."
MAGISK VIS!!! - der skal absolut ikke indgå nogen form for magi i sagen.
Og så kommer vi tilbage til den fortolkbare Basic fil, som ligger lige oven på jernet.Kom tilbage når det er 47 bytes :-)
"Nemmere" måske (ligesom alt muligt andet "nem" her i landet??), men ikke nødvendigvis bedre hvis man skal lære det helt basale, uden for mange abstraktionslag.
Abstraktionsniveauet er ca. det samme som i ZX80 Basic. Og når det handler om at komme igang så er nemt det samme som godt.
Uden noget der er nemt at gå til efterlader vi alt for mange der kunne have lært en masse. Jeg husker fra min folkeskoletid at der var der flere af vennerne hvis forældre købte Vic-20, Commodore 64, ZX Spectrum og ZX81 (og kloner) hvor de fleste aldrig kom længere end Hello World.
Exe-filen er på 47 kb
Kom tilbage når det er 47 bytes :-)
Man kan fortsat skrive kompakte hello-programmer idag. Dette er med Delphi 10.1:
program HelloProject; begin writeln('hello world'); end.
Exe-filen er på 47 kb.
Og jeg startede også med ZX81, derefter Oric-1, Oric-Atmos og så stod den ellers på PC/DOS med en Olivetti M24.
"Nemmere" måske (ligesom alt muligt andet "nem" her i landet??), men ikke nødvendigvis bedre hvis man skal lære det helt basale, uden for mange abstraktionslag.Scratch er helt klart et nemmere programmeringsprog end BASIC.
Dette er et moderne svar på ZX/Acorn Atom:Det ville være et stort skridt frem, hvis man satte ZX80 eller ZX81 i produktion igen, til erstatning for Micro:Bit til at lære skolebørn at programmere.
https://www.olimex.com/Products/Duino/Duinomite/DUINOMITE-MINI/open-source-hardware
Under 200 kr inklusive moms.
Tilslut et keyboard, en VGA monitor, strøm og man er igang med det samme.
Alle kommandoer kan være på et dobbeltsidet (lamineret) A4 ark.
Og så har den den store fordel at programmer kan gemmes på SD kort, og man kan lege med blinkende lysdioder mv., for dermed at få en meget tættere tilgang til jernet.
Jeg husker at have eksperimenteret med en ZX81, da jeg var barn.
I de gode gamle dage fyldte Hello World nogle få bytes og bestod af: 10 PRINT "HELLO WORLD" 20 GOTO 10
Nu om dage fylder Hello World adskillige megabytes på grund af maskingenereret kode (fra udviklingsmiljøet), diverse frameworks og autoloadede libraries.
Idéen om, at det var begrænset hvad den kunne bruges til, kan kun komme fra en, som ikke var med dengang.
Jeg er ganske enig i at man kunne lave rigtigt meget med ZX80. Det var en god måde at starte på for alle og ingen have forventninger om mus, grafik, lyd, etc. Blot et simpelt spil var helt vildt i forhold til hvad der ellers i ens omgivelser. Da ZX80 skal ses i relation til Pong som stadigvæk var nyt og spændende på den tid.
Begrænsningerne kom af det elendige keyboard, at ens programmer ikke altid kunne loades fra cassettebånd, samt at connectoren til udvidelsesporten (til fx. ram-udvidelse ... 1K RAM var aldrig nok) var ustabil.
Det ville være et stort skridt frem, hvis man satte ZX80 eller ZX81 i produktion igen, til erstatning for Micro:Bit til at lære skolebørn at programmere.
Det børnene lærer i skolen skal passe sammen med den tid de lever i. Scratch er helt klart et nemmere programmeringsprog end BASIC. Micro:Bit er en rigtig god start.
Idéen om, at det var begrænset hvad den kunne bruges til, kan kun komme fra en, som ikke var med dengang. Den kreativitet som begrænsningerne, og den skræmmende simple arkitektur, nødvendigvis resulterede i, gav grobund for nogle fantastiske programmer, som udnyttede maskinen langt ud over dens oprindelige formål, og lærte en generation nogle programmeringsmæssige færdigheder, som nutiden burde misunde dem, meget mere end den gør.
Det ville være et stort skridt frem, hvis man satte ZX80 eller ZX81 i produktion igen, til erstatning for Micro:Bit til at lære skolebørn at programmere.