Hilfe! Kompatibilitätsproblem? Unterschiede zw. 1200XL vs 600XL?

[Kveldulfur]

Hallo Leute!

Ich programmiere z.Zt. Schränker 4 und es läuft echt gut.
Auf dem Altirra funktioniert alles perfekt... auf dem 600XL+ läuft das Spiel ebenfalls ohne Probleme.
Das Spiel nutzt 64kB, also auch den RAM unterm ROM, ansonsten hat es keine Besonderheiten.

Nun hat Peter das Spiel auf dem MacEmulator testen wollen und alles funktioniert, nur meine Spielfigur kann nicht fallen?
Springt man hoch, bleibt sie in der Luft stehen... schon echt irrer Fehler. Aber auf org. Hardware geht es, also keine Aufregung, liegt am Emulator.

Nun ließ mir das keine Ruhe, also habe ich mein Spiel auf meinem 1200XL getestet... und was soll ich sagen. Funktioniert alles perfekt, bis auf das meine Spielfigur in der Luft stehen bleibt, wie beim MacEmulator.
Das ist schon etwas seltsam... zumal alles andere funktioniert. Wenn ich "in der Luft" zu einer Platform gehe, die sich vertikal bewegt, wird meine Spielfigur mitgenommen. In beide Richtungen. Gehe ich von der Plattform, flieg ich wieder.

Irgendeine Idee?

Da ich aktuell nur den 600XL+ und den 1200XL nutzen kann, weiß ich nicht, wie andere ATARIs reagieren.
Altirra ist es übrigens egal, ob NTSC, PAL, 50Hz oder 60Hz... da funktioniert das Spiel immer.

Bitte um Hilfe...
Janko

[Kveldulfur]

Hallo!

Bin natürlich kräftig am Suchen und habe nun herausgefunden, dass es am Betriebssystem liegt.
Wenn ich beim Altirra das AltirraOS nutze, funktioniert das Spiel nicht.
Alle anderen Betriebssysteme (ausser Ultimon XE) laufen. Das 1200XL-OS geht immer in den Selftest... daher kann ich es nicht prüfen.
Ob es daran liegt? Aber wieso, das OS schalte ich eigentlich ab, wenn man ein Level spielt.

Grüße
Janko

[Irgendwer]

Wenn Du das OS abschaltest bzw. Speicher unter dem OS nutzt, wirst Du sicherlich ein paar Vektoren verbogen haben/müssen.
Zeigen die vielleicht auf OS-Routinen und nutzen sie dann wirklich die "offiziellen Einsprungsadressen"?
(...nur mal so als Vermutung...)

[Kveldulfur]

Moin!

Sobald ich dann das Spiel mit START beginne, wird das Level geladen und angezeigt. In dem Moment, in dem man aktiv spielt, ist das ROM komplett abgeschaltet. Sämtliche VBI/DLI laufen direkt in meine eigenen Routinen.

Ab diesem Zeitpunkt hat das OS also keinen Einfluss mehr auf das Spiel. Alles ist extrem zeitkritisch, aber es läuft perfekt: Farben, Musik, Gegner – alles stimmt.

Ich berechne die Position der Spielfigur und den entsprechenden Bildschirmspeicher. Befindet sich dort eine „0“, also Luft, fällt die Figur. Es wird auch „nichts“ angezeigt auf dem Bildschirm unter der Figur – es muss also eine „0“ sein.
Wenn ich sterbe und das Spiel beendet wird, gelange ich ganz normal ins Menü zurück, kann neu starten usw.

Wieder so ein Rätsel, um das ich nicht gebeten habe.

Selbst wenn das OS beim Laden etwas in der Zero Page verändert, wird beim Spielstart alles neu initialisiert.
Vektoren verbiege ich keine – denn wenn das ROM deaktiviert ist, liegen im Bereich $FFFA bis $FFFF meine eigenen Routinen. Ist das ROM aktiv, stehen dort natürlich die Einsprungadressen des OS.
Aber das ROM ist wirklich nur während der Ladevorgänge aktiv – also meistens deaktiviert.

Grüße
Janko

[Dr. Irata]

erstaunlich, daß der Player echt in der Luft hängt und dort bleibt... also nicht runterfällt...

[Irgendwer]

Alles ist extrem zeitkritisch, aber es läuft perfekt: Farben, Musik, Gegner – alles stimmt.

Wieder nur ein Verdacht, aber AFAIK ist der 1200XL original eine NTSC maschine.
Kann es sein, dass einfach für 60 Updates pro Sekunde im VBI die Zeit fehlt und der VBI (wie meistens) nicht re-entrant ist?

[Kveldulfur]

