MUPID (österreichischer BTX-Computer)

Quote from gpospi

... war die Drehzahl falsch (nur 297 rpm) ...

Leider habe ich aber offenbar beim Kryoflux ein Problem mit dem zehnten Sektor, da entstehen beim Schreiben immer CRC Fehler...

Habt Ihr vielleicht Erfahrung mit sowas bzw. eine Vermutung zur Fehlerursache? Im Prinzip schaut es für mich nach einem Timing-Problem aus, sodass der CRC nicht mehr korrekt vor dem "Index Gap" abgeschlossen werden kann. Muss mir das Ganze wohl zum Vergleich mal mit FluxCopy/FluxTeen vornehmen...

Mit welcher Drehzahl arbeitest Du jetzt genau?

Der Fehler könnte eventuell auftreten, wenn die Disk zu schnell dreht und der letzte Sektor übers Indexloch hinaus geht.

Sind überhaupt die Daten in der Kryoflux-Datei vollständig? Könnte ja sein,. dass bereits dort die Daten des 10 Sektors teilweise überschrieben sind. Könnte man in den raw-Dateien nachsehen.

PAW

Ich habe sowohl mit QD/300rpm und HD/360rpm Laufwerken getestet. Die echte Drehzahl entspricht jeweils exakt der Vorgabe.

Im ursprünglichen Image (Imagedisk/Teledisk) sind alle Daten vorhanden und fehlerfrei. Das konvertiere ich mit dem HxD Tool ins Kryoflux RAW Format. Ich werde das gleich nochmal checken, sollte aber auch korrekt sein.

So, gerade nochmals geprüft: Das Standard-Kryoflux-Laufwerk ist ein HD mit nominell 360rpm und real 360.87rpm.

Das Quell-Image sieht so aus:

Das Resultat nach dem Schreiben und Zurücklesen:

Das Image ist für 300rpm/250kbps vorgesehen, sollte aber automatisch angepasst werden. Ich werde es nun nochmals explizit auf 360rpm/300kbps konvertieren und meinen Versuch wiederholen.

Quote from gpospi

Im ursprünglichen Image (Imagedisk/Teledisk) sind alle Daten vorhanden und fehlerfrei. Das konvertiere ich mit dem HxD Tool ins Kryoflux RAW Format. Ich werde das gleich nochmal checken, sollte aber auch korrekt sein.

Dem kann ich zustimmen: "Im ursprünglichen Image (Imagedisk/Teledisk) sind alle Daten vorhanden und fehlerfrei."

Ich habe dann ebenfalls die Daten mit HxC auf RAW-Dateien konvertiert und diese dann mit FLUXKRYOCONV auf FLX-FLUXCOPY-Dateien umgewandelt. Beim Schreiben dieser Dateien mittels FLUXCOPY auf eine DD-Disk (PC HD-Laufwerk) und Wiedereinlesen gab es die gleichen Probleme die gpospi von Kryoflux berichtet hatte. Der letzte Sektor jeder Spur war defekt.

Daraufhin habe ich die FLX-Dateien näher untersucht. Dabei kam Folgendes heraus:

Berücksichtigt man die Durchlaufzeiten des Indexloches kommt man auf eine Drehzahl von 304.0646 rpm, entspricht 197,3265 mSec. Dies wäre noch im möglichen Bereich.

Beim Zusammenzählen aller Zeiten der Fluxwechsel kommt man jedoch auf 199,8356 mSec.

Hier wird klar, dass sich die Daten bei einem Umlauf nicht ausgehen und am Ende des letzten Sektors abgeschnitten werden. Dies ist auch klar beim Dump der wieder eingelesenen Daten zu erkennen.

Hier die Quelle zum Schreiben:

=== Track: 1  Side(1/2): 1  Sector: 9/10  SecLeng: 256   CRC-OK

