Neueste Beiträge

Seiten: 1 2 3 [4] 5 6 ... 10
31
Hardware (Classic 16-/32-Bit) / Atari Falcon Instandsetzung ...
« Letzter Beitrag von Lukas Frank am Mi 29.04.2026, 17:34:37 »
Habe ein defektes Atari Falcon Mainboard bekommen und mache erstmal alles sauber und baue es auf original Zustand zurück und schaue dann was das Problem ist ...
32
Hardware (Classic 16-/32-Bit) / Re: STE - Video Problem - vertikale Streifen
« Letzter Beitrag von rolandDos am Mi 29.04.2026, 12:19:34 »
Hallo Zusammen,

So heute kommt mein neuer SideCar VGA adapter, mal sehen ob das Bild damit besser wird - bin gespannt bzw. denke mal, dass es das Problem generell nicht beheben wird bzw. das Bild nur etwas "glattbügelt" wird.

@GT76 - Danke für den Hinweis. Hmm das Bild Ork :-) sieht schon ganz anders aus als meines, ist echt ein ne ganz andere Nummer, klasse.

Klar der Mod geht an die Ursache ran.
Interessant wäre jetzt noch, wie das Bild vor dem Mod ausgesehen hat.
Hattest du auch diese vertikalen Linien?

Wenn ja, dann liegt es an wohl am Design bzw. daran, was zwischen Shifter und RGB-Buchse (Videopfad) so passiert.

Meinst du diese Anleitung - bräuchte die STE Variante? Wo gibts dann das Board zu kaufen?
https://blog.jokielowie.com/en/blog/atari-st-ste-modyfikacja-sprzetowa-perfekcyjne-wyjscie-obrazu-hdmi-dzieki-projektowi-rgbtohdmi-oraz-raspberry-pi-zero

Hmm also Löten kann ich, wenn ich die Anleitung so durchgehe, dann ist mir aber nicht sooo wohl dabei - über ungeschirmte Litzendrähte das Signal abgreifen etc.
Dann noch das Thema - wie bekomme ich die Schalter und HDMI Buchse nach außen ohne ein Loch ins Gehäuse zu bohren. 
Wenn ich das richtig gesehen habe, hast du das TV Modul entfernt und dann die Kabel nach Außen geführt?

Vg
Roland
33
Hardware (Classic 16-/32-Bit) / Re: STE - Video Problem - vertikale Streifen
« Letzter Beitrag von GT76 am Di 28.04.2026, 21:11:00 »
@rolandDos
Ich bin sehr zufrieden mit dem rgb2hdmi in meinem STE. Wenn du löten kannst, sollte der Einbau kein Problem sein.


34
Hardware (Classic 16-/32-Bit) / Re: Neues Suska Board
« Letzter Beitrag von udo am Di 28.04.2026, 11:43:25 »
Um den Atmega zu aktualisieren brauchst Du einen Atmega-ISP.
Ich verwende seit Jahrzehnten dafür einen Original AVR-ISP-MK2. Inzwischen gibt es davon Clones, die sicher genauso funktionieren. Angeschlossen wird er an der 6 poligen AVR-ISP-Buchse.

Beim Download aufpassen, daß Du auch das RAW-File lädst. Am besten die MD5-Summe prüfen.
Hier ist ein Log wie das Fashen bei mir aussieht:

udo@LABPC ~
$ curl https://raw.githubusercontent.com/umatthe/suska4/refs/heads/main/Firmware/system-bf.hex -o system-bf.hex
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100 129.5k 100 129.5k   0      0 324.9k      0                              0

udo@LABPC ~
$ md5sum ./system-bf.hex                                                        467d89d903db93e15de652836f81ee64 *./system-bf.hex

udo@LABPC ~
$ avrdude -c avrispmkII -p m649 -U f:w:./system-bf.hex -P usb -F
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0xffffff
avrdude.exe: Yikes!  Invalid device signature.
avrdude.exe: Expected signature for ATMEGA649 is 1E 96 03
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "./system-bf.hex"
avrdude.exe: input file ./system-bf.hex auto detected as Intel Hex
avrdude.exe: writing flash (63488 bytes):

Writing | ################################################## | 100% 3.24s

avrdude.exe: 63488 bytes of flash written
avrdude.exe: verifying flash memory against ./system-bf.hex:
avrdude.exe: load data flash data from input file ./system-bf.hex:
avrdude.exe: input file ./system-bf.hex auto detected as Intel Hex
avrdude.exe: input file ./system-bf.hex contains 63488 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 4.15s

avrdude.exe: verifying ...
avrdude.exe: 63488 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.


Danach sollte der Befehl info in etwa so aussehen:
BF fpga-shell:> info
raw Input Voltage: 0359
Input Voltage: 5.25V
ATMEGA-Version: 20260302
Boot image id: f
Boot App Version: 0
FPGA-Coretype: 07 30 (Suska-III/IV-B* FALCON WF68K30)
FPGA-Version: 20260409

35
Coding / Re: vr_trnfm() - Beispiel?
« Letzter Beitrag von AndreasKromke am Mo 27.04.2026, 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.
36
Hardware (Classic 16-/32-Bit) / Re: Neues Suska Board
« Letzter Beitrag von mcknopf am Mo 27.04.2026, 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.
37
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.
38
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.)

Zitat
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
39
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.  :)
40
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).
Seiten: 1 2 3 [4] 5 6 ... 10