VBXE mit WUDSN/MADS

[pps]

Ich fange einfach mal an... Das anhängende "Projekt" einfach in ein Verzeichnis packen und dann haben wir ein Programm, das einfach nur testet, ob ein VBXE da ist.

Der entscheidende Code ist natürlich in der .hea Datei und stammt aus einer Doku zur VBXE. Mein Programm bringt dann nur entweder Rot und stopp oder Grün und stopp - also nichts Wildes...

vbxe_test.zip

(1.72 KiB) 62-mal heruntergeladen

[Dr. Irata]

Guten Morgen,
habe das bei mir auf dem MacEmu getestet und bekomme natürlich Rot - der Mac hat keine vbxe Erweiterung.
Die hea-Date verstehe ich gar nicht

Vielleicht ist das ja auch gar nicht primär zwingend notwendig. Klar ist nur, man muss vorher eine Menge "Zeugs" initialisieren bevor man loslegt.
All das macht wohl die hea-Datei... diese includiert ins System und man kann starten.

Wir sollten aber zunächst hier eine kleine Zusammenfassung auflisten, was die vbxe Erweiterung alles kann bzw. was man damit machen kann.
Und dann würde ich mit einem einfachen Code anfangen - z.B. ein Hallo Welt
LG
Peter

[Dr. Irata]

... nun habe ich in Altirra die vbxe aktiviert und schon ist der Rand auf grün!

Zur Aktivierung einfach in Altirra auf System/Configure System//Devices gehen, dann mit Add das VBXE Board auswählen

[pps]

.hea Dateien sind normal einfach Definitionen. Aber hier sind auch Macros dabei, die man für die VBXE nutzen kann. Ich habe auch eine .hea Datei für all die ATARI Adressen im Normalfall immer mit meinen Dateien verlinkt - die habe ich irgendwann mal von Graph2Font genommen und ab und an wird sie ein wenig erweitert.

Das .zpvar=$f0 verlegt die Zeropage Variablen Definition auf den Bereich ab $f0. Normal macht MADS das sonst ab $80.
Gerade das .zpvar nutze ich gerne, da man da nicht selbst genau wissen muss, wo genau die zp Adressen sind und automatisch je nach Dateityp alles ordentlich reserviert wird.

statt:

Code: Alles auswählen

	regx		equ $80
	regy		equ $81
	copyfrom	equ $82
	shscrol		equ $84

macht man einfach:

Code: Alles auswählen

	.zpvar .byte regx,regy
	.zpvar .word copyfrom
	.zpvar .byte shscrol

Mit dem .zpvar=$f0 (das davor kommen muss) werden diese Variablen dann automatisch ab $f0 angelegt, lässt man das weg, kommen sie ab $80. Man sieht, so kann man auch schnell in einem Rutsch den Beginn verschieben, sollte der Platz nicht mehr reichen. Bei den ganzen EQU müsste man das von Hand machen oder imho noch umständlicher vorher definieren:

Code: Alles auswählen

	regx		equ $80
	regy		equ regx+1
	copyfrom	equ regy+1
	shscrol		equ copyfrom+2

Da ich das nicht nutze, kann ich da gerade auch nicht ganz korrekt notiert haben (glaube mich noch an ein *regx+1 zu erinnern).

[pps]

... nun habe ich in Altirra die vbxe aktiviert und schon ist der Rand auf grün!

Zur Aktivierung einfach in Altirra auf System/Configure System//Devices gehen, dann mit Add das VBXE Board auswählen

Ich habe mir mehrere Systeme konfiguriert (in Profiles), die ich dann schnell in der Auswahl umswitchen kann. Auch beim nächsten Start startet Altirra normalerweise mit dem zuletzt genutzten Profil.
Außerdem habe ich mir noch eine Tastenkombination angelegt, mit der man mal eben zwischen 50 & 60 Hz umschalten kann. So kann man eifach testen, ob der Code in "beiden Welten" läuft.
Normalerweise startet in WUDSN bei mir alles direkt auf einem "NTSC Rechner". So ist das mit dem Timing dort später kein Problem - daher ist im Beispiel auf PAL das Rot nicht wirklich Rot, sondern schon in Richtung Lila verschoben ($32 ist auf NTSC noch nicht wirklich Rot und auf PAL noch so gerade eben am ehesten Rot ist: NTSC $44 und PAL 24).

[pps]

Was kann das VBXE/XL?

Hier mal eine Liste, die keinen Anspruch auf Vollständigkeit erhebt:

• es hat normalerweise 512 kB VideoRAM (entsprechend nur halb soviel, wenn man es auch als Rambo nutzt)
• 640x480 interlaced oder 640x240 mit 64 Farben
• 320x240 mit 1024 Farben
• 160x240 mit 1024 Farben
• 80 Zeichen Textmodus mit 256 Zeichen Fonts!
• es hat einen Blitter, der Funktionen für das Zoomen, Transparenz und Kollisionserkennung enthält
• man kann es auch als RAM Erweiterung nutzen (256kB Rambo)
• man kann auch statt RGB direkt VGA ausgeben (allerdinsg gibt es dann einige Funktionen nicht, da der VGA Core nicht weiter entwickelt wurde)

