Omikron Compiler bitblt

[mcknopf]

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?

[goetz @ 3rz]

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?

[Thorsten Otto]

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.

[czietz]

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.

[czietz]

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.

[mcknopf]

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

[czietz]

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.

[Arthur]

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.

[czietz]

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.

[Thorsten Otto]

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.

[Arthur]

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.

[Atari060]

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

[laufkopf]

vsetmode
vsetscreen

[Atari060]

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

[laufkopf]

schau mal das gfa-basic listing an
http://paradize.final-memory.org/downloads/falc256.lst

[Atari060]

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

[Thorsten Otto]

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.

[mcknopf]

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)

[laufkopf]

Ich habe es mal probiert. Das Umschalten funktioniert hier zumindest einwandfrei. Nur zurück mag es nicht klappen. Aber zumindest ein kleiner Anfang.

Code: [Auswählen]

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


[mcknopf]

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.