Neueste Beiträge

1

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von AndreasKromke am Gestern um 21:19:55 »

Ich habe mein Testprogramm korrigiert und ein paar Tests mit vr_trnfm() gemacht. Das ist alles etwas seltsam:

• In jedem Farbmodus kann MVDI seinen eigenen Modus und monochrome Bitmaps konvertieren.
• Bei 16 Farben (interleaved) kann er auch 2 oder 7 planes konvertieren.
• Bei 4 Farben (interleaved) kann er auch 4 oder 7 planes konvertieren.
• Bei 2 Farben (monochrom) kann er auch 2, 4 oder 7 planes konvertieren.
• EmuTOS kann bei 256 Farben auch 2, 4 oder 7 planes konvertieren.

Fazit: Vermutlich haben EmuTOS und die MVDI-Interleaved-Colour-Treiber eine universale Funktion, die mit jeder Anzahl von "planes" umgehen kann, während die MVDI-Packed-Pixel-Treiber nur monochrom und ihre eigene Auflösung können. Ob das alles so richtig ist...

PS: Ich habe nur getestet, ob etwas rauskommt, nicht, ob es korrekt ist. Wie man "inplace" umrechnen kann, ist mir eh ein Rätsel.

2

Hardware (Classic 16-/32-Bit) / Re: Neues Suska Board

« Letzter Beitrag von mcknopf am Gestern um 19:14:02 »

Ich nehme an beim Starten der Suska müsste nach Firmware Update ATMEGA ein aktuelles Datum von 2026 anzeigen? Demnach hat das Update bei mir nicht geklappt. Muss das UART Kabel woanders als bei AVR-Debug eingesteckt werden? Die system-bf.hex Datei ist bei mir im Download Ordner, ist da noch was zu beachten? (Wähle mit cd Downloads vorher den Ordner).

Avrdude gibt immer „avrdude done. Thank you“ aus, also keine Fehlermeldung, daher sehe ich Erfolg/Misserfolg immer erst wenn ich danach das Terminal starte.

f-erase 31 führt zur Fehlermeldung

„31 out of range (0..15), daher nehme ich da auch an, dass die Firmware nicht aktualisiert wurde.

3

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von AndreasKromke am So 26.04.2026, 19:24:37 »

Du hast recht, bei DRI ist es noch am besten erklärt. Da war ich wohl durch meine falsche Grundannahme blind geworden.