[Dr. Irata]

Ich habe ja noch überhaupt keine Ahnung, wie man die vbxe programmiert - immerhin scheint es abwärts kompatibel zu sein. Infinity läuft ganz normal.
Vielleicht weiß schon jemand, wie mal mehr Farben auf den Bildschirm zaubert.
Wie muss ich die DL bauen, damit ich die höhere Auflösung anspreche und die Mehrfarben setzen kann...

[Dr. Irata]

bedeutet das, daß man einen eigenen Speicher für den Bildschirm hat, der innerhalb dieser 512 kB liegt? Entsprechend auch der 256 Zeichenfonds in diesem Extraspeicher liegt? Die Frage ist nun, wie man das alles anspricht ...

[andymanone]

.
Yaron Nir aus dem AA-Forum hatte da damals auch noch was zur Programmierung des VBXE veröffentlicht:

VBXE - a step by step code example in MADs assembly

Ist vielleicht nützlich...

Gtx.,
andY

[Dr. Irata]

lieben Dank für den Link - ja das ist enorm nützlich!
Puh ... ganz schön kompliziert...

[pps]

Hallo Peter,

ja das ist alles nicht so einfach mit dem VBXE...

Ich habe ja noch überhaupt keine Ahnung, wie man die vbxe programmiert - immerhin scheint es abwärts kompatibel zu sein. Infinity läuft ganz normal.
Vielleicht weiß schon jemand, wie mal mehr Farben auf den Bildschirm zaubert.
Wie muss ich die DL bauen, damit ich die höhere Auflösung anspreche und die Mehrfarben setzen kann...

Wenn Du nichts von den Features des VBXE nutzt, dann passiert auch nichts. Man kann sogar Sachen machen, die ohne VBXE gut aussehen und mit VBXE dann besser. Dank g2F hatte ich das mal in einem NYD Intro gehabt:

2013_nyd2k14.zip

(3.91 KiB) 51-mal heruntergeladen

Einfach mal mit und ohne VBXE starten.

Es gibt eine eigene DL, die man in die VBXE schreibt, die dann quasi als Overlap über dem Bildschirm des ATARI ist - soweit meine ich das zu verstehen. Eventuell ist es auch möglich, dass nur diese DL dann aber von der VBXE genutzt wird bei den hohen Auflösungen - das ist eine Annahme von mir - habe noch nahezu 0 Ahnung von der VBXE.

bedeutet das, daß man einen eigenen Speicher für den Bildschirm hat, der innerhalb dieser 512 kB liegt? Entsprechend auch der 256 Zeichenfonds in diesem Extraspeicher liegt? Die Frage ist nun, wie man das alles anspricht ...

Soweit ich das sehe, gibt es diesen eigenen Speicher für diese Overlay Grafik, die Fonts, die VBXE_DL und das Zeug, das der Blitter so macht. Hat man die Rambo aktiviert, wird wohl der hintere Teil der VBXE verwendet, aber es wird nie geprüft, ob der Programmierer diesen Bereich etwa überschreibt mit Grafikdaten. Daher also ganz wichtig das abzufragen und dem Nutzer dann eventuell sagen, dass er einen anderen Core ohne Rambo nutzen muss.

Ansprechen ist mittels 2er Fenster möglich, die, wie bei Speichererweiterungen auch im Adressbereich des ATARI eingeblendet werden. Ein Bereich ist immer 16 kB groß, wenn man ihn nutzt (wird dann ab $4000 eingeblendet). Der andere Bereich ist variabel von 1 kB bis 16 kB und auch, wo man ihn einblendet. Man kann für beide Bereiche auch festlegen, ob nur CPU, nur ANTIC oder beide Zugriff haben dürfen.

[Dr. Irata]

Guten Morgen in die Runde,
leider ist das Thema hier etwas eingeschlafen. Wahrscheinlich liegt es daran, daß es zunächst scheinbar zu komplex ist.
Aber zusammen mit den vorhandenen Informationen können wir da sicherlich Licht ins Dunkle bringen.
Der Start von PPS war ja schon super...

Gestern hatte ich ein wenig Zeit, um mich mal ein wenig einzulesen.

Es gibt 2 Möglichkeiten die vbxe zu. nutzen: 1. Die Hardware ist in den Atari eingebaut oder 2. man nutzt einen Emulator.
Zum testen oder programmieren unter Mads brauchen die die 2. Option. Leider (für mich) kann der AtariMac800X-Emulator das vbxe nicht abbilden. Wir sind also auf Altirra angewiesen, was es für alle Mac-User wirklich schwierig macht.
Wie man vbxe auf Altirra aktiviert, wurde oben erklärt.

