Neueste Beiträge

31

Hardware (Classic 16-/32-Bit) / Re: Atari Falcon Instandsetzung ...

« Letzter Beitrag von Lukas Frank am Sa 02.05.2026, 17:06:01 »

Clock wieder in den original Zustand versetzt und das leere NVRAM Modul ausgelötet um einen Sockel einzulöten ...

Habe noch ein 4MB Rammodul um das Mainboard zu Testen.

32

Hardware (Classic 16-/32-Bit) / Re: Atari Falcon Reparatur ...

« Letzter Beitrag von Lukas Frank am Sa 02.05.2026, 14:14:49 »

Weiss ich, hatte das bei meinem DFB1 Falcon so gemacht ...

33

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von AndreasKromke am Sa 02.05.2026, 12:10:49 »

Es gibt jetzt einen True-Colour-Bildschirmtreiber OFF16M_H.OSD, der bis auf das Lesen und Setzen einzelner Pixel alle Grafikausgaben an den Host delegiert. Der Treiber ist standardmäßig deaktiviert und heißt ".OSX". Um ihn zu aktivieren, muß man den 68k-Treiber OFF16MOV.OSD umbenennen, z.B. in .OSX, und dann den o.g. Treiber von .OSX in .OSD.

Ich teste das noch ein wenig, und dann werde ich die beiden Dateien vertauschen.

Geschwindigkeitsmäßig bringt es nicht fürchterlich viel, es ist eher eine Machbarkeits-Studie. Der 68k-Code ist halt extremst optimiert, betreibt heftiges loop unroll und verwendet für jeden Farb- oder Schreibmodus eine eigene Schleife, um jegliche bedingten Sprünge in den innersten Schleifen zu vermeiden. Die Mühe habe ich mir nicht gemacht, der C-Code ist hoffentlich deshalb etwas besser leserlich und auf jeden Fall sehr viel kürzer.

Die meisten Geschwindigkeitsmeßprogramme versagen wegen irgendwelcher Überläufe, aber in den Fällen, in denen Kronos mal lief, sehe ich ungefähr Faktor drei. Das ist nicht aufregend und vielleicht nur auf langsameren Rechnern interessant.

Auf jeden Fall habe ich viel über die Behne-Treiber-Paradigmen gelernt. 

34

Hardware (Classic 16-/32-Bit) / Re: Atari Falcon Reparatur ...

« Letzter Beitrag von Guus.Assmann am Sa 02.05.2026, 11:26:17 »

Hallo Frank,
Wegen den Uhren-IC, es ist auch möglich um das Gehäuse an die richtige Stellen auf zu Fräsen.
Dann kann eine externe Batterie angeschlossen werden.
Hab dies schon mehrmals erfolgreich gemacht.
Bei U-Tube gibts es bestimmt Vorführungen wie dies geht.
Ist dann so keine grosse Arbeit und das originele IC kann in die Platine bleiben.
Also weniger risico für die Platine und das Modul passt ja immer

Nür so eine Idee.

MFG/
Guus

35

CosmosEx, UltraSatan & Co. / Re: SD Karte in UltraSatan Problem

« Letzter Beitrag von anpera am Sa 02.05.2026, 10:57:58 »

Mit dem HDUTIL.PRG von ICDBoot müsstest du Bootinformationen ("Autoboot") schreiben können.

36

CosmosEx, UltraSatan & Co. / Re: SD Karte in UltraSatan Problem

« Letzter Beitrag von fsl_2024 am Sa 02.05.2026, 10:32:57 »

Was passiert wenn Du beim booten die D,E,F... Taste drückst. Dann sollte er von D,E,F... booten.

G muss ich drücken, wenn ich den ST einschalte, dann klappt es wieder mit der Karte und alle Partitionen sind da. Hatte ich anders in Erinnerung.

Ich habe die Treiberdisketten btw. nicht. Das einzige was ich habe ist ICDBoot ... aber nicht den Petari oder den Treiber von Uwe Seimet. FYI.

37

Emulatoren / Re: Wie BeePi Image erstellen

« Letzter Beitrag von Wosch am Fr 01.05.2026, 17:54:52 »

Hab noch nichts gemacht. Da muss ich mich erst einmal damit beschäftigen.
Die mitgelieferten Sachen funktionieren und im Internet war ich auch schon.
Ansonsten schön flott.
Als nächstes steht auf der Agenda:
Wie bekomme ich Programme drauf
Wie kann ich auf meine Synology oder ne andere Netzwerkfestplatte zugreifen.
Könnte ich das System auch auf ne SSD im ext. Gehäuse drauf spielen und bootet der 400er davon.

Mir gefällt das ganze weil es in einem Gehäuse mit Tastatur steckt und der 400er jetzt ne Beschäftigung hat.

Das MagicOnLinux wäre was für den zweiten 400er. Aber ob und wie das geht, keine Ahnung.

Gruß
Wolfgang

38

Emulatoren / Re: Wie BeePi Image erstellen

« Letzter Beitrag von bbisi am Fr 01.05.2026, 17:19:15 »

Und wie läuft der BeePi
Hast du Infos?
Ich habe den auf einem PI5 laufen
Aber letzte Woche auf Linux zurückgegangen

39

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von AndreasKromke am Fr 01.05.2026, 14:02:07 »

Die API ist mir jetzt klar, aber in welcher Reihenfolge liegen nach dem Umwandeln die monochromen planes des Farbbildes nun im Speicher? Dazu habe ich leider keine Information gefunden, die ich verstanden habe, vor allem nicht, ob man beim MSB oder LSB beginnt. Das MVDI macht es anscheinend so, daß das Pixel in Bytes zerlegt wird und dann von Bit 0 nach 7 abgearbeitet wird.

Bei 256 Farben wird dann Bit 0 zu plane 0, Bit 1 plane 1 und Bit 7 zu plane 7.

Bei 16M Farben (OFF16MOV.OSD) wird:

- Bit 0..7 (byte 4) zu plane 24..31,
- Bit 8..15 (byte 3) zu plane 16..23,
- Bit 16..23 (byte 2) zu plane 8..15,
- Bit 24..31 (byte 1) zu plane 0..7.

Das ergäbe doch nur Sinn, wenn das 32-Bit-Pixel als "little endian" interpretiert wird. Oder es ist einfach nur eine Entscheidung gewesen, weil es einfacher zu implementieren war? Seltsam‌.

PS: Es kommt noch ärger: Es scheint, daß bei 32k Farben in big-endian gerechnet wird, d.h. planes 0..7 sind im low-byte, welches an ungerader Adresse liegt, und planes 8..15 im high-byte.

40

Hardware (Classic 16-/32-Bit) / Re: Atari Falcon Reparatur ...

« Letzter Beitrag von kohli79 am Fr 01.05.2026, 13:54:31 »

Mainboard mit gut getestet.

Glückwunsch!