Hallo Leute!

Erst einmal danke für die Hilfe! Ich habe den Fehler gefunden... hat ja nur ein paar Stunden gedauert
Also, der Fehler ist ein Flüchtigkeitsfehler, der sich perfekt getarnt hat und nur durch die OS-Wahl aufgedeckt wurde.

Code: Alles auswählen

		
		; Nach Feuer suchen als Untergrund
?SearchFeuer	LDA (TEMP01),Y
		AND #%01111111		 
		CMP "!"			; # Unsichtbar			
		BEQ ?FoundGround
		CMP #$39		; # "Y" Feuer
		BCC ?SearchNext
		CMP #$3d		; # $3d = "\" Feuer
		BCC ?FoundGround

Diese Routine, die eigentlich Feuer suchen soll, wurde von mir ergänzt, weil es gut passte, um das Ausrufezeichen.
Das ist ein unsichtbares Zeichen im Spiel, womit ich Objekte, die selbst nicht als Boden definiert sind, zu einem Boden machen kann.
CMP "!" ist also gleichbedeutend mit CMP $01
Jetzt erkennt man schon direkt, dass dort das Hashtag fehlt... also CMP #$01 müsste es heissen.
Nun der Fan-Fact: Im XL/XE-OS steht an der Speicherstelle $01 (NGFLAG) eine 1 (RAM/ROM-Test ohne Fehler) und somit funktionierte alles.
Im AltirraOS (und vermutlich 1200XL-OS) steht an der Speicherstelle $01 eine 0, womit plötzlich die gesamte Luft zum Boden wird.

Kleiner Fehler... große Wirkung

Man, habe ich jetzt Kopfschmerzen...

Grüße
Janko

EDIT: Eben auf dem org. 1200XL gespielt... keine Probleme mehr

[Mathy]

.
Hallo Janko

Man, habe ich jetzt Kopfschmerzen...

Das sind die neuen Synapsen die sich jetzt bilden...

Tschüß

Mathy

[slx]

Mein Beileid! So einem vergessenen Hashtag verdankte ich als Teenager meine erste durchwachte Assemblerprogrammiernacht. Wenn man nach Dutzenden Versuchen draufgekommen ist, dann ärgert man sich über die sinnlos verbrauchte Zeit…

[Dr. Irata]

... Klassiker ...

[mega-hz]

wie wäre es wenn man definitionen anlegt?

BODEN .byte 01

CMP BODEN

usw.

Sowas hab ich mir seit der Arduino C-Programmierung angewöhnt, da auch ich früher nächtelang um den eigentlichen Fehler herumprogrammiert habe.
Nächsten morgen dann nach nem frrischen Kaffee hats dann "klick" gemacht und ich hab mich über die verschenkte Zeit geärgert...

[DjayBee]

Gelöscht weil Käse.

[Kveldulfur]

wie wäre es wenn man definitionen anlegt?
BODEN .byte 01
CMP BODEN

Hallo!

Das wäre eine eher schlechte Idee. Konstanten definiert man mit EQU

Code: Alles auswählen

BODEN          	EQU $01

Allerdings benötigt man dann weiterhin ein Hashtag, wenn man den Wert selbst nutzen möchte und nicht die Adresse.
Ausserdem erkenne ich durch #"!" sofort, dass es in dem Fall um das Ausrufezeichen geht, weshalb ich diese Nutzung sinnvoller finde.

Aber nun zu Deinem Beispiel:

Code: Alles auswählen

BODEN          	.byte $01
...
		CMP BODEN

Generell hast Du Recht, dass man hier kein Hashtag mehr benötigt. Man erkauft sich das aber durch folgende Nachteile:

• Wenn "BODEN" in der Zeropage definiert ist, benötigt dieser Befehl 2 Bytes und 3 Rechenzyklen

• Wenn "BODEN" ausserhalb der Zeropage definiert ist, benötigt dieser Befehl 3 Bytes und 4 Rechenzyklen

Normal benötigt dieser Befehl mit der Nutzung einer Konstanten (Immediate) 2 Bytes und 2 Rechenzyklen.
Da die Zeropage nicht soviel Platz bietet, würde man also statt 2 Rechenzyklen, die doppelte Anzahl benötigen. Was wiederum bedeutet, dass man in der selben Zeit nur 50% der Abfragen machen könnte!
Wenn das dann konsequent so gemacht wird, verschwendet man eine Menge Rechenzeit und die ist echt kostbar.

Grüße
Janko

[Dr. Irata]

Mann muss ja auch das Rad nicht schlechter und neu erfinden, weil man so vielleicht einen möglichen Bug weniger hätte... einfach den # verwenden und schon gehts ja wie gewünscht

