· Text 412 · w6 · inlagg
Är det någon som vet, och kan berätta, hur man gör FGPOINT, FGFILL
o.dyl. i assembler?
Retro Preservation Workspace
Monitorn
Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.
Grafik i assembler
53 posts in thread
-
-
· Text 420 · w6 · kommentarJag sysslar just med det, men på en abc806. Det är inte så krångligt, men det skulle ta en j-a tid att beskriva här i msg. evnt. blir det en artikel om det. TFP
-
· Text 429 · w6 · kommentarÄr det egna rutiner eller blir det ett interface mot ABC:ns grafikrutiner? Jag har gjort ett dylikt interface för lite sen, och det verkar funka bra. Håller nu på med ett likadant för Pascalen.
-
· Text 432 · w6 · kommentarFör tillfället ett hopkok av tolkens och mina egna. bl.a. finns det nu möjlighet att göra invert, dvs. byta färg enl. en viss algoritm. Förstår ni?? TFP
-
· Text 439 · w6 · kommentarGäller det alla funktioner (FGLINE, FGFILL mm.)? Finns det något nytt "godis"?
-
· Text 442 · w6 · kommentarInvert fungerar/finnes ej på FGFILL,FGPAINT. Jag har även laborerat med FNCIRCLE, men det är knappt påbörjat. Planer på ett sudigumkors med en mus???. tja, sen är det inte så mycket ännu. TFP
-
· Text 443 · w6 · kommentarFGPAINT är ju förståeligt om det inte finns invert, men FGFILL vore önsk- värt. På önskelistan står ju givetvis också FGSPRITE...
-
· Text 446 · w6 · kommentarJo, FGFILL är inget problem, dock är fgpaint som du skrev det. FGSPRITE, gärna det, men hur skall det styras osv. vilka parametrar skall finnas, skall dom kunna 'glida' över/under varandra???? Jag tror att det kan bli ganska svårt att göra. TFP
-
· Text 453 · w6 · kommentarJag kan försökra dig om att det blir svårt att göra en rutin för sprites som klarar fler nivåer och krasch av två polare,strunta i FGSPRITE!!! Gör det som är rimligt,men det bör väl helst vara bra gjort. En liten vädjan: Gör färdigt det du kan utan större svårighet och gör det bra. Man kan utveckla en sak till det oändliga,och då blir man ALDRIG färdig. Vad som kanske istället skulle kunna önskas är en rutin klarar att flytta ett område till ett annat,och att samtidigt invertera området efter valda mönster,(precis som på 1600) men utöver det borde man kunna definera ett objekt och sedan bara placera ut denna på skärmen,samma sak men figuren ligger ej i synligt område. Som jag har förstått så måste FG-rutinerna koppla bort det vanliga minnet blocka in HR och rita och sen tillbaka. Av detta kanske man skulle kunna tänka sig att det tar litet onödig tid. Något som vore önskvärt är att ett kommando stänga av all direkt skrivning i HR, därefter kunna rita upp en bild och sedan med ett kommando verkställa det hela. Alla kommandon skulle då lagras i en buffert och sedan kopplas HR-minnet in och sedan ritas allt på en gång. Detta borde snabba upp en del skulle jag tro,då man bara kopplar in HR en gång för alla. mvh T.M.G. Ps Var rutinenerna gjorda för 806,TFP?? I så fall tycker jag att du skall strunta i att vara kompatibel med andra 800'or såvida 806-rutinerna skulle försämras. 806 har ju bättre grafik!!! Jag hoppas inte någon tycker jag är för stygg.
-
· Text 454 · w6 · kommentarDom finns bara för ABC806, och då i 512*250 mod. Angående sprites: Jag tror att jag vet ett sätt. Och jag har misslyckats med fgarc (cirkel hanteringen alltså...). TFP
-
· Text 458 · w6 · kommentarDet var ju kul. Vad då för sätt (angående sprites). Hur hade du tänkt dig fgarc? Jag gjorde en funk som ritar cirklar, den räknar bara ut en åttondel av cirkeln och spegelvänder sedan denna. Jag änvänder mig av cirkelns ekvation: x2 + y2 = r2 So to speak. Denna metod tillåter tyvärr inga elipser,men den ritar inte ut onödiga punkter dvs som cos,sin. OM du inte riktigt hajar kan jag beskriva funken närmare. Jag tror det är förmånligt om man SKITER i cos,sin. Men det kanske du redan tänkt dig? Heja ABC806 !!! mvh TMG
-
· Text 459 · w6 · kommentardet som är problemet med fgarc är jus det att räkna ut punkter, jag misslyckades, så kom igen och förklara.. FGSPRITE kommer bara att finnas i ett plan med möjlighet att flytta ett (en) sprite till x/y kordinat,dvs. man måste göra allt manuellt (tills vidare... men det skall jag nog kunna råda bot på...). Det hela ligger för tillfället på sängen (vilar...) och jag sysslar med lite annat under påsken så jag vet inte när jag sätter mig ned nästa gång. Men följande kan vara intressant att veta: dessa adresser använder sig HR-kortet av: 65267 max antal bilder 65268 vilken bild 65269 senast valda färg (obs, ej 0-3 utan enl. något slags mönster som jag inte har härledt...) 65270 max antal färger samtidigt??? 65271 ???? 65272+273 = Kolumnoffsett (används vid FGCTL 7 t.ex. då =8) 65274+275 = Max kolumn 65276+277 = Kolumn 65278+279 = Rad (OBS!! 240-rad då den har origo i nedre hörnet...) 65266 = vilket attribut som för tillfället används. Attribute 7 kn såleddes ersättas med poke 65266,7. TFP
-
· Text 460 · w6 · kommentarLiten ifyllnad: 65269 akt färg enligt:Vid 16 färger:32103210 där 3210 är färgen Vid 4 färger:10101010 där 10 är färgen att färgen redan ligger i alla bitar gör det snabbare att använda byten för att lägga in färgen i bildminnet. 65271 kod för resolution: 0=240, 1=256, 2=512 Matts ps. För alla som inte redan upptäckt det: Brukisen till 806 innehåller på s. 48 en direkt lögn, grafikminnet är nämligen synnerligen adresserbart i BASIC. Basic's OUT a,b skickar nämligen 16 bitars portadress, så man gör bara OUT Adress+52,f_block. Adress måste vara delbar med 4096, och är den adress som det valda blocket ska läggas på i minnet. f_block är numret på det aktuella 4K blocket ur 128K- minnet. Bit 7 måste dessutom sättas för att adressera blocket, med b7=0 får man tillbaka det vanliga minnet. Själv brukar jag lägga blocket över DOS, och hämta/spara blocket med en sträng som ligger över DOS. ds.
-
· Text 470 · w6 · kommentarJag hoppas att det duger om jag förklarar i Basic? DEF FNCircle(Orx,Ory,Radie) LOCAL Orx,Ory,Radie ! Origo för x,y samt radien R2=Radie*Radie : Radie=Radie*.7 FOR I=0 TO Radie X=SQR(R2-I*I) FGPOINT Orx+X,Ory+I,Color : FGPOINT Orx+X,Ory-I FGPOINT Orx-X,Ory-I : FGPOINT Orx-X,Ory+I FGPOINT Orx+I,Ory+X : FGPOINT Orx+I,Ory-X FGPOINT Orx-I,Ory-X : FGPOINT Orx-I,Ory+X NEXT I RETURN -1 FNEND Som du ser så är det inte mycket uträkningar,vilket du förstår fördelen av. Dessutom följer denna metod helt och fullo en pixel,dvs ju mindre cirkel desto snabbare går det därför att den inte behöver räkna ut så mycket. Problemet är detta: En pixel är inte kvadratisk,cirkeln blir en elips. Botemedlet på detta är räkna om y koordinaten,du får då två nya y-värden ett som motsvarar I och för X; I2=I*Adj. : X2=X*Adj. Adj. får räknas ut med hjälp av storleken på en pixel. Det blir en liten skillnad mellan färg- och gulskärmen. Du kan ta och mäta längden på 100 x-koordinater resp 100 y-koor. Ja,hur man sen räknar ut får du klara själv,det är ju inte svårt. Jag vill dra mig till minnes att för färg blir det Adj.=.66 och för gult blir det Adj.=.7. Jag hoppas du förstår min enkla redovisning,du får ta och pröva,jag kan ha glömt nåt. Förhoppningsvis skall denna metod lämpa sig bra för maskinkod bättre än cos,sin,hehe! Jo,man kan inte göra hur stora cirklar som helst för då blir R2 för stort dvs över 65535 gränsen ligger någonstan vid Radie=190,men det är ju nästan litet väl stor cirkel. Rutinen är snabbare än cos,sin,men ändå mer "exakt",ritar aldrig samma punkt fler gånger. Notera även att du inte får multiplicera y-korrdinaten med tal över 1 för då blir den inte sammanhängande. mvh TMG Ps. Hoppas det blir nåt (snabbt,mumsmums) Den duger bra i Basic,testa!!
-
· Text 476 · w6 · kommentarDin cirkelalgoritm är enkel men slö. Jag har ett annat förslag: Def fnquno(radie) local x,y,d y=radie : d=3-y-y : while x<y if fnpoints(x,y) if d<0 d=d+4*x+6 else d=d+4*(x-y)+10 : y=y-1 x=x+1 : wend if x=y return fnpoints(x,y) else return 1 fnend Def fnpoints(x1,y1) fgpoint x+x1,y+y1 fgpoint x+x1,y-y1 fgpoint x-x1,y+y1 fgpoint x-x1,y-y1 fgpoint x+y1,y+x1 fgpoint x+y1,y-x1 fgpoint x-y1,y+x1 fgpoint x-y1,y-x1 return 1 fnend X,Y Cirkelns centrum Radie Cirkelns radie
-
· Text 477 · w6 · kommentarEhum,ehh öhh va? Skulle det där vara snabbare? För det första blev det inte snudden på en cirkel ens en gång. 8 diagonala sträck i par om två motsatta (cirkel) Ska jag tro på dig får du skriva ett komplett program som fungerar. 10 DEF FNQuno(Radie) LOCAL X,Y,Radie osv. testa programmet själv! En liten stilla undrar: VAD HAR D MED SAKEN ATT GÖRA????? Fnys!!! mmuhip /TMG (med mycket undrande hälsningar i påsk)
-
· Text 481 · w6 · kommentarDet är väl inte mitt fel om du é så järndö så du inte kan läsa innantill. Jag vet inte hur du gjorde ditt program men mitt fungerar hur bra som helst. Jag anser det inte vara på mitt ansvar om du inte lärt dig BASIC. Du får väl ursäkta mig men jag visste inte att ABC800 var ett slutet möte. Är inte detta till för att man ska dela med sig av erfarenheter osv. ? Det ska bli jävligt kul och se hur du hade tänkt skriva ditt program i assembler ! Jävligt trevligt att dra roten ur vad som helst. Kika lite kort på ärenderaden om du inte vet vad du ska skriva det i. Det finns processorer som kan addera och multiplicera men knappast dra rötter ! Angående hastigheten:; Har du nånsin i dit (korta) datorliv sett en algoritm för rotdragning ? Undersök gärna detta närmare om du är osäker ! OBS! när fantomen kör assembler står infödingarnas BASIC stilla ! (KÅ) (dvs. det är inte säkert att det är snabbare i BASIC men i assembler...) Till slut: Lär dig va f.n du snackar om innan du börjar häva ur dig vadsomhelst Om det inte passar kan du dra åt helf..te ! Den där algoritmen é åt hel mer seriös än vad du nånsin kommer att bli ! Den är gjord av J Michener som en vidareutveckling av J E Bresenhams teorier i ämnet "A linear algorithm for incremental digital display of circular arcs" Communications of the ACM 1977. Frostfrusna hälsningar
-
· Text 482 · w6 · kommentarOjsan,jag får be om ursäkt. Hördu,så taskig var jag väl inte? Du ska inte tro att jag menade vara dum. Ursäkta så mycket alla jag föro- lämpat. Men den lilla variabeln D fick ju bara vara med i uträkningarna Ursäkta,ehum,men skulle inte ni eventuellt glömt eller missat något. Jag skrev faktiskt av rutinen i godtro,och hoppades att det skulle bli något. Men tyvärr blev det inget. Vid närmare granskning använde du bara variabeln d för att ge den ett värde. du plussade bara x och y. Jag checkade rutinen fler gånger, vände på > och < men det blev aldrig någon cirkel. Hördu,kom igen visa!!! Ps. Nu slipper du mig i en vecka. Rotdragning är inte lätt. Jag ska ta och kolla rutinen en gång till! Mors
-
· Text 484 · w6 · kommentarGlöm alla tidigare kommentarer!!!!!! Någon bra ursäkt har jag inte! Men jag tittade bara flyktigt på rutinen,matade in den,och körde... ingen cirkel,nähe! Jag kanske har skrivit nåt fel. glutta..glutta.glutt bök.bök.bök... Det blev inte heller bra. Äh,jag skriver och frågar! Gjort...men dina svar gav mig en smärre chock,jag svarade litet...mycket fånigt (vilket jag även kanske gör nu???) Jag tittade igenom den litet mer nogrannt. Och förstod hela principen,ja.. nu gick jag och testade. Nu visste jag litet bättre värför d var där och blutta. Nu fungerar det!!! Och den var ju bra, ingen märkbar skillnad men i assembler blir den nog snabbare. Det enda jag inte satt mig in i är beräkningen av d,men vi får väl se om jag lyckas klura ut det. Jag hoppas du förlåter min litet väl snabba slutsats,litet ogrundad? Jag hoppas du inte blir ännu surare men man behöver inte bli så sur. Nog för att jag var för spydig,men... mvh TMG Ps. Nu ska jag ta semester från allt vad dumburkar heter och åka litet skidor. GLAD PÅSK !!! I morgon bär det av till ÅRE. Skönt!!! (idag,he)
-
-
-
· Text 478 · w6 · kommentarDessutom tvivlar jag högst att din plojrutin skulle vara snabbare. Skulle SQR(x) vara så slö???? För det är det enda jag räknar ut. Fnys
-
· Text 480 · w6 · kommentarHar du försökt göra rotdragning i assembler nån gång ? Skulle vara kul å se hur en expert gör ! Kaerimasu.
-
· Text 491 · w6 · kommentarDet finns en j-vligt intelligent assembleralgoritm för att dra upp saker med roten (hehe...), jag ska se om jag kan rota fram den.
-
-
· Text 483 · w6 · kommentarJag ger mig, men kan du inte ta och kolla din rutin (så att du inte glömt nåt) Hoppas du vill hjälpa mig och reda upp det här??? Ursäkta en än gång.
-
-
-
· Text 485 · w6 · kommentarTackar, skall testa det (när jag får tid...) TFP
-
-
-
-
-
· Text 611 · w6 · kommentarVarför inte sprites på ABC806?? Det finns ju utvecklat till ABC80!
-
· Text 612 · w6 · kommentarJag har inte det minsta emot sprites på ABC806. Men svårigheten att göra rutinen blir bara svårare ju mer avancerad den skall vara och multippel- faktorn är ganska hög, närmare kvadraten. Jag tänker inte göra någon än så länge, hellre en massa bra rutiner utan sprites än en massa halv- fungerande med taskig sprite. Men det kanske finns nån annan som kan. I sådana fall uppmuntrar jag honom att göra en. Fast, vad skall man ha sprites till, är det värt besväret??? mvh TMG
-
· Text 613 · w6 · kommentarOm det är någon som får för sig att skriva sprites och vill ha lite tips & smaskiga idéer kan höra av sig till Tom Sjöberg i styrelsen. / TGP
-
· Text 615 · w6 · kommentarvisade Allan Larsson T-D-X (tel 08/960180) förra gången jag träffade honom. Det var alla gamla funktioner - uppsnabbade, och en del nya (bl.a. sprites) + en del demoprogram på diskett. Systemet var inte prissatt ännu men han gissade c:a 2000.- Om inte Allan är inne så vet nog hans sekreterare vad priset blev.
-
· Text 625 · w6 · kommentarJag såg detta PROM aktiv i Tisdag. Det var en som inte tyckte mitt grafik program var så där jätte snabbt, och frågade om han fick sätta i ett annat PROM. Jovars...det var hyffsat. Principen för den är i huvudsak vad jag tidigare har funderat på och även nämnt här. Du lägger upp allt du skall rita i en sträng (kodat) och gör sedan med ett kommando som kallas FGDRAW xstart,ystart,figur¤. Det tar ju tid att hoppa fram och tillbaka i BASIC och mappa in HR-minnet för varende FG-rutin. Skickas allt med i en sträng mappas det bara in EN gång och ETT hoppitopp i BASIC. Således går (borde) FGPOINT gå fortare än FGLINE då FGLINE måste beräkna koordinater och FGPOINT redan får med sig dessa. De nya kommandona är FLASH Färgval¤,Färgval¤; FGDRAW x,y,figur¤ FGRUB x,y,figur¤; EXTFLASH Färgval1¤,Färgval2¤,Färgval3¤; FLASH och EXTFLASH växlar automatiskt mellan färgvals uppsättningarna, interuptstyrt Det är på så sätt man får VVS ledningarna att 'flyta'. Ojj, det höll jag ju på att glömma. FGCTL MIX är inte dumt, den grejen har ju diskuterats här. Man kan alltså ha 16 färger som kan mixas ihop (upplösning blir då 256x240) ex. FGCTL MIX BLK+BLK+RED+WHT+RED+BLU+BLU+CYA fgnummer 0 är svart,2 är rödvitt,3 är rödblått,4 är blåcyant... 16 såna här par kan användas, inte illa. Det blir 2 512x240 pixels med var sin färg. Är det någon som sett Demo programmet, det är MYCKET imponerande? Alla 806or borde ha detta PROM men Luxor var visst inte så värst intress- erade. Sprites är inte det riktigt rätta ordet. Det fungerar så här att alla kordinater i Figur¤ är relativa till xstart,ystart i FGDRAW xstart,ystart.. Och då kan man ju ha en liten figur som man kan flytta, man suddar figur¤ med FGRUB xstart,ystart,figur¤. Kodning av figur¤ kan jag ta upp om någon är intresserad, det spelar ju inte så stor roll om man inte har PROMet. Men de flesta borde skaffa sig det. Jag tänker nog göra det. ehh NO FLASH stänger av FLASH,EXTFLASH. mvh TMG
-
· Text 630 · w6 · kommentarHur får man plats med allt? Har man tagit bort V24-drivern, eller? Jag har för mig att det inte finns allt för mycket plats i det som finns i dag. I så fall, kan man få den delen mjukladdad?
-
· Text 636 · w6 · kommentarJag tror att de har har krympt PR/V24 rutinerna litet. De har även knysslat litet med FGLINE o sånt för att få det mindre. Å andra sidan är det inte såå mycket som lagts till, men ändå tillräckligt. mvh TMG
-
· Text 638 · w6 · kommentarVilka är förresten "de"? Med andra ord, vem har skrivit rutinerna.
-
· Text 655 · w6 · kommentarHmm, DATABERG heter hans företag. Berg i efternamn och bor i Gävle eller Uppsala. Vi har köpt PROMet på jobbet så jag har studerat det litet vidare. Den sista versionen är 3.1. Uppgifterna i tidigare inlägg är inte riktigt korrekta. mvh TMG
-
-
· Text 637 · w8 · kommentarÄr kortens adress rätt då? Eller byglingarna för drivarna på korten? Kan vara nåt sånt ev. Om du slår på drivarna, exp.enheten, och slutligen datorn, söker den inte på nån av driveenheterna? -=<MiN>=-
-
-
· Text 652 · w8 · kommentarDet kan bero på att lödningarna till bl a dioderna i nätdelen i bildskärmen börjar släppa. Omlödning av dåliga lödningar kan hjälpa.
-
-
-
· Text 616 · w8 · kommentarKörtiderna för de olika Pascal-vers., ja, jag blir stum alltså. Wooooooow!!!!!! Amazing!! Har du data om hur snabb ABC's basic är också, så man får en referenspunkt så att säga? Så har jag ett problem som jag går bet på alltså, och det har med ihop- koppling av två ABC-maskiner att göra. Det är alldeles åt skogen, det vill inte funka åt mig. Så här: ***** ***** * 1 * - - - - * 2 * ***** ***** Från 1 till 2 så har jag en seriell kabel. Dator 1 fungerar som värd, 2 som terminal. Vad som händer är att överhuvudtaget inga tecken alls kommer upp på 2, om man inte trycker som en idiot på t.ex mellanslag. Varför, är min fråga! Hälsningar: -=<MiN>=-
-
· Text 619 · w8 · kommentarOm man kodar på motsvarande sätt i Basic2 så tar det 1 minut och 48 sekunder att köra programmet.
-
-
· Text 617 · w8 · kommentarHm, anmärkningsvärt liten skillnad mellan Turbo Pascal på ABC:n och på SX:en. Nog borde väl en 16MHz 386SZ vara mer än 4 ggr snabbare än en 3 MHz Z80, tycker man!
-
· Text 618 · w8 · kommentarTja, men du vet ABC... hehe... Pc, går det att äta? :-)éÅ -=>MiN<=-
-
· Text 629 · w8 · kommentarKan det inte vara så att minnen m.m bromsar upp 386:an ?
-
-
-
· Text 616 · w6 · kommentarDet finns visst ett program som har namnet MERBASIC med instruktioner för rörlig HR-grafik (animering). Om dessa kommandon funkar som sprites vet jag ej, men klart är ju att man tydligen får lättare med att flytta HR-grafik. Ni kan läsa om programmet i Svenska Programbörsen sid 2. Programmet kostar 650:- och har också kommandon som SPOOL (lib),COPY (kopiering av filer), WAIT, TIME, DATE och LINE25 samt ljudinstruktioner för ABC800. Programmet funkar visst för alla 800:or. Om sedan programmet är skrivet i assembler vet jag ej men det förut- sätter jag. Petter Stahre <4501>
-
· Text 617 · w6 · kommentarDen rörliga grafiken i MERBASIC är ett slags "halv-sprites". Man lagrar utseendet för en figur i en sträng, och kan sedan med en BASIC-instruktion placera ut den på bildskärmen. Samtidigt sparas det som skyms av figuren i en annan sträng. För att ta bort figuren igen använder man samma instruktion, men med den andra strängen, varvid figuren försvinner utan att lämna några spår. Sen är det bara att placera ut figuren igen på något annat ställe, så har den rört sig en bit... Demo-program ochett program för att rita figurerna med medföljer. Anledningen till att jag vet det här är att det är jag som har skrivit MERBASIC. Egentligen skulle programmet funnits med redan i förra katalogen, men anmälan kom någon/några veckor för sent.
-
· Text 618 · w6 · kommentarHur stor (angivet i pixels) får en halv-sprite vara? Och hur många sprites kan användas? Vilken upplösning och hur många färger får man använda i spriten? Petter Stahre <4501>
-
· Text 623 · w6 · kommentarObegränsad storlek, men ju större desto långsammare. Man kan ha så många man får plats med i minnet, men man får ju hålla reda på all själv, och hamnar de ovanpå varandra, så fungerar det ju inte om man tar bort den undre före den övre. Alla sexton färger (varav en transparent) kan användas, och upplösningen blir den man valt med FGCTL, oberoende av lagrings- formatet. (Det går förstås inte att se alla sexton färger om man md FGCTL valt bara 4). Dessutom finns det instruktioner för scrollning av hela HR-skärmen i alla riktningar.
-
-
· Text 627 · w6 · kommentarHur kodas strängarna med figurerna??? muh TMG
-
· Text 641 · w6 · kommentarDet behöver man egentligen inte veta, eftersom det finns ett program för att koda figurer. Men, i alla fall: Det hela inleds med en byte som talar om hur tätt packad figuren är (pixels/byte) och om färg 0 ska tolkas som transparent eller vanlig färg. Därefter följer figurens linjer. Var och en inleds med en längd- angivelse, som föjs av själva utseendet. Så var det med det.
-
· Text 656 · w6 · kommentarÅhå! Jag förmodar att "utseendet" är färgnummret för varje pixel i tur och ordning. Borde vara för snabbast möjliga exec. Ärende: Pres av Grafik PROM, GRAF 806 Vers 3.1 (ABC GRAF) De nya BASIC-kommandona man får med PROMet är: FGDRAW Ritar ut en datasträng (Mycket snabbt) FGRUB Samma som FGDRAW men Färgnr är alltid 0 FLASH Man kan växla mellan 2,3,6 färgval,automatiskt NO FLASH Stänger av FLASH FGCTL MIX Färger paras ihop 2 och 2, res=256x240 FGSPEC -- Kan inte utrycka det riktigt, saknar manualen -- *kommer ej ihåg det sista* Det följer med en EXTENDED BASIC och därmed följer en drös nya kommandon bland annat: MIXSTATUS För att definiera linjer som skall mixas MIXLINE Ritar ut en mixad linje FGCLR -- Vad kan tänkas??? -- LDIR,LDDR Samma som m-kodens LDIR,LDDR FGLINE är förbättrat och upp till 25% snabbare FGPAINT är <=75% snabbare, beror på ytans typ FGFILL är nåt på ca: 17% snabbare Litet övrigt: Man kan kombinera 512x240 med 256x240, kan ju i vissa fall vara använd- bart. Med FGSPEC kan man AND litet i punkterna, vet inte riktigt hur det fungerar. Men med detta kan man får en figur att ritas framför en färg och bakom en annan. Och när man tar bort figuren finns det gamla kvar. Man kan även på nåt vänster rita två bilder på en och samma bild och med FGSPEC öppna "fönstret" och visa vad som finns bakom, det går även att stänga igen. Tja, vad finns mer att säga? I manualen står alla adresser till rutinerna så vill man göra något i m-kod behäver man inte göra några grundläggande grafikrutiner. Typ FGPOINT,FGPAINT osv. Alla?? systemvariabler finns oxå beskrivna. En positiv pryl med systemvaran beskriven. Tyvärr är nog inte terminal och printer rutinerna kvar i sina fullheter. mvh TMG
-
· Text 668 · w8 · kommentarOm din skrivare är en Microline 82A så klarar den inte högre överföringshastighet än 1200 bps. Om du kör med standardparametrarna så får du därför skräptecken. Jag skickar in filen PRINI.BAS som har använts för initiering av en sådan skrivare. Där framgår också hur parametrarna skall vara satta.
-
-
-
-
-
· Text 626 · w6 · kommentarJag har väl inte sagt att det inte fanns, tack för upplysningen. Kan man använda detta tillsammans med omdiskuterat PROM??? Är det många som har MERBASIC??? mvh TMG
-
-
-
· Text 612 · w8 · kommentarHur är "Pass-Kallen" för 800:an?? Snabbare än basicen? Hur mkt minne roffar den åt sig, och vilket minne dessutom? -=<MiN>=-
-
-
-
-
-
-
-
-
-
-
· Text 425 · w6 · kommentarMenar du göra själva rutinerna eller anropa de befintliga?
-
· Text 430 · w6 · kommentarJag skulle vilja veta hur rutinerna anropas, ja.
-
· Text 438 · w6 · kommentarDet är ganska komplicerat, det finns nämligen ingen hopptabell e dyl så man får leta rätt på rutinerna själv. Det enklaste sättet är kanske att gå via instruktionslänkarna och på så sätt få reda på startadressen. Sen finns det två vägar att gå: antingen kan man simulera basic-kod och anropa instruktionen "från början" dvs låta instruktionen avkoda dina i p-kod angivna koordinater. Då får man tänka på att man hoppar ur med felmeddelande om man kommer utanför skärmen. Det finns två sätt att undvika även detta: antingen att själv kolla koordinaterna innan man skickar iväg dem, eller också att sätta upp ON ERROR GOTO och låta den peka på t ex en CALL-instruktion till lämplig felhanteringsrutin. Den andra metoden att anropa rutinen är att man själv sätter upp stacken och lämpliga register och hoppar in efter anropet till basic-evaluatorn. Även här gäller att man själv måste kontrollera att koordinaterna är riktiga. Den här metoden är lite svårare eftersom man måste veta (m h a dis- assemblering) var man skall hoppa in för de olika rutinerna. Jag har skrivit några rutiner för att göra detta, men då de inte fungerar hundraprocentigt vill jag inte släppa dem. Det går tyvärr inte att förklara närmare (med programexempel) då det är såpass komplicerat att göra.
-
-
-