Aber hier [https://freemint.github.io/tos.hyp/en/vdi_structures.html#MFDB] (Width of a line in words) ist es dann stumpf falsch. Außerdem darf fd_addr nicht NULL sein. Das ist auch falsch dokumentiert. Die NULL ist nur bei den Kopier-Aktionen erlaubt. Und alle Felder im dstMFDB außer fd_addr werden ignoriert. Das ist auch falsch oder unzureichend dokumentiert. Die Funktion füllt dann nur fd_stand aus und läßt alle anderen Felder von dstMFDB unverändert. Das sehe ich auch nicht ausreichend dokumentiert.

4

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von czietz am So 26.04.2026, 18:16:22 »

Wo ist die VDI-Doku von DR denn falsch? Es ist etwas umständlich formuliert, aber im Wesentlichen steht da ja: fd_wdwidth = fd_w / 16. ("word size" ist 16, das ist anderswo definiert.)

The width of the raster area in words. This value is equal to the width of the raster area in pixels, divided by the word size

5

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von AndreasKromke am So 26.04.2026, 17:42:05 »

Aus der Erinnerung: "fd_wdwidth" ist die Länge in WORDs je Plane!.

Siehe auch das u.s. Beispiel aus dem Profibuch. (Beachte, wie die Zahl der Planes nicht in die Berechnung von fd_wdwidth eingeht).

Danke! In der Zwischenzeit hatte ich auch die Idee, das mal so auszuprobieren.

Ich hatte sogar ins Profibuch geschaut, aber das Beispiel übersehen. Sehr seltsam. In sämtlichen Dokumentationen steht es dann falsch; alle scheinen von der falschen Original-Dokumentation von DRI abgeschrieben zu haben, auch der TOS-Hypertext, quasi der Koran der Atari-Gläubigen. Vielleicht kann man das mal korrigieren, ist ja in github. Aber vorher probiere ich es aus. 

6

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von czietz am So 26.04.2026, 13:52:47 »

Aus der Erinnerung: "fd_wdwidth" ist die Länge in WORDs je Plane!.

Siehe auch das u.s. Beispiel aus dem Profibuch. (Beachte, wie die Zahl der Planes nicht in die Berechnung von fd_wdwidth eingeht).

7

Coding / Re: vr_trnfm() - Beispiel?

« Letzter Beitrag von thh am So 26.04.2026, 13:43:15 »

Moin! Wenn ich mich richtig erinnere (ist schon ziemlich lange her...), kannst du vr_trnfm() nicht direkt für True-Color benutzen. Schau mal in die Sourcen von STune (https://github.com/ggnkua/Atari_ST_Sources/tree/master/C/Thomas%20Huth/STune - die Dateien th_init.c und loadimg.c) oder Fanwor (https://fanwor.tuxfamily.org/), da gibt's Funktionen wie loadpic2true() und transform_truecolor(), die dir weiterhelfen könnten.

8

Coding / vr_trnfm() - Beispiel?

« Letzter Beitrag von AndreasKromke am So 26.04.2026, 12:42:26 »

Es treibt mich zum Wahnsinn ...   

Ich experimentiere gerade mit vr_trnfm() herum, aber alle meine Beispiele führen zum Absturz.
Beispielsweise bei 32 Bit Farbtiefe (true colour). Der Block habe 10x7 Pixel. Ich setze für srcMFDB:

 fd_w = 10
 fd_h = 7
 fd_nplanes = 32
 fd_wdwith = 20 (10 Pixel à 4 Bytes macht 40 Bytes macht 20 16-Bit-Werte)
 fd_stand = 0 oder 1 (habe beides probiert)

(allgemein: srcMFDB.fd_wdwidth = (srcMFDB.fd_w * srcMFDB.fd_nplanes + 15) / 16);

Beim destMFDB wird anscheinend alles ignoriert außer fd_addr. Trotzdem habe ich ausprobiert, die Felder identisch mit denen von srcMFDB zu setzen, ohne Erfolg.

Bisher stürzt nur monochrom->monochrom nicht ab. Geht in allen Farbmodi. Gebe ich eine unübliche Farbtiefe an, also 7, wird das in manchen Grafikmodi ignoriert, bei anderen stürzt das Programm ab. Die Farbkonvertierung habe ich in keinem der sieben getesteten Bildschirm-Modi hingekriegt, immer nur Abstürze, in beide Richtungen (Standard nach gerätespezifisch und andersrum).

Ich habe eine Suche in github gemacht, aber hier habe ich nur im Vision-Quelltext einen Schnipsel gefunden, der ist aber so ad hoc nicht verständlich.

Hat das je funktioniert? Was habe ich übersehen?

PS: Testprogramm liegt jetzt in [https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources/-/tree/master/MagiC/TEST/TESTS/VDITEST/TRNFM]. Ist nicht aufgeräumt, nur "quick and dirty".

PS/2: Mit Hatari, TT-Emulation, 256 Farben (extended VDI) gibt es die gleichen Abstürze. Der destMFDB wird kaputtgeschrieben, es steht nur noch Grütze drin, und es gibt einen Busfehler.

9

Biete / Re: Monitor SM124

« Letzter Beitrag von thomas am Sa 25.04.2026, 21:19:14 »

vergeben

10

Emulatoren / Re: AtariX => MagicOnLinux

« Letzter Beitrag von AndreasKromke am Sa 25.04.2026, 12:19:41 »

Also wenn das kein kapitaler Fehler ist, was dann?

Hier fehlte eine Registerzuweisung, wodurch bei der Ausgabe von Polygonen, Ellipsen etc. mit nutzerdefiniertem, farbigem Füllmuster in die Pampa geschrieben wurde, mit der Folge eines totalen Systemabsturzes. Da hat offenbar die QS völlig versagt, wenn sie denn überhaupt existiert hätte. Ich nehme an, daß so ein Fall in der Praxis äußerst selten vorkommt. Meist zeichnet man eh Rechtecke, und ein farbiges Füllmuster müßte man auch immer auf die Farbtiefe des Bildschirms abstimmen. Macht vermutlich niemand.

Fun fact: Ich habe mal einen Blick in fvdi geworfen. Hier habe ich keinen Code gefunden, der die Bit-Tiefe des nutzerdefinierten Füllmusters abfragt. Das sieht für mich so aus, als ob fvdi überhaupt nur monochrome Füllmuster kann. Ich habe aber nicht nachgeschaut, was fvdi macht, wenn ein Programm versucht, ein farbiges Füllmuster zu setzen. Im besten Fall gäbe es einen Fehlercode zurück, im mittelguten Fall würde fvdi nur 32 Bytes des Musters kopieren und es als "monochrom" fehlinterpretieren, und im schlechten Fall geht irgendetwas fundamental schief.