[Dr. Irata]

Hey Janko,
vielleicht magst du ja mal einen eigenen Artikel / Post übers RAM unter ROM mit Abschalten des OS und eigenen Routinen hier gut erklärt mit entsprechenden Routinen präsentieren... damit jeder es nutzen kann und weiß wie es funktioniert und worauf man da achten muss...
LG Peter

[mega-hz]

Das geht doch recht einfach...
Vorraussetzung ist, daß Dein Programm rein garnix vom OS benutzt.
Also auch VBI,DLIs usw. nicht.
Dann einfach mit $FE in $D301 das OS abschalten und schon ist von $C000-$FFFF Ram.
Vorher noch die IRQs die auf das OS evt. zeigen, deaktivieren...
(Natürlich nicht bei den Hardwareregistern $D000-$D7FF)

[mega-hz]

wie wäre es wenn man definitionen anlegt?
BODEN .byte 01
CMP BODEN

Hallo!

Das wäre eine eher schlechte Idee. Konstanten definiert man mit EQU

Code: Alles auswählen

BODEN          	EQU $01

Allerdings benötigt man dann weiterhin ein Hashtag, wenn man den Wert selbst nutzen möchte und nicht die Adresse.
Ausserdem erkenne ich durch #"!" sofort, dass es in dem Fall um das Ausrufezeichen geht, weshalb ich diese Nutzung sinnvoller finde.

Aber nun zu Deinem Beispiel:

Code: Alles auswählen

BODEN          	.byte $01
...
		CMP BODEN

Generell hast Du Recht, dass man hier kein Hashtag mehr benötigt. Man erkauft sich das aber durch folgende Nachteile:

• Wenn "BODEN" in der Zeropage definiert ist, benötigt dieser Befehl 2 Bytes und 3 Rechenzyklen

• Wenn "BODEN" ausserhalb der Zeropage definiert ist, benötigt dieser Befehl 3 Bytes und 4 Rechenzyklen

Normal benötigt dieser Befehl mit der Nutzung einer Konstanten (Immediate) 2 Bytes und 2 Rechenzyklen.
Da die Zeropage nicht soviel Platz bietet, würde man also statt 2 Rechenzyklen, die doppelte Anzahl benötigen. Was wiederum bedeutet, dass man in der selben Zeit nur 50% der Abfragen machen könnte!
Wenn das dann konsequent so gemacht wird, verschwendet man eine Menge Rechenzeit und die ist echt kostbar.

Grüße
Janko

Hmm, Zeropage?
Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen.
Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

[Dr. Irata]

Das geht doch recht einfach...
Vorraussetzung ist, daß Dein Programm rein garnix vom OS benutzt.
Also auch VBI,DLIs usw. nicht.
Dann einfach mit $FE in $D301 das OS abschalten und schon ist von $C000-$FFFF Ram.
Vorher noch die IRQs die auf das OS evt. zeigen, deaktivieren...
(Natürlich nicht bei den Hardwareregistern $D000-$D7FF)

... wenn du das so machst, klingt es natürlich zunächst recht einfach, dann ist der Rechner quasi aber fast tot!
Bringt also eigentlich nichts... wir wollen ja aber das ROM bzw. das OS abschalten, um den RAM unter ROM nutzen zu können, bestimmte Dinge brauchen wir aber dann dennoch. VBI, DLI, Joystickabfragen, bestimmte Routinen bzw. Register werden gesetzt werden müssen, Player/Missile, Tastatur... also da ist schon einges, was man beachten und definieren muss. Dafür wirft man aber den ganzen Ballast ab, den man vielleicht gar nicht ständig braucht ...

[Kveldulfur]

Hmm, Zeropage?
Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen.
Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

Hallo!

Das was Du meinst ist keine Variable sondern eine Konstante und die wird per EQU zugeweisen.
Eine Variable ist während der Ausführung änderbar und belegt somit eine Speicherstelle, dass geht z.B. mit ".byte".

Code: Alles auswählen

	ORG $0600
ConstA	EQU $05
VarA	.byte $01

In dem Beispiel wird die Speicherstelle $0600 mit dem Wert 1 belegt. Du kannst über den Bezeichner "VarA" statt $0600 nutzen.
Ein "cmp VarA" ist also ein "cmp $0600" und greift auf den Inhalt der Speicherzelle $0600 für den Vergleich zu.

ConstA belegt keinen Speicher, sondern wird sich nur während des Compiliervorgsang gemerkt und eingesetzt.
"cmp #ConstA" bedeutet "cmp #$05: Vergleiche mit der Zahl 5.
"cmp ConstA" bedeutet "cmp $05": Vergleiche mit dem Inhalt der Speicherstelle $05.

Eine Definition, dass "Boden = #$01" sein soll, gibt es meines wissens nicht und würde auch das Lesen des Quellcodes erschweren.

Grüße
Janko

[Dr. Irata]

ja... theoretisch könnte man folgendes coden:

BODEN .byte 01

....
cmp BODEN


In diesem Fall steht an der Speicherstelle BODEN der Wert 01 und mit cmp BODEN wird dann vom Akkumulator der Wert in Boden (also 1) abgezogen. Darauf folgt dann z.B. der branch
Das geht schon, erscheint allerdings umständlich. Lieber gleich an die richtige Syntax mit dem #1 denken!!

[Kveldulfur]

Hey Janko,
vielleicht magst du ja mal einen eigenen Artikel / Post übers RAM unter ROM mit Abschalten des OS und eigenen Routinen hier gut erklärt mit entsprechenden Routinen präsentieren... damit jeder es nutzen kann und weiß wie es funktioniert und worauf man da achten muss...
LG Peter

Hi!

Im Prinzip ist es, wie Wolfram es schreibt.

Mit folgendem Code:

Code: Alles auswählen

		SEI		; IRQ sperren
		LDA #$00	; VBI + DLI unterdrücken
		STA NMIEN

		LDA #$FE	; OS und Basic abschalten
		STA $D301	; PORTB

schaltet man NMI und IRQ aus – und kann anschließend das ROM deaktivieren.

Fertig

Man kann den ATARI auch komplett ohne Interrupts betreiben. Man muss dann allerdings das Timing selbst exakt steuern…
Deshalb ist es dann doch evtl. einfacher zumindest den NMI zu nutzen, weil der ANTIC einem dann ein wenig das Timing abnimmt.

Wenn das ROM abgeschaltet ist und man weiterhin Interrupts nutzen möchte, muss man sicherstellen, dass gültige Vektoren für den NMI und IRQ im RAM untergebracht sind:

- $FFFA/$FFFB – Vektor für die NMI-Routine (für VBI/DLI)
- $FFFE/$FFFF – Vektor für die IRQ-Routine (z. B. Tastatur, POKEY)

Im Spiel nutze ich in der Regel nur den NMI.
Den IRQ-Vektor setze ich einfach auf einen RTI, und durch SEI stelle ich sicher, dass kein IRQ während meines "zeitkritischen Codes" dazwischen funkt.

Die NMI-Routine muss zuerst prüfen, ob es sich um einen DLI oder VBI handelt.
Hier bietet sich der gleiche Mechanismus an, den auch das OS nutzt:

Code: Alles auswählen

		BIT NMIST
		BPL ?VBI
		JMP (VDSLST)

Mit BIT NMIST wird Bit 7 ausgewertet. Bei einem VBI (Bit 7 = 0) wird nach ?VBI verzweigt, ansonsten folgt ein Sprung zum DLI-Vektor in VDSLST.

Was in ?VBI passiert, hängt ganz vom Anwendungsfall ab – im einfachsten Fall reicht hier sogar schon ein RTI, wenn man DLI exklusiv nutzt.
Wichtig: VDSLST muss natürlich gesetzt sein, bevor man den DLI aktiviert.
Viel mehr ist es nicht.

Vorteile dieser Methode:

- Der RAM unter dem ROM kann genutzt werden
- Die VBI-Routine ist entweder deutlich schlanker – oder wird ganz entfernt, was Rechenzeit spart
- Die ZeroPage und der Bereich der Schattenregister ist theoretisch für eigene Zwecke frei verwendbar

Beim letzten Punkt muss man aber vorsichtig sein, möchte man nämlich zwischendurch doch das OS nutzen, sollte man diese lieber unangetastet lassen. Man beachte auch, dass ein RESET das OS wieder einschaltet, weil $D301 zurück gesetzt wird.

Grüße
Janko

[Irgendwer]

Nur der Vollständigkeit halber:
Es geht natürlich auch das RAM unter dem OS zu verwenden UND dem OS die Interrupts & Co zu überlassen.
In einer Routine im "normalen" RAM liegt dann ein Mini-IRQ-Handler der
* das OS einblendet
* die OS-Vektoren anspringt
* das OS wieder ausblendet
und somit dem Hauptprogramm den Zugriff auf das RAM unter dem OS ermöglicht.

Um Überraschungen zu vermeiden: Der Zeichensatz ist auch Teil des OS'. Sollen Buchstaben weiter sichtbar sein, muss ein eigener bzw. eine Kopie vom Zeichensatz im Speicher bereitgestellt werden der gerade verfügbar/eingeblendet ist...