Wenn ich das richtig verstanden habe, dann setzt sich oder dann setzt man das vbxe mit den wichtigen Registern in den freien Bereich $D600 oder $D700. Daher ist es im 1. Schritt wichtig abzufragen ob ein vbxe installiert wurde und wenn, wo die Register liegen.
Die wichtigen Register des vbxe liegen dann zwischen $D640 und $D65F bzw. $D740 und $D75F - ab hier schreiben wir dann aber $Dx40.... und x steht entweder für den Wert 6 oder 7.

Die Register sind ähnlich wie die normalen Atari-Register die Verbindung zum vbxe-Board. Hier wird alles gesteuert und festgelegt.
Das Board selber (oder die Emulation) hat dabei einen eigenen Speicher von 512kB, einen eigenen Bildschirmbereich mit mehr Farben und höherer Auflösung, einen eigenen Displaylistbereich - die xdl - wo wie beim A8 alles festgelegt wird und einen Blitter, der sich wohl um Dinge wie PM/Kollision und Speicherverschiebung im vbxe kümmert.
Wenn ich das richtig verstehe, dann legt sich die komplexe Grafik des vbxe wie eine Schicht über den eigentlichen Bildschirm... wie das ganz genau aussieht, gilt es noch zu verstehen.

Grundsätzlich gibt es wohl im Vorfeld folgende wichtigen Schritte, die man vorbereitet ausführen sollte:

1. Definitionstabelle mit den ganzen vbxe Registern erstellen und in das Programm einbinden
2. Routine ausführen, um die vbxe zu detektieren (ja/nein/wo)
3. xdl abschalten (gibt sonst primär unschönes Geflacker)
4. Den Speicherbereich für die vbxe initialisieren und festlegen
5. Die xdl festlegen und initialisieren
6. Die Farbpalette für die vbxe initialisieren und festlegen
7. Den Blitter leeren, initialisieren
8. Die Sprite-Daten in den vbxe-Speicher kopieren und auf dem vbxe-Bildschirm abbilden
9. Den Blitter starten

Für jeden Schritt braucht man die entsprechenden Subroutinen, entsprechende Routinen liegen aber schon vor und können recht leicht genutzt werden, alles werden wir dann hier Schritt für Schritt erarbeiten und erklären.
Am Ende möchte ich ein kleines Demoprogramm hier entwickelt haben, wo man sich möglichst leicht dran orientieren kann.

Bitte um kräftige Mithilfe!!!

LG
Peter

[Dr. Irata]

... vorhin im Ruheraum der Sauna habe ich mir mal das vbxe Handbuch vorgenommen.
Viele Dinge sind dort theoretisch relativ klar, das aber dann in ein lauffähiges Programm umzusetzten wird sicherlich nicht einfach am Anfang.

Vielleicht fangen wir ja mit einem einfachen "Hallo Welt" - Programm an, wo zunächst ein vielfarbiger Text dargestellt wird.
Interssant ist übrigens der Blitter. Dieser sorgt für eine schnelle Verschiebung von Speicherblöcken im Speicher des vbxe und die notwendige Kollisionserkennung. Ich denke die Speicherblockverschiebung macht er völlig unabhängig von der alten A8 CPU und ist somit in der Lage auch größere Blöcke schnell zu bewegen. Mit über 17 Hz Takt ist er wohl 10x schneller - ich hoffe das stimmt alles

[pps]

... Mit über 17 Hz Takt ist er wohl 10x schneller - ich hoffe das stimmt alles

Na ich hoffe doch, dass er deutlich höher als nur 17 Hz taktet :duckundweg:

[Dr. Irata]

14.18 MHz ...

[Dr. Irata]

Step 1: VBXE Detect
Ganz oben hatte Ralf ja schon den Code für die Detektion des vbxe gepostet, ich wollte das aber hier nochmal (für mich) aufarbeiten und verstehen.

Hier mein Code, der nichts anderes macht als der von Ralf:

Code: Alles auswählen

core_version = $40
minor_version = $41


			.proc checkvbxe 
			mva #1 vbxeind
  			mwa #$d600 baseaddr
			jsr major
			bne @+
			jsr minor
			beq exitdetect
@		
			inc baseaddr+1
			jsr major
			bne @+
			jsr minor
			beq exitdetect
@			mva #0 vbxeind
exitdetect
   			 rts

major		
			ldy #core_version
			lda (baseaddr),y
			cmp #$10
			rts
			
minor
			ldy #minor_version
			lda (baseaddr),y
			and #$70
			cmp #$20
			rts 
			.endp

