"opening lower border" in GEM?

[Thorsten Otto]

Denke mal die Cycle-Exakt Einstellungen dürfte dort keine grosse Rolle spielen, der Trick hier funktioniert ja über den Timer-B, und nicht durch genaues Cycle-zählen.

Ansonsten habe ich mal eine verbesserte Version gebaut, die nicht mehr an wilde ROM-Addressen springt. Sollte somit mit allen TOS-Versionen zurecht kommen. NVDI und Auflösungswechsel sollten auch funktionieren.

PS.: hatari scheint noch mehr Probleme als sonst zu haben, sich mit der Maus zu synchronisieren, und verliert manchmal den Fokus noch bevor die Maus den oberen Fensterrand erreicht. Das hat aber nicht direkt was mit dem Programm zu tuen.

[goetz @ 3rz]

Ansonsten habe ich mal eine verbesserte Version gebaut, die nicht mehr an wilde ROM-Addressen springt. Sollte somit mit allen TOS-Versionen zurecht kommen. NVDI und Auflösungswechsel sollten auch funktionieren

Sehr fein, danke dir!

Um das hier abzurunden wäre noch eine "ST-High" bzw. Monochrom-Version fehlend. Leider finde zwar, dass es Demos gab die Monochrom/ST-Hi „öffneten“, aber keine Beschreibung was man tun muß. Ich bin allerdings nicht gerade mit der Demo-Szene vertraut. In "Fullscreen"-Programming on the Atari ST                    by Flix of Delta Force“ finde ich nichts.

https://www.pouet.net/prod.php?which=29701 - Monochrom/ST-High-Demo mit geöffneten Rändern

https://demozoo.org/productions/73157/  - Monochrom/ST-High-Demo mit geöffneten Rändern

Und für Farbe/ST-Low: https://github.com/Number0000009/atari-wiki/blob/master/Fullscreen%20programming%20on%20the%20Atari%20ST.txt

[czietz]

https://www.pouet.net/prod.php?which=29701 - Monochrom/ST-High-Demo mit geöffneten Rändern

Die bekomme ich auf meinem ST nicht korrekt zum Laufen.

https://demozoo.org/productions/73157/  - Monochrom/ST-High-Demo mit geöffneten Rändern

Die schon. Quellcode im Turbo-Assembler-Format ist ja dabei. Auf den ersten Blick: Wie bei Fullscreens im Farbmodus wird hier auch per Timer B und passenden NOPs eine kurze Umschaltung von $FFFF8260 getimed. Eine Herausforderung könnte sein, das stabil für alle STs unter allen Bedingungen hinzubekommen.

[czietz]

Für diejenigen, die keinen Turbo Assembler installieren möchten, anbei der erwähnte Quellcode von...

; No Lower Border on Monochrome
; developed on the SWISS-ALP-CONVENTION 92'93

... konvertiert ins Textformat.

Zeile 1164ff.: VBL-Handler, der einen Timer-B-Handler installiert, um Zeilen zu zählen.
Zeile 1307ff.: Der Timer-B-Handler, der einen zweiten Timer-B-Handler installiert, um Zeilen zu zählen. Vermutlich, weil Timer B nicht in einem Rutsch bis knapp 400 zählen kann.
Zeile 1326ff.: Die eigentliche Border-Öffnung: Synchronisation auf den Shifter, dann per Zyklus-Zählung (mit vielen NOPs) passendes kurzes Umschalten auf Low-Res und zurück auf High-Res. Das bringt den Shifter außer Tritt, sodass er nicht nach 400 Zeilen aufhört.

[goetz @ 3rz]

Danke dir!

Wenn der Entwickler des Shifters das nur noch alles mitbekommen hat …

[Thorsten Otto]

Die NOBORDER Demo scheint mit Hatari nicht zu funktionieren. Zumindest seh ich da keinen Effekt. Auch ein ändern der Parameter (F1 etc) scheint nichts zu bewirken, im Help-Screen ändern die sich auch nicht.

PS.: hab ich das im Code richtig verstanden, daß damit 110 Zeilen zusätzlich möglich sind?

[czietz]

Die NOBORDER Demo scheint mit Hatari nicht zu funktionieren. Zumindest seh ich da keinen Effekt.

Ich kann die Anschaffung echter Hardware empfehlen:


Und ja, dort wo der Scrolltext zu sehen ist, ist im Mono-Modus normalerweise nur schwarzer Rand.

[czietz]

PS: Mit den Einstellungen im HELP-Screen kann man den Shifter offensichtlich in allerhand unsinnige Zustände bringen. Darunter auch welche, die mit Sicherheit nicht gut für meinen SM124 sind: Verzerrte Darstellung, sehr helle Streifen im Bild - Indizien dafür, dass die Ablenkung in der Bildröhre nicht mehr mitkommt.

PPS: https://hatari.tuxfamily.org/doc/compatibility.html: "monochrome overscan isn't supported by Hatari".

[Thorsten Otto]

Ich kann die Anschaffung echter Hardware empfehlen:

Ist klar, scheitert nur an den Penunzen

PPS: https://hatari.tuxfamily.org/doc/compatibility.html: "monochrome overscan isn't supported by Hatari".

Hm, mist. Kann natürlich versuchen das in das bestehende Programm einzubauen, aber das wäre dann nur im Blindflug. Kannst du denn die 110 zusätzlichen Zeilen bestätigen? Kommt mir recht viel vor.

Evtl. müsste man sich auch Gedanken machen wie man den Bildschirmspeicher besser allozieren kann. Momentan wird er Teil des residenten Programms, was bedeutet daß er a) nicht mehr wie sonst am Ende des Speichers ist und b) der vorherige Bildschirmspeicher von 32k damit brach liegt und nicht mehr genutzt werden kann.

[czietz]

Hm, mist. Kann natürlich versuchen das in das bestehende Programm einzubauen, aber das wäre dann nur im Blindflug. Kannst du denn die 110 zusätzlichen Zeilen bestätigen? Kommt mir recht viel vor.

Schwer zu zählen, weil die Demo ja größtenteils aus einem schwarzen Hintergrund besteht. Man müsste ein Schachbrettmuster o.ä. einbauen. Wobei die Frage auch ist, was eher in die Begrenzung geht: der Shifter oder der Bildschirm.

[Thorsten Otto]

Ja, gute Frage. Hängt vlt. auch vom verwendeten Monitor ob, und wie der kalibriert ist.

Man könnte natürlich konservativ vorgehen, und Speicher für 110 Zeilen reservieren, aber nur etwas weniger (vlt 80) GEM zur Verfügung stellen. Wenn man den Speicher vorher löscht, sollte dort auch kein Müll angezeigt werden.

[Thorsten Otto]

Kann jemand die angehängte Version mal in Monochrome probieren?

Wie oben beschrieben, reserviert dies 110 Zeilen mehr für den Bildschirm, und stellt GEM davon 80 zur Verfügung. Ansonsten habe ich noch gegenüber dem Original einen bclr #0,isra in den Interrupt-Routinen eingebaut, hoffe mal das bringt das Timing nicht durcheinander.
Auch sollte man erwähnen daß in der Demo direkt der VBL interrupt benutzt wird, während das bestehende Programm sich einen freien Platz in der VBL-Queue sucht.

[czietz]

Kann jemand die angehängte Version mal in Monochrome probieren?

Hm, nicht gut: https://youtu.be/lHM2eBrRWgg

Die durchlaufenden Streifen zeigen mir, dass Du Dich offensichtlich nicht korrekt auf das Ende des Bilds synchronisieren kannst. Weitere Tests und Debugging überlasse ich aber jemanden, dessen Monitor im Zweifelsfall nicht in "Boom!" endet.

EDIT: Unterschied, der mir auffällt (neben der Nutzung der TOS-VBL-Queue): Der VBL-Handler der Demo stoppt den Timer B; Dein Code nicht.

[Thorsten Otto]

EDIT: Unterschied, der mir auffällt (neben der Nutzung der TOS-VBL-Queue): Der VBL-Handler der Demo stoppt den Timer B; Dein Code nicht.

Hm, stimmt, muss ich übersehen haben. Wobei ich mich frage ob das notwendig ist, wenn der HBL interrupt nicht komplett verpasst wurde, kann dort ja eigentlich keiner auftreten. Ich nehme an du hast jetzt nicht ausprobiert ob das einen Unterschied macht, um deinen armen Monitor zu schonen?

