🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by Frank Bergemann Sun, 22 Sep 1991 09:07
GEM
#387
Author: Frank Bergemann
Date: Sun, 22 Sep 1991 09:07
21 lines
1363 bytes

	hallo !

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 ?
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 ;

Abhilfe schaffen ? .... logd() soll den logarithmus dualis berechnen....
das ganze soll dann die Anzahl der fuer den Bildspeicher notwendigen 
Bytes ergeben .... 

Gruss !
... Frank 
Re: GEM
#386
Author: 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 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads