Neueste Beiträge

31

Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...

« Letzter Beitrag von Lukas Frank am So 22.03.2026, 15:22:46 »

2 Stk. Simm Modul gleich groß funktioniert nicht und es werden nach meiner Vermutung immer 52MB oder das vierfache bei zwei 32MB Modulen erkannt.

Ein ungleiche Modulgröße funktioniert vermute ich ...


8MB + 4MB = ok insgesamt 12 MB
16MB + 8MB = 24 MB ok insgesamt 24MB
32MB + 16MB =48 MB ok insgesamt 48MB

Ausnahme ... 4MB + 4MB = 8 MB ok insgesamt 8MB

Einzel Simmmodule 4,8,16,32MB im Slot A funktioniert immer

32

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von AndreasKromke am So 22.03.2026, 14:05:18 »

Leichen über Leichen im Keller, diesmal stand "Behne" drauf    ...

Die Bildschirmtreiber für 16M, 32k und 16 Farben hatten eine kaputte Routine zum Zeichnen des VT52-Cursors. Der entsprechende Code war bei allen dreien von irgendwo her kopiert worden und totaler Quatsch. Das fiel nur auf bei weniger als 400 Bildschirmzeilen und abgeschaltetem VT52.PRG, denn dann verwendet der VT52 den 8x8-Zeichensatz. Im Taskmanager sah man es auch nicht, weil der Cursor hier abgeschaltet wird.

Die Reparatur war relativ simpel. Gut, wenn man den Quältext hat.

Die Mausrad-Unterstützung ist kniffelig, weil man dazu die vertikalen Fenster-Scrollpfeile simulieren muß, soweit ich verstanden habe. Die Nachrichten müßten wie Mausbewegungen oder virtuelle Tasten verschickt werden, über entsprechende Pakete. Weißt Du, wie EmuTos das macht? Da müßte ich wohl mal in den Quelltext von EmuTos schauen. Das ist langwierig und aufwendig. Aber ja, ich stolpere inzwischen auch darüber, daß das nicht geht, weil es jedes andere BS kann.

PS: Der Mauszeiger in "ST mid" sieht tatsächlich bei Hatari genauso schaise aus...

33

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von ragnar76 am So 22.03.2026, 12:34:24 »

Wie sieht es egtl. mit der Unterstützung vom Mausrad aus? Ich stolpere jedesal darüber dass das nicht geht 

34

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von AndreasKromke am So 22.03.2026, 12:10:41 »

Der Grund für die horizontal gestreckten GUI-Elemente im Modus "vier Farben" war relativ einfach zu finden. Das AES ist nämlich schlau und versucht, einige Elemente quadratisch zu machen, bei vorgegebener Höhe. Dazu braucht es die tatsächliche Pixelgröße. Die kommt vom VDI und wird in Mikrometern (Merkel sagte mal "Mühkrometer", aber die hat ja auch sonstwo sonstwas studiert ...) angegeben. Das VDI wiederum kriegt die Pixelgröße vom Bildschirmtreiber. Die VDI-Bildschirmtreiber geben üblicherweise 278 µm Pixelgröße an. Zum Vergleich: Ein 32-Zoll-4k-Monitor hat etwa 180 Mikrometer pro Pixel.

Nun gibt es zwei Ausnahmen: Der 16-Farb-Interleaved-Treiber verdoppelt die Pixelgröße in beide Richtungen, ein Relikt vom ST (niedrige Auflösung). Und der 4-Farb-Interleaved-Treiber verdoppelt die Pixelgröße vertikal, ein Relikt von der "mittleren" Auflösung des ST, und dadurch ergibt sich die Streckung.

Ich habe jetzt den Vierfarbtreiber so geändert, daß die vertikale Pixel-Streckung nur bei 640x200 ausgeführt wird, und - voilá - jetzt sieht es in den anderen Auflösung ordentlich aus. Dabei habe ich auch gleich ein paar sehr imposante Assembler-Befehle entfernt, die völlig überflüssig waren.

Was bleibt? Bei "ST-mid" ist der Mauszeiger häßlich gestreckt. War das beim ST auch so? Muß mal Hatari konsultieren. Und das CHGRES-Fenster darf man nicht verschieben, dann gibt es nämlich smutz. Vielleicht war der weiße Bildschirm die ehrlichere Lösung. Ich nehme an, daß sich Magxdesk beendet, um CHGRES statt seiner zu starten, und damit verschwindet der Desktop-Hintergrund. Vielleicht gibt es keinen Default-Hintergrund, das weiß ich nicht mehr.

35

Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...

« Letzter Beitrag von czietz am So 22.03.2026, 11:54:05 »

Ohne Dokumentation der (vermutlich unvollständigen) Adressdekodierung der FRAK komme ich nicht weiter. Alles andere wäre Rätselraten. 

36

Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...

« Letzter Beitrag von Lukas Frank am So 22.03.2026, 10:43:30 »

Ein einzelnes 32MB Simm im Slot A (der zur Platinen Mitte) sollte dann aber in Ordnung sein, oder?

37

Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...

« Letzter Beitrag von bbisi am So 22.03.2026, 10:23:40 »

ich habe auch den doppelten Ram Wert unter EmuTos 1.4 Pak Vers
Installiert habe ich 2x32MB EDO Sims
Unter Sysinfo.prg oder im Emutos wird immer 122.... MB angezeigt

38

Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...

« Letzter Beitrag von Lukas Frank am So 22.03.2026, 10:20:56 »

1x8MB Simm = ok

39

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von ragnar76 am So 22.03.2026, 10:08:35 »

Wo hast Du die andere Schriftart her?

Das ist der Monaco Font der bei NVDI mitgeliefert wird.

40

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von AndreasKromke am So 22.03.2026, 09:53:52 »

Es ist immer wieder putzig, was so alles an alten Fehlern bzw. Unschönheiten auffällt. Im Vierfarbmodus nimmt das AES eine Schriftgröße von 8x16, wenn der Bildschirm mindestens 320 Pixel hoch ist (das gilt wohl für alle Modi). Andererseits sind die Fenster- und andere GUI-Elemente dann horizontal gestreckt. Der VT52 verwendet aber den 8x8-Zeichensatz. Und das WINFRAME.SLB kann nur breite Rahmen, d.h. beim 8x8-Zeichensatz und mindestens 16 Farben bleiben die Fensterrahmen breit.

Upps: Bei 640x320x16M verwendet AES die 8x16-Zeichen, VT52 die 8x8-Zeichen, aber (!) die Abstände zwischen den Zeilen sind 16 Pixel, und der der Cursor blinkt 8x16 und erzeugt smutts. Der Fehler tritt auf bei weniger als 400 Pixeln Bildschirmhöhe.