atari-home.de - Foren
Software => Coding => Thema gestartet von: mcknopf am Mi 22.12.2021, 21:35:48
-
Hallo,
ich habe mir mal (endlich) Omikron Basic 3.6 zugelegt, dabei ist auch der Compiler. Nachdem es mir gelungen ist ein älteres Programm Falcon lauffähig zu machen, habe ich es kompiliert. In dem Programm frage ich ab ob ein Blitter vorhanden ist und falls ja, scrollt das Programm weich, da der bitblt Befehl von Omikron Basic enorm schnell ist. Nach dem kompilieren jedoch ist das Scrolling extrem langsam, es scheint, dass der bitblt Befehl nicht vom Blitter Verwendung macht. Kann man das hin bekommen, dass der bitblt Befehl auch im kompilierten Programm Den bitblt Befehl durch den Blitter ausführt, falls vorhanden?
-
ich habe mir mal (endlich) Omikron Basic 3.6 zugelegt, dabei ist auch der Compiler. Nachdem es mir gelungen ist ein älteres Programm Falcon lauffähig zu machen, habe ich es kompiliert. In dem Programm frage ich ab ob ein Blitter vorhanden ist und falls ja, scrollt das Programm weich, da der bitblt Befehl von Omikron Basic enorm schnell ist. Nach dem kompilieren jedoch ist das Scrolling extrem langsam, es scheint, dass der bitblt Befehl nicht vom Blitter Verwendung macht. Kann man das hin bekommen, dass der bitblt Befehl auch im kompilierten Programm Den bitblt Befehl durch den Blitter ausführt, falls vorhanden?
Ich habe keine Ahnung von Omikron Basic. Aber wenn du einfach mal die Abfrage nach dem Blitter wegläßt und drauflos blittest, geht es dann?
-
Hast du NVDI installiert? Ich kann mir kaum vorstellen, daß Omikron eigene Routinen für bitblt verwendet, es wird vermutlich die Line-A Funktionen vom System benutzen.
-
Ich habe früher viel in Omikron Basic gemacht, aber für den Compiler hat es nie gereicht.
Hast Du ein Minimalbeispiel (als .BAS und .PRG), das den Effekt demonstriert? Mithilfe der Tracingfunktionen von Hatari ließe sich sicher schnell feststellen, was der Unterschied im Ablauf ist.
-
Nachtrag: Ich habe es mir im Interpreter angeschaut. Dort führt der BITBLT-Befehl zu einem Aufruf der VDI-Funktion vro_cpyfm, die den Blitter nutzt, aber nur(!), wenn er systemweit aktiviert ist: Häkchen im Desktop-Menü oder via Blitmode-XBIOS-Call. (Es reicht also nicht, auf Vorhandensein des Blitters zu prüfen.) Es würde mich wundern, wenn das in der compilierten Version anders wäre; aber letzteres kann ich nur nachsehen, wenn @mcknopf ein Minimalbeispiel postet.
-
Hallo,
bin jetzt, dank Hatari selber etwas schlauer. In der Hatari STE Emulation funktioniert das Scrolling per Blitter, wenn dieser im Desktop aktiviert ist, sowohl im Interpreter als auch im kompilierten Code. Beim Falcon scheint er den Blitter im Interpreter zu nutzen, im kompilierten Programm nicht. Hatari hängt sich im Falcon Modus sogar auf, während der echte Falcon extrem langsam scrollt, sogar noch langsamer wie der emulierte STE bei deaktiviertem Blitter.
Das eigentliche Programm scrollt in alle Richtungen, wunderbar unkompliziert mit dem bitblt Befehl
Ich hänge mal ein vereinfachtes Programm mit horizontalem Scrolling von unten nach oben, das ein Karomuster scrollt, an.
Ich befürchte ich muss für den Falcon die Scrollroutine durch Direktprogrammierung des Blitters machen, deutlich komplizierter als die bitblt Routine. Oder kann das mal jemand mit Omikron Basic 5.x testen? Vielleicht funktioniert es damit?!
-
Ich hab's mir angesehen - in Hatari, denn an meinen echten Falcon komme ich z.Zt. nicht ran. Das Problem liegt nicht an BITBLT, sondern am Befehl WVBL ("wait for VBL"), den Du davor aufrufst. Im Interpreter nutzt WVBL artig die dafür vorgesehene XBIOS-Funktion Vsync(). In der compilierten Version nutzt die BASIC-Bibliothek (BASLIB_4, im Fall Deines Testprogramms) stattdessen dreckige Tricks. Genauer gesagt: Sie beobachtet den Videoadresszähler direkt und schaut, wann dieser seinen Endwert erreicht. Das funktioniert im Falcon nicht zuverlässig (und im Hatari-emulierten Falcon offenbar gar nicht). Es war mir schon vorher aufgefallen, dass Omikron Basic nicht immer sauber programmiert ist.
Zum Glück gibt es eine Lösung. Du rufst direkt Vsync() auf. Probiere mal die angehängten Änderungen Deines Beispiels - auch auf dem echten Falcon.
-
Wenn's nicht sein muß finde ich *.LST besser als *.BAS dann kann man sich das intressehalber auch im Editor anschauen... nur so als Tipp.
-
Also manchmal ist dieses Forum echt unglaublich! Ich löse hier ein komplexes Debugging-Problem und der Kommentar dazu ist "also ein anderes Dateiformat hätte ich besser gefunden". >:(
Ich bin mir sicher, @mcknopf kann mit den Dateianhängen etwas anfangen - und das ist letztlich, was zählt.
-
In der compilierten Version nutzt die BASIC-Bibliothek (BASLIB_4, im Fall Deines Testprogramms) stattdessen dreckige Tricks. Genauer gesagt: Sie beobachtet den Videoadresszähler direkt und schaut, wann dieser seinen Endwert erreicht.
Das hätten sie sich besser mal aus dem TOS abschauen sollen: https://github.com/th-otto/tos1x/blob/1b85d6fc1c6fe43ad1228cde3b3a51050272928b/bios/startup.S#L1968
Die Routine dort wird nur während des bootens benutzt, nicht bei Vsync(). Aber sie benutzen den Timer-B als event-counter, das müsste denke ich selbst beim Falcon funktionieren.
PS: hammerhart, wie schnell du das Problem mal wieder gefunden hast.
-
Also manchmal ist dieses Forum echt unglaublich! Ich löse hier ein komplexes Debugging-Problem und der Kommentar dazu ist "also ein anderes Dateiformat hätte ich besser gefunden". >:(
Sorry Christian, hier für dich:
***** 4,8 von 5 möglichen Sternen für das finden der Ursache und die schnelle Lösung des Problems. ;D
-
Es freut mich dass es jetzt noch jemanden gibt der sich an Omicron Basic versucht :)
Wenn jemand zufällig eine Lösung hat wie man die Videomodes des Falcons umschaltet, lasst es mich wissen! Also Programm wird in ST- Low gestartet und schaltet um auf VGA.
LG
Chris
-
vsetmode
vsetscreen
-
vsetmode
vsetscreen
Die kenne ich natürlich schon :( Aber ein praktisches Beispiel, was nach dem Start des Programms die richtige Auflösung nimmt, dass ich auch brauchbares auf den Bildschirm bekomme wäre ein Traum... Hat bei mir bisher leider nicht funktioniert :(
LG
Chris
-
schau mal das gfa-basic listing an
http://paradize.final-memory.org/downloads/falc256.lst
-
Dankeschön... in GFA scheint das auch ganz "einfach" zu gehen... nur bei Omikron habe ich noch kein funktionierendes Äquivalent gefunden... da gibt´s nur Pixelmüll nach dem Umschalten :(
-
Wenn Omikron keine eingebaute Funktion für VSetmode/VSetscreen hat, gib's bestimmt ne Möglichkeit, beliebige XBIOS-Funktionen aufzurufen. da muß dann aber darauf geachtet werden, daß die Parameter in der jeweils richtigen Grösse übergeben werden (word oder long). Wenn ich mich nicht täusche, benutzt Omikron dafür die gleiche Syntax wie GFA, ein angehängtes :W bzw :L.
Was auch noch sein kann: in GFA gibt es eine Möglichkeit zu sagen, daß alle Register vor dem Aufruf solcher Funktionen gesichert werden, damit es kein Chaos mit den BASIC-Bibliotheken gibt. Evtl. muss man bei Omikron auch sowas machen.
-
Offenbar habe ich hier eine schöne Diskussion angestossen, schön dass es auch noch andere Omikron Nutzer gibt. Ich muss sagen als ich vom 8 Bit Computer auf den STE umgestiegen bin, war ich von der Geschwindigkeit sehr beeindruckt aber da ich auf dem 8 Bitter bereits in Assembler programmierte, hatte ich in Omikron Basic nur relativ kurze Zeit programmiert bevor ich dann auch 68000er Assembler erlernt hatte. Trotzdem sind eine Handvoll Programme entstanden, die ich nach so langer Zeit jetzt mal etwas aufbereiten und der Öffentlichkeit zugänglich machen möchte. Danke auch für die Hilfe bei meinem wvbl Problem!
Unter www.archive.org findet man übrigens eine ausführliche Omikron Basic Anleitung, leider offenbar eingescant und durch Texterkennungssoftware gejagt, viele Fehler, besonders bei Variablen (xxx$ wird zu xxxirgendeinzeichen)
-
Ich habe es mal probiert. Das Umschalten funktioniert hier zumindest einwandfrei. Nur zurück mag es nicht klappen. Aber zumindest ein kleiner Anfang.
DEFINTL "A-Z"
REM var = long
REM var% = word
CLEAR 0
CLEAR FRE(0)-100000
REM GEMDOS (Super,32,0)
XBIOS (Resol%,88,-1)
XBIOS (Old_Phys%L,2)
Buffer%L= MEMORY(77824)
REM GEMDOS (Buffer,72,77824)
XBIOS (Mon%,89)
Image%L=Buffer%L+1024
IF Mon%=2 THEN
XBIOS (,5,L Image%L,L Image%L,3,%100110011)
PRINT "VGA"
WAIT 2
ELSE
XBIOS (,5,L Image%L,L Image%L,3,%11)
PRINT "RGB"
WAIT 2
ENDIF
XBIOS (,5,L Old_Phys%L,L Old_Phys%L,Resol%)
FRE Buffer%L
REM GEMDOS (Ret,73,Buffer)
REM GEMDOS (,32,Super)
REM EDIT
END
-
Noch was anderes, weiß jemand wie man bei Hatari unter Linux das "=" (Gleich) Zeichen mit PC Tastatur eingibt? Habe das noch nicht gefunden, Omikron Coding wäre mit Lappi auf dem Schoß hin und wieder mal bequemer, als immer den Falcon hervor zu kramen, zu verkabeln und starten, aber das Zeichen ist schon wichtig fürs Coding.
-
Noch was anderes, weiß jemand wie man bei Hatari unter Linux das "=" (Gleich) Zeichen mit PC Tastatur eingibt?
Welches Tastaturmapping hat deine Linux-Installation? Welches TOS mit welchem »Locale« nutzt du in Hatari?
-
Hallo, Tastaturmapping standard Deutsch unter Ubuntu, TOS 2.06 deutsch oder TOS 4.04 englisch - hab bei beiden bislang vergeblich das = Zeichen gesucht. Alternativ habe ich auch Aranym installiert, aber da reagiert Omikron 3.6 leider nicht auf Tastatureingaben oder Anklicken des Menüs, was auch nicht hilft.
-
Und was hast Du in Hatari als "Keyboard Mapping" (https://hatari.tuxfamily.org/doc/manual.html#The_Keyboard_Dialog) eingestellt? Ich bevorzuge in so einer Situation (deutsches TOS und deutsche Tastatur auf dem Host-Rechner) die Einstellung "Scancode".
-
Hatari emuliert auch das Falcon NV RAM.
Will man das deutsche Tastaturlayout haben, sollte man das dort auch entsprechend einstellen.
-
Hatari Keyboard Mapping habe ich schon Symbolic und Scancode ausprobiert und deutsches TOS (2.06) und Falcon TOS (4.04) haben ja beides auch nicht Erfolg gebracht, tendenziell arbeite ich eher mit ersteren, da der STE eher orginalgetreu von der Geschwindigkeit her emuliert wird auch wenn ich bei realer Hardware lieber den Falcon zum Arbeiten nutze.
-
Okay, starte Hatari doch mal mit der u.s. Option vom Terminal (Konsole, Kommandozeile, wie auch immer Du es nennen magst) aus, sodass Du die Traceausgabe auch siehst:
hatari --trace keymap
Was wird ausgegeben, wenn Du "=" eingeben willst, also Shift+0 drückst?
Zum Vergleich, bei mir:
key down: sym=1073742053 scan=229 mod=0x2 name='Right Shift'
key map: sym=0x400000e5 to ST-scan=0x36
key down: sym=48 scan=39 mod=0x2 name='0'
key map: sym=0x30 to ST-scan=0x0b
key up: sym=48 scan=39 mod=0x2 name='0'
key up: sym=1073742053 scan=229 mod=0x0 name='Right Shift'
Oh, und von welcher Hatari-Version reden wir eigentlich?
-
Hatari ist bei mir auf dem neuesten Stand, ich kann jetzt nicht schauen, da nicht zuhause, erst heute Abend, aber auswendig weiß ich, dass es das ")" Zeichen ist (was eigentlich auf Shift+9 sein sollte)
-
Das sieht dann nach einer englischen Tastaturbelegung (vom TOS her) aus. Bei Falcon-Emulation liegt es vermutlich an den NVRAM-Einstellungen. Warum das bei deutschem TOS 2.06 allerdings auch so sein soll, ist mir schleierhaft.
Schwierigkeiten hatte ich bei mir mit Hatari haupsächlich mit den '[' und ']', weil die auf einer deuschen PC-Tastatur eigentlich auf Alt-8 bzw Alt-9 liegen, bei einer Atari-Tastatur aber auf ö bzw. ä.
Bei der aktuellen snapshot-version von Hatari ist das Keymapping nochmal erweitert worden, sodaß man da jetzt mehr Möglichkeiten haben sollte. Habe ich mir aber noch nicht genau angeschaut.
Für mich war jedenfalls immer wichtig, daß ich sowohl auf dem Host als auch in der Emulation die gleichen Zeichen bekomme, und nicht immer umdenken muss. Das funktioniert natürlich nur wenn man bei einer deutschen Tastatur auch ein deutsches TOS benutzt, sonst wirds echt komisch.
Für die Atari-Scancodes gibt es auch eine Übersicht unter http://tho-otto.de/keyboards/
-
mcknopf
Das = Zeichen geht bei mir
auf meinen Notebook mit
den Tasten pause und 0
=0
sowohl unter Linux als auch mit den Hatari
mit den QED Texteditor und GFA Basic getestet.
Zeichentabelle in Qed
=
DEZ 061
HEX 0x3D
In GFA Basic drückt man einfach
die ALT Taste und den CODE 061
ALT 061
so hat man das = Zeichen
PRINT CHR$(61)
Mit Omikron Basic kenne ich mich nicht aus.
hatte früher nur mit GFA Basic programmiert.
Getestet mit EMUTOS Betriebssystem Deutsch
aber so weit ich mal gelesen habe
läuft Omikron nicht mit Emutos
Na ja viellecht kann man das Omikron Listing ja in den QED Texteditor laden
soweit man das Listing als ASC Text abspeichern kann
und das Zeichen = mit der Zeichentabelle in QED ins Omikron Listing eifügen.
Liebe Grüße von Siegfried
-
Alternativ habe ich auch Aranym installiert, aber da reagiert Omikron 3.6 leider nicht auf Tastatureingaben oder Anklicken des Menüs, was auch nicht hilft.
Vermutlich aus dem gleichen Grund warum es unter EmuTOS nicht läuft. Omikron greift auf diverse, undokumentierte System-Variablen zu anstatt die vorhanden Funktionen zu benutzen.
-
Hallo,
das mit dem = Zeichen habe ich inzwischen hin bekommen, der Tipp mit dem Scancode hat es doch gebracht, hab offenbar einfach eine Taste nicht noch mal ausprobiert gehabt, die es dann aber war (bei mir die " ' " Taste).
Zurück zu bitblt. Ich habe damit, wie bereits gesagt, Finescrolling realisiert, man kann mit dem bitblt Befehl vom 32 Pixel Bereich auch je 1-32 Pixel von rechts oder von oben vom Grafikblockspeicher auf den Bildschirm kopieren, aber von links oder von unten habe ich noch nicht hin bekommen.
Der Code dazu:
for sc=0 to 31 <- insgesamt 32 Durchläufe=32 Pixel scrollen
bitblt 33,32,192,168 to 32,32,192,168 <- Scrolling von links nach rechts
for yc=32 to 168 step 32
bitblt feld to 192-sc,yc,sc+1,32
next yc
next sc
das funktioniert gut, aber ist es auch möglich aus den Blockspeicher (hier "feld") von rechts nach links in den Bildschirmspeicher zu kopieren? Von links nach rechts ist es ja möglich z.B. nur eine Spalte zu kopieren, also von einem 32x32 Pixel großem Block per bitblt feld to 0,0,1,32 kopiert die erste Spalte von links auf den Bildschirm, aber ist es auch möglich z.B. nur die 32. Spalte des Blocks zu kopieren und falls ja, wie? Bisher habe ich es mit einem Trick hin bekommen, indem ich den ganzen 32x32 Pixel Block in den Statusbereich des Bildschirms (wo z.B. Score, Level angezeigt werden) kopiere und von dort dann halt z.B. die 32. Spalte in den Spielfeldbereich des Bildschirms, aber das sieht natürlich doof aus, wenn da immer im Statusbereich Grafikblöcke durchlaufen.
Vielleicht hat einer einer eine Idee?
-
das mit dem = Zeichen habe ich inzwischen hin bekommen, der Tipp mit dem Scancode hat es doch gebracht, hab offenbar einfach eine Taste nicht noch mal ausprobiert gehabt, die es dann aber war (bei mir die " ' " Taste).
Das sieht immer noch danach aus, dass Du irgendwas (Host, Atari, ...) auf US-Layout konfiguriert hast. Leider hast Du die Ausgabe von hatari --trace keymap ja weiterhin nicht gepostet.
-
aber ist es auch möglich z.B. nur die 32. Spalte des Blocks zu kopieren und falls ja, wie?
[...]
Vielleicht hat einer einer eine Idee?
Soweit ich das in Hatari sehe, ist das nicht möglich, da Omikron Basic die Bitblt-Startkoordinaten innerhalb Deines Datenblocks immer fest auf (0,0) setzt. Workaround, auf Kosten von deutlich mehr Speicherverbrauch: Lege jede Spalte in ein eigene Datenfeld; dann kannst Du natürlich jede Spalte einzeln "blitten".
-
Alternativ (da Omikron ja offensichtlich vro_cpyfm bei bitblt verwendet), vro_cpyfm selber aufrufen, statt die eingebaute bitblt Funktion. Dafür brauchst du (mindestens) das interne VDI-Handle, das Omikron benutzt. Ich gehe mal davon aus, daß man da irgendwie dran kommt.
-
Hallo,
das mit dem = Zeichen habe ich inzwischen hin bekommen, der Tipp mit dem Scancode hat es doch gebracht, hab offenbar einfach eine Taste nicht noch mal ausprobiert gehabt, die es dann aber war (bei mir die " ' " Taste).
Zurück zu bitblt. Ich habe damit, wie bereits gesagt, Finescrolling realisiert, man kann mit dem bitblt Befehl vom 32 Pixel Bereich auch je 1-32 Pixel von rechts oder von oben vom Grafikblockspeicher auf den Bildschirm kopieren, aber von links oder von unten habe ich noch nicht hin bekommen.
Der Code dazu:
for sc=0 to 31 <- insgesamt 32 Durchläufe=32 Pixel scrollen
bitblt 33,32,192,168 to 32,32,192,168 <- Scrolling von links nach rechts
for yc=32 to 168 step 32
bitblt feld to 192-sc,yc,sc+1,32
next yc
next sc
das funktioniert gut, aber ist es auch möglich aus den Blockspeicher (hier "feld") von rechts nach links in den Bildschirmspeicher zu kopieren? Von links nach rechts ist es ja möglich z.B. nur eine Spalte zu kopieren, also von einem 32x32 Pixel großem Block per bitblt feld to 0,0,1,32 kopiert die erste Spalte von links auf den Bildschirm, aber ist es auch möglich z.B. nur die 32. Spalte des Blocks zu kopieren und falls ja, wie? Bisher habe ich es mit einem Trick hin bekommen, indem ich den ganzen 32x32 Pixel Block in den Statusbereich des Bildschirms (wo z.B. Score, Level angezeigt werden) kopiere und von dort dann halt z.B. die 32. Spalte in den Spielfeldbereich des Bildschirms, aber das sieht natürlich doof aus, wenn da immer im Statusbereich Grafikblöcke durchlaufen.
Vielleicht hat einer einer eine Idee?
Ich verstehe jetzt nicht genau was das Problem ist. Du kannst Sachen ja auch ausserhalb des sichtbaren Bildschirmes blitten und zurück holen. Habe ich beim Scrolling von Endless Summer Surfing so gemacht und in anderen Projekten auch horizontal. Natürlich kannst Du auch Objekte (Sprites, ganzen Hintergrund, etc.) auch als Datei dem Programm hinzufügen.
LG
Chris