37 45 46 45 32 30 32 33 32 38 30 41 43 35 43 44    |7EFE2023280AC5CD|
43 36 30 31 43 31 31 30 46 33 32 33 32 33 43 39    |C601C110F32323C9|
33 45 32 30 43 35 43 44 43 36 30 31 43 31 31 30    |3E20C5CDC601C110|
46 37 32 33 32 33 43 39 32 41 45 41 30 31 43 44    |F72323C92AEA01CD|
34 37 42 31 32 33 32 33 30 31 30 41 30 30 37 45    |47B12323010A007E|
42 37 32 38 30 39 43 44 34 37 42 31 34 36 32 33    |B72809CD47B14623|
34 45 32 33 31 38 46 33 37 38 45 36 30 33 36 37    |4E2318F378E60367|
36 39 37 38 30 46 30 46 45 36 33 46 34 46 30 36    |69780F0FE63F4F06|
30 30 30 39 32 42 43 39 32 31 34 31 42 32 43 44    |00092BC92141B2CD|
46 36 30 31 43 39 30 36 30 43 37 45 46 45 32 30    |F601C9060C7EFE20|
32 33 43 38 31 30 46 39 43 39 32 41 30 38 30 32    |23C810F9C92A0802|
43 44 34 37 42 31 37 38 42 37 43 38 32 42 32 42    |CD47B178B7C82B2B|
37 45 45 36 46 30 46 45 33 30 43 30 32 33 33 36    |7EE6F0FE30C02336|
36 31 43 39 31 46 32 46 34 30 35 38 31 38 35 33    |61C91F2F40581853|
30 38 32 30 30 38 38 32 35 33 37 34 36 31 37 34    |0820088253746174|
37 35 37 33 33 41 31 42 34 31 34 34 31 42 34 32    |75733A1B41441B42|

Hier der ReRead (Siehe letzte Zeile, die letzten 4 Bytes sind unterschiedlich!):

=== Track: 1  Side(1/2): 1  Sector: 9/10  SecLeng: 256   CRC-OK
>>>CRC-ERROR in DATA<<<   CRC received (hex): FFFF   CRC calc (hex): BAB9

37 45 46 45 32 30 32 33 32 38 30 41 43 35 43 44    |7EFE2023280AC5CD|
43 36 30 31 43 31 31 30 46 33 32 33 32 33 43 39    |C601C110F32323C9|
33 45 32 30 43 35 43 44 43 36 30 31 43 31 31 30    |3E20C5CDC601C110|
46 37 32 33 32 33 43 39 32 41 45 41 30 31 43 44    |F72323C92AEA01CD|
34 37 42 31 32 33 32 33 30 31 30 41 30 30 37 45    |47B12323010A007E|
42 37 32 38 30 39 43 44 34 37 42 31 34 36 32 33    |B72809CD47B14623|
34 45 32 33 31 38 46 33 37 38 45 36 30 33 36 37    |4E2318F378E60367|
36 39 37 38 30 46 30 46 45 36 33 46 34 46 30 36    |69780F0FE63F4F06|
30 30 30 39 32 42 43 39 32 31 34 31 42 32 43 44    |00092BC92141B2CD|
46 36 30 31 43 39 30 36 30 43 37 45 46 45 32 30    |F601C9060C7EFE20|
32 33 43 38 31 30 46 39 43 39 32 41 30 38 30 32    |23C810F9C92A0802|
43 44 34 37 42 31 37 38 42 37 43 38 32 42 32 42    |CD47B178B7C82B2B|
37 45 45 36 46 30 46 45 33 30 43 30 32 33 33 36    |7EE6F0FE30C02336|
36 31 43 39 31 46 32 46 34 30 35 38 31 38 35 33    |61C91F2F40581853|
30 38 32 30 30 38 38 32 35 33 37 34 36 31 37 34    |0820088253746174|
37 35 37 33 33 41 31 42 34 31 34 34 37 FF FF FF    |75733A1B41447...|