Was macht der Code:
Im Prinzip schon eine ganze Menge! Wenn ein vbxe Board im Rechner drin ist oder bei Altirra aktiviert ist, dann stehen die ganzen wichtigen Register entweder ab der freien A8 Adresse $D600 oder $D700.
Zunächst definieren wir auf einer freien Zeropage (ich habe $e0 genommen) die Variable baseaddr. Wenn wir später die Register des vbxe ansprechen wollen, dann einfach mit
ldy "Register"
lda (baseaddr),y
wir laden das entsprechende vbxe-Register also einfach in das y-Register und laden (oder speichern) dann den Wert in den (oder vom) Akku.
Das vbxe-Core liegt im Register $40, der Untercore im Register $41. Beide Register müssen wir bei $D6... oder $D7.... abfragen und verarbeiten.
Wenn entsprechende Werte in den Registern stehen (also ein vbxe vorhanden ist), stelle ich vbxeind auf den Wert 1.
Falls kein vbxe vorhanden ist, steht vbxeind auf 0 - das lässt sich abfragen.
Damit ist Step 1 fertig!

In Step 2 schalten wir zunächst das xdl ab....

[Dr. Irata]

Um die xdl (extended displaylist / Displaylist des vbxe) ab- / oder anzuschalten, wird das gleiche Register benutzt, wie schon bei der vbxe Detektion:
baseaddr + $40
Dieses Register hat eine differente Schreib-/Lesefunktion. Bei der Schreibfunktion wird die xdl entweder (mit Wert 0) ausgeschaltet, oder (mit Wert 1) eingeschaltet.
Man sollte die xdl nach der vbxe-Detektion ausschalten bevor man die ganzen weiteren Initialisierungen durchführt, damit man auf dem Bildschirm kein Geflackere bekommt. Anschließend, wenn alles fertig ist, wird die xdl einfach wieder eingeschaltet.
Im folgenden die kleine Routine, die das macht.
Man muss den Wert 1 (für einschalten) oder 0 (für ausschalten) in den Akku laden und dann jeweils dieselbe Routine starten!

Code: Alles auswählen

.proc xdlstartstop
			;lda #1 für start xdl
			;lda #0 für stop  xdl
			ldy VIDEO_CONTROL
			sta (baseaddr),y
			rts
			.endp

Und damit haben wir bereits Step 2 der Initialisierung des vbxe fertig!

In Step 3 werden wir nun den Speicherbereich für die vbxe initialisieren und festlegen...

[Dr. Irata]

... falls irgendetwas unklar ist, bitte einfach nachfragen!!

Wer hier nun glaubt, ich kenne mich schon auch mit der Programmierung der vbxe, der irrt!
Ich habe das original Handbuch von T.Piórek aus 2009 auf englisch - dieses Handbuch ist wirklich rudimentär!!
Dann habe ich wohl als wichtigste Quelle den schönen Forumsbeitrag auf AtariAge, wo es auch entsprechende Beispiele auf MADS gibt.
Beides zusammen hilft mir, die vbxe-Programmierung lagsam "pö à pö" zu durchdringen.
So arbeite ich gerade an diesem Thema.... vielleicht gibt es dann auch Dinge, die ich zunächst falsch verstehe. Kreative Mitarbeit wäre also sicherlich hilfreich

[Dr. Irata]

... heute habe ich fast eine Stunde umsonst hier einen langen Text über MEMAC A und MEMAC B eingestellt, um dann zu merken, daß meine AtariAge Vorlage und das original Tutorial sich deutlich unterscheiden. Leider habe ich es gelöscht.. dann kam mir in den Sinn, daß das alte Manual von 2009 vielleicht schon überholt ist - und ganz ganau so ist es auch. Der verworfene Text war also richtig... hier erstmal das neuere Manuel, den alten Link oben unbedingt verwerfen!!!

vbxe-neuer.pdf

(222.86 KiB) 61-mal heruntergeladen

Was wurde verändert?
Die Register wurden zum Teil verändert. Früher gab es 4 Register für feste Bereiche und Größen der einzublendenden Speicherbereiche bei $4000-$7fff bzw. bei $2000-$3fff
Jetzt kann man die Bereiche deutlich flexibler hinsichtlich Größe und Ort wählen... das erkläre ich im folgenden!
Ach eins noch: Leider ist die englische Übersetzung aus dem polnischen Original nicht ganz korrekt... ich hatte mich schon echt gewundert, was soll denn diese komische Adressenbeschreibung bei MEMAC B .... hier wird ja ein vordefinierter Bereich von 16 kB an Adresse 0X4000 eingeblendet. Das riecht doch nach unserer guten alten Bankswitching-Geschichte unseres 130 XE ... und ja, genauso ist es auch. Im polnischen Manuel steht da nämlich gar nicht 0X4000 sondern $4000 - das wurde schlicht falsch übersetzt. Vorsicht also!!!

[Dr. Irata]

Step 3:

