Beiträge von Georg

    Bei mir auch. Jahrgang 61, Gymnasium NRW, Ende der Mittelstufe, der bekannte Aristo Bischolar LL im beige/roten Schuber.

    Wir haben den Umgang gelernt, weil es auf dem Lehrplan stand - im normalen (Schul-) Leben wurde er nicht genutzt. Da setzte sich bald der private elektronische Taschenrechner durch.

    Ich meine, wir hätten in dem Zusammenhang auch das Rechnen mit Logarithmentafeln gelernt. Auf jeden Fall hatten wir die benötigten Tafelwerke.


    Von meinen Vater habe ich noch zwei "Taschenrechner" geerbt, das sind Rechenschieber im Hemdtaschenformat:



    Ich möchte mich mal kurz einklinken. Ich bin auch bei der Refresh - Theorie. Bei einem Kaypro hatte ich nach einer Reparatur das gleiche Phänomen) (läuft solange er beschäftigt ist, Absturz nach ein/zwei Minuten idle) und musste dann lernen, dass es 4164 mit 128 Refreshzyklen gibt und solche mit 256. Ich hatte natürlich den falschen eingebaut, und den vertrug der Kaypro nicht.


    Das dumme an der Theorie ist, dass die 4164 von TI wohl schon ausprobiert wurden, und die haben afair den 128er Refresh und müssten eigentlich beide Refresh-Arten vertragen.

    Wollte ich auch gerade schreiben, erinnert an die türkisen Cisco-Terminal-Kabel

    Das war aber nicht der RS232 Chip wo der Hersteller ständig eine neue Revision rausbracht, nur um treibertechnisch die alte Version abzusägen oder doch?

    Von den Cisco-Routern habe ich keine Ahnung. Aber damit findet man schnell die Belegung der beiden noch unklaren Leitungen - womit Reinhard richtig lag:


    türkis - CTS (8)

    grün - DSR (6)


    Und ja, der FTDI-Treiber hat eine wilde Historie: teils haben die Treiber einfach die Zusammenarbeit mit den gefälschten Chips verweigert, teils wurden diese angeblich sogar zerstört, oder statt des tatsächlichen Datenstroms gab es einen entsprechende Fehlertext (siehe Wikipedia).

    Ich habe am Sonntag von obbi freundlicherweise diesen USB-RS232-Adapter bekommen:



    Statt einer DB9-Buchse gehen die RS232-Signale auf einen 8-poligen Modularstecker:



    Wenn ich obbi richtig verstanden habe hat er noch mehrere davon; deshalb hier meine bisherigen Erkenntnisse bei der Identifizierung der Signale am Stecker. Vielleicht nützt es ihm oder anderen etwas.


    Das Adapterkabel enthält im USB-Steckergehäuse einen FTDI232-Chip samt RS232-Pegelwandler. Unter Linux läuft der auf Anhieb problemlos; für Windows muss der entsprechende Treiber von Future Technology Devices International geladen werden. Angeblich macht dieser Treiber Probleme bei gefälschten FTDI-Chips - ich gehe allerdings davon aus, dass hier ein echter Chip verbaut ist. Probiert habe ich es nicht!


    Die Spannungspegel entsprechen der RS232-Norm, genau sind es ca. +7V und -7V. Es sind also keine TTL-Pegel, wie sie bei den günstigen USB-Seriell Modulen geliefert werden! Mit diesem Kabel geht man an eine echte RS232-Schnittstelle, die typischerweise einen DB9 oder DB25 Stecker bzw. Buchse besitzen.


    Die Belegung der einzelnen Leitungen ist folgende:

    (In Klammern stehen die Pin-Nummern der entsprechenden DB9-Buchse.)


    türkis: ?

    grün: ?

    orange: RX (2)

    schwarz: GND (5)

    weiß: GND (5)

    gelb: TX (3)

    lila: DTR (4)

    rot: RTS (7)


    Die ersten beiden Leitungen konnte ich bisher nicht identifizieren; es handelt sich um EIngangsleitungen, und Kandidaten wären die Signale CTS, DSR, DCD oder RI. Da bleibe ich noch dran ::hacking::


    Für viele Verbindungen reichen aber die Signale RX und TX (plus GND), so dass die beiden unbekannten Leitungen einfach offen bleiben können.

    Laplink seriell verwendet ein normales Nullmoden-Kabel für COM - Ports.

    Laplink parallel verwendet ein speziell verschaltetes Kabel für die Printer-Ports. Dabei wird je nach Ausführung der Ports mit vier oder 8 Bit parallel gearbeitet. Ist in beiden Fällen schneller als die serielle Variante.


    Man muss natürlich der Software mitteilen, ob man seriell oder parallel arbeiten will. Kann sein, dass Laplink das automatisch erkennt. Kann aber auch sein, dass andere Software nur die serielle Variante beherrscht.

    Ich habe es eben mal ausprobiert (mit Wine bekomme ich das auch unter Linux ans Laufen) und direkt mal meine zwei Wang-Disketten, die ich per Fluxteen/Fluxcopy ausgelesen habe, damit bearbeitet.

    ...


    D.h. man kann Fluxteen/Fluxcopy auch unter Linux via Wine zum laufen bekommen? Wie funktioniert das mit der USB Anbindung?

    Nein, das ist ein Missverständnis. Es ging nur um das Programm zur Analyse/Dekodierung der Fluxdaten (Fluxdump). Zum Auslesen der Disketten per Fluxteen braucht es einen Windows-Rechner.

    Da bin ich auch direkt neugierig geworden. 8-)

    Ich meine was von Computer Museum Foundation in Italien gelesen zu haben.


    Die haben noch kein WDE, aber eine 2201. Vermutlich funktioniert die sogar, wenn sie sie ausstellen. Respekt!

    Danke, so lese ich das jetzt auch. :) Wenn ich es richtig deute steht rechts daneben unter dem Epson-Drucker ein Wang-Diskettenlaufwerk, oder? Dann brauchen sie ja gar keinen WDE... :tüdeldü:

    Stimmt. Aber sie schreiben selber, dass die Floppylaufwerke für den Transport etwas schwer sind.

    Und auch die Funktionstüchtigkeit ist immer fraglich ...

    Ja, derAussteller ist aus Italien. Die IBMSchreibmaschine mit Wang Aufkleber klemmte leider, aber nachdem wir den Dip2-4 am Epson richtig eingestellt haben, konnte er da drucken.

    darunter sind drei 8" Laufwerke.

    Der Epson passt natürlich nicht zu dem Ensemble, deshalb hatte ich mir den rechten Bildrand nicht so genau angesehen und das Floppydevice nicht gesehen.


    Dass die IBM Kugelkopfmaschine nicht funktioniert ist schade, aber leider typisch. :(


    Danke für das Extrabild von der Beschreibung.

    Da bin ich auch direkt neugierig geworden. 8-)

    Ich meine was von Computer Museum Foundation in Italien gelesen zu haben.


    Die haben noch kein WDE, aber eine 2201. Vermutlich funktioniert die sogar, wenn sie sie ausstellen. Respekt!

    Abschlussbericht ;)


    Bei Arnos letztem Besuch im Januar waren wir nicht besonders erfolgreich - der Genie lief zwar, aber Arnos speziell für den Video Genie angepasstes TRS-IO funktionierte nicht. Zunächst hatten wir Sorgen wegen der SMD-Anschlüsse (Verdacht auf Kurzschlüsse) und haben dort noch mal nachgelötet, aber das half nicht.

    Im Nachhinein war es das zu lange Anschlusskabel (ich hatte hier nur ein 1m langes Kabel einer 8"-Floppy), für das wir an dem Nachmittag keinen Ersatz bauen konnten mangels 50-pol Kartensteckern.


    Die habe ich mir mittlerweile in China bestellt, und mit einem kurzen Kabel (ca. 25 cm) läuft die Erweiterung jetzt. Mit einer externen Antenne an dem Espressif-Modul arbeitet schließlich auch die WLAN-Verbindung stabil.


    Ein kurzer Überblick über die wesentlichen Features der Erweiterung:


    - HDMI Video Ausgang

    - Speichererweiterung auf 48 KB

    - WLAN-Verbindung ins Netz sowie auf eine SMB-Freigabe

    - Implementierung des Festplattenemulators FreHD, Plattenimages wahlweise auf Mikro-SD-Karte oder auf der SMB-Freigabe


    Weitere Eigenschaften kann man unter dem o.g. Link nachlesen.


    Hier noch die von fritzeflink gewünschten Bilder:


    Die Erweiterung selber:


    Einsatz am Video-Genie - Startmeldung der Erweiterung vor dem Einschalten des Rechners:


    Start des Rechners; Plattenimage auf einer Mikro-SD-Karte:


    Booten von Newdos:


    Zugriff auf das Plattenimage:


    Zu meinem Aufbau:

    Mangels Platz habe ich keinen BAS-Bildschirm am Rechner angeschlossen. Der sollte aber (bis auf den Startbildschirm des TRS-IO) die gleiche Anzeige bringen wie der HDMI-Ausgang. Stattdessen habe ich für die Anzeige ein kleines 7" HDMI Modul von Pollin verwendet.

    Das TRS-IO wird wahlweise über den USB-Anschluss des verwendeten Tang Nano 9K oder des ESP32 mit Strom versorgt.

    Billig geht fast immer einher mit schlechter Qualität.

    Der Umkehrschluss wäre ja, dass Teuer fast immer mit guter Qualität einher geht.

    Sorry, das ist nicht richtig.

    Das klassische Beispiel dazu lautet: Wenn es regnet, ist die Straße nass.

    Dein Umkehrschluss: Wenn es nicht regnet, ist die Straße trocken.

    Spätestens wenn der Nachbar wieder bei Sonnenschein sein Auto gewaschen hat erkennst Du den Fehler.

    Ich kann nachvollziehen, wenn man auf hochwertige Verarbeitung und hochwertige Qualität wert legen. Aber mit dem Preis hat das überhaupt nichts zu tun.

    Auch da möchte ich widersprechen. Ich denke schon, dass hochwertige Verarbeitung und hochwertige Qualität tatsächlich kostet. Die gibt's nicht zum Dumpingpreis.

    Allerdings stimme ich Dir zu, dass man Qualität nicht am Preis erkennen kann.


    "Gut ist i.d.R. teuer, aber teuer muss nicht gut sein"

    Darum hatte ich lange gebettelt, da ich die Fahrerei ins Gymnasium und die Warterei satt hatte, um wenige mal pro Woche für eine Schulstunde deren (quasi ständig belegten) WANG 2200S-Computer zu nutzen. Mit meinem eigenen Computer wurde dann natürlich viel gelernt (und nächtelang gezockt).

    Mmh, bist Du nicht an dem BASIC des Commodore verzweifelt?

    Wenn man von dem WANG - BASIC kam wirkten damals die meisten Homecomputer auf mich frustrierend. Beim C64 fand ich es besonders schlimm, weil die tollen Fähigkeiten (Grafik, Sound) nur mit viel PEEK und POKE erreichbar waren.


    Gut, vielleicht war es bei den CBMs besser, weil die halt weniger konnten. Das Verhältnis Hardware zu Software war da so gesehen besser. :tüdeldü:

    Das kenne ich auch zu gut. Ich behelfe mir dann mit einer 2€ Lesebrille vom Aldi.


    Das zentrale Problem bei mir ist dabei das 3D-Sehen. Ich kann z.B. das Lötzinn nicht sauber an die Lötstelle führen, weil ich gerne davor oder dahinter ziele. Oder ich kann bei ICs z.B. die hintereinanderliegenden Pins nicht mehr eindeutig identifizieren. Also wird nach Gefühl gelötet.


    In dieser Hinsicht kommt einem SMD aber eher entgegen - dort fehlt die 3. Dimension. Da ist alles flach ;)

    Update:

    Der Rechner läuft mittlerweile wieder.


    Im Endeffekt waren es auch hier vier Speicherbausteine sowie zwei Video-RAMs, die defekt waren. Richtig stabil lief der Rechner aber erst, nachdem ich zwei ROM-Sockel ersetzt und einige der Erweiterungen neu verdrahtet habe.


    Drei der defekten RAMs habe ich mit meinem selbstgeschriebenen RAM-Test im EPROM (mit Adapter) gefunden, den vierten erst nach aufwendiger Analyse mit dem Logikanalysator - dort kippte ein Bit erst nach ca. 100us (Rücksprungadresse auf dem Stack war beim POP eine andere, als gePUSHt worden war).


    Arno ist jetzt für eine Woche wieder in der Gegend; mit etwas Glück bekommen wir einen gemeinsamen Termin hin, so dass er seine Erweiterung testen und den Genie wieder mitnehmen kann.


    Danke noch mal für alle Tipps und Hinweise! :anbet:


    Georg

    Ja, alles ganz nett. Aber die Bauteilbeschaffung artet dann doch etwas aus, wenn man noch nie SMD-Bauteile beschafft hat. Sonst hätte ich das mit dem Löten mal ausprobiert und das wäre meine erste SMD-Platine geworden. ;)

    Deswegen gibt es in diesem Tread ja 2 Leute, welche für 5/6€ die Bauteile anbieten, einer davon bin ich.

    So genau habe ich hier nicht mitgelesen. Ich hatte das Anfangs nur am Rande verfolgt.

    Und ich hatte auch nicht damit gerechnet, dass es so kompiliziert wird und dachte, ich bestelle mir die paar Bauteile einfach bei der nächsten Reichelt-Bestellung mit.

    Ich fand es nicht übermäßig kompliziert.

    Für die Durchsteck-Diode habe ich einen passenden SMD-Widerstand von einer Schrottplatine abgepflückt - irgendwo im Thread wurden 4K7 empfohlen, und für mich passt das.


    Die beiden ICs habe ich flugs bei Kessler bestellt, und die kamen auch schon nach 2 oder 3 Tagen an. Deren Suchfunktion ist tatsächlich schwach, aber die zwei Typen waren in HCT dann doch schnell gefunden.


    Das Löten der ICs war auch keine große Herausforderung, selbst wenn meine Augen inzwischen nachlassen und die Hände mehr zittern. Allerdings war eine Überprüfung mit der Lupe nötig samt kleinerer Korrekturen :tüdeldü:


    Die LEDs und die THT-Widerstände stammen aus dem Vorrat. Ich bin nicht so gut versorgt wie Helmut, aber sowas gehört imho in jeden Haushalt, der einen Lötkolben beherbergt. Die Werte habe ich experimentell bestimmt und liegen bei 2k2 für rot und 1k für gelb und grün. Wobei ich überlege, den für gelb noch etwas zu reduzieren, die könnten etwas heller sein...


    An der Spitze habe ich eine weiße LED - die ist superhell und bekam deshalb einen 10k Widerstand, damit man sich den Baum überhaupt anschauen kann, ohne geblendet zu werden.


    Ich finde die Platine wunderschön mit all ihren kleinen und großen Details. Da ich momentan keinen C64 (Computer) am Start habe, versorge ich die Platine über die Lötösen von C64 (Kondensator) mit 5V.


    Was mir noch fehlt ist der hübsche Aufkleber für das EPROM. Wo bekomme ich diese Grafik her?


    Alles in Allem eine tolle Aktion von axorp und OliverW. Sehr schön gemacht und aus meiner Sicht auch ziemlich unkompliziert fertigzustellen.

    Sieht etwa sperrig aus. Aber Du kannst den Verkäufer ja mal kontaktieren und nachfragen, ob das sinnvoll zerlegbar ist, und ob Ihr Euch überhaupt einig werdet.

    Abholung könnte zwischen den Tagen oder sonst Anfang 2023 erfolgen. Zwischenlagern klappt bei dem Volumen vermutlich nicht; ich müsste wahrscheinlich aus dem Auto raus verpacken und direkt abschicken. Von daher müssten Adresse, Finanzierung etc. auch vorab geklärt werden.

    Jetzt wolltest Du es aber ganz genau wissen ;)


    Man könnte natürlich jetzt noch hingehen und mit einem Zähler die Instruktionen bzw. Zyklen zählen, die die einzelnen Maschinen tatsächlich brauchen. Anfang und Ende könnte ja über das Busy-Signal gesteuert werden, das das Lämpchen an der Tastatur steuert.

    In den ca. 0,3s konnen immerhin fast 200000 Instruktionen verarbeitet werden!


    Aber im Ernst: Es ist natürlich ein interessantes Thema, aber angesichts der Unterschiede ziemlich akademisch. Selbst die 0,3% Unterschied zwischen B/T und F finde ich eigentlich irrelevant - nur kenne ich hier halt die wesentliche Ursache. Wenn mir der unterschiedliche Aufbau der Refresh-Counter nicht aufgefallen wäre hätte ich mir nie Gedanken über Geschwindigkeitsunterschiede gemacht.

    Eigentlich dachte ich, dass zwischen der B und der T/F 0,3% wegen der 36 zu 32 Takte beim Refresh liegen. Die T und die F müssten doch eigentlich beim Refresh gleich sein, oder?

    Die Modelle B und T sind näher miteinander verwandt als mit dem Modell F. Sie benutzen (bis auf RAM und ROM) vergleichbare CPU-Boards; das Timing z.B. erledigt bei der B das Board 6308 und bei der T das Board 6708, die sich nur geringfügig unterscheiden. Beim Refresh-Zähler sehe ich auf Anhieb keine relevanten Unterschiede.

    Das Modell F ist dagegen komplett neu entworfen; beim Modell T besteht die CPU inkl. RAM/ROM aus sieben Boards - beim Modell F wurde das auf 2 Boards zusammengeschrumpft. Zwar ist die Architektur immer noch vergleichbar, aber es gibt geringfügige Unterschiede. U.A. wurden komplexere TTL-Bausteine verwendet, um ICs und damit Platz sowie Leistung zu sparen. Das äußert sich z.B. beim Refresh-Counter, der hier einfacher aufgebaut ist.


    Entsprechend sollten B und T eher gleich schnell sein, F etwas langsamer.

    (Hinweis: B steht repräsentativ für die Modelle A,B und C; entsprechend gelten die Aussagen zum Modell T auch für das Modell S, und schließlich haben die Modelle E und F ebenfalls identische CPUs.)

    0,3% wegen der 36 zu 32 Takte beim Refresh liegen

    36 / 32 sind 12,5% mehr. Oder hab ich da was falsch verstanden mit dem Refresh?

    Jaja, die Prozentrechnung. Damit kann man lustige Dinge anstellen.

    Richtig ist, dass zwischen zwei Refresh-Zyklen bei den Modellen B und T (und ihren Geschwistern) 12,5% mehr Instruktionen verarbeitet werden als bei den Modellen E und F. Da diese Abstände aber unterschiedlich lang sind, entspricht das nicht dem Unterschied in der Rechenleistung.


    Ich bin von 32 * 36 = 1152 Zyklen ausgegangen, die auf allen Maschinen in der gleichen Zeit abgearbeitet werden. Innerhalb dieser 1152 Zyklen gibt es bei den älteren Rechnern 32 Refresh-Zyklen und bei den Kompaktmodellen 36 Refresh-Zyklen.

    Tatsächlich werden also in dieser Zeit bei den alten Maschinen 1120 "echte" Instruktionen verarbeitet; bei den kompakten sind es in der gleichen Zeit 1116. Diese vier zusätzlichen Instruktionen entsprechen ca. 0,35% der Gesamtzeit; bezogen auf die 1120 Netto-Instruktionen bei den älteren Rechnern sind die neuen ca. 0,36% langsamer.

    Also gilt jetzt diese Reihenfolge:

    1. Emulator: 11:07 (kein DRAM-Refresh nötig)
    2. Modell B: 11:26
    3. Modell T: 11:27
    4. Modell F: 11:29

    Da ich nur sekundengenau handgestoppt habe, würde ich sagen, da gibt es bei diesem Programm quasi keine nennenswerte Abweichung zwischen den einzelnen Modellen. Der maximale Unterschied beträgt ja nur ca. 0,4 %...

    Nun, da der theoretische Unterschied zwischen der F und der T bei 0,3% liegt würde ich schon sagen, dass es sich bestätigt, dass die F langsamer ist.


    Also ich hatte mal einen Endlos-Benchmark auf den beiden gestartet und tatsächlich festgestellt, dass die T minimal schneller war.


    Die Sekunde zwischen B und T dürfte dagegen wirklich aus der Messmethode resultieren.

    Was die Fehler mit dem WDE angeht: das erinnert mich an die Probleme, die ich auf der CC mit der MVP im Multiuser-Modus hatte. Da scheint noch was besonderes im Protokoll zu existieren das ich nicht kenne.

    Eine Reset - Leitung von der CPU zum WDE gibt es natürlich, aber eigentlich sollte der dann nicht komplett neu booten, sondern nur der Zustand zurückgesetzt werden.

    Das mit der Adresse verstehe ich gerade auch nicht.

    Mal schauen, wann wir diesen Problemen auf die Spur kommen...

    Gerade habe ich auch die 2200T rechnen lassen, da ich sie für den Test mit dem Multiplexer sowieso eingeschaltet hatte. Sie brauchte 11 Minuten und 27 Sekunden. Die 2 Sekunden Differenz dürften wohl in der Toleranz liegen, oder?

    Zusammengefasst:

    Modell B: 11:43

    Modell T: 11:27

    Modell F: 11:29

    Emulator: 11:07


    Der Unterschied zwischen T und F entspricht ungefähr den 2,5s, die ich oben geschätzt habe. Das ROM der beiden ist afaik identisch.

    Die B hat ein anderes ROM - vielleicht ist die deshalb langsamer. Ich weiß z. B. nicht, ob die Zugriffe auf das Patchboard zusätzliche Zyklen kosten.

    (Info für den Rest der Welt: die ersten Modelle A bis C besaßen ein Patch-Board, mit dessen Hilfe Fehler im ROM korrigiert werden konnten. Die fehlerhaften Adressen wurden dort dekodiert, das Original-ROM ausgeblendet und durch eine aus Dioden gebildete Instruktion ersetzt.)


    Beim Emulator bringen die gesparten Refresh-Zyklen ca. 18 bis 19 Sekunden. Passt ungefähr...

    Toll, wenn sich die Theorie in der Praxis bestätigt! Afaik hast Du aber nur den einen Multiplexer, so dass sich das derzeit auf ein Modell T und die Workstation beschränkt, oder?

    Trotzdem eine tolle Sache. Klappt das auch mit dem Emulator?


    Und hast Du mal ein Bild von dem Setup?

    Die WANG 2200F ist von der Rechengeschwindigkeit her identisch mit der 2200B,

    Natürlich hast Du Recht, weil die Architektur und vermutlich auch der relevante Mikrokode identisch sind.

    Tatsächlich gibt es beim Refresh minimale Unterschiede: Das Modell B schiebt alle 36 Zyklen einen Refresh-Zyklus ein, beim Modell F kommt der nach 32 Zyklen. Von daher ist die F minimal langsamer.

    Wenn ich richtig gerechnet habe beträgt der Unterschied 0,3% oder 2,5s beim Apfelmännchen.