Ofenbar passt bei den durch HxC erstellten RAW-Dateien das Timing zwischen Indexloch und Fluxlängen nicht zusammen. Dumpt man die RAW-Quelldateien, so sieht man keinen Fehler, da beim Dump das Indexloch nur für den Start berücksichtigt wird. Sind die Fluxwechsel minimal länger, stört das auch nicht.

Bei Schreiben durch FLUXCOPY wird der Schreibvorgang beim (nochmaligen) Erreichen des Indexloches sofort abgebrochen, um nicht die Daten des ersten Sektors zu überschreiben.

Grüße, PAW

Habe noch ein Experiment durchgeführt:

Den RAW-File vom ersten Track händisch gepatched. Die Indexzeiten auf ca. 200 msec geändert, mit FLUXKRYOCONV auf FLX-Datei konvertiert. Diese dann mit FLUXCOPY geschrieben und wieder gelesen ... und siehe da, es funktioniert. Der letzte Sektor ist nun vollständig auf der Diskette und bringt keinen CRC-Fehler mehr beim Dumpen!

Zum Patch: im RAW-File gibt es einen Eintrag für jeden Indexdurchgang. Im Eintrag steht auch der Stand der IndexClock. Die IndexClock zählt bei Kryoflux mit ca. 3,00342867 MHz hoch. 200 mSec entsprechen ca. 600685. Der Eintrag hat 4 Bytes (LowByte first). Der erste Eintrag bleibt unverändert, jeder nachfolgende wird gegenüber dem Vorgänger um 200 mSec erhöht. Den Indexblock findet man mit 0x0D 0x02 0x0C 0x00 in der RAW-Datei. Die nächsten 8 Byte bleiben unverändert, darauf folgen die 4 Byte mit dem IndexCount, der verändert werden muss.

Ich wünsche Gutes Gelingen!

PAW

Ich staune über die Resultate die hier erzielt werden so toll!

Ich hoffe ich bringe meinen Mupid 1 auch mal zum Leben mit einem BTX Server

ZahrlAn könntest Du bitte die ROMs und vielleicht ein Foto von der Platine vom Mupid 1 zur Verfügung stellen?

Danke und Gruß

Robert

Quote from PAW

Habe noch ein Experiment durchgeführt:

Den RAW-File vom ersten Track händisch gepatched. Die Indexzeiten auf ca. 200 msec geändert, mit FLUXKRYOCONV auf FLX-Datei konvertiert. Diese dann mit FLUXCOPY geschrieben und wieder gelesen ... und siehe da, es funktioniert. Der letzte Sektor ist nun vollständig auf der Diskette und bringt keinen CRC-Fehler mehr beim Dumpen!

Zum Patch: im RAW-File gibt es einen Eintrag für jeden Indexdurchgang. Im Eintrag steht auch der Stand der IndexClock. Die IndexClock zählt bei Kryoflux mit ca. 3,00342867 MHz hoch. 200 mSec entsprechen ca. 600685. Der Eintrag hat 4 Bytes (LowByte first). Der erste Eintrag bleibt unverändert, jeder nachfolgende wird gegenüber dem Vorgänger um 200 mSec erhöht. Den Indexblock findet man mit 0x0D 0x02 0x0C 0x00 in der RAW-Datei. Die nächsten 8 Byte bleiben unverändert, darauf folgen die 4 Byte mit dem IndexCount, der verändert werden muss.

Ich wünsche Gutes Gelingen!

PAW

Display More

Ich habe gestern Abend noch die ersten zwei Spuren der Disk gepatched und erfolgreich am Mupid geladen. Nun muss ich mir ein Skript für die verbleibenden Spuren schreiben und dann den (hoffentlich) finalen Test durchführen. Bin aber guter Dinge, dass wir so letztendlich funktionierende Disketten bekommen. Herzlichen Dank für die Unterstützung!

Quote from gpospi

Quote from PAW

Habe noch ein Experiment durchgeführt:

Den RAW-File vom ersten Track händisch gepatched. Die Indexzeiten auf ca. 200 msec geändert, mit FLUXKRYOCONV auf FLX-Datei konvertiert. Diese dann mit FLUXCOPY geschrieben und wieder gelesen ... und siehe da, es funktioniert. Der letzte Sektor ist nun vollständig auf der Diskette und bringt keinen CRC-Fehler mehr beim Dumpen!

Zum Patch: im RAW-File gibt es einen Eintrag für jeden Indexdurchgang. Im Eintrag steht auch der Stand der IndexClock. Die IndexClock zählt bei Kryoflux mit ca. 3,00342867 MHz hoch. 200 mSec entsprechen ca. 600685. Der Eintrag hat 4 Bytes (LowByte first). Der erste Eintrag bleibt unverändert, jeder nachfolgende wird gegenüber dem Vorgänger um 200 mSec erhöht. Den Indexblock findet man mit 0x0D 0x02 0x0C 0x00 in der RAW-Datei. Die nächsten 8 Byte bleiben unverändert, darauf folgen die 4 Byte mit dem IndexCount, der verändert werden muss.

Ich wünsche Gutes Gelingen!

PAW

Display More

Ich habe gestern Abend noch die ersten zwei Spuren der Disk gepatched und erfolgreich am Mupid geladen. Nun muss ich mir ein Skript für die verbleibenden Spuren schreiben und dann den (hoffentlich) finalen Test durchführen. Bin aber guter Dinge, dass wir so letztendlich funktionierende Disketten bekommen. Herzlichen Dank für die Unterstützung!

Display More

Kurzer Zwischenbericht: Ich habe ein kurzes PC-Basic Programm zur Anpassung der Index-Timings geschrieben (weil ich PC-Basic schon am Rechner hatte). Leider emuliert PC-Basic auch die originale PC Geschwindigkeit, d.h. die Bearbeitung jeder Spur dauert 3 Minuten. Seit Fertigstellung des Programms habe ich schon 15 Spuren konvertiert und auch gleich mit Kryoflux auf eine echte Diskette geschrieben. Es schaut alles gut aus und ich konnte am Mupid auch schon ein Programm von diesen Spuren laden (was bisher immer wegen des defekten letzten Sektors gescheitert ist). Es schaut also wirklich gut aus! Den finalen Bericht gibt's dann in den nächsten Tagen, dann werde ich mich auch an die CP/M Diskette für den Mupid wagen...

Ich hab das Basic-Programm parallelisiert und die erste Diskettenseite fertig. Das Ergebnis ist wie gewünscht/erwartet, d.h. die Diskette ist nun tatsächlich funktionsfähig!

Habe vorhin das Program FLUXKRYOCONV erweitert.

Es gibt eine neue Option für die Konvertierung von RAW nach FLX. Wird diese angehakt, dann wird die Summe der Fluxtimings mit der Zeit zwischen den Indeximpulsen verglichen. Reicht die Zeit nicht, dann wird Zeit für die Indexpulse auf den Wert der Fluxwechsel gesetzt.

Habe vorhin das Mupid-Image mit FLUXCOPY auf eine physische Diskette geschrieben und wieder eingelesen. Es sind nun alle Sektoren vorhanden. Leider kann ich das Ergebnis nicht auf dem Zielsystem ausprobieren, da ich kein Mupid habe. Deshalb habe ich die neue Testversion an gpospi geschickt. Ich nehme an, dass er sie in den nächsten Tagen probieren wird.

PAW

Quote from PAW

Ofenbar passt bei den durch HxC erstellten RAW-Dateien das Timing zwischen Indexloch und Fluxlängen nicht zusammen. Dumpt man die RAW-Quelldateien, so sieht man keinen Fehler, da beim Dump das Indexloch nur für den Start berücksichtigt wird. Sind die Fluxwechsel minimal länger, stört das auch nicht.