Ansonsten muss das jemand mit einem nicht-so-empfindlichen Multi-Sync testen.

Die Werte die man In der Demo über F1/F2 und F3/F4 ändern kann, sind übrigens die branch-offsets bei delay2 und delay1, und beeinflussen die Anzahl der nops die dort ausgeführt werden. Alle anderen Parameter aus der Demo finden in der Standalone Version keine Verwendung.

[czietz]

Hm, stimmt, muss ich übersehen haben. Wobei ich mich frage ob das notwendig ist, wenn der HBL interrupt nicht komplett verpasst wurde, kann dort ja eigentlich keiner auftreten.

Meinen dunklen Erinnerungen an die MFP-Register zufolge macht es einen Unterschied, ob man das Timer-Data-Register beschreibt (was der Code ja tut), während der Timer läuft oder gestoppt ist.

Ich nehme an du hast jetzt nicht ausprobiert ob das einen Unterschied macht, um deinen armen Monitor zu schonen?

Sorry, ich habe nur begrenzt Zeit für Atari aktuell. EDIT: Vergessen zu erwähnen hatte ich, das ich Dein Programm auch mit einem LCD probiert hatte. Der mochte das Signal aber dermaßen nicht, dass er nur "no signal" angezeigt hat ... ist also zum Testen leider auch nicht geeignet.

[thh]

Evtl. müsste man sich auch Gedanken machen wie man den Bildschirmspeicher besser allozieren kann. Momentan wird er Teil des residenten Programms, was bedeutet daß er a) nicht mehr wie sonst am Ende des Speichers ist und b) der vorherige Bildschirmspeicher von 32k damit brach liegt und nicht mehr genutzt werden kann.

Schau mal in die Sourcen von meiner "SCREENPLUS 2" Variante, das hatte ich damals so geändert, dass der alte Bildschirmspeicher möglichst übernommen wird.

[Thorsten Otto]

Muss ich nochmal checken, aber übernehmen kann man den ja nicht so einfach. Der liegt normalerweise am Ende des physischen Speichers, der neue ist aber grösser. phystop nach unten schieben geht auch nicht so einfach, da alles von membot-phystop schon von GEMDOS verwaltet wird.

Aber erstmal muss das überhaupt laufen. Habe bisher noch keine sonstige Rückmeldung erhalten.

[thh]

Muss ich nochmal checken, aber übernehmen kann man den ja nicht so einfach. Der liegt normalerweise am Ende des physischen Speichers, der neue ist aber grösser. phystop nach unten schieben geht auch nicht so einfach, da alles von membot-phystop schon von GEMDOS verwaltet wird.

Doch, geht recht einfach so lange SCRPLUS recht früh im AUTO-Ordnr ausgeführt wurde, sogar ohne sich mit den System-Variablen rumzuschlagen. Der Trick ist, mit Malloc(-1) den größten Block zu suchen und zu allozieren. Der endet dann in der Regel genau am alten Bildschirmspeicher. Dann kann man den größten Block mit Mshrink() um die benötigte zusätzliche Speichermenge verkleinern und gleich drauf die zusätzliche Speichermenge Malloc'en - dann hat man einen Block genau vorm alten Bildschirmspeicher. Dann noch den größten Block wieder freigeben, und man hat jede Menge Speicher gespart.

[czietz]

Ich sehe gerade, dass ich zum Thema Software-Overscan in Mono in einem anderen Forum gepostet hatte, aber die Infos nicht hier her übertragen hatte. Sorry! Ich zitiere mich mal selbst, ohne Übersetzung:

----
Patching the "Mono-No-Border Screen" demo (https://demozoo.org/productions/73157/) to run with an inverted screen, i.e., white background, explains what I meant:



As you can see: Yes, it manages to display the scroll text below what would normally be the lower border of the monochrome screen. But it doing so, it massively messes with HSYNC, causing one very long line and, thus, very visible artifacts. You can see the analog electronics in the deflection circuitry of my poor SM124 slowly settling again during the next lines. I guess this is what troed is referring to when he says "you can't perform a sync-clean opening" [in monochrome]. The demo just hides all that in the black background; but you can't use it with arbitrary programs.
----

PS: Troed, sicherlich der Experte bzgl. Overscan-Tricks, hat meine Schlussfolgerung bestätigt.