· Text 2007 · w8 · inlagg
Är det verkligen *ingen* som vet hur man utför denna instruktion från
assembler?
muh Harald
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
FGCTL
23 posts in thread
-
-
· Text 2008 · w8 · kommentarVilken dator, ABC800 eller ABC806? Det är nämligen lite skillnad...
-
· Text 2012 · w8 · kommentarABC806 mvh Harald
-
· Text 2015 · w8 · kommentarLD C,7 LD B,Färgregister OUT (C),Färgvärde Det finns 16 färgregister (0-15) en för varje färgnr som kan lagras i grafikminnet. Färgvärdet bestämmer vad det blir för färg på skärmen och består egentligen (om jag inte minns fel) av två färgkoder om vardera fyra bits, varav det mest värda biten anger förgrunds/bakgrunsfärg och de övriga Röd, Grön och Blå i någon viss ordning. LD A,Text+4 OUT (54),A där Text är 0 eller 128 väljer om textskärmen ska visas eller inte.
-
· Text 2028 · w8 · kommentarVarför TVÅ färgkoder per färgregister? Hur markeras att grafiken skall visas på skärmen? muh Harald
-
· Text 2029 · w8 · kommentarGrafiken visas alltid. När den inte syns beror det på att alla färger är svarta, dvs nollor i alla färgregister. Som du (väl) vet kan man använda 806:ans grafik i två lägen, en med 256 punkter (eller 240) per linje och 16 färger vilket kräver 4 bits för en färgkod i grafikminnet, och en med 512 punkter och 4 färger där bara 2 bits behövs för färgkoden. Nu är det så att hårdvaran som sköter grafiken alltid arbetar likadant, oavsett vilken upplösning som används. Skillnaden åstadkomms helt mjukvarumässigt. När en del av en linje ska visas på skärmen hämtas således en halv byte = 4 bits från grafikminnet som får bestämma vilket färgregister som används. Detta register bestämmer färgerna på två pixels på skärmen. Har man valt upplösningen 256 punkter/linje har dessa två pixels samma färg och uppträder som EN punkt, då finns 16 färgregister att välja på med varsin färg. (Får man pixlarna att visa olika färg i stället får man blandfärger som man kan experimentera lite med. Går att göra helt i BASIC) Med 512 punkter/linje och 4 färger används alltså de två pixlarna i varje färgregister var för sig, men eftersom fortfarande 4 bits i stöten hämtas från grafikminnet och dessa ska ge två punkter på linjen och dessa ska kunna vara vilken som helst kombination av de fyra utvalda färgerna blir det lite mer komplicerat. Varje färgregister får representera en kombination av två färger. Två pixels, 4 färger ==> 4Ü2=16 kombinationer ==> 16 färgregister ==> Två pixels, 16 färger. Översättningen går alltså från 2-bits-färger till 4-bits-färger (Röd, Grön, Blå, För-/Bakgrund) Jag förmodar att detta arangemang ger vissa tekniska fördelar. Hoppas du får ut något av beskrivningen, den blev inte så genomtänkt.
-
· Text 2032 · w8 · kommentarJodå, din beskrivning är till stor hjälp. En sista (?) fråga: Hur är bildminnet organiserat? Dvs, hur tar jag reda på adressen till en viss punkt? mvh Harald
-
· Text 2035 · w8 · kommentarDet beror förstås på vilken metod du använder för att komma åt grafik minnet, det går ju till exempel att mappa in 4K-block av grafikminnet på valfri adress. Om du avänder LDIR-instruktionen i slutet av prommet med grafikrutinerna (adress 32765, finns även i ABC800) så har jag för mig att linjerna överst i bilden har lägst adress, och punkter till vän- ster har lägre adress än punkter till höger. Det går åt 128 bytes per linje, och det går 2 eller 4 pixel i varje byte. (ABC800 fungerar efter samma principer, men har alltid 4 pixel/byte och 64 bytes/linje). Om du räknar efter lite ser du att högsta utnyttjade adress är 30719 (240*128-1).
-
· Text 2119 · w8 · kommentarHmm, det blev visst inte den sista frågan, här kommer en till. Hur markeras *vilken* bild som skall visas, dvs hur funkar FGPICTURE? muh Thrud
-
· Text 2122 · w8 · kommentarDet hade jag också mycket problem med först, men nu förstår jag det! Det fungerar så här: I ABC806:an så finns det ju minne reserverat för 4 grafikbilder. När du startar datorn, så skriver du i bild nr 0. Datorn är alltså startad så här: FGPICTURE 0,0,4 Där den 1:a nollan betyder att man ritar i bild nr 0. Den 2:a nollan betyder att bild nr 0 visas (du kan alltså rita i bild nr 2 tex, och visa bild nr 0). 4:an betyder att det är 4 bilder du använder (bild nr 0,1,2,3). Alltså: Om du skriver FGPICTURE 0,3,4 så visas bild 3, medans du kan rita i bild 0. Om du skriver FGPICTURE 2,0,4 så visas bild 0, medans du ritar i bild 2 osv osv... Den fungerar alltså som 4 papper. Du visar någon papper nummer 2, där har du ritat en dator. När han/hon tittar på pappret så ritar du något annat på papper nummer 0. Detta skulle se ut så här på ABC806:an... FGPICTURE 0,2,4 Hoppas att du förstår! / mvh Petter Stahre <4501>
-
· Text 2123 · w8 · kommentarOm du hade läst de tidigare inläggen, hade du vetat att det gällde att fixa det från assembler, inte BASIC. Tack iallafall. mvh Harald
-
· Text 2138 · w8 · kommentarHittade det själv i tekniska manulen till 806. OUT 6,<bild som ritas>*16+<bild som visas> /Thrud
-
· Text 2228 · w8 · kommentarJag har för mig att man lägger ut adressen i HR-minnet nånstans, kan ha fel, känner du till något, förmodligen skulle man kunna scrolla om det gick. mvh / Patric Ps. Om jag inte raderat texten så får du ha överseende med den, men jag visste inte om att det rörde sig om att från ASM göra nött.
-
-
-
· Text 2226 · w8 · kommentarDet är väl inte knepigt? FGPICTURE Pwrite,Pshow,Pno Pwrite,Pshow anges från 0-3 alt 0-15 vid 512K Pno är antalet bilder dvs 1-4 alt 1-16 vid 512K No problems? Moss / Patric
-
· Text 2227 · w8 · kommentarVidare skall kanske anges att bilderna lagras uppifrån och ner, dvs bild nr 0 ligger högst i minnet bild nr 1 ligger därunder osv. Vad jag inte vet är hur det blir vid 512K. Någon som vet? Mojs / Patric
-
· Text 2236 · w8 · kommentarDet blir likadant, man fortsätter med bild 4-15. Värre blir det om man ska accessa minnet via mappern, då måste man räkna 'bakifrån' för att inte krocka med grafiken om man inte vill det.
-
· Text 2252 · w8 · kommentarUttryckte mig litet oklart. Men eftersom FGPICTURE 0,0,x ger blocket 96-128 (126) och FGPICTURE 1,1,x ger 64-96 (94), dvs det växer neråt från 128K. Blir det då inte likadant vid 512K? Det borde bli (512-32)-512 (512) och sedan växa neråt. Om allt skulle vara lugn och frid. Men det här behöver man ju inte bry sig om man bara skall rita, och använda bilder, men däremot om man använder RAM: eller vill gå in med m-kod och annat hyss. Eftersom RAM börjar nerifrån och FGPICTURE uppifrån vore det ju bra om det verkligen började ända uppifrån och inte från 128. Är du med på noterna? Mojs / Patric
-
· Text 2259 · w8 · kommentarJodå, det börjar i själva verket uppifrån, men har man inte 512K så gör man "wrap-around", dvs bank 0-127K = 128-255K = 256-383K = 384-511K. Därför är det bra om man i sina (assembler-)program tar hänsyn till att man möjligen kan ha 512K, och inte gör programmet okörbart av den anledningen.
-
-
-
-
-
-
-
-
-
· Text 2069 · w8 · kommentarAngående det här med att ladda B med ett värde. Vad händer egentligen (maskinärt/programmässigt)? Det förekommer ju liknande vid inblockning av grafikminnet. Jag hoppas ni förstår min fråga, man OUTar ju inte ut B eller nåt sånt utan bara laddar B med ett värde, vad händer med det, vart tar det vägen? Muh /Mojs Patric
-
· Text 2071 · w8 · kommentarInstruktionen OUT (C),A heter lite fel. Den lägger nämligen ut hela BC på adressbussen, vilket grafikminnet känner av.
-
· Text 2072 · w8 · kommentarSom jag nämnt tidigare fungerar det fint även i BASIC att OUTa 16-bits adresser. Manulen LJUGER alltså med att man inte kan accessa grafik- minnet i basic. Det går så bra så!
-
· Text 2182 · w8 · kommentarJaha, då förstår jag. Är Z80 menad att fungera så, eller har det blivit av misstag? Nåja nåt sånt borde vara menat, sen finns det nog inte så "tabbar" i en CPU. Moss / Patric
-
· Text 2185 · w8 · kommentarVisst finns det löss i cpu'er! Mest i dom stora naturligtvis. Dom kan ofta fixas genom att uppdatera mikrokoden. Mikroprocessorer är ju enklare men inte helt buggfria dom heller. Tar man och tittar i z80-manualen så hittar man en massa tomma rutor i 'shift-rotate group'. det är instruktioner som man inte tog med i dokumentationen för att dom inte funkade som avsett.
-
-
-
-
-
-
-
-
-
-