Wir fangen mal mit MEMAC B an.
MEMAC bedeutet Memory Access. Ganz generell bietet VBXE 2 Möglichkeiten auf die 512 kB des Boards zuzugreifen.
Die einfache kennen wir schon. MEMAC B macht nichts anderes, als unser guter alter 130 XE.
Am Speicherort $4000 blenden wir 16kB große Speicherblöcke des VBXE in den Atarispeicher ein, wo wahlweise der Antic, die CPU oder beide zugreifen können.
Dafür gibt es drei Register:

Dx5D MEMAC_B_CONTROL
Dx5E MEMAC_CONTROL
Dx5F MEMAC_BANK_SEL

MEMAC_CONTROL - Register ist folgendermaßen aufgebaut:
b7 b6 b5 b4 b3 b2 b1 b0
Basisadresse (als Hi-Byte) MCE MAE window size


b1 b0 window size
0 0 4K
0 1 8K
1 0 16K
1 1 32K

In Bit 4-7 steht als Hi-Byte die Startadresse für den Speicher drin- also wo unser "Fenster" liegt im A8
In Bit 2 und 3 sagen wir dem Antic bzw der CPU ob sie auf den Speicher zugreifen können und
in Bit 0 und 1 legen wir anhand der Tabelle die Größe des Fensters (der Bank) fest.

MEMAC_BANK_SEL - Register:
Wenn hier Bit 7 gesetzt wird, dann ist MEMAC A aktiviert und die Steuerung läuft dann nur über dieses Register für die Banks und das MEMAC-Control-Register. Mit Bit 0-6 steuert man dann die entsprechenden Banks (je nach Größe des Fensters).

MEMAC_B_Control:
Falls man dann also in den MAMAC-B Modus gehen möchte (der ja deutlich flexibler ist), dann steuert man statt mit dem Control-Register hier die Banks (Bit 0-4) und mit Bit 6 und 7 den Zugriff der CPU / Antic auf den Speicher.
Die Startadresse und die Größe des Fensters wird weiterhin über das Control-Register gesteuert.

So viel zur Theorie. ......... (wer hat sich denn das bloß ausgedacht)
Anschließend bauen wir für alle möglichen Definitionen dann entsprechende Codes mit Erklärung ... ich denke mit den Codes wird es auch noch heller im Dunkel werden.
Am Ende wissen wir dann ganz genau, wie der Speicher vom vbxe funktioniert und wie man ihn adressiert und prima nutzt!!

[Dr. Irata]

... wo ich jetzt echt etwas hänge ist, wie ich in MADS die Banks für vbxe definiere....
Für den normalen 130 xe definiere ich es ja so:

; Speicher reservieren
PMB DTA "0123456789"

; Definitionen der Banken an PORTB
DTA B($Ff) ; Keine Bank
DTA B($C3) ; Bank 1
DTA B($C7) ; Bank 2
DTA B($cb) ; Bank 3
DTA B($Cf) ; Bank 4

TMB .by $ff,$c3,$c7,$cb,$c

und dann kann ich die Codes oder Daten in den Banks unter MADS folgendermaßen ablegen:

;------------------------- Bank 0 Player-Set 1 -------------
ORG PMB ; $ff
LDA TMB+0 ; Bank 0 auswählen
STA PORTB
RTS
INI PMB

org $4000


.proc test1
rts
.endp


ORG PMB ;------------------------- Bank 1 --------------
LDA TMB+1 ; Bank 1 auswählen $c3
STA PORTB
RTS
INI PMB

ORG $4000

.proc test2
rts
.endp



ORG PMB ;------------------------- Bank 2 --------------
LDA TMB+2 ; Bank 2 auswählen $c7
STA PORTB ; 2. Phase und Intro
RTS
INI PMB

ORG $4000




ORG PMB ;------------------------- Bank 3 --------------
LDA TMB+3 ; Bank 3 auswählen $cb
STA PORTB ; 3. Phase und Extro
RTS
INI PMB

ORG $4000
....


Und dann die einzelnen Banks "sichtbar" machen. Hier z.B. mit

lda $cb
sta portb

wie aber geht das mit den ganzen Banks im vbxe ????
Wie initialisiere ich die unter MADS??

[Dr. Irata]

... die letzten Tage hatte ich nur wenig Zeit, aber die Implementierung unter MADS was die Banks und den Speicher angeht, habe ich jetzt geschafft.
Es ist eigentlich echt einfach...

Wir beschäftigen uns zunächst wie gesagt mit der einfachen MEMAC B Implementierung. Die läuft analog zu unserer Bank / Port B Implementierung des 130 XE.
Wir brauchen auch nur ein einziges Register - das Register $5D .... also $D65D oder $D75D
Bit 7 ist für die CPU und Bit 6 für den Antic reserviert - also jeweils ein 1 setzen für die Zugriffsoption auf den vbxe-Speicher. Bit 5 bleibt frei und Bit 0-4 nutzt man dann für die Bankanwahl der vbxe. Das Fenster im MEMAC B Modus liegt immer definiert an der Atari-Speicherstelle $4000 und hat eine definierte Größe von 16 kB.