Einige Threads bei AA beschäftigen sich auch mit dem Thema - wo es auch Beispielcode gibt:

https://forums.atariage.com/topic/13667 ... er-os-rom/
https://forums.atariage.com/topic/234080-under-the-os/
https://forums.atariage.com/topic/28097 ... ing-stuff/

Edit: ...und im Atari-Wiki gibt's auch Code für ACTION!:
https://atariwiki.org/wiki/Wiki.jsp?pag ... 0Computers

[mega-hz]

Hmm, Zeropage?
Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen.
Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

Hallo!

Das was Du meinst ist keine Variable sondern eine Konstante und die wird per EQU zugeweisen.
Eine Variable ist während der Ausführung änderbar und belegt somit eine Speicherstelle, dass geht z.B. mit ".byte".

Code: Alles auswählen

	ORG $0600
ConstA	EQU $05
VarA	.byte $01

In dem Beispiel wird die Speicherstelle $0600 mit dem Wert 1 belegt. Du kannst über den Bezeichner "VarA" statt $0600 nutzen.
Ein "cmp VarA" ist also ein "cmp $0600" und greift auf den Inhalt der Speicherzelle $0600 für den Vergleich zu.

ConstA belegt keinen Speicher, sondern wird sich nur während des Compiliervorgsang gemerkt und eingesetzt.
"cmp #ConstA" bedeutet "cmp #$05: Vergleiche mit der Zahl 5.
"cmp ConstA" bedeutet "cmp $05": Vergleiche mit dem Inhalt der Speicherstelle $05.

Eine Definition, dass "Boden = #$01" sein soll, gibt es meines wissens nicht und würde auch das Lesen des Quellcodes erschweren.

Grüße
Janko

Ja wie Keveldur schon sagte, VBI,DLI usw. muss man dann selber machen!

[mega-hz]

Hmm, Zeropage?
Ich meinte eigentlich nur im WUDSN Assembler Variablen einen Wert zuweisen die rein "nur" für den Menschen als Ersatz für Werte stehen.
Der Assembler müsste dann doch aus CMP BODEN ein CMP #$01 machen...

Hallo!

Das was Du meinst ist keine Variable sondern eine Konstante und die wird per EQU zugeweisen.
Eine Variable ist während der Ausführung änderbar und belegt somit eine Speicherstelle, dass geht z.B. mit ".byte".

Code: Alles auswählen

	ORG $0600
ConstA	EQU $05
VarA	.byte $01

In dem Beispiel wird die Speicherstelle $0600 mit dem Wert 1 belegt. Du kannst über den Bezeichner "VarA" statt $0600 nutzen.
Ein "cmp VarA" ist also ein "cmp $0600" und greift auf den Inhalt der Speicherzelle $0600 für den Vergleich zu.

ConstA belegt keinen Speicher, sondern wird sich nur während des Compiliervorgsang gemerkt und eingesetzt.
"cmp #ConstA" bedeutet "cmp #$05: Vergleiche mit der Zahl 5.
"cmp ConstA" bedeutet "cmp $05": Vergleiche mit dem Inhalt der Speicherstelle $05.

Eine Definition, dass "Boden = #$01" sein soll, gibt es meines wissens nicht und würde auch das Lesen des Quellcodes erschweren.

Grüße
Janko

Ja genau so meinte ich es.

[Dr. Irata]

... wie gesagt, wir diskutieren hier über ein Bug im Code. Also ein vergessenes # was dazu führt, daß das Programm an dieser Stelle nicht mit dem Wert vergleicht, sondern mit der Speicheradresse. Wenn ich also aktuellen Akku-Inhalt mit cmp #1 vergleichen möchte und das # vergesse, dann bewirkt cmp 1 einen Vergleich mit Speicherstelle 1. Wenn da nun zufällig der Wert 1 drin steht, dann läuft alles wie gewünscht und man merkt den Fehler gar nicht. Ist mir auch schon passiert. Wenn da jetzt ein anderer Wert drin steht, dann gibt es entsprechende Programmfehler. Ganz blöd wird es, wenn unterschiedliche Werte dort reinkommen, dann kann es zu Fehlern führen, die man nur sporadisch bemerkt und die schwer zu finden sind. Man muss dann detektivisch die entsprechende Routine finden, die dafür verantwortlich ist. So haben wir es ja auch in diesem speziellen Fall gemacht und Janko hat dann schnell den fehlenden # gefunden.

Im Vorfeld alternative langsamere Definitionen zu finden, um diesen Bug zu umgehen machen m.E. keinen Sinn. Dann kommen andere Bugs...