1
Biete / Re: Monitor SM124
« Letzter Beitrag von thomas am Gestern um 21:19:14 »vergeben
Neueste Beiträge
2
Emulatoren / Re: AtariX => MagicOnLinux
« Letzter Beitrag von AndreasKromke am Gestern um 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.
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.
3
Biete / Monitor SM124
« Letzter Beitrag von thomas am Gestern um 12:02:20 »Biete hier diesen funktionierenden Monitor an. Er soll 20 Euro kosten, der Versand ist bereits enthalten. :-)
4
Hardware (Classic 16-/32-Bit) / Re: MEGA ST C100501 / Floppy spinnt
« Letzter Beitrag von Lukas Frank am Gestern um 11:04:24 »... persönlich würde ich erstmal via Ohmmeter suchen.
Scheint auch immer etwas anders zu sein im Fehlerbild also schlechte Lötstellen vielleicht oder auch schlechte PLCC Sockel Kontakte.
Scheint auch immer etwas anders zu sein im Fehlerbild also schlechte Lötstellen vielleicht oder auch schlechte PLCC Sockel Kontakte.
5
Hardware (Classic 16-/32-Bit) / Re: MEGA ST C100501 / Floppy spinnt
« Letzter Beitrag von damien996699 am Gestern um 09:52:53 »Kommen denn die Steuersignale RDAT, WDAT, LATCH von der MMU bei den Bus-Treibern an? Kommen RAS0 und CAS0x bei den RAMs an?
Ohmisch gemessen, ja kommen alle an
RAS0 & CAS0 zeigen an den RAMs per Oscar "Leben"
Ohmisch gemessen, ja kommen alle an
RAS0 & CAS0 zeigen an den RAMs per Oscar "Leben"
6
Emulatoren / Re: AtariX => MagicOnLinux
« Letzter Beitrag von AndreasKromke am Fr 24.04.2026, 19:09:51 »Das Grafiktreiberdrama nimmt kein Ende: Nur (!) im True-Colour-Modus führt das Zeichnen von Polygonen mit nutzerdefiniertem Farb-Füllmuster bei Ellipsen zu einer leeren Ellipse, bei Dreiecken zum totalen Systemabsturz. Man braucht nur das uralte Testprogramm VDITEST\POLYGON\OPLYGON.PRG auszuführen, und dann -- Bumms.
Da liegt ja anscheinend noch einiges im argen...
Da liegt ja anscheinend noch einiges im argen...
7
Hardware / Re: Defekte Apple Quadra 700 ...
« Letzter Beitrag von dbsys am Fr 24.04.2026, 09:36:31 »Schaut doch schon ganz gut aus.
8
Hardware (Classic 16-/32-Bit) / Re: MEGA ST C100501 / Floppy spinnt
« Letzter Beitrag von czietz am Do 23.04.2026, 22:00:44 »I2 RAM disturbance 0000000000000000 1111111111111111 000008
... heißt ja, dass alle Bits, obwohl sie 0 sein sollen, 1 sind. Also, ja, da funktioniert etwas Grundlegendes mit dem RAM nicht. Kommen denn die Steuersignale RDAT, WDAT, LATCH von der MMU bei den Bus-Treibern an? Kommen RAS0 und CAS0x bei den RAMs an?
... heißt ja, dass alle Bits, obwohl sie 0 sein sollen, 1 sind. Also, ja, da funktioniert etwas Grundlegendes mit dem RAM nicht. Kommen denn die Steuersignale RDAT, WDAT, LATCH von der MMU bei den Bus-Treibern an? Kommen RAS0 und CAS0x bei den RAMs an?
9
Hardware (Classic 16-/32-Bit) / Re: MEGA ST C100501 / Floppy spinnt
« Letzter Beitrag von damien996699 am Do 23.04.2026, 21:30:12 »Frage an die Spezialisten bzgl. Diag-ROM Auswertung, siehe Anhang.
Geht doch in Richtung D3 Ram, oder ?
Geht doch in Richtung D3 Ram, oder ?
10
Hardware (Classic 16-/32-Bit) / Re: STE - Video Problem - vertikale Streifen
« Letzter Beitrag von anpera am Do 23.04.2026, 20:49:42 »Zitat von: rolandDos
Wenn ich das jetzt richtig interpretiere, sind diese Streifen generell bei nicht modifizierten STFM und STE-Modellen vorhanden und dann wieder unterschiedlich ausgeprägt.Es betrifft auch STF. Aber ja, in unterschiedlichen Ausprägungen. Mein STF mit 2MB Speichererweiterung hat vertikale Streifen nur im Grün-Signal, und dort je heller umso stärker. Da gibts auch keine Chance, es über Einstellungen am Monitor rauszuregeln. Müsste mal schauen, ob das an der Speicherweiterung, einer Verbindung zum Shifter, oder an gealterten Komponenten im Analogteil nach dem Shifter liegt.
Zitat von: rolandDos
Da dein generalüberholter STFM keinerlei Streifen aufweist, könnte es dann wohl an einer der Modifikationen liegen.Entweder das, oder an ersetzten Komponenten. Oder beides.
Die 4MB-Speichererweiterung von Exxos kommt mit einer Adapterplatine für den Shifter. Da ist noch irgendeine Zusatzschaltung mit drauf, die dafür verantwortlich sein könnte.
Der Original-RAM wurde entfernt. Ich gehe weiter davon aus, dass in dem Gerät ordentlich recapt wurde, und auch am Netzteil das eine oder andere gemacht wurde. Die Platine sieht aus wie geleckt. Genau wie das eindeutig ge-RetroBright-ete Gehäuse.
Zitat von: rolandDos
Dieser Adapter hat wohl noch ein paar mehr Filter onboardHilfreich wäre wohl schon so eine Art Bewertungs-Tabelle für den AD-Wandler, damit er nicht pro Pixel aus über 16 Millionen Farben auswählt, sondern nur die möglichen Palettenfarben der ST(E)s zur Verfügung hätte. Der OSSC bietet sowas wohl in einer Funktion namens "Lumacode". Leider scheinbar nur für 8-Bit-Systeme wie C64, Spectrum, Coleco, MSX, NES und Atari 400/800/2600/5200. Müsste mich mal damit beschäftigen, ob und wie man das für den ST nutzen kann. STE dürfte noch mal eine Stufe schwieriger sein.
Würde mich interessieren, was der Sidecar-Adapter zu bieten hat
Zitat von: rolandDos
Insgesamt wäre es natürlich sehr interessant, wie man den STE intern so modifizieren kann, damit keine externen Lösungen von Nöten sind.Wenn es "nur" darum geht, ein sauberes analoges Ausgangssignal zu bekommen, wird das wohl nur über den Austausch von Komponenten gelingen. Wenn du einen HDMI-Anschluss am STE haben willst, kannst du mal die Suche hier im Forum quälen. Zumindest für STs gibt es einige interessante Ansätze. Bei dem 2. erwähnten STFM hab ich einen OSSC ins Gehäuse dazu geworfen. Die Streifen hat der - wie erwähnt - halt trotzdem auch.