atari-home.de - Foren
Software => Coding => Thema gestartet von: gh-baden am Mi 23.03.2022, 22:11:06
-
Hallo,
viele Demos nutzen ja diverse Tricks (http://pub.dss.in.tum.de/brandt-research/fullscreen.txt), 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.
-
Hättest Du denn eine Idee wie sich das verwirklichen ließe?
-
Theoretisch: v_opnwk abfangen, und dort vorher & hinterher die Line-A variablen anpassen. Sollte sogar mit NVDi funktionieren.
-
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 (http://pub.dss.in.tum.de/brandt-research/fullscreen.txt), 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/ (https://demozoo.org/productions/73157/)
-
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.
-
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?
-
... Ging das auch in monochrom? ...
Rand Öffnen (per SW) geht in monochrom (leider) grundsätzlich nicht.
-
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.
-
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!
-
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?
-
... 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 …
-
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 ;-)
-
Für Hatari 2.3.1 Win eine zu harte Nuss wie es scheint...
-
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.
-
Thomas' Version von ScreenPlus startet im Autoordner mit einerTextmeldung und macht direkt einen Reset... und das dann als Dauerschleife.
-
funktioniert prima bei mir (Hatari 2.4.0-devel).
-
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?
-
Freue mich schon auf Hatari 2.4.0 :)
-
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 (https://www.newtosworld.de/viewtopic.php?t=34&p=34)
-
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.
-
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.
-
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
-
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.
-
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.
-
Danke dir!
Wenn der Entwickler des Shifters das nur noch alles mitbekommen hat …
-
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?
-
Die NOBORDER Demo scheint mit Hatari nicht zu funktionieren. Zumindest seh ich da keinen Effekt.
Ich kann die Anschaffung echter Hardware empfehlen:
(https://forum.atari-home.de/index.php?action=dlattach;topic=16900.0;attach=30581;image)
Und ja, dort wo der Scrolltext zu sehen ist, ist im Mono-Modus normalerweise nur schwarzer Rand.
-
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".
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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:
(https://forum.atari-home.de/index.php?action=dlattach;topic=16900.0;attach=30941;image)
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.