Meine unangenehme Erfahrung mit HxC ist, dass da eh viel Murks gemacht wurde. Konkret kann es nicht meine Disketten vom Basis 108 (Apple 2 Format zweiseitig mit 80 Zylindern) fehlerfrei dekodieren. Da kommen unglaublich viele schlechte Sektoren raus, oder es erkennt auf manchen Spuren gar kein Format. Sowohl mein eigener Dekoder als auch der von fluxengine kommen damit problemlos klar. Ich kann daher HxC nicht einmal zur Visualisierung des Sektorlayouts verwenden, da unbrauchbar.

Ich habe nun auch die CP/M Diskette konvertiert und erfolgreich geladen:

Mir ist noch nicht ganz klar, weshalb die urspünglichen IMD/TD0 Files nicht korrekt geschrieben werden konnten.

Bei der Konvertierung auf Kryoflux hat ja offenbar das HxC Tool Mist gebaut, wodurch die Disketten dann nicht funktioniert haben.

Nun ist aber soweit alles korrigiert und ich habe ordentliche Kryoflux RAW Files vom Mupid27 BTX System und vom CP/M.

Ich werde alles noch ordentlich testen und dann wieder hier zur Verfügung stellen bzw. archivieren.

Hier nun die Images der Mupid27 BTX und CP/M Bootdisketten:

CPM.zip

CPM_raw.zip

Mupid_BTX.zip

Mupid_BTX_raw.zip

Quote from gpospi

Hier nun die Images der Mupid27 BTX und CP/M Bootdisketten:

Inwiefern unterscheiden sich die IMD-Files von den bisherigen Diskettenimages?

Ich habe diese IMDs wieder mit HxC von den korrigierten Kryoflux RAW Files erzeugt. Die RAW Files habe ich erfolgreich mit Kryoflux auf Disketten geschrieben. Die IMD Files habe ich nicht getestet, mit einer gewissen Wahrscheinlichkeit sind sie weiterhin/wieder defekt (da ja offenbar HxC einen Bug bei der Konvertierung hat). Ich kann demnächst mal versuchen, eine nachweislich funktionierende Mupid Disk direkt mit Imagedisk einzulesen. Gebe dann wieder Bescheid!

Finaler Bericht:

• Mein Archiv-Rechner kann offenbar keine FM-Images im 1.2 MB/96 Track/360 RPM Laufwerk bearbeiten (vielleicht ein Problem mit der Drehzahl, FM im "normalen" 360 KB/40 Track/300 RPM Laufwerk funktioniert). Insofern kann ich von den Mupid Disketten leider keine funktionierenden IMD Images erstellen bzw. die "konvertierten Images" (Kryoflux RAW in IMD mittels HxC Tool) nicht überprüfen.
• Mit der RPM-Adaptierung in FluxKryoConv konnte ich nun auch die CPM1 und CPM2 Images korrigieren (Drehzahl- bzw. Indexanpassung) und auf Disketten schreiben. Da sind verschiedene CP/M Tools drauf (Kermit, UNARC, Fortran). Vereinzelt gibt es Lesefehler (BDOS Error), aber die Programme selbst funktionieren! Man kann also z.B. mit FORT RAND das Fortran-Programm RAND übersetzen und dann per FRUN RAND ausführen.
• Die Disketteninhalte selbst hatte ich am PC schon früher ausgelesen, so sind die einzelnen Dateien nutzbar (siehe Mupid_CPM.zip).

CPM1_RAW.zip

CPM2_RAW.zip

Quote from gpospi

Finaler Bericht:

• Mein Archiv-Rechner kann offenbar keine FM-Images im 1.2 MB/96 Track/360 RPM Laufwerk bearbeiten (vielleicht ein Problem mit der Drehzahl, FM im "normalen" 360 KB/40 Track/300 RPM Laufwerk funktioniert). Insofern kann ich von den Mupid Disketten leider keine funktionierenden IMD Images erstellen bzw. die "konvertierten Images" (Kryoflux RAW in IMD mittels HxC Tool) nicht überprüfen.
• Mit der RPM-Adaptierung in FluxKryoConv konnte ich nun auch die CPM1 und CPM2 Images korrigieren (Drehzahl- bzw. Indexanpassung) und auf Disketten schreiben. Da sind verschiedene CP/M Tools drauf (Kermit, UNARC, Fortran). Vereinzelt gibt es Lesefehler (BDOS Error), aber die Programme selbst funktionieren! Man kann also z.B. mit FORT RAND das Fortran-Programm RAND übersetzen und dann per FRUN RAND ausführen.
• Die Disketteninhalte selbst hatte ich am PC schon früher ausgelesen, so sind die einzelnen Dateien nutzbar (siehe Mupid_CPM.zip).

Ja, das meinte ich zu Beginn, ob dein Setup überhaupt funktioniert. Sehr wenige FDC können FM bei 150 kBit/s (nötig bei 360 UpM).

Die Floppyimages sind wohl von meinem Server. Ich hatte da zwei CPM-Arbeitsdisketten erstellt, eine für A: und B:, die zweite für C: und D: (siehe README.txt). Da ist auch ein Image mit TP3 dabei

Quote from lgp30

Quote from gpospi

Finaler Bericht:

• Mein Archiv-Rechner kann offenbar keine FM-Images im 1.2 MB/96 Track/360 RPM Laufwerk bearbeiten (vielleicht ein Problem mit der Drehzahl, FM im "normalen" 360 KB/40 Track/300 RPM Laufwerk funktioniert). Insofern kann ich von den Mupid Disketten leider keine funktionierenden IMD Images erstellen bzw. die "konvertierten Images" (Kryoflux RAW in IMD mittels HxC Tool) nicht überprüfen.
• Mit der RPM-Adaptierung in FluxKryoConv konnte ich nun auch die CPM1 und CPM2 Images korrigieren (Drehzahl- bzw. Indexanpassung) und auf Disketten schreiben. Da sind verschiedene CP/M Tools drauf (Kermit, UNARC, Fortran). Vereinzelt gibt es Lesefehler (BDOS Error), aber die Programme selbst funktionieren! Man kann also z.B. mit FORT RAND das Fortran-Programm RAND übersetzen und dann per FRUN RAND ausführen.
• Die Disketteninhalte selbst hatte ich am PC schon früher ausgelesen, so sind die einzelnen Dateien nutzbar (siehe Mupid_CPM.zip).

Ja, das meinte ich zu Beginn, ob dein Setup überhaupt funktioniert. Sehr wenige FDC können FM bei 150 kBit/s (nötig bei 360 UpM).

Die Floppyimages sind wohl von meinem Server. Ich hatte da zwei CPM-Arbeitsdisketten erstellt, eine für A: und B:, die zweite für C: und D: (siehe README.txt). Da ist auch ein Image mit TP3 dabei

Oh super den "Owner" der Images hier zu treffen! Das TP3 Image funktioniert bei mir leider gar nicht (kann in HxC nicht gelesen werden).
Die anderen Images konnte ich inzwischen in Kryoflux konvertieren und auf Disketten schreiben (wie in den vorigen Postings erwähnt).

Quote from gpospi

Das TP3 Image funktioniert bei mir leider gar nicht (kann in HxC nicht gelesen werden).

Wenn Du die Images von hier meinst: ftp://ftp.informatik.uni-stuttgart.de/pub/cm/mupid/disks/

Habe versucht die tp3.imd mittels SAMdisk_GUI auf .DSK zu konvertieren. Dabei kommt folgende Fehlermeldung:

Error.JPG

PAW

Quote from PAW

Wenn Du die Images von hier meinst: ftp://ftp.informatik.uni-stuttgart.de/pub/cm/mupid/disks/

Habe versucht die tp3.imd mittels SAMdisk_GUI auf .DSK zu konvertieren. Dabei kommt folgende Fehlermeldung:

Error.JPG