Für die Bankdefinition oben im MADS-Programm kommt zunächst im Hauptcode:

Code: Alles auswählen

		; Speicher reservieren
PMB		DTA 1,2,3,4	

nun die Subroutine für die initiale MEMAC B - Initialisierung:

Code: Alles auswählen

			.proc memacbini
			ldy #$d5		  ; Register für MEMAC B
			lda #%11000000   ; primär Bank 0
			sta (baseaddr),y
			
			rts
			.endp

weiter hinten dann die Banks initialisieren unter Mads:

Code: Alles auswählen

			
								;------------------------- Bank 0 Player-Set 1 -------------
			ORG PMB				
			lda #%11000000   ; CPU + Antic / Bank 0
			sta $d65d
			sta $d75d
			rts
			
			INI PMB
			
			org $4000
	
			.proc testbank0
			inc 710
			rts
			.endp
			
			
			
			ORG PMB				;------------------------- Bank 1  --------------
			lda #%11000001   ; CPU + Antic / Bank 1
			sta $d65d
			sta $d75d
			rts
			INI PMB
		
			ORG $4000 
			
			.proc testbank1
			inc 712
			rts
			.endp
			

sta $d65d und sta $d75d muss hier sein, da mit sta (baseaddr),y an dieser Stelle ein Absturz kommt - das geht vielleicht noch anders.

Im Hauptcode kann man dann mit

Code: Alles auswählen

			ldy #$5d
			lda #%11000001    ; Bank 1 oder z.B. lda #%11000011 Bank 3
			
			sta (baseaddr),y
			
			
start		
			
			jsr testbank1
			
			
			jmp start

umschalten und die Codes anwählen...

Im folgenden kümmern wir uns dann um die MEMAC A Implementierung, die flexibler ist...

[Dr. Irata]

... inspiriert von Janko würde ich am Ende dann ein echtes umfangreiches Tutorial / Handbuch verfassen mit Codebeispielen wie man vbxe nutzen kann...

[pps]

Obwohl mich das sehr interessiert, bin ich momentan nur lesend hier unterwegs. Habe gerade zu viel um die Ohren, um selbst aktiv zu unterstützen.

Ich hoffe, dass es bald besser wird und ich wieder mehr machen kann.

[Dr. Irata]

schade, du hattest ja dieses Thema hier extra eröffnet... egal, ich mache hier mal weiter und jeder kann ja jederzeit mitmachen...

[JoSch]

... inspiriert von Janko würde ich am Ende dann ein echtes umfangreiches Tutorial / Handbuch verfassen mit Codebeispielen wie man vbxe nutzen kann...

Wenn ich eine Bitte hätte, wäre es nicht nur mit Assemblercode zu erklären, sondern die Operationen auch textuell oder per Pseudocode zu erklären. Nicht jeder kann flüssig Assembler lesen und möchte vielleicht auch in einer anderen Sprache programmieren.

[Dr. Irata]

MEMAC A:

Das ist deutlich schwieriger umzusetzen. In der Theorie relativ klar und einfach ging es jetzt darum, einen brauchbaren Code umzusetzen.
Da habe ich jetzt einige Tage dran getüftelt!

Zunächst zur Theorie:
Wie oben schon erklärt, ist man mit MEMAC A deutlich flexibler, da man die Bankgröße und die Banklage variabel gestalten kann.
Für MEMAC A brauchen wir 2 Register: $5E und $5F - wobei es ja eigentlich $D65E oder $D75E und $D65F oder $D75F ist. Dies wurde oben ja schon erklärt und im folgenden schreibe ich hier für die Register nur noch z.B. $5E oder analog $Dx5E wobei für x dann enteder 6 oder 7 steht - je nach Lage der Register des VBXE. Das hat auch im Programm Bedeutung!!

Mit dem Register $5E steuern wir die Lage der Banks im Atarispeicher, ob CPU und oder Antic zugreifen können und wie groß die Bank ist (4kB, 8kB, 16 kB oder 32kB):
Bit 0 und 1 legen die Größe der Banks fest, Bit 2 enabled den Antic, Bit 3 die CPU, Bit 4-7 die Lage im Speicher. Hier steht der Hi-Byte-Wert der Lage!
Beispiel:
Ich möchte eine 8kB große Bank für die CPU an Stelle $9000 initialisieren. Der Befehl wäre dann:

ldy #$5e
lda #%10011001
sta (baseaddr),y

oder

lda #%10011001
sta $Dx5e

mit lda #%10011001 setzte ich Bit 7 und Bit 4 (=9 für $9000), Bit 3 für CPU enable und Bit 0 für 8 kB.

