Junior Computer ][

Gestern Abend hab ich mal den Zeichensatz mit dem MicroElectronica GLCD Font Creator zusammengeklickt. Leider werden die exportierten Daten um 90° verdreht ausgegeben, so dass noch ein kleines Delphi Programm notwendig war, um den V9938 damit zu füttern.

Letzlich habe ich jetzt eine Mischung aus Apple II und HP 28S Font erstellt - je nachdem, welches Zeichen mir besser gefallen hat. Die Control Zeichen ASCII 0-31 sind alle (erst mal) leer, also nicht anzeigbar. Im oberen Zeichensatz Bereich (ASCII 128-255) sind ab ASCII 160 alle Zeichen von ASCII 32 bis 126 als inverse Zeichen abgelegt. ASCII 255 ist der Cursor und ASCII 128-159 sind eine Annäherung an die MouseText Zeichen des Appe //gs. Mal schauen, wozu man die mal gebrauchen kann.

Farbige Ausgabe war leider noch nicht möglich. Am Composite Ausgang hab ich nur ein verzerrtes Grisseln, welches sich aber mit Änderung des Bildschirminhalts ebenfalls ändert. Den RGB Ausgang hab ich noch nicht ausprobiert, da muss ich erst noch ein Kabel suchen. Ich hoffe mal, dass mein ausgelöteter CXA2075 Farb Encoder nichts abbekommen hat. Wäre eventuell doch besser gewesen, einen zu bestellen, oder doch lieber Transistor Endstufen zu nehmen und auf S-Video zu verzichen. Morgen gibt es dann weitere Programmier Experimente mit der VPU.

Uuuuhhh, 80 Zeichen !!!

Ich hab jetzt mal das Taktsignal für die PAL Trägerfrequenz angeschaut. Das RC Glied am Ausgang des Clock Generator sollte eigentlich dafür sorgen, den Takt mehr nach einer Sinuskurve aussehen zu lassen - wie vom CX2075 wenn möglich verlangt. Dabei ist aber der Signalpegel zu klein geworden und der Farb Encoder hat gar keinen Takt mehr bekommen. RC überbrückt - und schon klappt es. Zu mindest am RGB und S-Video Ausgang kommt jeweils ein schlüssiges Signal. Zu mindes sieht für mich das S-Video Signal nach Luma/Chroma aus.

Jetzt müssen nur noch die richtigen Kabel gefunden werden.

Bin jetzt gerade etwas frustriert.

Ich hatte mir gestern noch ein DB9 auf Scart Kabel gebastelt und es gerade ausprobiert. Auch hier kein Farbbild. Also nochmals Oszi an die Ausgänge des CXA2075 und wie befürchtet, es kommen keine Signale aus den R-G-B Ausgängen. Ebenfalls tot ist der Chroma Ausgang. Luma zeigt ein seltsames Verhalten. Der RGB Encoder ist also doch futsch. Beim runter löten sind dann gleich noch zwei nicht unwichtige Lötpads mit abgegangen .

War ja klar, dass sich der Einsatz der mistigen SMD Bauteile irgendwann rächen würde.

Wenigstens funktioniert die Schwarz-/Weißausgabe noch. Ich kann also weiter mit der Programmierung der verschiedenen Modi herumexperimentieren.

Ich bin gerade am Überlegen, eine neue Platine entweder nur mit Mono BAS Ausgang und RGB für SCART (bzw. auch Commodore 1083S o.ä. Monitore) zu machen, oder auf den CXA1645P umzuschwenken. Der ist im wesentlichen Identisch zum CXA2075, aber eben noch im DIP Gehäuse erhältlich (UTSource).

Der CXA1045P wäre auch eine Alternative. Dieser war z.B. in der Amiga 600 und der NeoGeo verbaut. Allerdings ist hier mehr Aufwand für den FBAS Ausgang zu betreiben, da er keine interne Verbindung zum CVOut Mixer hat und deshalb extern noch Verzögerungsschleifen braucht. Der Baustein wäre aber etwas besser verfügbar.

Eventuell könnte man auch die RGB Transistor Endstufen für SCART auf die Hauptplatine und den RGB Encoder für FBAS und S-Video über eine kleine optionale Platine realisieren. Dann wäre ein Experimentieren mit den verschiedenen Bausteinchen nicht gleich wieder so eine teure Angelegenheit und könnte (soweit keine SMD Bauteile) zum Testen auch via Lochrasterplatine aufgebaut werden.

Wie auch immer, ich werde jetzt mal schauen, alle Funktionen auf der Platine, soweit möglich, mit Treibern zu unterstützen und dann gibt es eine neue Platine, die dann auch die bereits gepatchten Leitungen enthält.

Tut mir leid für alle, die auf die Platine gewartet hatten. Ich hab natürlich immer noch vier Platinen für unerschrockene Early Adopters übrig, weiss aber nicht, ob der CXA2075 durch das erstmalige Auslöten von der im Keller gefundenen Decoder Platine schon beschädigt wurde, oder es doch noch einen tötlichen Fehler auf meiner Grafikkarte gibt.

Jetzt gibt es erst mal eine Tafel Schokolade um wieder glücklich zu werden .

PS: Sorry Norbert, PACMAN muss also leider noch warten

Zitat von trazom

Den CXA1145 aus dem A600 kann ich dir in größeren Mengen besorgen

Das wäre natürlich Klasse. Ich melde mich morgen mal via PM bei dir.

Jetzt war dann doch mal wieder eine arbeitsreiche Woche, weshalb ich mich garnicht um den Junior kümmern konnte.

Gestern hat mich dann aber das SD Karten Problem umgetrieben.

Der Stand war ja, dass ein paar Karten nur direkt nach dem Einschalten funktionierten, nach einem Reset des Juniors aber nicht mehr gefunden wurden. Erst ein Ausschalten, 40 Sekunden warten und wieder Einschalten ließ diese Karten wieder zum Leben erwecken, eine 64GB Karte wurde problemlos immer erkannt.

Bei einer weiteren 8GB Karte hatte ich folgendes Problem: Einschalten - die Karte wurde - meist - erkannt und der MBR Boot Manager gestartet. Nach Auswahl einer Partition wurde dann manchmal der Boot Block gelesen - manchmal aber auch nicht. Sprich das ganze war jetzt ein Glücksspiel.

Aufgefallen ist mir jedenfalls, dass der Kartenslot manchmal ein Kontaktproblem hat. Die oben erwähnte 64GB Karte wurde nämlich manchmal nach dem Einstecken ebenfalls nicht erkannt. Aus- und wieder Einstecken, und das Problem war dann hier behoben. Das konnte ich auch bei den anderen Karten beobachten. Allerdings ließen sich ja dadurch nicht die Leseprobleme nach einem Reset erklären.

Mein erstes Vorgehen war jetzt, die Initialisierungsphase zu verlängern. Die SD Karte wird direkt nach dem Einstecken im Native Mode betrieben, wofür die vier Datenleitungen DAT0..DAT3 der Karte benötigt würden. Ein Umschalten in den SPI Modus geschieht durch senden von mindestens 74 Takten bei nicht selektierter Karte, also /CS = High. Ich hatte da bisher 80 Takte gesendet. Jetzt bin ich auf das vierfache, also 320 Takte umgestiegen. Der Effekt war, dass die erwähnte 8GB Karte nun immer nach dem Einschalten erkannt wurde. Ebenfalls muss nun nach dem Aus- und wieder Einschalten nicht 40 Sekunden gewartet werden. Also ein erster Erfolg. Allerdings wollte die 8GB Karte trotzdem nach dem Lesen des MBR Boot Managers manchmal einfach von dort nicht weiter machen. Da ich mit der alten IO Platine mit genau dieser SD Karte ständig herum experimentiert hatte, wusste ich, dass es hier also eher ein Problem mit der neuen Schaltung geben musste.

Da mich ja auch einige darauf hingewiesen haben, dass bei anderen Projekten mit SD Karte DAT1 und DAT2 nicht verbunden und offen in der Luft hängen, hab ich also mit dem Cutter Messer die entsprechende Verbindungsleiterbahn durchtrennt und...keine Änderung.

Also mal den Logic Analyzer an die SPI Schnittstelle (Ausgänge des 4050 CMOS Hex Buffers für das Level Shifting) gehängt. Test aller Karten: OK !!!!

Test Clips wieder weg...Karten sporadisch wieder nicht erkannt.

Ja hab ich denn versehendlich einen $c#€i$$ Quanten Computer gebaut, bei dem die Messung den Zustand verändert???

Test Clips dran...Karten wieder alle erkannt. OK, vielleicht ist im Analyzer irgendein Widerstand gegen VCC oder so verbaut. Also Stecker aus dem Analyzer gezogen, Test Clips noch am 4050, Einschalten - geht. Reset - geht wieder. Nochmal Reset - geht. Wow, jetzt wird es echt gruselig

Test Clips einzeln weg. Bei bei Pin 4 (MOSI) fängt der Mist wieder an zu spinnen.

Ich hab dann mal alle Clips bis auf den an MOSI getrennt: Tut. Clip von MOSI weg: Spinnt rum.

Nächster Versuch. Clip mit Leitung an 10K Widerstand und den Widerstand an +3,3V. Vielleicht braucht MOSI ja einen Pull Up. Tut. Hurraaaa. Also 10K Widerstand zwischen Pin 1 (3,3V) und Pin 4 (MOSI) des 4050 gelötet. Einschalten: Nun wird garkeine Karte mehr erkannt, nicht mal die 64GB Karte die vorher, mit oder ohne Clips tadellos funktionierte. Widerstand wieder weggelötet. Mit 64GB Karte booten...geht. Andere Kartren rein. Mal geht es, mal wieder nicht.

Langsam bin ich Blutdruckmäßig im oberstern Bereich.

Nächster Versuch. Alle Clips weg, einschalten, rechner bootet von 16GB Karte. Reset, Karte nicht gefunden. Breadboard Kabel an Pin 4 halten, Reset...tut. Kabel weg, Reset...tut nicht. Nochmal Reset...tut nicht. Kabel dran, Reset...bootet

WTF...was für ein mistiges Problem ist das denn? Kann mir das jemand erklären?

Zu Erläuterung:

- Defekter 4050 kann ausgeschlossen werden. Hab bereits 5 andere probiert.

- Gebrochene VIA oder Leitung? Dann würde die 64GB Karte auch nicht funktionieren.

- Offene Eingänge am 4050. Nein, alle nicht benötigten Buffer sind Eingangsseitig auf GND.

- Zu niedrige Versorgungsspannung des 4050? Exakt 3,3V, sollte also OK sein.

- Software Problem? Hat mit fertig aufgebauten SD-Kartenmodul fabelhaft funktioniert.

Also ich bin mit meinem Latein am Ende. Muss ich jetzt an die MOSI Leitung eine Antenne basteln, damit die SD-Karte läuft?

Klar ist, dass es sich um irgendeinen Efekt bzgl. CMOS handelt. Nur welchen, das erkenne ich gerade überhaupt nicht. Hat jemand einen Vorschlag?

Logic Analyzer an den Eingängen des 4050 - "Antenne" an Ausgang Pin 4 (MOSI)

Logic Analyzer an den Eingängen des 4050 -ohne "Antenne". SD Karte gibt kein Response

Hängt der Analyzer an den Ausgängen des 4050 geben die Karten immer ein Response.

Rechner Reset mit "Antenne"

Rechner Reset ohne "Antenne"

Hallo Reinhard, danke für dein Feedback.

Ich hab jetzt sowohl 10pF als auch 22pF zwischen MOSI unhd Masse gehängt. Offensichtlich bügelt der Kondensator dann das Signal vollständig weg. Auch die 64GB Karte bootet damit dann nicht mehr. Ohne läuft sie wieder.

Ich hab jetzt nochmal die Spannung am 3,3V Regler gemessen. Dieser hat jetzt gerade tatsächlich 4,09V, also viel zu hoch. Gestern hab ich noch 3,302V gemessen. Ich werde den Regler morgen mal tauschen. Stellt sich die Frage, was den geschossen hat.

Eventuell werde ich auch mal einen 7417 Buffer mit Open Collector anstatt des 4050 ausprobieren.

PS: Wärend ich gerade den letzten Satz geschrieben habe, ist der Regler auf 4,9V durchgebrochen.

Hallo Reinhard, ich prüfe das morgen mal. Hab heute echt die Nase voll. Dank dir einstweilen. Ich melde mich, sobald ich nochmal alles durchgegangen bin.

Der Spannungsregler ist getauscht. Allerdings spackt der SD Leser immer noch. Ein, wie von Reinhard vorgeschlagener 10-45pF Kondensator von MOSI gegen Masse stört das MOSI Signal so stark, dass eine Datenübertragung nicht mehr möglich ist.

Alternativ habe ich jetzt mal zuerst einen 100K Ohm und dann einen 6,6K Ohm Widerstand von MOSI gegen Masse geschaltet. auch dass hat nur einen minimal besseren Erfolg. Der Leser läuft zwar nach dem Einschalten, und es sind zwei, drei Resets möglich, dann fängt das Problem aber wieder an.

Ich hab jetzt, um endlich mal wieder an was anderem Arbeiten zu können, einfach einen Clip mit ca. 10 cm angeschlossener Leitung an Pin 4 des 4050 gehängt.Der Rechner bootet jetzt normal, lässt sich beliebig oft resetten und raubt mir erst mal nicht den Nerv.

Ich vermute, dass der CMOS Ausgang irgendein kapazitives Problem mit der/den eingelegten Karte(n) hat. Welche Maßnahme dagegen hilft, ist mir gerade noch ein Rätsel. Die "Antenne" (wie ich sie mittlerweile liebevoll nenne ) kann natürlich nicht der Weisheit letzter Schluss sein.

Ich bin - wie Reinhard ja auch - der Meinung, dass eine Level-Shift Lösung mit Open Collector nicht wirklich ideal ist, weil dadurch natürlich bei hohen Frequenzen die Signale verschliffen werden. Das war ja auch der Grund, warum ich zum 4050 gegriffen hatte. Eventuell ist aber ein 74LVC245 ebenfalls für das Level-Shifting geeignet und macht weniger Probleme als der 4050 CMOS Buffer. Ich werde da mal experimentieren.

Dennoch, falls irgend jemand einen Hinweis hat, was das Problem sein könnte, soll er sich bitte melden. Bloss nochmal zur Erinnerung wie der Schaltungsteil gerade aussieht:

Bis zur Klärung des Sachverhaltes bleiben mal die neuen IO Platinen noch bei mir im Schrank (sorry) und die Karte für mich erst mal nebensächlich.

Ich werde als nächstes wohl die Grafikarte so abändern, dass ich über eine Steckmodul einen Farb Encoder aufflansche. Dann kann man mal mit den verschiedenen Varianten (CXA1145P, CXA1645P, etc) rumexperimentieren, ohne die Grafikkarte ständig ändern zu müssen. Für alle, die auch keinen FBAS und/oder S-Video Ausgang benötigen wäre eine solche Karte dann auch optional.

Hallo Thomas,

ich hab die restlichen drei Gattereingänge alle auf GND liegen.

PS: Schön wieder was von dir zu hören

Ich hab gerade den Test mit einem 74LVC245 gemacht. Da die LVC Bausteine bei 3,3V Versorgungsspannung an den Eingängen eben auch TTL Pegel verarbeiten können sind sie auch wunderbare Pegelwandler.

Was soll ich sagen, keine Probleme mehr beim Booten. Egal wie oft ich eine Karte resette, Ein- und Ausschalte, Karte bei eingeschalteten Rechner tausche und dann einen Reset mache, die Karten werden sofort erkannt. Als ich den MOSI Aussgang mit dem Oszilloscope untersucht habe, gab es dann nach einigen Resets wieder vereinzelt Probleme. Offensichtlich hat hier die Messleitung eher Störpotenzial. Ohne läuft die Schaltung jetzt aber wie mit dem fertigen SD-Karten Modul von AZ-Delivery.

Ich weiß schon, warum ich die 40xx CMOS Bausteine immer gemieden habe. Da gibt es zwar ein paar interessante Funktionsbausteine, aber das ganze ist doch wesentlich empfindlicher als die 74xx TTL/CMOS Familie. Ich vermute, dass sich beim 4050 der Ausgang nach ein paar Pegelwechseln kapazitiv aufgeladen hat und manche Karten dann keinen definierten Logik Pegel mehr lesen konnten. Da ich aber beim Anschluss des Oszis oder des Logic Analyzers das Phänomen durch die Messelektronik beseitigt hatte gab es auch nie die Chance den Fehler zu beobachten.

Da die SPI Schnittstelle beim Junior ][ mit gerade mal PHI2 / 2 also 500KHz läuft (was aber wesentlich schneller als die Bit-Banging Lösungen in anderen Schaltungen ist), sollte die SPI Taktfrequenz eigentlich kein Problem darstellen. Na ja, wie auch immer. Ich werde als Übergang den 74LVC245 bei mir erst mal auf dem Lochrasterfeld der IO-Platine unterbringen. Eine neue Platine werde ich dann zeitgleich mit dem geänderten Floppy-/Grafik-Controller bestellen.

Hallo Dietrich,

das kann ich glaube ich alles ausschließen. Den 74LVC245 hab ich gerade frei fliegend über das Breadboard auf den Sockel verbunden.

D.h. die letzten cm Leitungsverbindungen zum Kartenadapter sind die gleichen wie beim 4050. Ich hab die jetzige Schaltung so sehr gestreßt wie nur möglich und hab keine Ausfälle mehr. War also ganz klar ein Problem mit dem 4050. Beim 74LVC245 hab ich durch das 20 polige DIP Gehäuse allerdings einen echte Platzmangel. Der 4050 hat mit dem 16 pol Gehäuse gerade in die Lücke vor dem SD-Sockel gepasst. Ich werde deshalb wohl einen 74LVX08 (AND Gatter im SOP Gehäuse) einsetzen. Der lässt sich noch gut von Hand löten und tut es als Pegel wandelnder Buffer ja genauso.

Der 74LVC245 ist jetzt auf dem Lochrasterfeld und alles funktioniert so wie es soll.

Auf der neuen Platine setzte ich jetzt doch auch den 74LVC245 im DIP Gehäuse ein. Er hat doch noch super in die Lücke gepasst.

Es gibt allerdings dennoch ein paar SD-Karten, die absolut nicht laufen. Ich vermute, das liegt daran, dass ich die SD-Karten im Modus 3 laufen lasse, was bedeutet, das der SPI Takt mit der fallenden Flanke die Daten schiebt und diese dann gelatched werden. Das sollte mit den meisten Karten auch funktionieren. Allerdings ist Modus 0 wohl der übliche Modus, bei dem mit steigender Flanke gelatched und dann erst geschoben wird. Auf der Seite elm-chan.org liest sich das dann so: "Thus the SPI mode 0 (CPHA=0, CPOL=0) is the proper setting to control MMC/SDC, but mode 3 (CPHA=1, CPOL=1) also works as well in most case".

Bei mir gibt es von 11 getesteten Karten gerade drei, die nicht funktionieren. Dabei scheint sowohl der Hersteller als auch die Kartengröße egal zu sein. Zum Beispiel laufen bei mir alle SanDisk Karten, bis auf die 32GB Ultra. Bei den 64GB Karten möchte eine nagelneue Philips Ultra Pro nicht mit dem Junior zusammenarbeiten, und eine alte1GB noname Karte verweigert sich ebenso.

Gute Karten...

Schlechte Karten...

Nachdem jetzt das booten soweit wieder funktioniert, kann ich mich wieder an @Dietrichs CPM-65 erfreuen, dass meines Erachtens nach jetzt schon wunderbar funktioniert. Ich möchte ihm da jetzt nichts vorweg nehmen. Aber er hat da ganze Arbeit mit der Portierung geleistet. Ich wünschte, bei mir würde es so schnell voran gehen.

Ich hoffe Dietrich schreibt hier im Forum auch noch etwas über sein Betriebssystem.

Oh je, da muss ich jetzt wohl das Büßer Hemd anziehen...

mit meinem letzten Anhang der ASCII Keyboard Firmware hat sich tatsächlich ein Bild mit den alten, und somit falschen, Fuse Bits für den ATMega 32 eingeschlichen.

audiokit_nl hatte deshalb auch erst mal eine nicht funktionierende Tastatur.

Ausserdem war zweimal die US Belegung in der Zip statt einmal US und DE. Ich hatte aber ja versprochen, mich um dieses Problem auf besondere Weise zu kümmern. Sowohl bei der alten Rev. 1, als auch bei der neuen Rev. 2 Tastatur kann nun mit der neuen Firmware via Jumper P1 zwischen US und DE Belegung umgeschaltet werden. Auf der Rev. 2 kann auch P0 noch für weitere Layouts genutzt werden. In der Rev. 1 sind die Jumper leicht anders belegt, da zunächst ja für die Umschaltung zwischen ASCII Parallel und einer angedachten PS/2 Schnittstelle vorgesehen war.

Die neue Firmware funktioniert mit beiden Platinen Revisionen, da hier dann auf den externen Quarz verzichtet wird.

Nach dem Ändern des Tastatur Layouts, muss der Rechner entweder neu eingeschaltet werden, oder ein Neustart über die Reset Taste des Rechners gemacht werden. Ein Reset über Ctrl-Shift-Del an der Tastatur liest die Jumper Konfiguration NICHT neu ein!

######################################

Alle die das ASCII Keyboard gerade nachbauen, sollten bitte die angehängte neue Firmware mit den entsprechenden Fuse Bits programmieren.

######################################

Ein weiterer Fehler mit der Revision 2 Platine ist mir aufgefallen, als ich gerade eine solche aufgebaut habe, nachdem Edzard so lieb war, mir eine von seiner letzten Bestellung zukommen zu lassen. Auf der Rev. 2 nutze ich nicht mehr einen 16 pol IC Sockel für die Verbindung zum Rechner, sondern eine gewinkelte 2x8 Stiftleiste. Beim Verbinden mit dem Junior 2 tat sich dann garnichts. Das Problem liegt im IC Stecker des Flachbandverbinders verborgen. Pin 1 des Flachbandkabels liegt bei diesen Quetschverbindern nämlich nicht auf Pin 1 des Steckers, sondern auf Pin 16 !!!

Wird also ein normaler 2x8 Quetschstecker auf der andere Seite angebracht, liegen hier die Pin Paare 1-2, 3-4, 5-6 und 7-8 vertauscht vor. Das lässt sich zwar durch auftrennen des Flachbandkabels und drehen der Leitungspaare beheben, ist aber ein ziemliches Gefummel.

Auf der Rev. 1C IO-Platine werde ich deshalb wohl beide Steckertypen unterstützen.

Bei der Grafikkarte bin ich jetzt durch einen billigen NTSC zu PAL Konverter doch noch zu einer Farbausgabe gekommen. Diese war bei mir allerdings extrem schlecht.

Eine Untersuchung der Horizontal und Vertikal Sync Pulse hat für mich eine Überraschende Erkenntnis gebracht. Diese sind nämlich (so zu mindest meine Annahme) VGA kompatibel. Ich werde jetzt mal den Test machen, mit einem LM1881 Video Sync Separator das V-Sync Signal aus dem Composite Sync Signal zu extrahieren und dann zusammen mit den R,G und B Signalen auf einem VGA Monitor auszugeben.

Endlich war mal wieder am Wochenende etwas Zeit, um ein wenig am Junior DOS weiter zu programmieren.

Den erste Teil für den DIR Befehl konnte ich jetzt mal soweit fertig stellen. Hierbei wird zunächst nur das Root Directoy des ersten Verzeichnisblocks der SD Karte ausgegeben, der beim Booten bereits geladen wurde.

Jetzt steht noch die kleine Fleißarbeit an, die nächsten Blöcke für die verschiedenen Verzeichnistypen (FAT12/FAT16 Root-Direcoty, FAT32 Root-Directory, Unterverzeichnisse alle FATs) zu laden. Da die alle etwas unterschiedlich gehandhabt werden, ist das leider mal wieder nicht ganz so einfach.

Der LM1881 Sync Seperator ist jetzt übrigens auch eingetroffen, womit ich dann mal ausprobieren kann, ob ein Multi Sync VGA Monitor was mit den 15KHz Zeilenfrequenzen des V9938 anfangen kann, oder ob er sich da doch verschluckt.

PS: Jetzt ist mir gerade aufgefallen, dass ich die aktuelle Laufwerks Nummer durch den DIR Befehl überschrieben habe (sieh oben: Aus C: wird A:). Fehler ist jetzt schon gefixt

Zitat von 286Micha

Wahnsinn Jörg!

was du da als "One-Man" show so leistet !! meinen größten Respekt..

wenn Commodore solche Mitarbeiter schon Mitte der 70ziger gehabt hätte... hätte man den KIM1 direkt

übersprungen und einen 128er gebracht

ich bin weiter gespannt
LG Micha

Alles anzeigen

Oh je, dann wäre Commodore wahrscheinlich schon in den 70er Jahren Pleite gegangen, so schlecht wie die Verkaufszahlen des C128 waren.

Ja, das stimmt schon. Und es lag wahrscheinlich ja auch nur daran, dass die Zeit der 8 Bitter da schon vorbei war. Der C128 hatte das gleiche Problem wie der Apple IIgs. Die kamen einfach zu spät auf den Markt.