Kristoffer Eriksson
<5357>
· Text 4229 · w8 · kommentar
1988-04-12 23:59
Ärende: Ingen grafik i ABC80
Koden för slut-grafik CHR¤(135) fungerar inte att PRINT:a om man
drar ifrån 128, så då är det ju naturligt att presentera den andra
koden (151) utan att dra ifrån där också.
Drar man 128 från 135 blir det 7, och den koden tolkas vid PRINT
som pling-i-högtalaren (kallat BEL i ASCII-tabellen).
I bildminnet lagras koderna dock som 7 och 23, med 128-bitten
borttagen. Den bitten används ju i stället för att sätta blink på
tecknen.
Det är inte alls onaturligt att göra en viss översättning mellan
koden man använder vid PRINT eller motsvarande och den som används
i bildminnet. Man har nämligen lite olika krav på dessa koder.
Den man PRINT:ar brukar helt enkelt vara ASCII, så datorn skriver
med en standardiserad kod. Den har reserverat vissa koder (0-31)
för styrändamål, bl a radbyte (CR, LF), pling (BEL), bakåtstegning
(BS). De tecknen skrivs inte in i bildminnet, utan styr var övriga
tecken skrivs in.
I bildminnet har man däremot inte det styrbehovet, (inte med
en normalt konstruerad bildgenerator i alla fall) och inget
standardbehov. Där kan man utnyttja alla koder till tecken som
verkligen syns, särskilt då 0-31, och utnyttja somliga bittar för
att styra tecknens återgivning på skärmen (blink).
Så i slutänden kan det hända att man får olika koder för
specialtecken vid PRINT:ning och i bildminnet.
Varför man nu i det här fallet valt två koder > 128, och inte två
oanvända koder < 32, kan man fråga sig. Men i riktig ASCII är
koderna < 32 trots allt upptagna, även om alla inte används på just
den här maskinen (ett ganska svagt argument dock). De koder som
har valts stämmer med Videotex, varifrån deras funktion också är
hämtad, och de har gått bra att bygga ut till att inkludera färg
och andra finesser på ABC800-serien, med bibehållen likhet till
Videotex, så något slags förutseende verkar ha varit inblandat.