Jetzt noch die entsprechende Bank anwählen - und das geht mit dem Register $5F bzw. $Dx5F
Das ist dann relativ einfach:
Bit 0-6 bei 4kB Banks
Bit 1-6 bei 8kB Banks
Bit 2-6 bei 16kB Banks und
Bit 3-6 bei 32kb Banks
Bit 7 sollte dabei auf 1 gesetzt werden, damit wird MEMAC A global fixiert.

Und nun zum Code:

Zunächst habe ich im Hauptcode 2 neue Subroutinen:

Code: Alles auswählen

			.proc memacaini
			
			lda #%10011000
			sta $d65e
			sta $d75e
			rts
			.endp
			
			.proc bankx
			jsr memacaini
			txa
			adc #128
			sta $d65f
			sta $d75f
			rts 
			.endp

memacaini initiaslisiert Register $5E - in diesem Fall bei $9000 ein 4kB Fenster
bankx initialisiert dann jeweils die Banks - und immer jeweils für $D6.. und $D7.. weil hier die Option sta (baseadrr),y nicht funktioniert und zum Absturz führt.

Die einzelnen Banks sehen dann so aus:

Code: Alles auswählen

					;------------------------- Bank 0 Player-Set 1 -------------
			ORG PMB	
			clc
			ldx #0			
			jmp bankx
			
			
			INI PMB
			
			org $9000
	
			.proc testbank0
			inc 710
			rts
			.endp
			
			
			
			ORG PMB				;------------------------- Bank 1  --------------
			clc
			ldx #1
			jmp bankx
			
		
			INI PMB
		
			ORG $9000 
			
			.proc testbank1
			inc 712
			rts
			.endp

und der Aufruf im Hauptprogramm:

Code: Alles auswählen

			ldy #$5f
			lda #%10000000			; oder einfach:	lda #128
			sta (baseaddr),y		;     		sta $d65f
			
start		
			
			jsr testbank0
			
			
			jmp start

Keine Sorge, am Ende packe ich alles in einen zusammenhängenden Code mit Remarks....

[Dr. Irata]

Und als nächsten Step 4 beschäftigen wir uns mit der xdl - also der Displaylist vom VBXE-Board!
Bin selber schon gespannt!!!

[Dr. Irata]

Step 4:

Die XDL zu verstehen ist gar nicht so schwer, da sie ganz ähnlich aufgebaut ist, wie die normale Displaylist.
Aber zunächst machen wir uns mal ein paar Gedanken zum Bildschirmspeicher im VBXE.
Wenn man von einer Auflösung von 320x192 mit 1 Byte pro Pixel für eine hübsche Auflösung ausgeht, dann macht das mal eben 60bK Speicherbedarf für diesen hochauflösenden Bildschirm. In dem Beispiel aus dem AA-Forum wählt der Autor ein Fenster im Atari (um auf den Speicher des vbxe zuzugreifen von 4kB. Ob das geschickt ist?? Da bräuchte ich ja 15 Banks... also mein erstes Beispiel mit der XDL werde ich also etwas anders gestalten. Ich nehme den vordefinierten MEMAC B mit 16kB am Ort $4000. Damit kann man schön arbeiten und es ähnelt der Bank-Architektur vom 130XE. Es reichen dann also 4 Banks aus, um den XE-Bildschirmspeicher vollständig zu "erfassen". Ob das geschickter ist werden wir am Ende sehen.

Den Bildschirmspeicher positionieren wir an den Anfang vom vbxe Speicher - also bei $000000-$00efff
Damit ist auch schon klar, wo die XDL anfangen kann - direkt dahinter, also bei $00f000
Die XDL ist vertikal aufgebaut und könnte auch woanders im Speicher starten und kann praktisch beliebig lang sein. In der XDL selber steht dann natürlich auch, wo der Bildschirm starten soll - hier in unserem Beispiel praktischerweise bei $000000
Es gibt jetzt 4 Register, die wir für die XDL benötigen:
Dx40, Dx41, Dx42 und Dx43
Dx40 ist das Video_Control Register. Bit 0 ist dabei zuständig für das Ein- und Ausschalten der XDL - das hatten wir ja schon oben.
Wert 1 in Bit 0 schaltet XDL ein und Wert 0 in Bit 0 schaltet die XDL aus.
Dx41 - Dx43 sind die Adressen für den XDL Start bzw. wo sie beginnt im VBXE-Speicher.
In unserem Fall soll ja die XDL direkt hinter dem Bildschirmspeicher starten, daher müssen die Register $Dx41 und $Dx43 den Wert $00 bekommen und das Register $Dx42 den Wert $f0
Damit haben wir nun auch schon die XDL positioniert und im besten Fall angeschaltet.
Bevor sie angeschaltet wird, muss natürlich auch was drinstehen... und damit kommen wir zum eigentlichen Aufbau der XDL.

Die XDL ist gleichförmig aufgebaut:
Immer startet sie mit einem XDLC (C bedeutet hier control word - also ein Befehl) mit Gesamtlänge von 2 Bytes.
Nach dem XDLC kommen dann Daten von 0-20 Bytes
Das XDLC ist also ein Befehl für jede Bildschirmzeile mit 16 Bit Länge, jedes Bit hat dabei eine spezielle Befehlsfunktion.
Diese 16 Bit´s arbeiten wir im nächsten Beitrag durch und im Anschluß bauen wir ein konkretes Beispiel...

[Dr. Irata]

Wie nun gestaltet sich der Aufbau der XDL?
Jede Zeile kann theoretisch frei gestaltet werden und ist somit ähnlich flexibel, wie die DL vom Atari.
Die XDL fängt für jede Zeile mit einem 16 Bit Steuerbefehl an (also Byte 1 und Byte 2) und nachfolgend kommen dann weitere zusätzliche Bytes, wo Informationen drin stehen.
Die einzelnen 16 Bits werden nacheinander in Reihenfolge abgearbeitet und je nach Bit - also ob es gesetzt wird oder nicht - stehen dann die nachfolgenden Bytes für weitere Informationen zur Verfügung. Diese weiteren Bytes kommen dann nach dem XDLC und in klarer Reihenfolge der zuvor im DLC gesetzten Bits. Jedes gesetztes Bit erwartet also 0-5 Bytes. Dies werde ich jetzt für alle 16 Bits des XDLC erklären:

Es startet also mit
Byte 1 vom XDLC
Bit 0 (XDLC_TMON ) - aktiviert den Overlay Textmodus - zusätzliche Bytes: 0
Bit 1 (XDLC_GMON ) - aktiviert den Overlay Grafikmodus - zusätzliche Bytes: 0
Bit 2 (XDLC_OVOFF ) - deaktiviert den Overlay Modus - zusätzliche Bytes: 0
Bit 3 (XDLC_MAPON ) - aktiviert Farbattribute - zusätzliche Bytes: 0 - komplexe Möglichkeiten, wird eigens erklärt
Bit 4 (XDLC_MAPOFF) - deaktiviert Farbattribute - zusätzliche Bytes: 0
Bit 5 (XDLC_RPTL) - wenn aktiviert, dann wird die definierte Zeile um x Zeilen gleichermaßen wiederholt - zusätzliche Bytes: 1 (Anzahl der zu wiederholenden gleiche Zeilen)
Bit 6 (XDLC_OVADR ) - hier steht die Displayadresse des VBXE und die Pixelanzahl pro Zeile - zusätzliche Bytes: 5 (3 Bytes für die Adresse und 2 Bytes für die Pixelanzahl)
-> in unserem Beispiel startet der Bildschirm bei $00 also jeweils $00 für die ersten 3 Bytes, Zeile mit $140 (320) Pixel also $40 Byte 4 und $01 Byte 5
Bit 7 (XDLC_OVSCRL) - aktiviert Scroll-Modus - zusätzliche Bytes: 2 - Byte 1 (0-7) für hscroll und Byte 2 (0-7) für vscroll - bei Wert=0 jeweils kein scroll

Byte 2 vom XDLC
Bit 0 (XDLC_CHBASE ) - ein eigener Font wird aktiviert - zusätzliche Bytes: 1 - ein Byte für die Fontadresse, zu beachten ist eine 2kB Grenze für den Start, 256 Character sind möglich
Bit 1 (XDLC_MAPADR) - hier wird eine Colormap gesetzt - zusätzliche Bytes: 5 (3 Bytes für die Adresse und 2 Bytes für die Steps - wird später erklärt
Bit 2 (XDLC_MAPPAR ) - setzt Scroll-Attribute - zusätzliche Bytes: 4 - jeweils 1 Byte für hscroll, vscroll, Höhe und Breite - wird später genauer erklärt
Bit 3 (XDLC_ATT ) - hier kann man weitere Attribute hinsichtlich BS-Breite und Overlays mit PMG (Player/Missile) festlegen - zusätzliche Bytes: 2 - wird später erklärt
Bit 4 (XDLC_HR ) - aktiviert hochauflösenden Modus auf 640 Pixel - zusätzliche Bytes: 0
Bit 5 (XDLC_LR) - aktiviert niedrigauflösenden Modus auf 160 Pixel - zusätzliche Bytes: 0
Bit 6 (-) - reserviert
Bit 7 (XDLC_END) - wenn aktiviert - kennzeichnet das Ende des XDL, springt dann wieder zum Anfang der XDL

Die Möglichkeiten sind wie man sieht sehr vielfältig, etliche Möglichkeiten werde ich später noch genauer behandeln, zunächst konstruieren wir aber mal eine relativ einfache XDL!