🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: dnet.atari
Article #386

Re: GEM

#386
From: Karsten Isakovic
Date: Sun, 22 Sep 1991 19:00
49 lines
3148 bytes
Hallo Frank,

>Fuer eine saubere GEM-Einbindung brauche ich Infos ueber den Overscan...
>die Fkt. vrt_cpyfm benoetigt in ihrem parameterfeld MFDBs in denen u.a.
>eine Angabe "Breite des Speicherblocks in Integers". Das hiesse allerdings, 
>dass vorausgesetzt wird, fuer saemtl. moegl. bildschirmgroessen wirkl.
>jede zeile ein vielfaches von einem Word im speicher belegt - ist dem so ?

Ja, das GEM arbeitet nur mit Zeilen die in 16 Pixel Schritt organisiert 
sind. Du machst allerdings einen grossen (frueher weit verbreiteten) Fehler:
Wenn man vom/auf den Bildschirmspeicher blittet darf man den Screen-MFDB nicht
selber ausfuellen! Dies geht bei mindestens 5 mir bekannten Grafikkarten
garantiert schief. Immer einen NULL-Pointer in fd_addr benutzen!
Es bereitet dem VDI keinerlei Probleme, zwischen MFDBs unterschiedlicher
Wort-Breite zu kopieren, womit wir gleich zu Deiner zweiten Frage kommen...

>ausserdem finde ich keine funktion, die angibt, wie gross der in der
>gegebenen Aufloesung verwendete Bildspeicher ist - kann man da einfach 
>mit der Rechnung (nach v_opnvwk) 
>
>       (work_out[0]+1)*(work_out[1]+1)*logd(work_out[13])/8 ;
>

Nein, nicht ganz ;-) Nimm statt logd(work_out[13]) lieber die Anzahl der
Planes, die Du bei vq_extnd in work_out[4] erhaeltst.

Lege Deine 2.Bildschirmseite mit BPL = Width/8 * Planes und obriger Laenge
an. Wenn Du den zugehoerigen MFDP korrekt ausfuellst und fuer den Screen
den MFDB mit einem Nullpointer verwendest geht es unter allen Aufloesungen.

Du kannst auch mit eigenen Routinen in diesen Speicher schreiben und den
Bereich mit vro_cpyfm auf den Schirm bringen (macht Zb Script-II so). Dies
geht aber nur, wenn das Bitplane-Layout, dem des STs entspricht. 
Allerdings gibt es ja mittlerweile auch wieder eine Menge VGA-Karten, bei
denen dieses nicht der Fall ist. 
 
In diesem Falle (schreiben auf eigenem Bildschirmspeicher) muss man daher
folgendermassen vorgehen:

Anlegen einer 2.Bildschirmseite mit 'obriger' Laenge. Allerdings nicht im
'bitplane-interleaved' Geraete-Format, sondern im ATARI Standardformat. Dies
heisst, 'Planes' monochrome Bitplanes hintereinander. Nach dem Beschreiben
dieses Hintergrundpuffers muss noch in das jeweilige Geraeteformat gewandelt
werden. Dies geschieht mit vr_tranfm und es ist wesentlich guenstiger,
wenn man noch eine 3.Bildschirmseite anlegt, in die tranformiert wird. Das
transformierte Ergebnis kann man dann mit vro_cpyfm auf den Schirm bringen
(wie immer Null-pointer in fd_addr verwenden).

Gruss, Karsten 
Technical Details
Message-ID: <4861@trick.cs.tu-berlin.de>
Path: arc1-ca.pugleaf.net!gmdzi!unido!opal!ki
References: <2681@netmbx.UUCP>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII-7-bit
X-Google-Thread: 12bdcf,27a7b83a68c20f06,start
X-Google-Attributes: gid12bdcf,public
X-Google-Thread: 14eee0,27a7b83a68c20f06,start
X-Google-Attributes: gid14eee0,public
X-Google-ArrivalTime: 1991-09-22 12:38:43 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!opal!ki
From: ki@opal.cs.tu-berlin.de (Karsten Isakovic)
Newsgroups: dnet.atari,sub.sys.st
Subject: Re: GEM
Message-ID: <4861@trick.cs.tu-berlin.de>
Date: 22 Sep 91 19:00:21 GMT
References: <2681@netmbx.UUCP>
Distribution: dnet
Organization: Technical University of Berlin, Germany
Lines: 49