31
Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...
« Letzter Beitrag von Lukas Frank am So 22.03.2026, 17:45:30 »TOS 3.06 nochmal aufgesteckt und mit 2 Stück 8MB Simm Modulen probiert ...
Neueste Beiträge
32
Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...
« Letzter Beitrag von czietz am So 22.03.2026, 17:36:00 »Solange wir warten, kann ich nur raten.
Wenn Du das bisherige Ergebnis meiner Raterei ausprobieren möchtest, ist angehängt ein PAK3-EmuTOS-ROM, das eine(!) Möglichkeit der Spiegelung testet. Du müsstest es sowohl in Konfigurationen testen, die bislang funktioniert haben (damit sicher ist, dass ich nichts kaputt gemacht habe), wie auch in RAM-Konfigurationen, die bisher falsch detektiert wurden.
Wenn Du das bisherige Ergebnis meiner Raterei ausprobieren möchtest, ist angehängt ein PAK3-EmuTOS-ROM, das eine(!) Möglichkeit der Spiegelung testet. Du müsstest es sowohl in Konfigurationen testen, die bislang funktioniert haben (damit sicher ist, dass ich nichts kaputt gemacht habe), wie auch in RAM-Konfigurationen, die bisher falsch detektiert wurden.
33
Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...
« Letzter Beitrag von Lukas Frank am So 22.03.2026, 17:12:54 »@pakman ... meldet sich schon irgendwann und wird weiterhelfen.
Mit dem PAK TT TOS gibt es das Problem ja nicht. Habe ja keine Ahnung aber das Fastram Händling von TOS wird ja nicht gepacht bei den PAK Patches? Ist halt die Frage ob man das beim FRAK/2 Design bzw. beim/im GAL Satz ändert oder das EmuTOS anpasst?
Mit dem PAK TT TOS gibt es das Problem ja nicht. Habe ja keine Ahnung aber das Fastram Händling von TOS wird ja nicht gepacht bei den PAK Patches? Ist halt die Frage ob man das beim FRAK/2 Design bzw. beim/im GAL Satz ändert oder das EmuTOS anpasst?
34
Hardware (High-End) / Re: FRAK/2 + EmuTOS 1.4 PAK Version ...
« Letzter Beitrag von czietz am So 22.03.2026, 16:50:39 »Man kann spekulieren(!), dass die Adressdekodierung der FRAK/2 insofern unvollständig ist, als dass sie in den Fehlerfällen den Speicher spiegelt, d.h. an mehreren Adressen einblendet. Für so etwas kann man nur eine Erkennung in EmuTOS einbauen, wenn bekannt wäre, wie diese Spiegelung passiert, d.h. wie genau die Adressdekodierung der FRAK/2 realisiert wurde.
35
Tausche / FRAK/1 gesucht ...
« Letzter Beitrag von Lukas Frank am So 22.03.2026, 16:20:47 »... suche eine FRAK/1 und tausche eventuell gegen eine FRAK/2 bei Bedarf.
36
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
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
37
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...
...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...
38
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 
39
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.
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.
40
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. 