"opening lower border" in GEM?

[goetz @ 3rz]

Hallo,

viele Demos nutzen ja diverse Tricks, um die Ränder in ST-Low nutzbar zu machen. Worauf später teilw. Overscan aufbaute.

Für den unteren Rand muss man in der 199. Zeile kurz auf 60 Hz umschalten. Gab es eigentlich einen „Treiber“ der das machte und GEM verkaufte, so dass man 320x240 hatte statt 320x200? Das scheint mir ja nicht soo rechenintensiv wie einige der anderen Ränder zu sein.

[Arthur]

Hättest Du denn eine Idee wie sich das verwirklichen ließe?

[Thorsten Otto]

Theoretisch: v_opnwk abfangen, und dort vorher & hinterher die Line-A variablen anpassen. Sollte sogar mit NVDi funktionieren.

[tin]

Gab es eigentlich einen „Treiber“ der das machte und GEM verkaufte, so dass man 320x240 hatte statt 320x200? Das scheint mir ja nicht soo rechenintensiv wie einige der anderen Ränder zu sein.

Ich habe zumindestens noch keinen gesehen.

Der Grund dafür wird sein, dass es zwar prinzipiell "einfach" ist, es aber sehr, sehr schwer sein wird, das auch stabil zu bekommen, wenn man die Timer und die DMA-Aufrufe nicht 100% komplett kontrollieren kann.

Eine (untere oder obere) Randöffnung muss bzgl. Timing einigermassen genau erfolgen. Timer C, die Maus-IRQs, der Blitter und die Floppy/Hardisk-DMA werden dafür sorgen, dass es einfach nicht wirklich stabil benutzbar sein wird. Entweder stehlen sie (ununterbrechbar) Zyklen (Blitter, DMA) oder sie kommen zu unpassenden Zeitpunkten (Timer) oder beides.

Daher muss man alles, was da die Randöffnung stören könnte, "aus dem Weg verschieben" und das ist zwar an sich möglich, aber im normalen TOS-Umfeld nicht praktikabel umsetzbar (IMHO natürlich).

Daher gibt es z.B. auch keine Fullscreens, die bei der Darstellung nachladen, obwohl eine Demo das gesamte System voll unter Kontrolle hat.

viele Demos nutzen ja diverse Tricks, um die Ränder in ST-Low nutzbar zu machen. Worauf später teilw. Overscan aufbaute.

Nur als Randbemerkung (no pun intended): es gibt auch offene Ränder in S/W per Software, z.B. hier: https://demozoo.org/productions/73157/

[thh]

Moin! So ein Programm gab's tatsächlich schon mal - nannte sich SCREEN PLUS:

https://www.stcarchiv.de/stc1992/04/screen-plus

Ich hatte davon auch mal selbst ein kleines Update gemacht was auch (teilweise) mit NVDI zusammen funktionierte ... ich müsste das noch irgendwo habe, könnte ich bei Interesse mal raussuchen.

[goetz @ 3rz]

Moin! So ein Programm gab's tatsächlich schon mal - nannte sich SCREEN PLUS:

https://www.stcarchiv.de/stc1992/04/screen-plus

Ich hatte davon auch mal selbst ein kleines Update gemacht was auch (teilweise) mit NVDI zusammen funktionierte ... ich müsste das noch irgendwo habe, könnte ich bei Interesse mal raussuchen.

Spannend! Das wäre interessant. Ging das auch in monochrom?

[mfro]

... Ging das auch in monochrom? ...

Rand Öffnen (per SW) geht in monochrom (leider) grundsätzlich nicht.

[tin]

Moin! So ein Programm gab's tatsächlich schon mal - nannte sich SCREEN PLUS:

Schöner Fund - ich habe Bitmasters Beispiel-Source mal in ein PRG assembliert (siehe Anhang) und bei der Gelegenheit auch die fehlenden TOS1.04-Adressen nachgetragen.
Läuft nur aus dem AUTO-Ordner und nur unter TOS1.2 und da aus o.g. Gründen nur leidlich (flackern+Bitplaneverschiebungen bei Diskzugriff).  Die TOS1.4-Unterstützung ist eher experimentell und hat wohl andere (nicht mit der Randöffnung an sich verwandte) Probleme.

Rand Öffnen (per SW) geht in monochrom (leider) grundsätzlich nicht.

Das ist so nicht ganz richtig, siehe die oben verlinkte Demo, die den unteren Rand in S/W öffnet. Es gibt IIRC noch mindestens eine weitere, die das tut.

[mfro]

Das ist so nicht ganz richtig, siehe die oben verlinkte Demo, die den unteren Rand in S/W öffnet. Es gibt IIRC noch mindestens eine weitere, die das tut.

War mir neu. Danke für die Info!

[Thorsten Otto]

Schöner Fund - ich habe Bitmasters Beispiel-Source mal in ein PRG assembliert (siehe Anhang) und bei der Gelegenheit auch die fehlenden TOS1.04-Adressen nachgetragen.

