Software > Coding

"opening lower border" in GEM?

<< < (4/8) > >>

mfro:
funktioniert prima bei mir (Hatari 2.4.0-devel).

Thorsten Otto:

--- Zitat von: thh am Di 05.04.2022, 21:33:58 ---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.

--- Ende Zitat ---

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:

--- Zitat von: Thorsten Otto am Fr 08.04.2022, 17:50:13 ---PS.: weiss eigentlich jemand ob dieser (oder ein ähnlicher) Sync-Trick auch auf TT funktioniert?

--- Ende Zitat ---

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:

--- Zitat von: Arthur am Mi 06.04.2022, 19:42:12 ---Thomas' Version von ScreenPlus startet im Autoordner mit einerTextmeldung und macht direkt einen Reset... und das dann als Dauerschleife.

--- Ende Zitat ---

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete