· Text 7296 · w8 · inlagg
Finns det något sätt att komma åt rastern på en ABC806:a?
/Martin
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
Raster
15 posts in thread
-
-
· Text 7300 · w8 · kommentarPå en abc806a går det att nå raster på färg 0 med out 7,xxx. På en monokrom skärm ger 15 ett snyggt raster som jag brukar använda, på en färgskärm kan man få diverse snygga färgraster och förgblandningar med samma stil. Tyvärr har jag inte hittat något systemi detta, så du får prova dig fram...
-
· Text 7327 · w8 · kommentarSystemet för OUT 7,.... vid ABC806 med färgskärm är följande (jag har visserligen det nya grafikprommet, men nedanstående tror jag gäller även för det gamla prommet): Utport 7 (HRS) kan användas för för färgval. Där finns 16 bytes, där man kan lagra färgkoder. Färgvalsnumret, som används i grafikinstruk- tionerna (FGPOINT etc) avgör vilken av dessa bytes, som skall användas. Innehållet i den är färgkoden som avgör vilken färg som vi- sas. Vilka koder, som läggs där kan man bestämma med fgctl ..., ..., ..., osv där man som bekant kan som mest ange 16 färger. Varje byte i detta minne ger färg till 2 på varandra följande pix- els på grafikskärmen. Den byte i färgvalsregistret, som innehåller färgkoden, har ju 8 bitar. Av dessa bestämmer bitarna 4-7 färgen på den vänstra och bitarna 0-3 färgen på den högra av de 2 pixels, som skall färgsättas. Färgkoden består alltså av 4 bitar. Vänstra pixeln ! Högra pixeln --------------------------------- ! --------------------------------- bit 7 bit 6 bit 5 bit 4 ! bit 3 bit 2 bit 1 bit 0 Täcker Blå Grön Röd ! Täcker Blå Grön Röd Färgerna gul, cyan och magenta fås genom att både röd och grön resp både blå och grön resp både blå och röd bit är satt. Vit färg fås om både röd, grön och blå bit är satta. 'Täcker' betyder täckande färg, dvs grafik har prioritet över text. Om denna bit är släckt, har texten prioritet och blir inte osynlig under grafiken. Binärt Dec Färg Binärt Dec Färg --------------------------------------------------------- 0000 = 0 --> BLK 1000 = 8 --> GBLK 0001 = 1 --> RED 1001 = 9 --> GRED 0010 = 2 --> GRN 1010 = 10 --> GGRN 0011 = 3 --> YEL 1011 = 11 --> GYEL 0100 = 4 --> BLU 1100 = 12 --> GBLU 0101 = 5 --> MAG 1101 = 13 --> GMAG 0110 = 6 --> CYA 1110 = 14 --> GCYA 0111 = 7 --> WHT 1111 = 15 --> GWHT Normalt vid färgsättning med basickommandona, läggs samma färgkod i bytens båda nibbles, så att de två pixels som motsvarar en byte, får samma färg. Grafikskärmen ligger alltid ute, även när man inte har gett några grafikkommandon, och då med färgvalsnr 0, som då inne- håller färgkoden 00000000 binärt, dvs 0 decimalt. Om man i kommandomod skriver fgctl red <ret> så finner man att man får röd bakgrund till sin text, fgctl blu ger blå bakgrund etc. Röd färg motsvarar då att färgkoden binärt är 0001 0001 = 17 dec. Blå färg motsvarar binärt 0100 0100 = 68 decimalt. Exakt samma saker som med fgctl kan man alltså erhålla genom att istället skriva out 7,17 resp out 7,68. Pröva! Men nu kommer det roliga. Om man sätter olika värden i bitarna 4-7 gentemot bitarna 0-3, så får vänstra pixeln annan färg än högra pix- eln. Hela skärmen får alltså ett rastermönster. Om man gör out 7,1 så motsvarar det binärt 0000 0001, dvs varannan pixel blir svart och varannan röd. Man får en mörkröd färg, som jag tycker är behagligare bakgrund än den högröda. OUT 7,4 ger på samma sätt en mörkblå bak- grund. Allmänt kan man skriva OUT 7, v*16 + h där v är det decimala tal som motsvarar vänstra pixelns färg enligt ovanstående tabell, och h den högra pixelns färg. Värden på v eller h > 7, medför att bakgrunden täcker över texten, och kan därför inte rekommenderas. Allting blir inte lika lyckat, men man kan experimentera fritt. Man kan som bekant välja färg för texten också. Om man skriver: ATTRIBUTE 5 <ret>, ; YEL <ret>, OUT 7,4 <ret> så kan i fort- sättningen skriva gul text på mörkblå bakgrund, vilken är behagligt och vilsamt för ögonen (och dessutom känns väldigt fosterländskt på något sätt). Vissa kommandon återställer värdet 0 i färgvalsregistret och tar därigenom bort den bakgrund man har lagt in, det är framförallt LIST och RUN. Mvh Lars
-
· Text 7329 · w8 · kommentarJag glömde skriva, att om man vill få bort det där med att LIST och RUN tar bort en inställd bakgrundsfärg, så kan man göra POKE 65421,201. Då kan man behålla en inställd bakgrundsfärg hela tiden. Mvh Lars
-
· Text 7340 · w8 · kommentarSom hemuppgift för den intresserade, kan vi fråga vad som lagåiras i färgvalsregistren när man skriver FGCTL RED+BLU. Tänk på att man ska kunna rita en röd och en blå pixel intill varandra i bilden trots att två pixels tillsammans delar på en byte färgval.
-
· Text 7348 · w8 · kommentarNär man skriver FGCTL RED+BLU lagras färgkod 0001 0001 (=17) i HRS0 och 0100 0100 (=68) i HRS1. I grafikminnet finns inga färgkoder lagrade, bara färgvalsnummer, som anger vilken byte i HRS, som skall få bestämma pixelfärgen. Om man har valt 256*240 pixels grafikskärm, så disponerar varje pixel 4 bitar för sitt färgvalsnummer, dvs man kan välja mellan 0-15. Om man har valt 512*240 pixels grafikskärm, så disponerar varje pixel bara 2 bitar för färgvalsnumret. Man kan då bara välja mellan 0-3. Att bara en pixel i taget kan tändas beror på hur grafikkommandona arbetar. FGPOINT X,Y,F påverkar bara en pixel om pixeln till höger har annat färgvalsnummer lagrat. Har den samma, _kan_ pixeln till höger också påverkas, som skall visas nedan. Med basicens OUT P,D kan man bara nå HRS0, första byten i HRS-reg. Det är där som man utan att använda maskinspråk kan lägga 'mixfärger' med exempelvis out 7,2*16+4. Följande experiment visar hur det fungerar. Allt skrivs i kommando- mode: a) FGPOINT 0,0 b) FGFILL 511,239,1 (nu har alla pixels färg- valsnumret 1). c) FGCTL RED+BLK (initiering med 0001 0001 i HRS0 och 0000 0000 i HRS1. Grafikskärmen är mörk, eftersom alla pixels har val nr 1). d) OUT 7,1*16+2 (HRS0 byter till 0001 0010 dvs 'vänsternibbeln' motsvarar rött och 'högernibbeln' grönt) e) FGPOINT 200,100,0 --> en röd punkt tänds f) FGPOINT 201,100,0 --> en grön punkt tänds g) FGPOINT 202,100,0 --> en röd punkt tänds h) FGPOINT 203,100 0 --> en grön punkt tänds o s v Tydligt är att jämna x-koord. är 'vänsterpixlar' och udda x-koord är 'högerpixlar'. En intressant variant är emellertid: i) FGPOINT 201,50,0 --> en RÖD punkt tänds j) FGPOINT 202,50,0 --> en ny röd punkt tänds k) FGPOINT 203,50,0 --> en grön punkt tänds l) fortsättningsvis blir det röd-grön-röd-grön-....... m) MEN: om man nu skriver: FGPOINT 200,50,0 --> så tänds en röd punkt där, men SAMTIDIGT BYTER PIXELN 201,50 FÄRG TILL GRÖNT!!! Den påverkades alltså! I det nya grafikprommet (som jag har) finns den nya instruktionen FGCTL MIX inlagt, med vars hjälp man kan lägga mixfärger i alla HRS-bytes. Man kan på sätt få 64 olika färgschatteringar istället för bara 8. Det är möjligt att man med assemblersnuttars hjälp kunde skapa en funktion FNFgctlmix(Fgctl¤) med vars hjälp man kunde få mixfärger även med det vanliga prommet. Mvh Lars
-
· Text 7354 · w8 · kommentarTråkigt att säga var det inte så rätt, ditt svar på "hemuppgiften". Om man studerar hårdvaran och grafikprommen lite (och det måste kvitta vilket grafikprom man har) får man lite andra svar. Man KAN nå alla färgvalsregistren med Basics OUT-instruktion: OUT 7+SWAP%(Färgvalsregister),Färgval. Fast det finns förstås inte dokumenterat någonstanns. Den viktigaste principen att komma ihåg, är att hårdvaran arbetar på precis samma sätt oavsett vilken upplösning man valt (256 eller 512 punkter i x-led). Och mjukvaran gör inga mystiska saker beroende på grannpixlarnas färger. Hårdvaran läser 4 bittar från grafikminnet. Dessa väljer ett av sexton färg- valsregister. Där hämtas en byte, 2 x 4 bittar som styr färgerna på två intil- liggande bildpunkter, enligt ditt tidigare inlägg. Så går det alltid till. När den låga upplösningen (16 färger) används är det enkelt: De två bildpunkterna i varje färgvalsregister visar samma färg, så det ser ut som en bred punkt. Det är här man kan få trevliga färgnyanser om man i stället lägger två olika färger i registren. När det är hög upplösning (4 färger) ska varje par av bittar i grafikminnet (i stället för 4 bittar) ge en pixel på skärmen. Men hårdvaran läser ju alltid 4 stycken i taget. Som sagt, så översätts de av färgvalsregistren och ger två individuellt styrbara punkter på skärmen, så på något sätt måste det gå. Eftersom de fyra bittarna från grafikminnet innehåller två pixels, måste det färgvalsregister som väljs ut av dessa i kombination(!), innehålla färgkoderna för dessa två pixels. Om vi har två pixels bredvid varandra med färgnumren 01 respektive 00 binärt, läser hårdvaran alltså 0100 i ett enda stycke, och använder till att välja ut ett av färgvalsregistren (nummer 4 decimalt). Om 01 ska vara röd och 00 grön, måste registret ange röd färg i vänstra halvan och grön i högra halvan (färgkodningen blir 0001 0010). Än kanske det inte verkar så krångligt, men fundera nu på vad som händer om vi byter ordningen på dessa pixels, så det blir 00 resp 01 i grafikminnet. Hårdvaran läser nu 0001 och tar register 1 denna gång. Det viktiga är nu att registret har programmerats så att vänstra halvan visar grönt och högra rött, och inte några ovidkommande färger. FGCTL GRN+RED fixar denna programmering, och det görs alltså INTE så att register 0 blir helgrön och register 1 helröd och resten helsvarta. Jo, register 0 blir helgrön, men skälet är att det registret ju används när det står 0000 i grafikminnet, vilket ska visas som två gröna pixels (två pixels med kod 0). Register 1 blir grön och röd, eftersom den används för pixelkombinationen 0001 (en med kod 00=grön och en 01=röd). Register 2 blir grön och svart osv. Man kan ställa upp ett schema: höger pixel 00 01 10 11 00 grn+grn grn+red grn+blk grn+blk v pixel 01 red+grn red+red red+blk red+blk 10 blk+grn blk+red 11 blk+grn blk+red Numret för vänster och höger pixel i kombination utgör färgvalsregistrets nummer, och dess innehåll står inne i schemat. Att det blir så mycket BLK beror förstås på att vi bara använt två av fyra möjliga färger. De fyra tomma platserna ska vara blk+blk. Jag skrev inte ut dem för det hade blivit mer svårläst. Skillnaden på dessa färgblandningar, och de som ger fina nyanser i låg upplösning, är att här är de kombinerade efter ett visst system. Att du fick en pixel att byta färg i ditt exempel, berodde på att när du ändrade pixeln bredvid ändrades deras kombinerade kod så att det färgvalsregister du programmerat om utnyttjades, och det registret följde ju inte det här färgsystemet. (Hoppas någon fattar något. Jag öser på med ord här, men det går fortfarande att missförstå, och jag har ju ingen omedelbar feedback från läsarna som visar när de börjar förstå.)
-
· Text 7358 · w8 · kommentarTack för svaret, magistern, jag blir väl kvarsittare nu, antar jag. Det hela understryker bristen på öppenhet och information, som har vidlått Luxors, DIABS m.fl. policy, och på ett negativt sätt skiljer sig från APPLE, MS-dos etc. Det är inte så lätt att knäcka mysterierna genom experiment och stu- dier av maskinkoden i tolken. Men kanske ändå ganska spännande, som att försöka knäcka en fiendes chiffersystem. En hel del hade jag väl fattat riktigt tidigare, det som är nytt, är systemet för lagring av färgkoder, som tydligen är ganska smart. Du ville ha feedback från läsarna, om dom börjar förstå. Om jag har börjat förstå rätt, så innebär FCTL F0+F1+F2+F3 att det lagras: ! höger pixel ! 00 01 10 11 ------------!------------------------------ 00 ! F0+F0 F0+F1 F0+F2 F0+F3 vänster 01 ! F1+F0 F1+F1 F1+F2 F1+F3 pixel 10 ! F2+F0 F2+F1 F2+F2 F2+F3 11 ! F3+F0 F3+F1 F3+F2 F3+F3 där det matematiska mönstret syns klart. Vad händer nu, om man använder mixfärger, så att vissa Fx motsvarar två färger, en vänsterfärg och en högerfärg? Det tycks mig som om det skulle bli: ! höger pixel ! 00 01 10 11 ------------!-------------------------------------- 00 ! F0v+F0h F0v+F1h F0v+F2h F0v+F3h vänster 01 ! F1v+F0h F1v+F1h F1v+F2h F0v+F3h pixel 10 ! F2v+F0h F2v+F1h F2v+F2h F2v+F3h 11 ! F3v+F0h F3v+F1h F3v+F2h F3v+F3h Jag tycker att detta stämmer med experimentella resultat (bl a slutet av inlägg 7348) men vill gärna ha det konfirmerat. Med det nya grafikprommet kan man använda färgmask och pixelmask, som 'AND-ar' färgen respektive pixel-värdet, och kan maska bort delar av dem. Detta ger användaren ökade möjligheter vid grafikanvändningen. Att man kan nå alla färgvalsregister från basic, finns, som du säger, inte dokumenterat, och det var därför en nyhet för mig. Vad som finns dokumenterat är att assemblerns OUT (C),r (till skillnad från OUT (n),A!) lägger innehållet i B i adressbussens övre halva och C i dess nedre, varför B-värdet kan användas som parameter, vilket an- vänds t.ex. vid blockning av grafikminnet. Jag gissade att B-värdet skulle användas för att adressera visst register, och försökte tidigt med en assemblersnutt: .... LD B,Regval LD C,7 LD A,Färg OUT (C),A .... Till min besvikelse fungerade det inte, färgkoden ham- nade lika förbaskat i register 0. Om man i basic skriver OUT 7+SWAP%(Regval),Färg , så förefaller det mig som om detta vore ungefär detsamma som assemblersnutten, ty värdet 7+SWAP%(Färgvalsreg) borde ju hamna på adressbussen. Men resultatet blir ju faktiskt ett helt annat. Hur hänger det ihop? Mvh Lars
-
· Text 7362 · w8 · kommentarFörlåt mig, du behöver inte förklara för mig det där sista jag skrev om LD B,... LD C,7 LD A,... OUT (C),A. Jag har själv kommit underfund med det. Jag laddade in min mixfärg i register 1 (dvs B=1) och gick sedan (i 512*240-mode) in och lade ettor i hela grafikskärmen. Jag trodde då att detta var rätt. Jag har nu efter studier av tabellen förstått att jag i denna mode måste välja B=5 för att få den effekt, jag önskade. Det fungerar all- deles utmärkt nu med assemblersnutten. Min tidigare gissning var tyd- ligen alldeles riktig, det var kunskapen om lagringssystemet, som var fel (i högupplösningsmode). Mvh Lars
-
· Text 7386 · w8 · kommentarNu verkar du förstå FGCTL med fyra färger. Men mix-färgerna är det inget speciellt med, om man kör med lågupplösning, och i högupplösning finns de ju inte, om vi syftar på samma fenomen. Eftersom man kör med lågupplösning är det ju som du från början antog ett färgvalsregister för varje färgnr i grafikminnet rätt och slätt, och då behöver de inte blandas enligt något speciellt system. Alltså kan man lägga en valfri mixfärg i varje register, och använda 16 stycken olika samtidigt.
-
· Text 7395 · w8 · kommentarDu skriver att i högupplösning finns inte mixfärgerna. Jag har försökt tillämpa mina nyförvärvade kunskaper om FGCTL med fyra färger, och lagra vänster- och högerfärger enligt principen ! höger pixel ! ! 00 01 10 11 ! ------------!----------------------------------------!------------- 00 ! F0v+F0h F0v+F1h F0v+F2h F0v+F3h ! (reg 0- 3) vänster 01 ! F1v+F0h F1v+F1h F1v+F2h F1v+F3h ! (reg 4- 7) pixel 10 ! F2v+F0h F2v+F1h F2v+F2h F2v+F3h ! (reg 8-11) 11 ! F3v+F0h F3v+F1h F3v+F2h F3v+F3h ! (reg 12-15) Jag har hittills använt basic enligt : 10 DIM F(3,1) ! 1:a index:Färgval 0-3. 2:a index:0=v och 1=h. 20 ; "Ange (med färgkoder 0-7) F0v,F0h,F1v,F1h,F2v,F2h,F3v,F3h: "; 30 INPUT ""F(0,0),F(0,1),F(1,0),F(1,1),F(2,0),F(2,1),F(3,0),F(3,1) 40 FOR I=0 TO 3 : FOR J=0 TO 3 ! Inmatning i 16 register. 50 OUT 7+SWAP%(4*I+J),16*F(I,0)+F(J,1) 60 NEXT J : NEXT I Om jag vid input svarar exempelvis 0,1,2,1,3,5,0,7 får jag mix- färgerna blk/red, grn/red, yel/mag och blk/wht. Jag kan då adressera 512*240 pixels och exempelvis använda fgline och fgfill. Mixfärgerna tycks fungera bra. Mvh Lars
-
-
-
-
-
-
· Text 7349 · w8 · kommentarNär det gäller min 806'a funkar det inte, jag har tydligen ett gammalt prom. Det som händer är att jag får en massa röda prickar och däremmellan är det svart, och c:a en tredjedel av skärmen blir helt röd, den nedre. Annars verkar det intressant. Förresten, är prommet till GRAF806 det NYA prommet du menar. MVH ARNE
-
· Text 7350 · w8 · kommentarJa det det prommet jag menar. Mvh Lars
-
· Text 7353 · w8 · kommentarJag kör med det 'gamla' grafikprommet, och får rastren att fungera. 'Felet' ligger tydligen inte i prom.
-
· Text 7374 · w8 · kommentarDet hjälper säkert om du ser till att grafikminnet innehåller en tom bild. Ditt problem är att den innehåller skräp när du får den att synas. Den brukar rensas vid byte av upplösning, eller med lämplig FGFILL.
-
-
-
-