Also bei diesem Anwendungsfall würde ich tatsächlich nichts mit zwei MeanWell-Netzteilen basteln.
Für 3,5"-Festplatten gibt es externe Netzteile, die aussehen wie ein Laptop-Netzteil, aber am einen Ende einen Molex-Stecker mit 12V und 5V haben.
Da braucht man dann nur noch ein Adapterkabel oder neue Stecker.
Das mit der Drehzahl sehe ich ein. Denn das merkt man evtl. gar nicht, wenn man die Diskette im selben Laufwerk beschreibt und liest (Format sollte etwas empfindlicher sein). Also zumindest noch mal die beschriebene Diskette in einem anderen Laufwerk lesen.
Man kann es aber bemerkbar machen, wenn man absichtlich an dem Diskettenformat herumspielt.
Im wesentlichen muss man dabei gucken, wie viel man mit konstanter Datenrate in eine Spur schreiben kann, bevor man den Anfang wieder überschreibt.
Ist die Drehzahl zu hoch, passen ungewöhnlich wenig Daten in die Spur.
Ist die Drehzahl zu niedrig, passen ungewöhnlich viele Daten in die Spur.
Verkohltes Platinenmaterial kann zu einem gewissen Grad leitfähig werden.
Du müsstest also eventuell einmal den Widerstand zwischen zwei Punkten an der schwarzen Stelle messen, um das auszuschließen.
Den Widerstand zwischen der Stelle und VCC bzw. GND, die möglicherweise auf den mittleren Platinenlagen liegen, solltest du auch messen.
Anbei - viel Erfolg beim Re-Engineering
Sieht mir nach einem Embedded Computer aus... inkl. 8051-basierter MCU (SyncMOS)... mit "Standardbeschaltung" ist es da wohl nicht weit her
Dem Anschein nach sind da fette Video-Converter-Chips (leider EOL) mit einem kleinen 8051 für die Initialisierung verbaut.
Mein eigener Ansatz wäre eine Kombination aus einem Composite ADC und einem RGB DAC gewesen, die dann auch einen kleinen µC für die Initialisierung bräuchte.
Okay. Kommt irgendwo ans Ende der kilometerlangen To-Do-Liste.
So, habe jetzt was gefunden - geht miz PAL & NTSC, hat 50/60 Hz Umschalter, RGB + Sync und RGsB Output. Mit RGB + Sync kann ich jetzt direkt in den RGB + Sync / CTM-Eingang reingehen, und brauche nicht mal mehr den LM1881. Der Konverter ist nicht günstig, aber das war es mir jetzt wert. Jetzt kann ich also alles mit meinem CTM machen:
Interessantes Gerät! Könntest du für uns rausfinden, was für Chips das Ding benutzt?
Die Schaltung selbst wird wahrscheinlich kaum über die Standardbeschaltung hinausgehen.
Du solltest den geplatzten RIFA durch einen X2-Entstörkondensator ersetzen. Glücklicherweise hat das Netzteil auch passende Löcher für 15mm Rastermaß, denn die im RM20 bekommt man meistens nur wieder die gleichen RIFAs, die nach einigen Jahrzehnten stinkend den Geist aufgeben - Das kann man seinen Erben ja ersparen
Ehrlich gesagt sehe ich keinen vernünftigen Grund, davon auszugehen, dass RIFA nach vierzig Jahren noch den gleichen bekanntermaßen mangelhaften Kunststoff verwendet.
Vielleicht rauchen in ein paar Jahrzehnten die Entstörkondensatoren einer anderen Marke ab. Hoffentlich aber gar keine.
hat jemand eine Quelle (oder einen Restbestand) für die "Audio Jacks" vom Apple I Cassette Interface (ACI)?
Und zwei MPS3704 bräuchte ich noch
Die billigste Einbaubuchse von Reichelt, die „EB 35“ für derzeit 30 Cent, kommt recht nah dran. Ist die schön genug?
Zum Netzteil, ich habe mir überlegt, das alte Innenleben raus und dann sowas einbauen.
Mir(!) käme sowas als Selbstbastelgerät nicht ins Haus. Gerade wenn man was selbst macht und einen hübschen, alten Rechner damit bewahren möchte, kann man was qualitativ Angemessenes einbauen.
Zumal man für das Geld ein komplettes kompatibles Steckernetzteil kriegt und dann das Original, das schon immer einen fragwürdigen Ruf hatte, nicht mehr anfassen muss.
Da kannst du einfach beim Händler deines Vertrauens einen billigen 8-poligen Mini-DIN-Stecker und einen DE9-Stecker besorgen und basteln.
Alternativ lässt du andere basteln und zahlst entsprechend drauf.
Für die Stromversorgung bietet sich ein Gitarreneffektnetzteil an. Es muss nichts teures sein, weil ja kein Hi-Fi-Zeug dran hängt.
Die Dinger haben die ansonsten heute unübliche Polarität des Hohlsteckers mit innen liegendem Minuspol.
hier fehlen irgenwie die Farben ? Ich probiere weiter, aber vieleicht hat noch jemd eine Idee.
Wenn das VGA-BIOS bei der Initialisierung beim Systemstart auf die Idee kommt, es sei nur ein Schwarzweißmonitor angeschlossen, werden fortan VGA-BIOS-seitig die Paletteneinträge auf Graustufen gesetzt.
Das lässt sich umgehen, indem man die Paletteneinträge am VGA-BIOS vorbei auf Registerebene setzt.
Das ist meine sehr starke Vermutung. Wie das VGA-BIOS auf diese Idee kommen könnte, weiß ich allerdings nicht.
Bezgl. des RGBI Signals mache ich mal ein Bild. Weißt du wo der Baustein auf der Platine sitzt und ob man dafür noch einen Ersatz bekommt?
Laut Schaltplan ist das ein 74LS244 namens U603, den ich in der Nähe des Grafikchips (PVC4, U601) vermuten würde und der immer noch produziert wird.
Das Signal für den FBAS-Ausgang wird zwischen Grafikchip und Treiber mit ein paar Widerständen gebildet und mit einem Transistor verstärkt.
Das würde zu der Beobachtung passen, dass nur der RGBI-Ausgang nicht geht.
Bevor du den Chip auslötest, könntest du aber noch einmal paranoid den DE9-Steckverbinder durchmessen.
Ach ja: Dass beim FBAS-Signal im 80-Spalten-Modus die Farbe nicht zuverlässig durchkommt, ist durchaus CGA-typisch und muss nicht heißen, dass irgendetwas kaputt ist.
P.S.: Ich sehe gerade, dass bei einem der UV-EPROMs auf deinem Board das Päppchen fehlt. Tu da mal Ersatz drauf, bevor dir der Inhalt flöten geht.
Zumindest der Monitor lässt sich als Ursache ausschließen, weil du sonst auch keinen Text sehen würdest.
Demnach kann nur entweder die Software oder die Grafikhardware eine Fehlfunktion haben.
Sind denn alle Grafikmodi betroffen, oder nur bestimmte?
Diverse Software setzt im VGA-Modus 80186-Befehle voraus.
Bei einem VGA-(Verlängerungs-)Kabel, bei dem sich der Strecker öffnen lässt, wird sich sicherlich eine Möglichkeit finden, den Pin 9 herauszuoperieren.
Dann wird aber PAL-FBAS erzeugt, weil ich sehe es zwar schwarz weiß - aber ansonsten ist schon ok.
Nein. Eben gerade nicht.
PAL ist nur die Farbnorm. Mit der Zeilenzahl und der Vertikalfrequenz hat das im Grunde nichts zu tun, auch wenn es im praktischen Einsatz starke Korrelationen gibt. Der europäische 1084 ist flexibel genug, um die allgemein mit NTSC assoziierten Timings zu unterstützen, unterstützt aber das eigentliche NTSC-Signal (d.h. die Farbinformationen) nicht.
Die Streifenmuster / Probleme habe ich mit dem RGBI Signal
Wie sehen denn die Streifenmuster aus? Hast du mal ein Bild von dem Bild?
Vielleicht hat der Treiberbaustein (meist 74LS244 oder 74LS245) einen weg.
Mir ist dann nur völlig unverständlich warum der 1084 bei VGA an Composite über einen Adapter Farben anzeigt, bei direktem Composite Anschluss an den PC aber nicht.
Das Rätsel kann ich auflösen:
Der 1084 kann zwar 50Hz und 60Hz, aber nur genau dann das aus der CGA-Karte kommende FBAS-Signal in Farbe anzeigen, wenn es sich bei dem 1084 um ein amerikanisches Modell mit NTSC-Decoder-Chip handelt. Europäische Modelle haben stattdessen einen PAL-Decoder. Der sieht in einem NTSC-FBAS-Signal nur ein Schwarzweißbild mit lustigen Streifenmustern.
Ich habe mir um das näher untersuchen zu können daher ein Multi-Messgerät gekauft, das misst auch fröhlich, allerdings ist mir nicht ganz klar wie ich es benutzen sollte. Muss ich zu jedem Teil herausfinden, was z.B die eigentliche Ladekapazität oder Widerstand sein sollte und es dann entsprechend mit der Messung abgleichen?
Im verbauten Zustand kann man die Komponenten kaum sinnvoll durchmessen, weil meist andere Komponenten in der Schaltung die Messung verfälschen.
Ggf. könntest du aber die Synchronpulse im Bildsignal messen. Idealerweise mit Logikanalysator oder Oszilloskop, aber mit Widerständen und einer Soundkarte sollte es notfalls auch gehen.
Ein kurzer Blick in die Funktionsbeschreibung lässt mich sehr stark vermuten, dass sich MMU und IOU jeweils mit ein bis zwei GALs nachbilden lassen.
Soll der Rechner SRAM benutzen, ist sowieso ein neues Platinenlayout vonnöten, also sollte die Unterbringung der GALs kein Problem sein.
Bezüglich des Gehäuses bleibe ich dabei, dass ein Holzgehäuse wahrscheinlich am praktikabelsten ist. Für eine „Bausatz-Apfelkiste“ wäre es auch durchaus stilecht.
Bei einer FPGA-basierten Lösung empfehle ich einen Blick in Richtung MiSTer FPGA und das darauf aufbauende MiSTer Multisystem.
Ob nun dafür oder für einem kompatiblen Nachbau mit Logik-Chips, EPROM und SRAM könnte man auf jeden Fall recht leicht ein Sperrholzgehäuse bauen.
Tastaturschalter und Tastenkappen sind auch nicht das Problem.
Es ist natürlich möglich, daß im code des int21 gar nicht der befehl des Schreibens der Bytes in den Speicher stattfindet, sondern "außerhalb", in tieferen BIOS-Schichten. Wenn das so ist habe ich mit meinem Ansatz Pech gehabt. Ich glaube aber vorerst, daß das nicht so ist. Der Grund ist, daß das das Schichtenmodell untergraben würde: Anwendungsprogramm <-> Dos <-> Bios/Hardware. Man wird sehen.
Wie bereits zuvor erwähnt, kann das überhaupt nur funktionieren, wenn der Transfer vom Disketten-/Festplattencontroller in den RAM nicht per DMA erfolgt, was aber eigentlich die effizientere und bei PCs übliche Variante ist.
Grund: Was auf seinem Weg in den RAM niemals in CPU-Registern landet, kann man auch nicht „vor dem Zurückschreiben“ bearbeiten.
Hier wäre also die Frage, ob du die Zielarchitektur gut genug kennst, um das ausschließen zu können. Ansonsten verbrätst du eventuell viel Zeit für nichts.
Zu 99% wird das einfach eine Kopie, vor dem Befehl das Byte in den RAM zu schreiben kommt bei mir aber noch die gewünschte Änderung des Wertes und dann erst das mov es:[di],al oder stosb. Auf diesem Weg erspare ich mir das höchst zeitaufwändige nochmalige Einlesen vom RAM in die CPU, Änderung des Wertes, Zurückschreiben ins RAM.
Was spricht gegen ein gewöhnliches Lesen mit anschließendem Ersetzen mit z.B. folgendem Code und passender Tabelle für xlatb?
transform:
shr cx,1
jc odd
l1: lodsb
xlatb
stosb
odd: lodsb
xlatb
stosb
loop l1Das ist nicht einmal auf einem 8088 langsam. Der Flaschenhals dürfte eher der Massenspeicher sein.
Hintergrund: Ich möchte in TurboPascal einen Ersatz für die blockread(params....) Prozedur schreiben, welcher eine Datei einliest, deren Bytes bevor sie noch im RAM landen aber on-the-fly verändert TPs original blockread() ruft dazu den int21 Unterfunktion 3FH auf.
Soweit ich weiß befördert das BIOS die Daten vom Festplatten- oder Diskettencontroller per DMA-Transfer an der CPU vorbei direkt in den RAM.
Folglich wird es sich gar nicht vermeiden lassen, zum Ersetzen einzelner Byte-Werte noch einmal über den Block zu iterieren.
Vorschlag von meiner Seite:
Lass den Quatsch mit dem Disassemblieren und versuche stattdessen, die Schleife zum Ersetzen der Werte bestmöglich zu optimieren.
Zum Nachbearbeiten von Scans ist ggf. das Kommandozeilenwerkzeug unpaper einen Blick wert.
Die Funktionen davon beinhalten z.B. das Zentrieren des erkannten Inhalts auf weißem Hintergrund, Entfernung kleiner Fleckchen etc.
Es kann auch Scans begradigen. Die Funktion ist aber nicht sehr zuverlässig.
Meist muss außerdem erst einmal der Kontrast stimmen, damit unpaper halbwegs brauchbare Ergebnisse liefert.
Für Konsolenlaufwerke gibt’s oft noch Ersatz-Dioden, da die Laufwerke über ihre Firmware an das Gerät gebunden sind und nicht gegen x-beliebige Alternativen getauscht werden können. Mit Glück passt eine solche Diode auch im PC. Die Frage ist nur, ob sich die Ersatzteile lohnen. Gibt’s nicht vielleicht ein Gotek für IDE-CD/DVD-Laufwerke?
Es gibt auf jeden Fall SATA-zu-PATA-Adapter, mit denen man ein neues Laufwerk anschließen kann.
Bei Hardware-Emulatoren bewegt sich diesem VOGONS-Thread nach zu urteilen auch langsam etwas.
Ich frage mich gerade, ob man für diesen Anwendungsfall einen Satz Peephole-Optimizer-Regeln für den SDCC schreiben könnte.
Dann könnte man im C-Quelltext 8080-Funktionen einbinden, die dann von diesem Regelsatz zunächst in Z80-Syntax umgewandelt und anschließend von den normalen Optimizer-Regeln des Z80-Backends in effizienteren Z80-Code umgewandelt werden.
Für einen Commodore 1084 aus dem Hause Philips habe ich auch seit ein paar Jahren ein umgebautes Seriell-Kabel mit achtpoligem DIN-Stecker (kreisrund, nicht Hufeisen) im Einsatz.
Läuft bei mir mal an einer CGA-Karte, mal an einer EGA-Karte im 200-Zeilen-Modus.
Korrektor: Die PLL-Parameter sind M=117, N=6 und R=1. Die Parameter von oben würden rechnerisch auch den korrekten Takt ergeben, aber für ein Zwischenergebnis eine einschränkende Bedingung im Datenbuch verletzen.
Da bei mir der besagte Button immer noch ausgegraut ist, kann ich leider auch nicht die Timing-Werte eintragen...
Wenn es keine kompatiblen Tools gibt, bleibt wohl nur Frickeln.
Ok, wir sprechen von einer älteren Grafikkarte (ca. 1995) und Windows 98 (SE). Denke daran habt Ihr gar nicht gedacht.
Zu dem Zeitpunkt (also ca. 1998-1999) gab es noch keine Wide-Screen Monitore.
Doch, doch. Die weitgehende Nichtexistenz von Breitbildformaten bei PCs interessiert aber die Taktgeneratoren der Grafikkarte nicht.
Inzwischen habe ich mein „über den Daumen gepeilt“ etwas präzisieren können. Dies sind die Timings für die VESA-Modi mit 1280x1024 und 1440x900 Pixeln bei je 60 Hertz:
http://www.tinyvga.com/vga-timing/1280x1024@60Hz
http://www.tinyvga.com/vga-timing/1440x900@60Hz
Wie man sieht, weicht der Pixeltakt um knapp 1,5% ab. Entweder kann man das über geeignete PLL-Parameter kompensieren oder man muss mit der Abweichung leben und die Gesamtbreite anpassen, damit die übrigen Timings wieder stimmen.
Ich hatte schon einmal den Plan geschmiedet, einer S3 Trio64V+ unter DOS durch Programmierung auf Registerebene einen 1360x768-Pixel-HighColor-Modus zu entlocken, der so gerade in den VRAM passt, bin aber bislang noch nicht dazu gekommen.
Nachtrag:
Mit den PLL-Parametern M=117, N=14 und R=0 kommt man bei einem Referenztakt von 14,31818 MHz auf einen Videotakt von 106,49 MHz, der an den 106,47 MHz aus der Tabelle sehr nah dran ist. Damit sollte die Hardware dem 1440x900-Pixel-Modus nicht im Wege stehen.
Also über den Daumen gepeilt sollte die Karte zu einer Auflösung von 1440x900 Pixeln bei 60 Hz fähig sein und eine Trio64 mit 4 MiB VRAM sollte das auch in TrueColor können.
Hier wirst du aber den passenden Treiber für die Auflösung selber schreiben bzw. modden müssen. Immerhin sollten die notwendigen Informationen aus dem Handbuch hervorgehen, wodurch es prinzipiell machbar ist.
Bei so einem einzelnen Loch wäre ich da viel zu faul für und würde einfach einen dieser runden „Q.C. passed“-Aufkleber drauf machen.
Noch besser: „warranty void if removed“. Wetten, keiner merkt 's?
?!
Selbstverständlich nicht für den Weiterverkauf bestimmt.
Für die private Sammlung ist das Konzept „Mackenaufkleber“ aber oft die mit Abstand einfachste Lösung.
Ich würde da was 3D-drucken und mit einem kleinen Tupfer halbwegs passender Farbe schmücken.
Hab sowas an einem 64ger gemacht, um das Loch eines Schalters zu schließen:
Bei so einem einzelnen Loch wäre ich da viel zu faul für und würde einfach einen dieser runden „Q.C. passed“-Aufkleber drauf machen.
Noch besser: „warranty void if removed“. Wetten, keiner merkt 's? 
