Posts by Snear

    Ich habe endlich die Zeit gefunden mich mal um meine beiden Amiga 600er zu kümmern - und ich vermute ich bin spät dran. Beim ersten funktionierte die Festplatte nicht mehr. Da ich sowieso ein neues OS raufspielen wollte, habe ich in mühsamer Arbeit das ROM gesockelt habe (2 häßliche Brücken :( musste ich dabei setzen), wollte ich einen Recap vornehmen, da an der einen oder anderen Stelle schon "Grünspan" zu sehen ist. Ich habe da IDE-Kabel abgezogen und in dem Kabel sind 4 Pins steckengeblieben. Die anderen sind auch schon halb abgerottet. :( Das Board wird noch viel Arbeit kosten... wobei es ja immerhin anläuft.


    Meine Frage bezieht sich auf das zweite Board: das habe ich irgendwo mal gebraucht gekauft und es hieß, dass mal ein Recap gemacht wurde. Stimmt das? Die Fotos sehen nicht danach aus. Allerdings sehe die Ersatzkondensatoren, die ich habe, alle genauso aus. Vielleicht kann ja einer von euch erkennen, ob hier schon mal jemand dran war... Falls es Recap gemacht werden muss, werde ich es auf jeden Fall irgendwo einschicken und machen lassen. Ich selbst musste beim Sockeln des ROMs wieder feststellen, dass ich beim Auslöten ein ziemlicher Trampel bin.

    Schneller wird dadurch nichts.

    Wieso? Compiler erzeugen doch seit geraumer Zeit fleißig SSE Instructions, sicher nicht ohne Grund?

    Ja, wobei ich das Wort "fleißig" streichen würde. Das ist eher die Ausnahme, weil die Situationen, in denen SSE einen Geschwindigkeitsgewinn versprechen würde, gar nicht so leicht zu ermitteln sind. Ein (nicht SSE)-Beispiel: du zählst die Anzahl der gesetzen Bits in einem Register per Schleife. Es ist ein hartes Stück Arbeit einem C-Compiler beizubringen, dass er das doch bitte gegen POPCNT austauschen soll. Als Entwickler nutzt mal da lieber gleich die Compiler-Erweiterungen, um sicherzugehen, dass SSE & Co auch wirklich benutzt werden.


    Ich vergleiche mal SSE mit den funktionierenden illegalen Opcodes vom C64. Würdest du die bei einem C-Compiler einschalten, nur weil sie ein Geschwindigkeitsgewinn von vielleicht 0,2% versprechen oder ein 10KB-Programm 10 Bytes kleiner machen? Also ich nicht. :)

    Danke für den Tipp! Salix Linux läuft tatsächlich... so ein bisschen zumindest.

    Schonmal Peppermint ausprobiert? Damit habe ich ganz gute Erfahrungen gemacht.

    https://distrowatch.com/table-…p?distribution=peppermint

    Auch hier: Minimum i686. Bei Anwendungen kann ich es verstehen, aber warum man SSE im Kernal braucht, bleibt mir ein Rätsel. Schneller wird dadurch nichts. Microsoft ist erst 2018 auf i686 umgestiegen. Irgendwann ab Mitte 2018 konnte man die Updates ohne SSE nicht mehr installieren. Bis dahin hätte ich auf der K6-3-Kiste auch noch Windows 7 benutzen können. Bei Salix-Linux war die einzige "große" Anwendung, die problemlos lief, GIMP - und ausgerechnet die würde massiv von SSE profitieren.

    Hat jemand das C=Key von Jim Brain im Einsatz? Leider finde ich kein Foto im Netz was den Anschluss betrifft. Mein größtes Problem: wo versorge ich das Ding mit Spannung? Auf dem Board sind VCC und GND nicht markiert und aus dem Schaltplan werde ich nicht schlau...

    Dann bin ich mir auch etwas unsicher, was den Anschluss an den Pfostenstecker des C64 betrifft. Ich vermute auf der Unterseite auf dem Foto ist eine Buchsenleiste gelötet, so dass man das C=Key direkt auf den C64 stecken kann. Passt beim C64-1 natürlich perfekt, nur beim C64-C sind da Elkos im Weg. Kann ich die Buchsenleiste also weglassen und verbinde C64 und C=Key über die Steckerleiste mit einem Flachbandkabel?


    Im Anhang ist das Foto von Jim Brains Webseite.

    Snear Wenn du Linux tatsächlich mit Windows XP vergleichen willst (was Genügsamkeit angeht), dann solltest du fairerweise auch ein Linux aus der damaligen Zeit einsetzen, und kein modernes 'Tiny-' Linux von heute.

    Es geht ja darum aktuelle Software einzusetzen - zumindest bei Mail-Client und Browser ist das schon aus Sicherheitsgründen geboten. Bei einem Ubuntu von 2004 kann ich den Firefox mit Glück auf 2.0 updaten. Ich bezweifle, dass ich damit im Netz weit komme. :) Ich werde es aber mal ausprobieren.

    Snear


    Probier doch mal Linux Salix hab Ich auch auf Rechner installiert wo sonst nur XP rund lief muss sagen es läuft Super musste nur noch ein Wi-Fi client nachinstallieren und halt die updates machen.


    Linux Puppy gibt es auch noch aber Linux Salix läuft besser

    Danke für den Tipp! Salix Linux läuft tatsächlich... so ein bisschen zumindest. :) Es bootet in respektablen 2:16 (XP 0:41), aber alles Weitere ist relativ unbrauchbar. Im "Notepad" kommt ein Tastendruck mit 1-2 Sekunden Verzögerung an, im Terminal sind's noch mehr. Der Mauszeiger flimmert und flackert wie verrückt, Fenster bauen sich selbst unter GEOS schneller auf. Ich werde mal ein paar Videos davon machen. Firefox und LibreOffice crashen übrigens schon beim Start - ich vermute, die sind mit SSE kompiliert worden, was der K6 nicht hat. Updates konnte ich nicht durchführen, weil sich das Terminal auch laufend aufhängt. Wird die Distribution überhaupt noch mit Updates versorgt?

    Ich weiß, es gibt schlanke Distributionen - aber die führen eine Nischendasein, kommen und gehen im Jahrestakt und laufen auf einem PC < 1 Ghz mehr schlecht als recht. Es kann doch eigentlich nicht sein, dass Windows XP für so eine alte Kiste immer noch das beste Betriebssystem ist.

    Ich weiß nicht genug, um es wirklich beurteilen zu können, aber ich fürchte, ich muss dir tendentiell recht geben. Drum benutze ich in erster Linie Lubuntu (und vielleicht dann noch irgendwas anderes, wenn es sein muss).

    Ich sehe es nämlich so, dass das OS möglichst bescheiden und schlank sein soll, und sich im Hintergrund aufhalten. Ich habe nichts von einem OS, das sich vordrängt, mir eine Milliarde Bunti-Klicki-Optionen aufs Aug drückt, die ich allesamt nicht brauche, und dafür gleich einmal 60% der Ressourcen des Rechners besetzt. Das ist ja haargenau das, was ich an Windows NICHT mag.

    Ich hätt einfach nur gern ein OS, das möglichst lange - über Jahrzehnte, wenn geht - stabil bleibt, und alles andere mag sich dann über zusätzliche SW ergeben.

    Genau das wünsche ich mir auch - ein OS, das über Jahrzehnte hinweg Support bekommt und bei dem sich die Entwickler ausschließlich um Bugfixes und Anpassungen an neue Hardware kümmern und den Rest anderen überlassen.


    Ich hatte gerade wieder Spaß mit Linux. Eigentlich wollte ich meine These "bei alten Kisten hilft nur XP, weil schlanke Linux-Distributionen unbrauchbar sind" durch ein paar Tests auf meinem K6-3 mit 550Mhz und 768MB Ram untermauern und ein paar Linux-Distrubutionen testen, um zu zeigen, das vom Bootvorgang (XP: 41 Sekunden) bis zum Öffnen eines aktuellen Browsers (XP: 6 Sekunden) und Laden der Forum64-Seite (XP: 11 Sekunden ohne JS, 20 mit JS) so eine Linux-Distribution sehr viel mehr Zeit benötigt.


    Nach der 3.Distribution habe ich aufgegeben. SliTaz Linux kommt mit Midori-Browser und behauptet auf einem 486er mit 24 MB RAM zu laufen - bei der Installation heißt es dann aber, dass der Kernal CMOV braucht, das es erst ab PII und K7 gibt. Ohne Worte. ;( Bodhi-Linux lehnt sich nicht ganz soweit aus dem Fenster. 500Mhz und 256 MB Ram sind Minimum. Auch hier: nix geht ohne CMOV. Puppy Linux redet von 333Mhz und 64 MB Ram, braucht aber bei der Installation neben CMOV auch noch PAE. Das gibt's bei AMD erst ab K8. Ich hätte im schlimmsten Fall damit gerechnet, dass ich zum Messen der Zeiten bei Linux keine Stoppuhr mehr brauche, sondern einen Kalender, aber selbst diese Erwartungen ist noch enttäuscht worden... :) Fairerweise möchte ich erwähnen, dass Linux auf meinem Server und meinen Routern wirklich prima läuft.

    Ich glaube aber, die Leute hinter Linux sind viel zu vielfältig und unorganisiert und desinteressiert an sowas wie "Erfolg". Man (also der Entwickler, nicht der User) hätte ja nichts davon, wenn die User-Zahlen in die Höhe schnellen würden. Warum sollte man das also forcieren? Von daher glaube ich, dass in erster Linie nicht der "böse Markt" Schuld an der Stagnation ist, sondern die Tatsache, dass gar kein Wille da ist, größer zu werden. Ich glaube, da würden mir viele OpenSource-Entwickler zustimmen. Wirkt ja irgendwie auch ganz sympathisch, wenn man nicht an diesem "Höher/Weiter/Schneller" teilnimmt und mit dem Status quo zufrieden ist.

    Linux steckt doch voll drin in dem "Höher/Weiter/Schneller". Der Kernal wächst und wächst, es wird immer die allerneuste Hardware unterstützt und die GUI wird ständig neu auf Hochglanz poliert. Die Systemanforderungen steigen mit jedem Release. Man hat einen Kampf gegen Microsoft und Apple aufgenommen, den man aber nie gewinnen wird. Da draußen gibt es theoretisch Milliarden von Computer, die für 95% der User ausreichend schnell und zugleich spottbillig sind. Einen einfachen Thin Client gibt's für einen Zehner. Man könnte damit im Netz surfen, Mails und Briefe schreiben, Fotos bearbeiten, Videos schauen usw... Diese PCs werden vom MS & Co. im Stich gelassen - weil das eben keine zahlungskräftigen Kunden sind, die immer den heißesten Scheiß haben wollen und von Werbung angefixt werden. Wenn Linux die Menschen abgreifen würde, die keine Lust oder kein Geld haben sich ständig etwas Neues zu kaufen, dann würde man Marktanteile erobern, weil Leute zu Linux wechseln, die keinen funktionsfähigen PC auf den Schrott werfen wollen. Ich weiß, es gibt schlanke Distributionen - aber die führen eine Nischendasein, kommen und gehen im Jahrestakt und laufen auf einem PC < 1 Ghz mehr schlecht als recht. Es kann doch eigentlich nicht sein, dass Windows XP für so eine alte Kiste immer noch das beste Betriebssystem ist.

    Es gibt dazu spezielle Handbücher, wo für Bauteile ein λ (Lamda) Wert angegeben ist.

    Daraus lässt sich dann MTTF (Mean time to Failure) berechnen. Also die mittlere Dauer bis zu einem Ausfall.

    Anhand spezieller Modelle kann man dann Systeme durchrechnen, wann mit einem Ausfall zu rechnen ist.

    Bzw. kann man dann Systeme so konstruieren, dass sie länger halten. Bei Systeme wo das z.B. gefordert wird (Flugzeuge, Raumfahrt, ...)

    Bei Spezialhardware für kritische Systeme mag es so etwas geben und Werte für MTTF auch Hand und Fuß haben, aber das Hauptinteresse hier liegt ja bei Consumer-Hardware. Heute sind die Strukturen in Chips ja deutlicher kleiner als vor 35 Jahren - dafür die Spannung sehr niedrig, was sich sicher positiv auf die "Lebenszeit" auswirkt. Wo ist die goldene Mitte? Gibt es irgendeine Generation von Chips, die besonders lang- oder kurzlebig ist? Ich höre immer nur "30-40 Jahre", aber dass das auf alle Chips bei so unterschiedlichen Fertigungstechniken zutrifft, erscheint mir doch etwas seltsam.

    Das mit dem Markdown Texteditor finde ich ja super, genau wie vielleicht ein Dateimanager. Auf der anderen Seite habe ich gerade überlegt wann ich Markdown schreibe. Das wäre wenn ich was neues lerne, sei es wie jetzt 6502 Assembler und Democoding oder sonst was. Dann probiere ich Sachen aus und/oder Recherchiere und nebenbei ist immer mein Texteditor auf und ich notiere meine Sachen. Es ist also immer ein Zusammenspiel von mehreren Programmen. Nie habe ich den Editor als einzelne Anwendung offen, es ist immer ein Miteinander. Nun zu meinem Problem. Wenn ich am PC was mache wie Programmieren oder ein Thema/Technologie verstehen, dann würde ich nicht für meine Notizen zum C64 wechseln. Denn der best mögliche Texteditor dort wäre noch viel schlechter als alles was ich am PC habe. Ein Totschlagargument wäre das Fehlen der Zwischenablage. Ich würde sicher nicht aus dem Netz kopiere Sätze oder Codeschnipsel 1:1 auf dem C64 abtippen, das wäre der Tod fürs Lernen neuer Sacher und ich würde unglaublich viel Zeit und Nerven verlieren. Damit ich also den C64-MarkDown Editor nutzen würde, müsste ich auch am C64 arbeiten und dafür ist er definitiv nicht geeignet, da kein Browser, PDF, ePup, IDE, Mutitasking/switching usw.

    Wenn der PC erstmal läuft, ist er ja super... aber bis dahin dauert's eben ein paar Minuten. Wenn ich mal kurz einen Taschenrechner brauche oder ein paar Notizen speichern will, schmeiße ich meist den MS-DOS-Rechner an. TSR-Taschenrechner, TSR-Notizblock. Einfach eine Tastenkombination und schwupps - das Textinterface ist da. Das schöne ist, dass ich alles im Netzwerk speichern und später am "richtigen" PC weiterverwenden kann. Ein Kalender wollte ich mir auch immer nochmal einrichten. Und dann ist da noch der Passwortmanager. So etwas würde ich niemals unter Windows benutzen - es ist ja gerade Sinn der Sache die Passwörter separat zu halten. Mal eben einen Wikipedia-Artikel aufrufen geht auch. Wenn ich dann noch ein Kartentool hätte, mit dem ich (vereinfachte) Navigationskarten aufrufen kann, würde ich den PC noch seltener anmachen. Ich muss dazu sagen, dass ich kein Smartphone habe. Wahrscheinlich macht die Masse der Menschen die Dinge, die ich gerade aufgezählt habe, mittlerweile damit. Aber all das Genannte könnte auch ein C64 übernehmen. Mein Problem ist immer, dass ich den Windows-PC eigentlich nur für 5 Minuten anmachen wollte, um etwas nachzuschauen, aber dann doch für Stunden festhänge, weil mir immer noch was Sinnloses einfällt, was ich dann noch mit erledigen könnte... :(

    So, das Ganze hat mir eine schlaflose Nacht beschert, aber ich habe es geschafft.


    U7 war nicht kurzgeschlossen - leider habe ich ein sehr träges Messgerät, das ewig braucht, um den Widerstand zu ermitteln. Und wenn ich merke, dass eine Verbindung da ist, dann warte ich gar nicht ab, was angezeigt wird, sondern gehe davon aus, dass die Pins verbunden sind und die Anzeige bei 0 Ohm landet. Die Ungeduld wieder... Tatsächlich besteht aber ein Widerstand von ca. 330 Ohm zwischen Pin 16 und 15. Bei U8 waren Pin 16 und 15 allerdings kurzgeschlossen - und das war der Fehler. Von Pin 15 führt eine Bahn rüber zur der vertikalen Leiterbahn neben U8. Die habe ich beim Entlöten getrennt. Ich schätze der Fehler ist mir nicht aufgefallen, weil die Leitung perfekt durch die aufgedruckte 16 läuft. Beim Löten von Pin 16 ist dann etwas Lötzinn auf die Vorderseite durchgesickert und hat sich an die offene Leiterbahn geschmissen.


    Meine 72x Chips haben überlebt - genau wie alle Speicherchips. Das einzige, was defekt ist, ist eine der 64K-Erweiterungen. Dort ist der 72x Chip (wieder ein anderes Modell) wohl durchgebrannt. Aber die andere, die ich noch hier liegen hatte, funktioniert, so dass der C16 jetzt 64K hat. Als nächstes kommt noch JiffyDos rein.


    Danke für eure Hilfe! Hätte ich allein nie hinbekommen.

    Edit: So nachgeschaut, selbe Geschichte bei U8. Kurzgeschlossen. Du hast nen ziemlichen Kurzen da auf dem Board oder beide Chips sind hinueber. Erstmal beide Chips raus so nicht betreiben und diesen Kurzschluss finden/loswerden. Ich finde es somit schwer zu glauben, da nichts heiss wurde.

    Bist du sicher? Masse ist doch eigentlich Pin 8, oder? Oder bedeutet "G" auch Masse?


    http://www.datasheetdir.com/SN…BN+Selectors-Multiplexers


    Ich bin der letzte, der sich mit Elektrotechnik auskennt, aber ein Chip zu designen, bei dem Masse und VCC direkt nebeneinander liegen, würde nicht einmal mir in den Sinn kommen. :)


    Ich bin mir 100%-ig sicher, dass zwischen 16 und 15 bei U8 eine Brücke auf der Vorderseite war. Im besten Foto, was ich im Netz gefunden habe (siehe Anhang), kann man sie zumindest erahnen.

    Ich nehme dieses Zitat mal als Grundlage für meine Meinung:

    Nein, das hast du falsch verstanden. Der Bitmap-Mode wurde deshalb von mir gewählt (und das habe ich mehrfach so kommuniziert), weil ich vor allem die extrem harte Beschränkung der 40 Zeichen/Zeile aufbrechen will. Hätte der C64 einen echten 80-Zeichen-Modus (wie viele seiner "Kollegen"), würde ich über Bitmaps wahrscheinlich gar nicht nachdenken.


    Der 2. Grund ist der beschränkte Zeichensatz. Im Charmode benötigt man nahezu zwingend invertierte Zeichen im Charset, was den Zeichen-Vorrat von 256 auf 128 Chars halbiert. Zudem benötigen viele Text-UIs "grafische" Chars fürs UI, was den Vorrat weiter dezimiert. Letztlich bleibt kaum mehr über als ein nackter ASCII/PETSCII-Buchstaben-Satz ohne internationale Belegung. Das konnte man vielleicht 1982 den privaten Kunden noch verkaufen aber heutzutage ist das eine Qual. Und zwar nicht nur, weil mir darüber Ä und Ö und ß und é und à und € und "bedingter Trennstrich" fehlen, sondern weil ich jeden blöden Textschnipsel zwischen C64 und PC konvertieren muss. Und ich will ja gerade die Zusammenarbeit von C64 mit der modernen Hardware-Landschaft verbessern. Denn einer meiner Grundgedanken war es, dass der C64 desto öfter von Fans benutzt wird, je weniger "sperrig" er sich gibt (nebenbei genau das Gegenteil von GEOS).

    Also zunächst einmal ist deine Motivation, nämlich den C64 für Dinge nutzbar zu machen, die technisch möglich wären, absolut löblich. Ich würde die Kiste viel öfter anreißen, wenn ich sinnvolle Dinge damit anstellen könnte. Und dann möchtest du auf jeden Fall eine GUI bauen. Zwischen den beiden Vorhaben gibt es definitiv eine Schnittmenge. Die Frage ist, ob die Schnittmenge hinreichend groß ist, um viele Nutzer zu begeistern. Klar - ein Kalender, der die Daten aus dem Internet synchronisiert, wäre fantastisch, aber meiner Meinung nach krankt es an anderen Stellen, wenn wir von echtem Nutzen sprechen. Der C64 hat letztlich drei Probleme, die ihn für einen "Bürorechner" disqualifizieren und zwei davon willst du anpacken: die mageren 40 Zeichen pro Zeile und fehlendes ASCII bzw. Latin-X. Das dritte Problem ist ein fehlendes DOS. Die Syntax für Disk-Operationen ist viel zu kryptisch. Ist es nicht seltsam, dass ich die SD-Karte aus dem SD2IEC nehme und in den PC stecke, nur um eine Datei in ein anderes Verzeichnis zu kopieren? Mag sein, dass es über einen irgendeinen Befehl geht, aber wie immer er auch aussieht: er ist garantiert zu kompliziert. Eigentlich müsste ich den C64 einschalten und einfach "cp 8:/games/choplifter.prg 9:/favorites" eingeben können. Warum ich stattdessen immer noch den BASIC-Interpreter beim Einschalten habe... ich weiß es nicht. :-)


    Am wichtigsten für so eine GUI wäre deshalb der Unterbau - also ein gutes Terminal. Wenn es erstmal ein "wget" gibt, dann kommen die Anwendungen von ganz allein. Die GUI ist dann am Ende das Sahnehäubchen - so war das bei Linux ja auch. Wenn man allerdings zum Abrufen der heutigen Termine und Geburtstage statt eines simplen "wget" zwingend eine ganze GUI-Anwendung bauen muss, wäre das mir persönlich schon zu viel um mich damit zu beschäftigen. Wenn ich es kann - toll. Wenn ich es muss - nicht so toll. :-)

    Ich bin in akribischer Arbeit nochmal alles durchgegangen. Bei den beiden Ramchips U5 und U6 sehe ich keine Probleme. Es gibt dort keine zwei benachbarten Pins, die kurzgeschlossen sind. Bei U7 und U8 sieht das anders aus. Da verstehe ich das Layout nicht so ganz. Bei U8 sind bei mir die letzten drei Pins (14,15,16) kurzgeschlossen.Warum ist auf der Oberseite zwischen 15 und 16 eine Brücke, wenn man die unten alle auf breite Leiterbahn hätte ziehen können? Bei U7 sind bei mir Pin 15 und 16 kurzgeschlossen. Ist das richtig so?

    Aus diesem Schaltplan hier werde ich nicht so richtig schlau: http://www.zimmers.net/anonftp…c16-251788-2of3-right.gif

    Es ist schon sehr hilfreich zu wissen, dass es nicht die 72x Chips sind - danke für den Hinweis. Bevor ich hier schreibe, muss ich schon kurz vor der Verzweiflung stehen, d.h. alles, was mir einfällt, habe ich schon selbst gecheckt. Ich habe die Lötstellen alle überprüft und auch wenn ich auf den Chips rumdrücke, ändert sich das Bild nicht. Habe von jedem Pin im Sockel zu der Stelle auf dem Mainboard durchgemessen, wo er hinfuhrt. Das Bild ist absolut konstant bei mehrmaligen ein/ausschalten und heißt wird nichts. Ich vermute auch, dass der Speicher ok ist, denn 32K-Chips geben ein ähnliches Bild ab - die Character sind an einigen Stellen anders, aber das Muster ist identisch. Das ist auch absolut konstant und ändert sich nicht, wenn ich z.B. die beiden 8K Chips tausche. Daher wird's wohl eine durchtrennte Leiterbahn sein... ich schätze mal das Mainboard wird mich noch lange beschäftigen, aber vielleicht ist es ganz gut, dass mein Übermut bestraft wurde. Das nächste Mal wird wieder ein Chip nach dem anderen ausgelötet...


    Chips falschrum drin ist mir in meinem Leben noch nicht passiert... :-)

    Nachdem ich darauf gestoßen bin: Videosignal des C16/116/+4 deutlich verbessern.


    habe ich zum Lötkolben gegriffen um meinen C16 auf Vordermann zu bringen. Das Überbrücken von FB13 hat zu einem deutlich besseren Bild geführt. "Lebensverlängerne Maßnahmen" habe ich durchgeführt, indem ich den 7805 durch einen Schaltregler von Recom ersetzt habe - C16 lief prima. Dann kam das RAM-Upgrade. Ich hatte das hier noch zu Hause rumliegen: https://idoregesz.hu/product/c…ernal-ram-upgrade-to-64k/


    Leider habe ich natürlich mal wieder alles auf einmal ausgelötet... und die beiden 74LS257XX abgeknipst um dann bequem die PINS auszulöten. Das RAM-Upgrade funktioniert nicht - es gibt nicht einmal ein Bild. Da ich immerhin die Speicherchips verrnünftig ausgelötet habe, habe ich die wieder reingesetzt und bei U7 und U8 einfach zwei SN74LS257BN genommen. Ergebnis: Grafikmüll auf dem Bildschirm mit einem blinkenden Cursor in der linken oberen Ecke. Tastatureingaben werden nicht angenommen.


    Meine primäre Frage ist: vorher waren bei U7 und U8 ein 74LS257A und ein HD74LS257P drin. Brauche ich Chips mit exakt diesen Bezeichnung oder sollte die von mir verwendeten auch gehen? Wäre schön den C16 erstmal ohne die 64K wieder zum Laufen zu bringen...