Nett. Allerdings gelten die hard-kodierten Addressen nur für die deutsche Version (für andere Sprach-Varianten müsste da jeweils Offset drauf-addiert werden, siehe auch https://github.com/th-otto/tos1x/blob/b96e4d9482eac4f6a616061e31bff9c4da6ad4d6/common/sections.inc#L329). Evtl. sollte man auch bei 1.04 auf EmuTOS prüfen, dort dürfte der Maus-Fix nicht nötig sein.

Läuft das auch mit NVDI? Und wenn ja, muss es vor oder nach NVDI ausgeführt werden?

[goetz @ 3rz]

... Ging das auch in monochrom? ...

Rand Öffnen (per SW) geht in monochrom (leider) grundsätzlich nicht.

Doch, zumindest in eine Richtung (unten). Das wäre das was ich suche …

[thh]

Läuft das auch mit NVDI? Und wenn ja, muss es vor oder nach NVDI ausgeführt werden?

Wie gesagt, ich hatte damals mir eine Version zusammengebastelt, die auch mit NVDI lief - indem ich den Mausfix in ein Extra-Programm ausgelagert habe. Beim Benutzen von NVDI konnte man dann einfach den Mausfix weglassen.

Ich häng meine Version hier mal an ... laut LIESMICH.TXT gab's aber noch ein problem beim Auflösungswechsel unter NVDI ... vielleicht hat ja jemand noch Lust zum debuggen ;-)

[Arthur]

Für Hatari 2.3.1 Win eine zu harte Nuss wie es scheint...

[tin]

Für Hatari 2.3.1 Win eine zu harte Nuss wie es scheint...

Interessant. Magst Du einmal ausführen, was genau bei Dir passiert? Hatari ist recht genau, was Randöffnungen angeht - die Entwicklungsversion zur nächsten Version hatte (wie bei Entwicklungsversionen üblich) da gerade ein paar Regressionen, die sind da aber auch inzwischen behoben. Hatari 2.3.1 ist zumindest, was die "alten"/"einfachen" Tricks angeht, recht korrekt.

Gerade die "original", als auch Thomas' Version von ScreenPlus in Hatari 2.3.1 wie beschrieben installiert und getestet (TOS1.4de) und beide öffnen hier den unteren Rand für den Desktop.

[Arthur]

Thomas' Version von ScreenPlus startet im Autoordner mit einerTextmeldung und macht direkt einen Reset... und das dann als Dauerschleife.

[mfro]

funktioniert prima bei mir (Hatari 2.4.0-devel).

[Thorsten Otto]

Wie gesagt, ich hatte damals mir eine Version zusammengebastelt, die auch mit NVDI lief - indem ich den Mausfix in ein Extra-Programm ausgelagert habe. Beim Benutzen von NVDI konnte man dann einfach den Mausfix weglassen.

Die entsprechenden Addressen für 1.04 (deutsche Version) wären $fd0d46,$fcade4,$fd0bf6

Ich war allerdings immer der Meinung, daß der Bug in der Address-Berechnung erst mit TOS 3.x gefixt wurde (wegen dem deutlich grösseren Bild-Schirm-Speicher in den TT-Auflösungen). Scheinbar wurde das aber bereits in 1.04 gemacht: https://github.com/th-otto/tos1x/blob/b96e4d9482eac4f6a616061e31bff9c4da6ad4d6/vdi/mouse.S#L449-L451

Dort wird bereits adda.l verwendet. Der Maus-Fix ist dementsprechend für 1.04 nicht nötig. Witzigerweise wird die gleiche Routine zur Berechnung der relativen Addresse auch an anderen Stellen benutzt (z.B. get_pixel/put_pixel), dort wird allerdings (auch in TOS 1.02) anschliessend bereits adda.l verwendet.

Ich versuche gerade mal, die original-Routinen aus TOS an den entsprechenden Stellen einzufügen, anstatt Versions-abhängig an die entsprechenden Stellen zu springen (würde, wie schon oben beschrieben, eh nur bei deutschem TOS funktionieren).

Ansonsten müsste man sich mal anschauen, ob das mit dem restaurieren des VDI-traps so richtig ist. Problem ist daß (zumindest in >= 1.04) der Trap zweimal verbogen wird, einmal für VDI-Aufrufe, und einmal für AES Aufrufe. Zu dem Zeitpunkt wo v_opnwk() vom AES aufgerufen wird (und das Programm sich dann wieder aus der Routine ausklinken will), ist der Vektor bereits auf den AES-Trap verbogen. Ihn dort wieder auf den ursprünglichen VDI-Trap zurück zu setzen, wäre also falsch. TOS 1.02 habe ich allerdings noch nicht vollständig, möglicherweise wurde das dort noch anders gemacht.

PS.: weiss eigentlich jemand ob dieser (oder ein ähnlicher) Sync-Trick auch auf TT funktioniert?

[Arthur]

Freue mich schon auf Hatari 2.4.0

[goetz @ 3rz]

PS.: weiss eigentlich jemand ob dieser (oder ein ähnlicher) Sync-Trick auch auf TT funktioniert?

Zumindest (Hardware) Overscan gab es ja auch für den TT, und brachte dort richtig viele Pixel zusätzlich:

-ST-Low: 416 × 248 px
-ST-Mid: 832 × 248 px
-ST-High: 832 × 496 px
-TT-Low: 416 × 496 px
-TT-Mid: 832 × 496 px

Man sieht, dass hier deutlich mehr in der horizontalen zu holen ist, als beim ST. Handbuch mit Funktionsweise

[thh]

Thomas' Version von ScreenPlus startet im Autoordner mit einerTextmeldung und macht direkt einen Reset... und das dann als Dauerschleife.

Also bei mir läuft's mit Hatari 2.3.1 ohne solche Probleme (allerdings unter Linux, nicht Windows). Schau evtl. mal ob du noch andere AUTO-Ordner Programme hast, die das stören könnten, bzw. ob die CPU-Einstellungen in Hatari auch auf "cycle exact" 68000 mit 8 MHz stehen.