Posts by mnaberez

    Ich habe mal von ihm eine FD 2000 gesehn, Was für ein Schrott. Platinen handgefertig und so.?(

    Da ich noch nie ein von Maurice hergestelltes Produkt untersucht habe, weiß ich nicht, wie sie aussehen. Es ist aber möglich, dass einige Produkte, die von CMD selbst hergestellt wurden, auch von Hand gelötet wurden.


    Als Maurice 2001 die Fertigung von CMD übernommen hat, hat er einen Artikel geschrieben, in dem er davon erzählt hat, dass er CMD besucht hat, um Komponenten abzuholen und in der Fertigung trainiert zu werden. Er hat erwähnt, dass er dort jemanden namens Angel kennengelernt hat, der ein paar Jahre lang die CMD-Produkte von Hand gelötet hatte.


    Bis heute erinnere ich mich an diesen Artikel, weil ich ein bisschen überrascht war, als ich ihn gelesen habe. Ich habe nämlich ein paar meiner Geräte von CMD geöffnet und die Lötstellen haben immer sehr gut ausgesehen. Sie waren so gut, dass ich davon ausgegangen bin, dass sie von einer Maschine gelötet wurden.

    Der ZuluSCSI ist nicht so teuer, leichter zu bedienen und sollte laufen.

    Am Samstag habe ich die mechanische Festplatte in einer meiner CMD HDs durch einen ZuluSCSI RP2040 ersetzt. Nach der Entdeckung, dass man mehrere CMD HDs gleichzeitig an die RAMLink anschließen kann, will ich jetzt natürlich zwei CMD HDs dran haben. Seit 2015 hat eine meiner CMD HDs keine mechanische Festplatte mehr, also macht sie keine Geräusche. Die andere hatte noch eine echte Festplatte. Nach so vielen Jahren ohne Geräusche hat mich die andere ein wenig gestört, deshalb habe ich einen ZuluSCSI RP2040 dafür gekauft.


    Befestigung


    Der ZuluSCSI RP2040 hat die gleichen Löcher wie die Unterseite einer 2,5 Zoll Festplatte. Die CMD HD wurde für eine 3,5 Zoll Festplatte entworfen, daher braucht man einen Rahmen zur Befestigung. Ich hatte bereits so einen Rahmen, aber der ZuluSCSI RP2040 konnte nicht auf die Oberseite gelegt werden, weil er breiter als eine 2,5 Zoll Festplatte ist. Ich habe ihn stattdessen auf der Unterseite befestigt und den Rahmen verkehrt herum installiert. Dafür musste ich ein bisschen Material vom Rahmen abschneiden:


    01-Rahmen.jpg  02-Festplatte-in-Rahmen.jpg  03-Schnitte.jpg


    Man braucht einen Adapter fürs Stromversorgungskabel. Wenn der Rahmen verkehrt herum eingebaut ist, dienen die Kanäle als Kabelmanagement und verstecken den Adapter:


    04-Stromversorgungskabel.jpg  05-Kanäle.jpg


    Für den ZuluSCSI habe ich vier M3-Abstandshalter auf dem Rahmen befestigt. Auf den Seiten des Rahmens befinden sich verschiedene Löcher zur Befestigung. Ein Loch befindet sich direkt über der Batterie. Da ich die Batterie in einem Halter habe, habe ich dieses Loch nicht verwendet. Mit den von mir ausgewählten Löchern ist der Rahmen zwar ein bisschen schief, aber es ist nicht besonders auffällig. Die Batterie kann leicht untersucht oder gewechselt werden:


    06-Abständshalter.jpg  07-Löcher.jpg  08-Batterie.jpg


    So sieht das Ganze aus:


    09-das-Ganze-von-der-Seite.jpg  10-das-Ganze-von-oben.jpg


    Schalter


    Es gibt drei Schalter auf dem ZuluSCSI RP2040. Zwei müssen wie folgt konfiguriert sein:

    • 1 INITIATOR auf OFF
    • 3 TERMINATION auf ON

    Den anderen Schalter, 2 DEBUG LOG, hatte ich zunächst auf ON und dann habe ich ihn später ausgeschaltet.


    SD-Karte


    SD-Karten nutzen sich jedes Mal ein wenig ab, wenn man darauf schreibt. SD-Karten, die angeblich länger halten, stehen jedoch zum Verkauf. Ich habe so eine Karte, “SanDisk 32GB MAX Endurance”, gekauft, ihre Teilenummer ist SDSQQVR-032G-GN6IA.


    Die Karte muss als FAT32 oder ExFAT formatiert werden. Darauf muss man eine Imagedatei erstellen, deren Größe der Größe der emulierten Festplatte entspricht. So habe ich die Größe der Imagedatei berechnet:


    Die größte Partition, die man mit HD-TOOLS erstellen kann, ist 65280 Blocks groß. Wenn man eine Partition von 65280 Blocks hinzufügt, verliert man genau 65280 freie Blocks. Laut dem Handbuch darf man insgesamt 254 Partitionen erstellen. Das System (HD-DOS) benötigt aber auch Speicherplatz, und ich weiß nicht, wie man genau berechnet, wie viel Speicherplatz es benötigt. Ich bin deswegen davon ausgegangen, dass die Partitionsnummer eine 8-Bit-Zahl ist (256 oder von 0 bis 255):


    65280 Blocks * 256 Bytes * 256 Partitionen =

    4278190080 Bytes für die Imagedatei


    Wenn die Imagedatei eine Größe von 4278190080 hat, zeigt HD-TOOLS "BLOCKS AVAILABLE: 16710624" an. Man sollte dann tatsächlich 254 Partitionen von 65280 Blocks erstellen können, da 16710624 Blocks größer sind als die erforderlichen 254 * 65280 = 16581120 Blocks. Die Imagedatei könnte jedoch kleiner sein. Wenn jemand erklären könnte, wie man den erforderlichen Speicherplatz genauer berechnet, würde ich es gern wissen.


    Um die SD-Karte vorzubereiten, habe ich die Kommandozeile auf Ubuntu 22.04 verwendet. Obwohl es mehrere Videos und Anleitungen zum ZuluSCSI gibt, sind die meisten für Windows. Darum sind hier die Befehle, die ich ausgeführt habe, um die Karte vorzubereiten. Man sollte sich gut mit der Kommandozeile auf Linux auskennen und natürlich muss "/dev/sdb" geändert werden.

    CMD HD UTILITIES


    Die CMD HD muss den BOOT ROM 2.80 haben. Ich habe eine CMD HD UTILITIES Diskette mit HD-TOOLS 1.12 und HD-DOS 1.92 verwendet. Nach meinem Kenntnisstand sind das die neuesten Versionen.


    Andere Einheiten auf dem Bus (z. B. die 1541) werden möglicherweise nicht ansprechbar, wenn die CMD HD kein HD-DOS auf der Festplatte hat und nicht richtig hochfahren kann. Die HD sollte deswegen ausgeschaltet bleiben.


    Während die HD ausgeschaltet ist, wird "CREATE SYS" von der Diskette geladen. Es ist nicht notwendig, "LLFORMAT" auszuführen. Man kann stattdessen direkt mit "CREATE SYS" loslegen. Nachdem es ausgeführt wurde, zeigt "CREATE SYS" eine Anleitung und wartet, bis man RETURN drückt. Jetzt wird die HD eingeschaltet: während die HD eingeschaltet wird, müssen "SWAP 8" und "SWAP 9" gleichzeitig gedrückt werden. Nach ein paar Sekunden kann man "SWAP 8" und "SWAP 9" loslassen. Sobald man sie losgelassen hat, drückt man RETURN, um den Prozess zu starten. Wenn "CREATE SYS" fertig ist, lädt es "REWRITE DOS" automatisch. Solange der Prozess endet, ohne Fehlermeldungen wie "SCSI ERROR xxx" zu zeigen, sollte die HD jetzt verwendbar sein.


    Um die Partitionen zu erstellen, wird "HD-TOOLS.64" dann geladen und ausgeführt, ohne den C64 neu starten zu müssen. Die Gerätenummer der HD wird 12 sein. Das kann auch mit HD-TOOLS geändert werden.


    Bisher habe ich die HD mit dem ZuluSCSI drei oder vier Stunden lang benutzt und bin auf keine Probleme gestoßen.

    cmd hat doch auch ein HD-Kabel als schnelle Verbindung zwischen HD und RAMLink vorgesehen.

    wäre das nicht noch schneller bzw. doppelt-gemoppelt?

    Oder ist Dein Aufbau ein Eigenbau dieses HD-Kabels?

    Das ursprüngliche Kabel, das CMD verkauft hat, sieht so aus:



    Mit diesem Kabel kann nur eine HD an die RAMLink angeschlossen werden. Mein Kabel hat drei Stecker, also kann man zwei HDs an die RAMLink anschließen. Ansonsten funktioniert es genauso wie das Kabel von CMD. Die Möglichkeit, mehrere HDs anzusprechen, ist eigentlich ein Teil des Designs der parallelen Schnittstelle. Sowohl die Hardware als auch das HD-DOS/RL-DOS wurden so entwickelt, dass sie es unterstützen. Nach meinem Kenntnisstand hat CMD diese Möglichkeit nie erwähnt.

    Klingt interessant. Sind alle Adern 1:1 geschaltet? Wie erfolgt die Ansprache der unterschiedlichen HDs? Nutzt du nur den SWAP Button oder hast du eine der internen IDs geändert?

    Ja, alle 14 Pins sind 1:1 verbunden. Mit dem Programm "HD-TOOLS" habe ich die internen IDs geändert. Die eine CMD HD ist 9, die andere ist 10. Man verwendet einfach diese Adressen wie gewohnt.

    Heute habe ich ein Kabel zusammengebaut, um zwei CMD HDs an die parallele Schnittstelle der RAMLink anzuschließen. Die beiden funktionieren!


    Meines Wissens nach wurde diese Möglichkeit nie von CMD erwähnt. In der E-Mail-Gruppe “cbm-hackers” hat Roberto Muscedere 2022 gepostet, dass er den ROM-Code der RAMLink untersucht hat. Er hat mitgeteilt, dass über die parallele Schnittstelle mehr als eine Einheit angesprochen werden kann.


    Ich wollte es ausprobieren, aber ich dachte auch, dass die Geräte beschädigt werden könnten, weil ich nicht wusste, ob es elektrisch funktionieren würde. Neulich habe ich allerdings erfahren, dass der ursprüngliche Schaltplan der CMD HD aufgetaucht ist. Der Schaltplan hat bestätigt, dass es tatsächlich funktionieren sollte, zumindest seitens der CMD HD, also habe ich mich entschieden, das Risiko einzugehen.


    Bei eBay USA habe ich mir ein paar Adapter gekauft, die für den Atari ST gedacht sind. So sehen sie aus:



    Um drei dieser Adapter miteinander zu verbinden, habe ich heute ein eigenes Y-Kabel zusammengebaut:



    Hier ist mein ganzes Setup zu sehen:



    Mit dem Programm "FCOPY" habe ich hunderte von Dateien zwischen den Einheiten kopiert. Soweit ich sehen kann, funktioniert es problemlos.

    Es gibt mindestens einen Fehler im ursprünglichen Schaltplan von CMD. Da ich Interesse an der parallelen Schnittstelle habe, habe ich mir den entsprechenden Teil des Schaltplans angeschaut und ihn mit dem Code im VICE-Emulator verglichen:

    Die Signale der Knöpfe ("SWAP 8", "SWAP 9" und "WRITE PROTECT") sind im Schaltplan falsch markiert. Die anderen Signale zum 8255 stimmen überein.

    Wow! Ich freue mich, das zu sehen. Obwohl ich manchmal die dortigen Beiträge lese, ist der Thread im anderen Forum an mir vorbeigegangen.


    Durch Zufall bin ich auf diese Erweiterung (HAL PCG-9000) gestoßen. Wie es in einem obigen Beitrag schon gesagt wurde, besitze ich eine leider nicht. Als ich an einem anderen Projekt gearbeitet habe, um mein PEDISK-II Diskettensystem zum Laufen zu bringen, hat mir Jim Oldfield seine alten Disketten dafür geschickt. Auf einer habe ich die Spiele für die PCG-9000-Erweiterung gefunden. Jim hat diese Erweiterung nicht erwähnt und sie war mir früher unbekannt. Als ich ihn danach gefragt habe, hat mir Jim die Fotos und das Handbuch geschickt, die auf meiner Webseite sind. Seitdem habe ich zwar Interesse daran, aber ich habe auch andere Projekte zu erledigen. Ich finde es super, dass ihr diese Erweiterung nachgebaut habt und jetzt an neueren Varianten dieses Konzepts arbeitet.

    Schade, dass nichts mehr für die Flash 8 herausgekommen ist. War eigentlich eine gute und bei mir stabile Turbokarte.

    Muss der Drehknopf auf dem Flash 8 manchmal gedreht werden?


    In den 1990er Jahren besuchte jemand meine CBM-Benutzergruppe in den USA, um das Flash 8 auszustellen. Er sagte uns, dass er vorhatte, das Flash 8 in die USA zu importieren. Während des Treffens habe ich ein wenig mit dem Flash 8 herumgespielt. GEOS ist schneller gelaufen und das war damals beeindruckend.


    Ein Drehknopf auf dem Flash 8 fiel mir allerdings auf. Ich fragte den Typen nach dem Zweck des Drehknopfs. Er sagte mir, dass der Drehknopf manchmal gedreht werden muss, um das Timing anzupassen, wenn das Flash 8 nicht gut an einem bestimmten C64 funktioniert. Das fand ich merkwürdig.


    Ein paar Monate später hatten wir ein weiteres Treffen, in dem er mir sagte, dass er beschlossen hatte, das Flash 8 nicht zu verkaufen, weil es seiner Meinung nach nicht zuverlässig genug war. Er hat den Drehknopf erwähnt. Da CMD kurz davor die Entwicklung der SuperCPU angekündigt hatte, stellte ich ihm keine weiteren Fragen dazu.

    I think Jim Brain was working on a clone. I haven't heard anything about it lately. I think he was able to reverse the GALs on it.

    Ich weiß nicht, ob er auch am Flash-8 arbeitet, aber Jim Brain arbeitet an einem ähnlichen Gerät namens Turbo Master CPU. Es ist auf GitHub zu sehen.


    Die Turbo Master CPU wurde von Schnedler Systems in den USA hergestellt und läuft mit 4,09 MHz. Laut einem Thread im Lemon64-Forum ist Jims Replik noch nicht fertig, weil weitere PAL-Chips ausgelesen oder ersetzt werden müssen.

    Anbei findet ihr ein paar Fotos, die nicht auf Steves Webseite sind. Ich hatte vor, einen Beitrag über das Projekt zu posten, aber ihr seid schneller als ich. :)


    Steves Platine basiert auf dem ursprünglichen Schaltplan. Sie ist jedoch keine Replik, weil das Layout ganz anders aussieht und einige moderne Komponenten verwendet werden. Das Design wurde erweitert, z.B. hat es größere ROM- und RAM-Chips und die Möglichkeit, schneller als 1 MHz zu laufen. Es enthält auch den 8563-VDC aus dem C128.


    Als seine ersten Platinen geliefert wurden, hat Steve schon angefangen, an der Tastatur und dem Gehäuse zu arbeiten, also habe ich ihm meine Hilfe angeboten. Steve hat angenommen und dann habe ich die erste Platine zusammengebaut und zum Laufen gebracht. Obwohl ich einige Fehler korrigieren und einen Chip hinzufügen musste, hat das Design größtenteils funktioniert. Im Laufe des Testens habe ich Teile des CLCD-Kernals disassembliert und kleine Varianten davon gemacht. Da ich zunächst kein Display und keine Tastatur hatte, habe ich CHROUT, CHRIN, usw. modifiziert, um diese Geräte durch den 6551-ACIA zu ersetzen. Jetzt funktioniert der 8563-VDC auf der Platine, also habe ich den Kernal modifiziert, um ihn zu verwenden. Wir wissen noch nicht, ob die Tastatur funktioniert, denn ich habe sie noch nicht zusammengebaut. Eine 1541 kann allerdings an die Platine angeschlossen werden und sie funktioniert!


    Die ursprünglichen Anwendungsprogramme laufen noch nicht, weil die MMU des CLCDs noch nicht umgesetzt ist. Es gibt allerdings mehrere CLCD-Emulatoren, in denen die Anwendungsprogramme problemlos laufen, daher wissen wir, wie die MMU funktioniert.


         

    Du hast CP/M für den CBM? Wie geil ist das denn! Habe ich noch nie gesehen oder auch nur davon gehört. :thumbsup:

    Ja, in den 1980ern gab es eigentlich zwei solche Systeme. Ich habe glücklicherweise die beiden Systeme, denn ich sammle seit vielen Jahren die Erweiterungen für die PET/CBM-Rechner.


    Eines der zwei Systeme heißt der "Z-RAM" und wurde von Madison Computer in den USA entwickelt. Der Z-RAM war in Europa als "CP/Maker" bekannt. Dieses System besteht aus einer Platine, die im Rechner installiert wird. Es ist ein interessantes Design, weil es auch als RAM-Erweiterung für den 6502 funktioniert, wenn das CP/M nicht aktiv ist. Dieser zusätzliche Speicher ist allerdings nicht mit anderen RAM-Erweiterungen kompatibel. Interessanterweise befinden sich keine ROMs auf der Platine. Ein Bootloader auf dem PET lädt stattdessen den Z80-Code von der Diskette in den Speicher der Platine, dann beginnt der Z80 zu laufen und er übernimmt den Speicher. In diesem Modus kann der 6502 nicht mehr auf den Speicher zugreifen. Während das CP/M auf dem Z80 läuft, läuft ein Terminalprogramm auf dem PET, das über einen I/O-Port mit dem Z80 kommuniziert. Ich konnte es kaum glauben, aber das Terminalprogramm ist teilweise in BASIC geschrieben. Zudem wird das CP/M-Dateisystem in REL-Dateien im CBM-DOS-Dateisystem gespeichert. Wegen der Implementierung der Software ist das System sehr langsam, obwohl der Z80 mit 4 MHz läuft. Ich habe den Z-RAM ausprobiert aber nicht gründlich untersucht.


    Das andere System heißt die "SoftBox" und wurde von einer Firma in Großbritannien namens Small Systems Engineering entwickelt. Die SoftBox hatte meines Wissens nach keine anderen Namen. Im Gegensatz zum Z-RAM ist die SoftBox ein externes Gerät, das ans IEEE-488-Bus angeschlossen wird. Deshalb ist die SoftBox mit allen internen PET-Erweiterungen kompatibel. Man kann beispielsweise die SoftBox mit dem SuperPET verbinden, um einen 6502, einen 6809 und einen Z80 am selben CBM-Rechner zu haben. Um das CP/M auf der SoftBox zu benutzen, wird ein Terminalprogramm auf dem PET ausgeführt. Das Terminalprogramm hört dem IEEE-488-Bus zu und wartet auf Befehle von der SoftBox, daher verhält sich der CBM-Rechner wie ein Peripheriegerät. Die SoftBox selbst steuert den IEEE-488-Bus und spricht Laufwerke und Drucker direkt an. Anstatt das CP/M-Dateisystem in REL-Dateien zu speichern, werden die CBM-DOS-Sektoren direkt verwendet. Ein CBM-DOS-Sektor (256 Bytes) entspricht zwei CP/M Sektoren (jeweils 128 Bytes). Aus der Sicht des Benutzers funktionieren der Z-RAM und die SoftBox zwar ähnlich, aber die SoftBox ist nicht nur einfacher zu installieren, sondern auch schneller zu benutzen.

    Ja, es gibt leider keine Nachbauten. Suche auch schon lange ;-)

    Die Schaltpläne der beiden Geräte sind auf meiner Webseite zu sehen. Da ich kein Handbuch hatte, als ich meine SoftBox bekam, musste ich die ROMs und die Software disassemblieren, um herauszufinden, wie die SoftBox bedient wird. Wir haben deswegen viel mehr Infos zur SoftBox im Vergleich zum Z-RAM. Ein Nachbau der SoftBox wäre toll.

    Das ist eine Grafikerweiterung, dessen Nachbau hier gebracht ans Laufen gebracht wurde.

    https://forum.classic-computin…&postID=356249#post356249

    Danke für den Link. Ich wusste nicht, dass eine Replik gebaut wurde. Das ist super.


    Steve Gray und ich besitzen auch diese Erweiterung. Vor einigen Jahren haben wir ein paar Programme dafür geschrieben, die sich auf Steves Webseite befinden. Das ursprüngliche deutschsprachige Handbuch kann auch dort heruntergeladen werden.

    Heute zu meiner grossen Überraschung beim Versuch, eine Diskette auf meinem 8296D zu formaiteren, auf beiden Laufwerken einen "Speed Format Error" bekommen. Der 8296D hat ja bekanntermassen eine internen 8250LP. Die Laufwerke schreiben und lesen bislang einwandfrei. Die Kondensatoren auf der Motorplatine sind bei beiden Drives natürlich schon vor langer Zeit ersetzt worden.

    Ich habe eine SFD-1001, die 2014 ein ähnliches Problem hatte. Außer der Fehlermeldung beim Formatieren hat die Einheit gut funktioniert. Bei meinem ersten Reparaturversuch habe ich die Kondensatoren auf der Motorplatine ersetzt. Die neuen Kondensatoren hat dem Laufwerk geholfen, besser zu funktionieren, aber es war nicht voll zuverlässig. Als ich versucht habe, eine Diskette zehnmal zu formatieren, ist die Formatierung zwei- oder dreimal fehlgeschlagen.


    Danach hat ein Mitglied der Benutzergruppe "TPUG" mir eine Diskette gegeben, auf der ich ein Programm zum Testen der Geschwindigkeit gefunden habe. Das Programm heißt "PROGRAM 977777.A DISK SPEED TEST FOR SYSTEMS 2031/2040/4040/8050/8250". Im Anhang findet man die Diskette.


    Soweit ich mich daran erinnere, befindet sich ein Potentiometer zum Anpassen der Geschwindigkeit auf der Motorplatine. Ich glaube, dass ich dieses Potentiometer gedreht habe, während das Programm gelaufen ist, bis das Programm ein gutes Ergebnis angezeigt hat. Nach der Anpassung hat die Einheit zuverlässiger funktioniert, und sie konnte eine Diskette zehnmal ohne Fehler formatieren.


    Igitt, da wird ein Byte des Bildschirm-RAMs verwendet. Aber das müsste man doch leicht ändern können.

    Die Speicherstelle $87d0 könnte möglicherweise durch $03fd ersetzt werden. Ich bin mir nicht ganz sicher, aber ich glaube, dass $03fd nicht von BASIC 4 verwendet wird.

    Ist denn das Assembler-File relozierbar? Also kann man das für einen anderen Speicherbereich assemblieren?

    Ja. Ich habe Varianten für andere Startadressen assembliert, und sie haben funktioniert.

    Mit dem Wissen, dass die originalen VC20/C64 Kernal-Routinen Pate standen, müsste sich doch auch eine Jiffy-Dos-Version ableiten lassen, oder?

    Eine zukünftige Version mit dem JiffyDOS-Protokoll wäre möglich, weil es im ROM-Bereich noch viel Platz ist. Das VC-1541-DOS ist nur 2,25K, aber der Bereich von $A000-AFFF ist 4K. Ein paar unabhängige Programme für den C64 existieren, die das JiffyDOS-Protokoll umsetzen, z.B. SJLOAD und SDOS. Vielleicht könnte die Umsetzung einer zukünftigen Version auf einem dieser Programme basieren.

    Hast Du die Befehle alle ausprobiert? Ich habe es ja nicht geschafft, irgend etwas aus der korrekt geschriebenen SEQ datei zurück zu lesen. Ich habe immer nur "G" erhalten beim input# und get#.

    Jeder Befehl funktioniert, soweit ich sehen kann. Hier ist ein Programm, das INPUT# und GET# enthält:


    CMD hat in den 1990ern einen Artikel veröffentlicht, in dem eine Modifikation der Platine der RAMLink erklärt wird. Im Anhang befindet sich der Artikel. Es wäre schön, wenn die Replik einige Jumper hätte, um das gleiche Ergebnis zu erreichen, ohne die Platine zu modifizieren.


    Programme, die für die REU geschrieben werden, funktionieren nicht, wenn der "Normal / Direct" Schalter auf "Normal" steht. Andererseits funktioniert der SwiftLink nicht im "Pass-Thru Port", wenn der Schalter auf "Direct" steht. Die REU und der SwiftLink sind jedoch eine nützliche Kombination, die von mehreren Programmen unterstützt wird, z.B. ACE. Darum wird eine Lösung gebraucht, die ermöglicht, die beiden Geräte zusammen zu verwenden, wenn der Schalter auf "Direct" steht.


    Zwei Methoden werden im Artikel erklärt, um dieses Problem zu lösen. Zuerst kann man einen Chip installieren, der "RLDIRECT" heißt. Dieser Chip ist nicht mehr verfügbar, und ich kenne niemanden, der ihn hat. Zweitens kann man die Platine modifizieren. Nicht jeder kann das machen, weil man Spuren auf der Platine schneiden und Drähte anlöten muss. Einige Jumper auf der Platine der Replik würden beide Methoden unnötig machen.


    ramlink_passthru_port_mod.pdf