Beiträge von Georg

    Die Koffer haben den Vorteil, dass sie etwas abstrahieren. Man arbeitet direkt mit den Gattern statt mit irgendwelchen Pins von ICs, muss sich um deren Stromversorgung nicht kümmern etc.

    Wobei oben ja auch die Möglichkeit besteht, eigene ICs zu nutzen.


    Zugegeben wirds bei komplexeren Schaltungen ungemütlich, weil man keinen Einfluss auf die Anordnung der Bauteile hat. Ich finde es dennoch für den Anfang einfacher und besser als Steckbretter oder ähnliches.

    Das ist echt der Knaller! Echt schoene Koffer.

    Vor allem toll, das die nicht jemand zwischendurch entsorgt hat.

    Ja, ich bin auch extrem überrascht, dass die Koffer all die Jahre überlebt haben. Der damalige Computer samt Teletype, das Terminal aus dem Sekretariat - alles wurde verschrottet.

    Vor kurzem ist die gesamte Schule leergeräumt worden wegen Renovierung. Vermutlich sind dabei die Koffer in irgendeinem Kellerraum aufgetaucht, und zum Glück war wohl jemand in der Nähe, der sich auskennt und die Dinger gerettet hat. Ich möchte nicht wissen, was bei der Gelegenheit alles entsorgt wurde: Mobiliar, Bücher, Lehrmittel, Landkarten, Fernseher, Projektoren...

    Kennt jemand diese Geräte?



    Mit diesen Teilen habe ich vor über 40 Jahren in der Schule Digitaltechnik und Boolsche Algebra gelernt.

    Jetzt besucht mein Sohn die gleiche Schule, und die Koffer gibt es immer noch. Jetzt lernt er damit den Bau von Halb- und Volladdierern, Zählern, Schieberegistern etc.


    Hier ein Bild aus meiner Zeit:



    Ich finde die Teile nach wie vor genial, und offenbar lernen die Kids von heute damit immer noch gerne, trotz all der Simulations-Apps auf dem Smartphone.

    Das SINIX-H auf der MX300-10 wurde 1990 eingerichtet, Doku gibt es hier und hier .

    Allerdings hilft mir die doku nur bedingt, nach 2 Disketten möchte die Installsoftware ein tape welches ich momentan nicht habe.

    Bevor ich da was dummes mache nehme ich lieber eine andere ESDI harddisk zum spielen.

    Ich habe hier immer noch das Paket mit 5.24 liegen. Das hatte ich nach Krefeld mitgenommen, aber Du hast es wohl nicht dahin geschafft.

    Wenn Du glaubst, es könnte Dir helfen, kann ich es Dir auch zuschicken.

    Ach, das ist ja interessant... Man lernt nie aus. Das erklärt tatsächlich die Cellulite an manchen größeren Leiterbahnen :D

    Diesen Effekt kenne ich auch, ist ja manchmal sehr extrem. Für mich erklärt sich da aber zunächst gar nichts. Ist jetzt das Zinn unter dem Lack so schrumpelig, oder verändert sich der Lack nach dem Auftragen?

    Ich habe mich tatsächlich schon öfters nach der Ursache dieses Effekts gefragt. Das erscheint dann aber nicht wichtig genug, um diese Frage wirklich mal zu formulieren....

    funkenzupfer Wir hatten ja schon mal in Krefeld über das Thema gesprochen. Ich bin immer noch baff wie locker Du mit diesen digitalen Zählern umgehst :anbet:


    Jedenfalls habe ich dieses neue Wissen dann mal ausgenutzt und meine 8.2 etwas gepimpt, d.h. den Abgriff an dem Zähler umgelegt und so immerhin 2400 Baud geschafft - allerdings hatte ich dann Zeichenverluste. Seltsamerweise bei der Ausgabe, also war nicht die CPU überfordert, sondern eher der Grafikchip oder der Charactergenerator :grübel:


    Ich hab's dann aber nicht weiter verfolgt. Die 8.2 ist vermutlich eh eine Sackgasse.

    OK, OK, jetzt kommen die Fakten ja schneller, als ich lesen kann :)


    CP/M habe ich vergessen, dafür braucht es doch auch ein Miminal ROM? Oder geht das mit dem MAT32K?


    Und MAT32K mit 9600 über die CPU? Muss ich mal irgendwie ausprobieren...


    Jedenfalls scheint es noch viel mehr Kombinationen zu geben als ich befürchtet hatte.

    So langsam verliere ich den Überblick :fp:


    Wir haben im Original MFA folgende Monitorversionen:

    MAT85 und MAT85+

    MAT32K für serielles Interface

    (Gibt es für die Videokarte(n) eine spezielle MAT32?)


    Und wir haben folgende Videokarten:

    Video 8.2

    Video 8.4


    Und zusätzlich dann noch die seriellen Karten.


    Frage: was kann man kombinieren?

    Beispiele:

    1. Geht Video 8.4 mit MAT85?

    2. Geht Video 8.2 mit einem MAT32?

    3. MAT85 und serielle Karte?


    Und wie schnell kann das laufen?

    Wenn die MAT32 19200 kann, geht das wohl kaum über den Bus und die 8085-serielle? Aber wie sonst?

    So, mit etwas Verspätung kommt jetzt auch der Quellcode für das Monitorprogramm.


    Mittlerweile habe ich ja meine Videokarte auf den "allgemeinen Standard" 7E2 umgestellt und auch den Monitor entsprechend angepasst. Weitere Änderungen:

    * Anpassung auf die 64 Zeichen Zeilenbreite

    * Ausblenden der nicht unterstützten Disk-Befehle

    * Umbau des Forth-Interpreters auf CR statt LF, damit die Tastatur richtig arbeitet

    * Verwendung von Port 80h statt 0 für den UART


    Die letzte Modifikation erlaubt es, die Z80-Karte so umzubauen, dass der UART nicht mehr den ganzen Adressraum belegt, sondern die erste Hälfte für andere Peripherie frei lässt.


    Von vaxman, dem Autor des Monitors, haben wir die Erlaubnis zur Nutzung, Modifizierung und Veröffentlichung des Codes. Herzlichen Dank dafür an Bernd!


    Im Bild ist meine Z80-Karte, geparkt auf einer Parallelkarte. Da meine CPU derzeit mit 6MHz läuft, lasse ich die 8085-Karte momentan mit im System für den 2MHz-Takt - dort habe ich nur die V.24-Treiber entfernt. Sobald ich aber an den Daten- und Adressbus drangehe muss das natürlich anders gelöst werden.




    Quellcode und Binardatei:

    Z80mini_MFA_016.zip


    Georg

    Ich schätze, dass es dem Wang 2200 PCS (Portable Computer System) genau so ergehen würde.

    Evtl. mit dem Unterschied, dass ein Laie den aufgrund seines Aussehens eher für einen "richtigen" Computer halten würde. Aber gerade die Experten kennen eher den IBM als den Wang.

    Technisch vergleichbar, d.h. diskrete CPU, Bandlaufwerk, Bildschirm, Tastatur, kompakt. Und etwa genau so alt.


    Aufgrund der geringeren Bekanntheit vermutlich auch günstiger - wenn denn mal einer auf dem Markt ist.


    2200PCS_DataSheet.700-3825.3-76.pdf

    OK. Da habe ich offenbar einen Exoten erwischt. Und außerdem schaue ich wohl ständig in die falsche Doku. Ich habe die Scans aus dem gebundenen Buch (von rfka01 ?) verwendet, da hört es auf Seite 13 auf und das Bild oben gibt es dort nicht:fpa:


    Herzlichen Dank in die Runde, dann mache ich meinen auch mal kompatibel::solder::


    PS. Nette neue Smilies hier...

    Wir haben heute festgestellt, dass die Einstellung meiner Videokarte (8.2) von denen bei PeterSieg abweicht.

    Da uns nicht klar ist, welches die richtige Einstellung ist, wollte ich mal rumfragen, wie es bei Euch eingestellt ist.


    Es geht um die Lötjumper an den Pins 35 bis 39 des UART, direkt vorne an der Frontplatte (siehe Bild).


    Meine Konfiguration (7N2):


    35 offen

    36 offen

    37 offen

    38 geschlossen

    39 offen


    Peters Konfiguration (7E2):


    35 - geschlossen

    36 - offen

    37 - offen

    38 - geschlossen

    39 - offen


    Ich würde mich genau so freuen, wenn jemand Informationen findet, welche Einstellung evtl. als Standard vorgesehen ist.

    Die Disketten habe ich definitiv getestet, bevor ich die verschickt habe. D.h. Zumindest gebootet und mal ein Kommando ausprobiert.

    Ich finde auch, dass das eigentlich schon ganz gut aussieht. Ich müsste mal schauen, wie das bei mir aussieht mit BIOS etc.


    Wegen der Stromversorgung hatte ich bisher ein anderes Bild. Da war doch ein Laufwerk völlig tot, bis Du die Anschlüsse vertauscht hast?


    Die Messung hatte ich auch am Anschlussstecker der Floppy gedacht; an den Motoren kannst Du eigentlich nur mit Oszilloskop sinnvoll messen.

    Die Werte werden tatsächlich binär eingegeben, weil jeder Schalter nur 1 oder 0 darstellt. Durch die Gruppierung in Viererblöcken wird eine hexadezimale Interpretation erleichtert, aber tatsächlich ist es binär. Und nein, da braucht es kein ROM, die Bits werden 1:1 (über Puffer/Latches) auf den Daten- bzw. Adressbus gesetzt und je nach Steuersignal (separate Tasten) in den Speicher geschrieben, oder der Wert aus dem Speicher gelesen.


    Bei den alten Maschinen (PDP, H316, Großrechner) wurden meistens Dreierblöcke gebildet, weil damals das Octalsystem weiter verbreitet war. Es erschien denen damals wohl einfacher, mit 0-7 zu denken als mit 0-F.

    Ein eindrucksvolles Beispiel ist auch der Honeywell 316 von Philipp Hachtmann.


    Bei den ganz großen Eisen gab es das für den Boot-Vorgang ebenfalls. Hier ein Beispiel eines CDC-Panels für den "Deadstart". Allerdings wurde dort eine komplette Befehlssequenz fest eingestellt, nicht wie bei Altair & Co einzelne Befehle nacheinander.

    Bilder !?

    Jaja, ich weiß, Bilder sagen mehr als tausend Worte, aber meine Karte sieht (bis auf den Austausch 28C256 gegen 27C256) tatsächlich genau so aus wie die oben abgebildete von Peter, und die eingebaute Karte verschwindet - wie beschrieben - hinter einem fremden Slotblech. Wenig Möglichkeiten für aussagekräftige oder neue Bilder. 8-)

    Die Platine ist heute angekommen. Mit Lineal und Cuttermesser habe ich den Millimeter vorgeritzt und dann mit einem scharfen Vornschneider weggeknabbert - ging recht schnell und sieht sehr gut aus. Schleifen hätte mehr Dreck gemacht und wäre vermutlich nicht so schön gerade geworden.


    Da ich nur EPROMs und keine EEPROMs

    habe musste ich zwei Anschlüsse austauschen, aber danach funktionierte es tadellos. Ein herzliches Dankeschön an PeterSieg für die Platine!


    Wie geplant habe ich diese kurze Karte in einen Slot gesteckt, der durch die Frontplatte einer anderen Karte verdeckt wird. Klappt prima, und ich spare mir zwei komplette Slots (RAM-Karte und ROM-Karte).

    Glückwunsch! Gut gemacht!


    Die kurze Bauform konnte doch auch ein Vorteil sein? Man kann dann vielleicht einen Busplatz nutzen, der durch eine Karte mit doppelter Frontblende blockiert wird.


    Und zum Rausziehen könnte man sich ein Werkzeug denken, ein Griff mit zwei Haken...


    Danke für die Platine! :)

    Klar - geht alles.. die Idee war, diese Z80 Karte einfach anstatt der 8085 CPU Karte einzustecken - und fertig.

    Mittlerweile habe ich eine von Peters Platinen aufgebaut und wie geplant in den MFA eingesetzt.


    Zu dem Z80 mini System muss gesagt werden, dass es wirklich Mini ist: Z80, 16550 UART, 32K RAM, 32K EPROM, je 1 Quarzoszillator für den Prozessor und den UART, eine Resetschaltung und zwei Gatter zum Adressieren von RAM und ROM. Leider keine Adressdekodierung für Peripheriegeräte, keine I/O-Ports, nicht mal eine Power LED.

    Aber zu dem Projekt gehört ein netter Monitor samt Forth Interpreter.


    Für die erste Montage habe ich eine Parallelkarte genutzt. Neben der Stromversorgung brauche ich nur 3 Leitungen zum Bus: RX, TX und den 2MHz Systemtakt.



    Hier sieht man die mit Kabelbindern befestigte und fliegend verdrahtete Platine auf der Parallelkarte. Und damit läuft das dann so wie von Peter vorgeschlagen: 8085-Karte raus, Z80 Karte rein, loslegen. Das Ergebnis sieht dann so aus:



    Das ist die Meldung des Monitorprogramms. Ich müsste natürlich die Baudrate sowie die Parameter des UART auf Werte einstellen, die von der Videokarte erwartet werden (1200 Baud, 7 Datenbits, keine Parität, 2 Stopbits), und in einem ersten Schritt habe ich die Ausgabe dieser Meldung an die 64 Zeichen des MFA-Bildschirms angepasst. Da ist aber noch einiges mehr zu tun.


    Wichtiger ist aber der Anschluss der Daten- und Adressleitungen an den Bus, und wenigstens eine minimale Adressdekodierung. Erste Ideen haben wir schon...

    Vor allem nach Entfernen der Elkos die Platine gut schrubben. Das Zeug leitet!

    Echt? Dielektrikum sollte das doch nicht?

    Das Dielektrikum ist in dem Fall die Oxydschicht auf der Folie; die Soße (das Elektrolyt) ist der zweite Pol. Und das sollte leiten ...

    Meine ist auch fehlerhaft (gleicher Fehler wie bei joshy ). Ich habe schon beim Leserservice reklamiert. Bei denen im Forum haben sich auch schon einige gemeldet, offenbar gibt es auch andere Fehlervarianten.


    Na, da kann Heise ja noch mal einen ganzen Schwung nachdrucken lassen, wenn die alle reklamieren. Bei einem anderen Thema hätte ich es vielleicht verschmerzt oder die fehlenden Teile online gelesen, aber eine Retro-Ausgabe will man doch retromäßig auf Papier haben ...

    Danke für die Photos. Gabs nicht sowas auch von NEC?

    Keine Ahnung, mir geht es da wie den anderen: Habe ich sonst noch nie gesehen.

    Wenn das Teil nicht so schwer wäre (und ich etwas mehr Zeit hätte :() würde ich den mal zerlegen - vielleicht bekommt man dann den echten Hersteller raus. Denn das der von Cromemco selber gebaut wurde halte ich für eher unwahrscheinlich.


    Was es nicht alles gibt... so etwas habe ich noch nie gesehen.

    Das mit dem Typenkorb ist der Knaller. Hab ich noch nie gesehen.

    Tja, andere haben einen Apple I, ich habe einen Typenkorbdrucker. Der scheint seltener zu sein 8o


    Aber im Ernst - mir ist das erst damals eingefallen, als wir über unsere alten Drucker diskutiert haben.

    Ich fand den seinerzeit (späte 80er, frühe 90er) auch nicht exotischer als einen Kugelkopfdrucker oder einen mit Typenrad. Aber die anderen haben dann doch eine wesentlich größere Verbreitung gefunden. Da war der bei mir aber schon fast in Vergessenheit geraten.

    Hier eine Spezialität für Toshi  ;)


    Ich war heute im Lager und da ist er mir über den Weg gelaufen - naja, genau genommen war es umgekehrt. Jedenfalls habe ich meinen Drucker Cromemco 3355A gefunden, den ich Euch schon immer mal vorstellen wollte:




    Leider ist er etwas zugebaut, und ich konnte ihn deshalb nicht in voller Pracht aufnehmen.

    Aber das ist relativ unwichtig - hier geht es definitiv um den Druckkopf.




    So kann man noch nicht viel erkennen, deshalb kommt jetzt erst mal das Farbband raus:




    Leider verbirgt sich das Wichtigste immer noch unter der Haube. Also aufklappen, und wundern:




    Mit der Haube haben wir auch den Hammer hochgeklappt - der guckt jetzt oben raus. Und unten ist jetzt der Typenkorb sichtbar geworden. Im Prinzip ist das ein Typenrad mit abgewinkelt Speichen, so dass die Drehachse nicht waagerecht, sondern senkrecht steht.


    Leider fehlten mir die Zeit und die Möglichkeiten, um den Drucker auszuprobieren. Ich bin noch nicht mal sicher, ob der das normale Centronics Protokoll spricht - ich habe den Drucker zusammen mit einem Cromemco System Three bekommen und bisher auch nur daran ausprobiert. Wenn ich mich recht erinnere hat er mir dabei auch gerne die Sicherung rausgeholt...


    Vielleicht schaffe ich bei meinem nächsten Besuch mehr. Falls die Sicherung hält ;)

    =Z80=


    Hier folgt jetzt die Version für die andere Fraktion. Der größte Teil behandelt dabei die Konstruktion der Schleife; das ist eigentlich nicht das Thema dieses Threads, bietet aber einige interessante Einsichten speziell in die Unterschiede zwischen den Prozessoren.

    Die Beispiele sind alles "Trockenübungen" und deshalb nicht verifiziert - sollte ich einen Fehler drin haben bitte ich um sachdienliche Hinweise :tüdeldü:


    Eine einfache Übersetzung der Syntax sähe etwa so aus:


    Leider funktioniert das so nicht, aber dazu später.


    Wir sehen zunächst, dass der Befehl zum Schreiben in oder aus dem RAM derselbe ist wie zum direkten Laden von Registern oder auch zum Transfer zwischen zwei Registern:


    LD [Ziel],[Quelle] ; kopiere (lade) den Wert aus Quelle in das Ziel


    Details hierzu folgen hoffentlich noch in dem entsprechenden Nachbarthread.


    Außerdem treffen wir den relativen Sprung wieder, diesmal mit Bedingung. Beim Z80 unterscheiden wir absolute Sprünge, die den gesamten Adressraum von 64K erreichen können, von den relativen Sprüngen im Bereich von 256 Adressen in unmittelbarer Nachbarschaft.

    Beide Sprungarten können mit Bedingungen versehen werden:


    Code
    1. JP nnnn ; unbedingter absoluter Sprung
    2. JP Z,nnnn ; absoluter Sprung, wenn Zeroflag gesetzt
    3. JR NZ,nnnn ; relativer Sprung, wenn Zeroflag nicht gesetzt
    4. JR C,nnnn ; relativer Sprung, wenn Carryflag (Übertrag) gesetzt
    5. etc.


    Jetzt aber zu der Frage, warum die obige Version nicht funktioniert:

    Tatsächlich ist es leider so, dass die Register B und C nicht einfach in und aus dem RAM übertragen werden können. Das ginge nur über den Umweg über den Akku.

    Allerdings hat der Z80 einen Befehl, um das Registerpaar BC im Speicher zu sichern bzw. zurück zu lesen:


    Code
    1. LD (4000),BC ; BC nach 4000 und 4001 sichern
    2. LD BC,(4000) ; BC von dort zurücklesen


    Damit ergibt sich dann folgende Version:


    Code
    1. LD (4000),BC
    2. LD BC, 7500
    3. L1: DEC C
    4. JR NZ, L1
    5. DEC B
    6. JR NZ, L1
    7. LD BC,(4000)
    8. RET

    Das sollte jetzt funktionieren.

    Eine Kleinigkeit ist noch anders als im 6502-Beispiel: Hier startet die innere Schleife immer bei 0. Der erste DEC-Befehl liefert dann den Wert $FF; insgesamt zählen wir einmal mehr (256 mal gegenüber 255 mal). Dafür sparen wir uns das erneute Laden des C-Registers, da es - wenn nach 256 Durchläufen der inneren Schleife nun die äußere Schlife einen Schritt macht - wieder beim gleichen Startwert 0 angekommen ist.

    Außerdem nutzen wir wieder die Möglichkeit, die beiden Register B und C zusammenzufassen und mit einem Befehl zu laden.


    Unschön an dieser Lösung ist das Sichern und Zurücklesen des BC-Registers. Der Z80 braucht für diese Opcodes jeweils 4 Byte, und überhaupt ist es (zumindest beim Z80) üblich, sowas grundsätzlich auf dem Stack zu machen. Vielleicht liegt es daran, dass der Z80 problemlos alle (Doppel-)Register sichern kann:


    Code
    1. PUSH BC
    2. LD BC, 7500
    3. L1: DEC C
    4. JR NZ, L1
    5. DEC B
    6. JR NZ, L1
    7. POP BC
    8. RET

    Während die erste Version 18 Byte benötigt, sind es hier nur noch 12. Schneller ist es auch, aber das sollte bei einer Warteschleife ja keine Rolle spielen ... ;)


    Sorry, wenn ich den Stack hier vorgezogen habe - da sollten wir schleunigst mal ein eigenes Kapitel zu schreiben.


    Und damit wir auch etwas über die Feinheiten des Z80 lernen, hier die "typische" Lösung unter maximaler Ausnutzung der 16 Bit Register:

    Code
    1. PUSH BC
    2. LD BC, 7500
    3. L1: DEC BC
    4. LD A,B
    5. OR C
    6. JR NZ, L1
    7. POP BC
    8. RET

    In diesem Fall schachtelt man nicht zwei Schleifen mit je einem 8 Bit Zählern, sondern benutzt eine Schleife mit einem 16 Bit Zähler. Denn der Z80 inkrementiert und dekrementiert problemlos auch die Doppelregister.


    Dummerweise werden dabei aber (anders als bei den 8 Bit Decrements) die Flags nicht gesetzt. Das muss man unbedingt wissen, um kapitale Programmfehler zu vermeiden. Als Abhilfe wird der Umweg über den Akku genommen. Das ist ein klassischer Weg, die Doppelregister zu prüfen: ein Register wird in den Akku übertragen, und das zweite wird damit logisch "or" verknüpft. Das Ergebnis ist genau dann 0, wenn beide Register B und C den Wert 0 haben - und diesmal wird auch das Zeroflag gesetzt, das im nachfolgenden JR NZ abgefragt wird.


    Als Nachteil wird der Akku zerstört - wer das verhindern will, sichert den eben auch vorher auf dem Stack.


    Zu guter Letzt die Frage nach dem Aufruf: Der erfolgt beim Z80 über die Call-Befehle. Diese sind grundsätzlich absolut, d.h. sie können jede 16-Bit-Adresse erreichen, und es gibt sie sowohl unbedingt als auch mit den Bedingungen, wie wir sie schon bei den Sprüngen kennengelernt haben:


    Code
    1. CALL nnnn ; unbedingter Aufruf einer Subroutine
    2. CALL Z,nnnn ; Aufruf der Subroutine nur bei gesetztem Zeroföag
    3. CALL NC,nnnn ; dito nur bei nicht gesetztem Übertragsflag
    4. etc.

    Ansonsten ist der Mechanismus für den geordneten Sprung zur Subroutine und zurück wie oben beschrieben: nach dem Einlesen des vollständigen Call-Befehls zeigt der Programmzähler (instruction pointer) auf den nächsten Befehl im Speicher. Bei Ausführung des Calls wird dieses Register auf den Stack gesichert und mit der Zieladresse neu geladen - wodurch die Programmausführung bei der Subroutine fortgesetzt wird.

    Wenn der Ret-Befehl gelesen und verarbeitet wird wird der letzte Eintrag vom Stack zurückgelesen und in den Programmzähler geladen, woraufhin die Ausführung an der Stelle hinter den Call fortgesetzt wird.


    Damit das Ganze auch sauber funktioniert muss die Subroutine dafür sorgen, dass sie den Stack so hinterlässt, wie sie ihn vorgefunden hat: wenn sie Register dort geretter hat muss sie genau so viele Register wieder zurücklesen (genausoviele POPs wie PUSHs). Andernfalls werden Daten als Adresse des Programms interpretiert, was in aller Regel zum Crash führt.