Huch, der erste, dem das auffält... Da muss ich wohl ein neues Image erzeugen. Dieses ist eundeutig kaputt.

Quote from lgp30

Huch, der erste, dem das auffält... Da muss ich wohl ein neues Image erzeugen. Dieses ist eundeutig kaputt.

Genau, mit dem originalem IMDViewer kommt nur:

Liebe Mupid-Freunde, ich habe ein neues kleines Rätsel für Euch:

• Mein "Arbeits-Mupid" läuft ja inzwischen ordentlich mit der M-DISK Floppy und CP/M. Allerdings ist die Tastatur etwas hakelig. Darum wollte ich nun auch meinen zweiten NOS-"Museums-Mupid" damit mal in Betrieb nehmen. Leider erscheint nur ganz kurz das Startbild, dann beginnt das Bild für 1-2 Sekunden vertikal zu hüpfen/laufen und verschwindet dann ganz. Das gleiche Verhalten konnte ich auf mehreren TVs (alte CRTs und neue TFTs) reproduzieren. Der "Arbeits-Mupid" liefert auf allen TVs ein ordentliches Bild. Der Museums-Mupid ist zwar betriebsbereit und nimmt Tastatureingaben an, liefert aber eben kein Bild.
• Also habe ich den Rechner mal aufgeschraubt und untersucht. Dabei fiel mir im Video-Bereich eine Zusatzplatine auf, die im Arbeits-Mupid und auch im Bild vom Computermuseum Stuttgart (http://computermuseum.informat…s/mupid/ptc100/cpu_vr.jpg) nicht vorhanden ist.
  
  
  
• Technische Unterlagen zum Mupid sind ja leider nicht vorhanden, aber immerhin habe ich zu dem TDA 8571B Bauteil was gefunden (https://www.limpulsion.fr/upload/docs/TDA3571B.PDF). Meine Video-Elektronik-Kenntnisse sind leider recht bescheiden, aber offenbar handelt es sich um eine Schaltungsergänzung zur Erzeugung/Optimierung von Sync-Signalen. Kann mir hier vielleicht jemand mit Ideen bzw. genaueren Informationen zur Funktion dieser Schaltung helfen?
• Da das Teil im anderen Mupid nicht vorhanden ist, habe ich es einfach mal ganz frech entfernt. Siehe da, der Rechner liefert das normale Videobild und kann einwandfrei verwendet werden. Aber wozu wurde es dann überhaupt eingebaut? Hat es vielleicht mit der Umschaltung BTX-Bild / Fernseh-Bild zu tun, wo der BTX-Rechner die "externe Synchronisation" vom TV nutzen konnte (wobei mir der Zweck nicht klar ist)?
  

Ich habe wieder eine "Mupid Baustelle", d.h. einen Mupid der beim Einschalten kein Lebenszeichen von sich gibt (Startton bleibt aus, es gibt auch kein Bild). Da kommt natürlich sofort das Netzteil in Verdacht. Beim Anschluss eines anderen Mupid-Netzteils bestätigt sich das, d.h. mit anderem Netzteil startet der Rechner. Für weitere Tests wollte ich nun natürlich zuerst die benötigten Spannungen sowie die Pin-Belegung des Mainboard-Stromanschlusses ermitteln, leider habe ich bislang für den Mupid2 keine Schaltpläne gefunden. Mit ein wenig Detektivarbeit ist die Pin-Belegung aber schnell gefunden, es handelt sich um die üblichen Computer-Spannungen (-12V, +12V, +5V). Insofern lässt sich der Mupid auch testweise mit PC-AT/ATX Netzteilen (bzw. einem ITX Netzteil plus ATX Spannungswandler) betreiben!

Pinout am Mainboard:
Pin 1/2/3 (Frontseite des Rechners) = +5V

Pin 4 = -12V

Pin 5 = +12V

Pin 6/7/8 (Rückseite des Rechners in Richtung Netzteil) = GND