Regnecentralens RC-702 er en 8bit microcomputer bygget på en Zilog Z80 processer med en clockfrekvens på hele 4Mhz og 48 kilobytes ram. Maskinen blev lanceret på ISAK, Indkøbsmesse for Stat, Amt og Kommune, i Fredericia d. 25. - 29. August 1980. Den blev, set med datidens øjne, utroligt populær, primært herhjemme, men også i resten af Vest-europa, med omkring 10.000 solgte enheder.
Udviklingen af maskinen blev påbegyndt under Regncentralens konkurs i 1979 af en håndfuld ingeniører der havde fået forbud mod at arbejde på eksisterende projekter og efter rekonstruktionen vedtog man at fortsætte udviklingen og gøre den til et officielt produkt.
Overgangen fra store klassiske datamaskiner til microcomputere som først Piccoloen, og sidenhen Partner og Piccoline maskinerne, er den primære årsag til at Regnecentralen stadig var en ting op i halvfemserne.
Jeg er meget passioneret omkring bevarelsen af dels de her danske maskiner, men også blot historien om dem. Lige pt. arbejder jeg godt nok mest med Comet serien fra ICL / HH-Electronics (Comet 2000 Wanted, dead or alive) men da det gik op for mig at Piccolo havde 40 års fødselsdag i 2020 var jeg nødt til at lave en lille video om det..
Oprindeligt var jeg af den overbevisning at der var "masser af dokumentation" vedr. Regnecentralen og deres produkter, men faktum er at det faktisk var en udfordring for mig at finde noget så simpelt som "antal solgte enheder" af RC-702, det tal vi er kommet frem til er basseret på estimater fra en håndfuld medarbejdere jeg har talt med. Der er med andre ord rigtig meget at give sig i kast med her.
Apropro arbejde, så har vi et problem ude på Datamuseet i Ballerup, som pt. er det eneste sted der beskæftiger sig med bevaring af den danske IT Historie i signifikant scala, er ved at blive hjemløse. Vores lokaler, som Ballerup kommune har stillet gratis til rådighed i 25 år, bliver desværre opsagt da lokalerne skal bruges til anden side.
Det er en kæmpe katastrofe, så hvis du syntes det her er vigtigt og har lyst til at hjælpe så kan du enten melde dig ind i foreningen, støtte vores indsamling og/eller overbevise din chef om at melde jeres virksomhed ind.
Det vil være et enormt stort tab hvis vores samling ender på genbrugspladsen!
Jeg mener DIKU brugte Piccoliner på Dat0 i 1981/1982, men da Piccolinen først kom i 1984, må det vel have været Piccolo-systemer dengang på DIKU?
@Mike: jeg kan ikke finde det i videoen lovede link til rc702 emulatoren; ej heller på mikjaer.com/retro, det er nok bare mig, der er fatsvag;-)
Det er at tankevækkende, at DEC blev startet for $70.000 i 1957 og overlevede, som selvstændigt frem til 1998. Mens RC kostede $120.000 i 1955 og lukkede i 1993.
Undskyld mig, jeg fandt dem selv:
Piccolo: http://www.jbox.dk/rc702/emulator.shtm Piccoline: https://rc700.dk/
Det var ikke Piccoliner men derimod Piccoloer som blev brugt på Dat0 til programmering i COMPAS Pascal. I øvrigt brugte man 8" disketter med en kapacitet omkring 100 kB !
Jeg var selv sidste årgang der anvendte dem (88/89) - året efter blev de udskiftet med PC'ere....
Ja jeg husker det som 160 kbytes på de 8" jeg havde på min North Star fra 1978. Disse Schugart drev voksede dog også til 320 kiobytes og siden til tosidig læsning. Jeg smed dem ud i 1992 inden jeg rejste til Kouroru for at arbejde med Ariane 4. Det var uheldigt et af systemerne vi havde leveret fra Rovsing ca. 1981 blev stadig brugt, så de kunne virkelig have brugt en backup, De store hardiske den gang var typisk CDC med 80 megabytes og evet med en 10 Megabytes udskiftelig - de var naturligvis 14" g krævede et mindre elværk for at starte.
Vi er ikke blevet formelt opsagt af Ballerup Kommune endnu, men vi har fået et meget kraftigt vink med en vognstang om at det vil ske inden længe (med 12mdr. opsigelse).
Uanset dette, var vi dog allerede løbet tør for plads og har måtte ty til meget lidt ideelle opbevaring af de mindst vigtige dele af vores samling, bla. i en nedlagt stald.
Det var netop derfor jeg skrev "bliver opsagt" og tænkte at folk kunne læse detaljerne i dit blogindlæg, jeg kan godt rette det hvis du stadig ikke syntes det fremgår klart nok?
Har præcis sådan en skærm stående og har tit undret mig over hvad den havde været brugt til. Den så så gammel ud at jeg ikke ville smide den ud. Skal da lige se om jeg kan finde piccoloen også
er da et schweizisk udviklet programmeringssprog af Niklaus Wirth
Jeg husker at Piccoloen havde 5 1/4" diskettedrev (jeg fandt for nyligt min første diskette der netop blev brugt på Piccoloen). Det er også det der er på maskinen på billedet til artiklen. Var der også en 8" version
?
Piccoloerne på DIKU havde ganske rigtigt 8" drev. de havde også 64K RAM.
Men Compas Pascal (aka Poly Pascal aka Blue Label Pascal aka Turbo Pascal) blev udviklet af Anders Hejlsberg og kørte rigtigt fint på Piccoloen.
Udviklingsrækken var så vidt jeg husker Blue Label Pascal -> Compas Pascal 2 -> Compas Pascal 3 -> Poly Pascal 3. Her skifter rækken så fordi PolyPascal 3 og Turbo Pascal 3 levede side om side indtil Poly Pascal blev udkonkurreret af Turbo Pascal 4 og 5.
Poly Pascal blev markedsført af danske Polydata, som var naive nok til at sælge koden til USAnske Borland, som så markedsførte det under navnet Turbo Pascal.
Det er skønt, at I arbejder på at holde den regionale computer- og softwarehistorie i hævd, og jeg kan kun opfordre til, at man får sig et virksomhedsmedlemskab.
Vi har som virksomhed meldt os ind, da vi er flere kolleger, der tydeligt kunne huske nogle af de gamle maskiner og softwarepakker fra vores barndom og anerkender, hvordan de har været med til at forme vores interesser og, senere, vores professionelle virke.
Fx var vi nogle, der hygge-hackede på Piccoliner i folkeskolen, imens andre senere var så heldige at få fingrene i en kopi af Turbo Pascal og fik lov at kode en DOS-applikationslauncher til skolens PC'er (store sager). Dertil kommer selvfølgelig utallige andre maskiner og softwarepakker af dansk oprindelse, man har haft fingrene i igennem tiden.
Et shout-out går også til Rolf Ask Clausen, som i 1980'erne skrev en skøn bog om Commodore 64'eren og dens brugerport, hvilken var medvirkende til, at to knejter fra udfordrede familier, en C64 og vores forsøg på at lave en "smart home"-styring kunne vinde en præmie ved Ingeniørens Unge Forskere-konkurrence i slut-90'erne. Dette konsoliderede knejternes oplevelse af, at de kunne blive til noget indenfor feltet - og siden også blev det.
Vi har en rigtig spændende computerhistorie her i landet, som fortjener at blive udforsket og fortalt, så lad os bakke op om Dansk Datahistorisk Forening og hjælpe med at skabe geek-cred til de mænd, kvinder og virksomheder, som hjalp os med at gøre Danmark til en lilleput-stormagt på IT-området, og som har inspireret så mange. ?
Så vidt jeg husker var der en UCSD Pascal til Piccolo'en. Er ret sikker på at det var den første Pascal compiler jeg brugte i gymnasiet.
Compas Pascal (aka Poly Pascal aka Blue Label Pascal aka Turbo Pascal) blev udviklet af Anders Hejlsberg og kørte rigtigt fint på Piccoloen.
Den satte dog underviserne på DIKU grå hår i hovedet, for Compas Pascal opførte sig ikke helt som lærebøgerne foreskrev. Specifikt brugte Compas Pascal shallow binding i stedet for deep binding (som Wirth foreskrev), hvilket gjorde, at programmer, der brugte referenceoverførte parametre ikke altid opførte sig, som de skulle. Men shallow binding er mere effektiv end deep binding, så blandt andet derfor kørte Compas Pascal en del hurtigere end f.eks. UCSD Pascal. En anden årsag er, at UCSD Pascal oversatte til P-kode (en stakbaseret virtuel maskine), som blev fortolket.
Shallow binding betyder, at hver variabel har en fast plads i lageret, og når en ny lokal variabel med samme navn erklæres, gemmes den gamles værdi på stakken, og hentes ind igen, når den lokale variabel nedlægges. Ved deep binding lægges alle nye variable øverst på en stak og refereres relativt til staktoppen eller en frame pointer, og ikke-lokale variable skal tilgås via statiske links, som kan betyde to eller flere lagerhentninger. Deep binding er selvsagt mere effektivt (når man ikke har registerallokering, og det har man sjældent på 8-bit processorer), men hvis man har en reference til en variabel, risikerer man, at den, inden man følger referencen, er udskiftet med en anden variabel. Det er specielt et problem i forbindelse med rekursion.
1.2 MB (600 kB/side) på en 8"
De tidlige 8" disketter (single sided, single density) havde kun 100kB per disk, og det havde de tidlige 5¼" disketter også. Heldigvis steg datatætheden og begge sider blev taget i brug. Jeg fik et 5¼" drev til min BBC Micro, og med DDDS kunne jeg have ca. 400kB, og da jeg fik min Archimedes med 3½" drev, kunne jeg have 1,3MB på en disk. Acorn brugte deres eget filsystem og diskformat, som kunne lagre lidt mere data på en disk end CPM og DOS.
De tidlige 8" disketter (single sided, single density) havde kun 100kB per disk, og det havde de tidlige 5¼" disketter også.
Som skrevet brugte jeg Piccoloen fra 1981 - 1984 og der var 8" disken til den omkring 1 MB (den kan have været lige under eller over), men den var cirka 4 x størrelsen på en 5¼". Hvad en 8" havde af kapacitet før det, skal jeg ikke gøre mig klog på.
Specifikt brugte Compas Pascal shallow binding i stedet for deep binding (som Wirth foreskrev), hvilket gjorde, at programmer, der brugte referenceoverførte parametre ikke altid opførte sig, som de skulle.
Jeg skal ikke kunne sige hvad Z80 versionen gjorde, men x86 versionen allokerede variable på stakken og alle referencer til lokale variable var relativt til SP (eller nærmere BP). Men ok, Z80 mangler også de effektive stack-relative memory instruktioner der findes på moderne processorer så det giver fin mening der.
Jeg skal ikke kunne sige hvad Z80 versionen gjorde, men x86 versionen allokerede variable på stakken og alle referencer til lokale variable var relativt til SP (eller nærmere BP). Men ok, Z80 mangler også de effektive stack-relative memory instruktioner der findes på moderne processorer så det giver fin mening der.
Ja, det blev ændret i senere udgaver, og, som du siger, var det nok specifikt Z80-udgaven, der brugte den nemme løsning. Men så vidt jeg husker havde 8086-versionen den begrænsning, at en frame maksimalt kunne være 64kB stor, da der brugtes 16-bit offsets.
Ja, det blev ændret i senere udgaver, og, som du siger, var det nok specifikt Z80-udgaven, der brugte den nemme løsning. Men så vidt jeg husker havde 8086-versionen den begrænsning, at en frame maksimalt kunne være 64kB stor, da der brugtes 16-bit offsets.
Ja, x86 versionen kunne håndtere et kodesegment på 64K, et datasegment på 64K og et stacksegment på 64K. Herudover kunne man allokere på heapen for få adgang til resten. Kode kunne lægges i "overlay" funktioner som under runtime kunne swappes ind fra (floppy) disken sådan at man kunne have mere end 64K kode.
Mht. til UCSD pascal, så var det primært brugen af fortolket p-code der gjorde systemet uendeligt langsomt. Spændende er det at p-code fik en renaissance med Java ... heldigvis fandt man hurtigt ud af at JVM også ville være ukonkurrencedygtig uden JIT compiling til machinecode og løste det problem.
