MFA SAVE + LOAD

  • Die MAT* Firmware bietet eine SAVE und LOAD von Daten an. Ebenso auch aus dem Steuer-Basic heraus.

    Dabei wird 'eigentlich' dann ein Kassetten Interface angesprochen.

    Dieses ist aber eine serielle Schnittstelle auf Basis 8251 Uart, welcher an Adresse Fx angesprochen wird!

    D.h. man kann anstatt eines Kassetten Interfaces auch einfach eine serielle Karte an Adresse Fx nehmen.

    (Siehe PDF zur Kassetten Karten Beschreibung).


    Ich habe da mal hterm hinten dran gehangen (2400 8N1) und aufgezeichnet, was beim SAVE - sowohl aus dem Monitor als auch aus Basic herauskam.

    (Siehe sertest.txt). sertest Print 8000-800D ist dabei das per SAVE gesicherte Mini-Programm:


    Code
    8000 3E 2A CD 21 08 CD EF 07
    8008 CD 52 00 C3 00 80


    Dabei verstehe ich die Bytes/Zeichen vom SAVE aus dem Monitor nicht - da gibt es eine Auffälligkeit/Fehler? Habe ich markiert. Habe das aber 2x gemacht mit identischem Ergebnis!


    Das Mini-Basic Programm war:


    Code
    10 PRINT 42


    Auch beim Basic SAVE gibt es noch Fragezeichen ;)


    Die Idee dahinter könnte sein:

    • SAVE+LOAD einfach auf Notebook/PC per serieller Aufzeichnung/Abspielen.
    • Dito aber anstatt PC ein Arduino+Speichermedium (z.B. SD Karte/EEprom/etc.).


    Peter

  • Die MAT32kT hatte wohl einige Änderungen, damit man über das Terminal Datentransfer machen kann. Ich bin noch am Suchen ob das irgendwo im RCAS/WCAS steckt. Leider habe ich von der Terminal Version kein Listening. Disassemblieren und rekonstruieren ist mühsam. Bin aber dran...

  • Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    ::matrix::

    Edited once, last by tokabln ().

  • Hi Torsten,

    danke für die Links. Die sind wohl bekannt.


    Nein ich war auf dem Holzweg. Auch in der T-Variante wird der UART Fx für die Cassetten Routinen verwendet. Ich dachte das sie den UART des Terminals mitbenutzen.


    Kann man das hacken?

    Die Zuordnung erfolgt über eine Definition und nicht über eine Konstante. Langt also nicht nur einen Wert im ROM zu tauschen. Außerdem will ich keine 2. Init auf dem UART, also nur CASI/CASO. Dann bekomm ich immer noch einen RST6.5 bei jedem Zeichen... neee besser nicht.


    Um die Cassette zum Datentransfer zu verwenden müsste man also folgendes tun:

    2. Serielle Karte und ein Serielles-Cassetten-Interface auf meinem Arduino-Terminal. Wäre möglich.


    Schönen Gruß, Volker

  • Kann man das hacken?

    Hi Torsten,

    ja, das kann man „hacken“.


    Die serielle Ein- und Ausgabe des MAT85 wird über zwei Sprungvektoren (JMP $FC80 und JMP $FC83) gesteuert. Diese werden in der INIT-Routine gesetzt und zeigen Standardmäßig auf die Hexadressen $082D (serielle Eingabe) und $089F (serielle Ausgabe)

    Wenn man diese durch die CASI / CASO – Adressen (CASI: $07EF, CASO: $0821) ersetzt, wird die komplette Ein- und Ausgabe des MAT85 (und Mat85+) über das Serielle Interface auf der Port-Adresse $0Fx abgewickelt.


    Die Init-Werte des UART können dann dem Terminal angepasst werden. Die für die Einstellung des Teilerverhältnisses zuständige Routine ist im MAT85 hier zu finden:

    Ein sinnvoller Wert ist hier der Binärwert 0100110 (Zeile 1292 MVI A,$4E statt $CF)

    Bedeutet dann: 1 Stopp-Bit, keine Parität, 8 Datenbits, Teiler 16


    Durch die Änderung des Teiler von /64 auf /16 bekommst Du auf einen Schlag die 4-fache Geschwindigkeit auf dem RS232-Interface ohne größere Änderungen an der Hardware vornehmen zu müssen (einfach die Baudrateneinstellungen jeweils x4 nehmen):

    Ein Teiler 1 macht teilweise wenig sinn, denn im Empfang ist der MFA aufgrund des fehlenden Handshake und der Geschwindigkeit etwas eingeschränkt.

    Anpassungen im MAT85

    Konkrete Änderungen um die Ein-/Ausgabe des MAT85(+) auf das UART-Interface umzubiegen:


    Hexadresse:Wert

    015B: EF - Lowbyte CASI

    015C:07 - Highbyte CASI

    0161: 21 - Lowbyte CASO

    0162: 08 - Higbyte CASO

    0819: 4E - UART-Init


    Bei der Gelegenheit:

    Genau diese ganze Ein-/Ausgaberoutine und die ganzen Sprungvektoren die im MT85 definiert sind, werden nicht in allen MAT32k-Routinen konsequent angewendet. Sprich die Programmteile z.B. Erweiterungen, angefangen vom MINI-DOS über das Basic, SPS sowie Editor nutzen diese Vektoren nicht immer. So wird die SERI/O-Routine oder auch andere System-Routinen, gerne mal hart codiert angesprungen, anstatt über die Sprungtabelle am Anfang des MAT85 zu gehen.

    Codeanpassungen sind dadurch natürlich sehr schwer umzusetzen, denn die Verschiebung um nur ein Byte, bringt das ganze System ins Wanken.

    Aus dem Nähkästchen geplaudert:

    Ich bin gerade dabei den gesamten MAT32k-Code zu reassemblieren. Bin schon ziemlich weit gekommen, was jetzt noch fehlt ist der Bug den ich mir im Basic (was übrigens ein fast 1:1 Tiny-Basic ist) rein-disassembliert habe (die Exception-Routine ist fehlerhaft) und der Editor sind noch nicht fertig. Das ganze mache ich übrigens mit Visual-Studio-Code und dem Retroassembler. Hier sind auch schon sehr viele Änderungen und Anpassungen in den Code eingeflossen. Aber bis das fertig ist, dauert es noch eine paar kühle Abende. Sofern Du oder jemand anderes Interesse an dieser frühen Variante hat, bitte PN. Wenn ich den Code fertig reassambliert habe, stelle ich diesen selbstverständlich hier zur Verfügung.

    Aus dem Nähkästchen geplaudert - Teil 2:

    Um die Möglichkeiten zu haben, mehrere RS232-Schnittstellen zu nutzen (Anschluss PC als Terminal, Arduino, weiterhin LOAD/SAVE z.B. über PC-Up-Download), habe ich eine Multi-RSR232-Karte entworfen. Der Prototyp funktioniert schon, muss nun nur noch die gröbsten Fehler ausbügeln danach kommt auch hier wieder eine neue Karte ins Forum und somit in das „MFA-Universum“

    Aber auch hier sind beim Testen einige Fehler im MAT85-Code aufgefallen. Denn z.B. die CAS-Schnittstelle wird nicht einheitlich mit $F0 und $F1 (Daten- und Steuerregister des UART) angesprochen sondern auch mal gerne mal mit $FE und $FF. Aber auch für diese Karte brauche ich noch ein/zwei kühle Abende ... ;)


    Gruß
    Thilo

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Oh... na dann bin ich ja auf die Karte gespannt. Davon hätte ich bestimmt gerne EINE oder auch ZWEI. :tüdeldü::anbet:

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    ::matrix::

  • Auch beim Basic SAVE gibt es noch Fragezeichen ;)

    Hi Peter,

    im Zuge meiner Re-Assemblierung des MAT32-Codes habe ich solche Fragezeichen auch mehrmals erhalten.


    Deine Annahmen sind aber aufgrund meiner bisherigen Analyse korrekt:

    Grundlegend ist es hier so: Die Load und Save-Routinen des MAT85 (und damit auch das Basic oder SPS) nutzen das Standard Intel-Hex-Format. Der Aufbau des Outputs den Du in hterm erhalten hast, ist somit das, was auf Kassette hätte geschrieben werden sollen.

    Siehe dazu auch https://de.wikipedia.org/wiki/Intel_HEX


    So ist das 0C am Anfang die Anzahl der in der Zeile zu übertragen Bytes. DB wäre dabei die für diese Zeile ermittelte Prüfsumme.

    Das 00-Byte ist hier übrigens "nur" das Ende des Basic-Programmes und hat somit mit dem DB nicht direkt etwas zu tun.

    Auch Deine Annahme von 0A als Programmzeilennummer ist vollkommen korrekt (2 Bytes).


    Aber gerade der Anfang des Basic-Speichers ($8000 - $806E) beinhaltet am Anfang Teilweise Code (17 Byte) mit Sprungadressen, sowie verschiedene Pointer auf die aktuelle Adresse des Basic-Programmes (Anfang/Ende) und noch einige andere Pointer. Hier bin ich noch mitten in der Analyse.


    Somit wäre es denkbar, alle Load und Save-Routinen auf eine serielle Schnittstelle zu leiten und daran einen PC oder Arduino o.ä. hängen, um damit eine Kassette zu simulieren. Das war auch mit der Ansatz für meine hier erwähnte neu entworfene Multi-RS232-Karte um mit einer Karte mehrere Schnittstellen zu bedienen (Schnittstelle zum PC als Videokarten/Terminal-Ersatz und gleichzeitig eine Schnittstelle zum Laden und Speichern)

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Davon hätte ich bestimmt gerne EINE oder auch ZWEI

    Hi Torsten,

    Karte ist eingeplant :) Dauert aber noch ein paar Tage bis ich mein Layout überarbeitet habe... :kafeee:

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Thilo : hast du dir dafür tatsächlich professionell eine Frontplatte von Schaeffer machen lassen? ...was kostn son Ding?

    hättest du evtl. die Rohdaten dafür als STL oder Step-Datei ...oder was auch immer, dann könnte man die auch 3D-Drucken evtl.

  • hast du dir dafür tatsächlich professionell eine Frontplatte von Schaeffer machen lassen? ...was kostn son Ding?

    ja, die Frontplatte ist von der Schaeffer AG. Kostet aktuell (mit gefräster Schrift) ca. 39 EUR.

    Die FP-und exportierten Konstruktionsdaten habe ich angehängt. Da kannst Du mit Sicherheit auch eine Frontplatte drucken. Ich habe leider keinen 3D-Drucker.

    In einem meiner Threads wurde auch eine PCB mit schwarzem Finish dafür bei JLCPCB erstellt. Sah auch cool aus.

  • Hallo Thilo,


    + 1 Karte...


    Also da hast du dir richtig Arbeit gemacht mit der Antwort... wow, danke.

    Ich verwende schon die 32k-t Variante. Da wird sdtio schon über den UART geleitet. Meine ursprüngliche Intension war eigentlich das Cassetten-interface über die gleiche Schnittstelle zu führen.

    Interessant wäre auch wie bei der T-Variante damals Daten auf das Terminal übertragen wurde. In der Lehre/FOS hatten wir nur MAT85+, daher hab' ich keine Erfahrung von CPM/Floppy und Co. Ich meine aber in der Anleitung gelesen zu haben, dass man in der Terminalversion auch Dateien auf dem Terminal abspeichern konnte.


    Den Sourcecode vom OS, das wäre was feines! Wo findet man denn den "Retroassembler" ?

  • Hi,

    ja die Schnittstellenproblematik war auch der Aufhänger für meinen neuen Entwurf der Multi-Seriell-Schnittstelle um Cassetten-Interface und Terminal gleichzeitig zu nutzen.


    Der Sourcecode des MAT85 ist teilweise echt ein Problem, denn ausser dem MAT85 (Speicherbereich 0 - ca. $10A0) findet man wenig brauchbares im Netz. Auch der Systemcode des MAT85 ist nicht vollständig in der Originaldoku enthalten, denn der Assembler, Disassembler und Tracer sind leider nirgends zu finden. Hier war leider aufwändiges Re-Assemblieren nötig. Aber wie bereits erwähnt, dauert noch eine kleine Ecke, bis ich alle Fehler gefunden habe.


    Den Retro-Assembler kann man über den Visual-Studio-Marketplace als Plugin nachinstallieren.

    Informationen und Doku dazu findest Du hier: https://marketplace.visualstud…ineDesigns.retroassembler


    Gruß

    Thilo

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Der Sourcecode des MAT85 ist teilweise echt ein Problem, denn ausser dem MAT85 (Speicherbereich 0 - ca. $10A0) findet man wenig brauchbares im Netz.

    Ja, da hast du Recht.

    Wenn dich der Source des Mini-DOS interessiert, den gibt's hier.

    https://oldcomputers-ddns.org/public/pub/rechner/mfa_mikrocomputer_fuer_ausbildung/dokumentation/mfa_band-3_kapitel/bfz-mini-dos_v1.54_1985.pdf

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Wenn dich der Source des Mini-DOS interessiert, den gibt's hier

    Hi,

    danke für den Link. Die Seite habe ich auch schon mal durchforstet. Bot mir zumindestens eine bessere eingescannte Version des DOS-Listings. Denn ich hatte leider nur eine schlechte Kopie in meinen alten Unterlagen.

    Daraufhin habe ich dann vor einigen Wochen, an einem verregneten Wochenende, das ganze von Hand abgetippt.

    Der Assemblercode ist deshalb leider noch ohne die ganzen Kommentare, die kommen eventuell beim nächsten verregneten Wochenende, sofern es das nochmal geben sollte... Aber der bisherige umgesetzte Code funktioniert bereits.

    Auch die "externen Programme" des MAT, wie BFZ diese selbst im Code nannte, funktionieren nach einigen Kopfschütteln und vielen Tassen Kaffee nun endlich. :kafeee:

    ... MAT85-Code - Fortsetzung folgt ;)

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Hi,

    der erste Prototyp der Multi-Seriell-Karte wurde noch einmal komplett überarbeitet. Beim ersten Prototyp hatte ich noch mit einem Zählerbaustein zur Baudraten-Takterzeugung und Jumperfeld für den UART gearbeitet. Das hat mich aber schon immer gestört. Baudrate ändern bedeutete immer, MFA ausschalten, Karte raus, Jumper umstecken, rein und wieder einschalten. Deshalb habe ich in dem erweiterten Entwurf eine per Software einstellbare Baudrate integriert. Aber nicht über den Timer-Baustein 8253 (war auch eine meiner ersten Ideen), sondern einem einstellbaren Zählerbaustein. Denn ein 8253 zu parametrisieren würde einen massiven Eingriff in den Systemcode (Init-Bereich) bedeuten. Auch eine „schnelle Änderung“ ist mit einem 8253 nicht so nebenbei zu machen. Mein Anspruch war: Baudrate einstellen muss genau so einfach sein, wie ein Jumper umstecken.


    Daraus wurde dann die hier vorgestellte Schaltung: per Out-Befehl auf eine bestimmte Adresse der Karte, wird die Baudrate der Schnittstelle verändert. Selbst wenn nach dem Einschalten kein Out-Befehl kommt, hat die Karte eine bestimmte feste Baudrate. Somit kann diese auch ohne „Konfiguration“ direkt eingesetzt werden.


    Kurze Beschreibung des Entwurfes:

    • Adresse X0/X1 für UART1
    • Adresse X2/X3 für UART2
    • Adresse X4 (X5) für Baudrateneinstellung
    • Das Ur-Taktsignal ist grob per Jumper einstellbar (beginn der Teilung dann bei 1.228.800 oder 614.400)
    • Die Baudrateneinstellung wird im 8-fach Latch IC4 gespeichert und liegt an den beiden Teilern IC7 und IC13 an (oberes und unteres Nibble)
    • Beide Signale werden mit IC16 nochmal geteilt und dadurch bereinigt (der Zählerbaustein liefert nur kurze Low-Impulse, was bei RxC eventuell zu einem Problem führen könnte, da der UART hier aus dem Tritt kommen könnte
    • Die Pinbelegungen der RS232-Stecker sind per Jumper frei einstellbar (RxD/TxD und CTS/RTS vertauschbar), es muss am Stecker nichts umgelötet werden
    • UARTs können per Jumper einen Interrupt auslösen

    Der Rest ist üblicher (MFA-)Standard.



    Den aktuellen Entwurf stelle ich hier gerne mal zur Diskussion. Denn gerade die Mitstreiter, die bereits Interesse an meinem ersten Prototyp bekundet haben, dürfen hier gerne noch, sofern machbar, Ihre Wünsche mit einfließen lassen.

    (Aktuell: tokabln, Shadow-aSc, Toast_r, rfka01, felge1966, Bernhard, Andechs)


    Alle anderen dürfen aber auch gerne Kritik üben oder Verbesserungsvorschläge einbringen. Denn durch konstruktive Diskussionen kann der Entwurf ja nur besser werden. Nur Layout-technisch bekomme ich langsam ein paar Schwierigkeiten, denn viel passt nicht mehr auf die Platine. ?(


    Anmerkung zum Plan:

    Der im Plan eingezeichnete 74192 ist eigentlich ein 74193, meine IC-Bibliothek hat keinen 193er ... :fp:

  • Dann fang ich mal den Besserwisser-Modus an. ;)


    /CLK (X1-A2) ist auf der Z180 Karte nicht mehr verfuegbar, oder nur bedingt. Da kriegt zumindest Toast_r ein Problem. Da wuerde ich lieber den Ausgang IC8A nehmen. Der 8251-CLK EIngang hat nichts mit dem Prozessorclock zu tun.

    Hierbei musst du beachten, das die TxC und RxC Eingaenge max. 1/5 der CLK Frequenz sein darf.


    Wofuer sollen denn C18 und C30 sein? Und 100nF an TTL-Ausgaenge geht sowieso nicht.


    IC9B ist eigentlich auch nicht gut. Lt. 8251 Datasheet sollen die Eingaenge C/D und /CS vor /RD oder /WR gueltig sein. Mit diesem Gatter geht das aber nicht.

    Ich weiss, auf den MFA Platinen gibt es diesen Bloedsinn auch.


    IC3: M.E. ist /IOW am DIR-Eingang falsch.

    Weiter wird der Treiber aktiv, wenn der LS85 aktiv wird. Dadurch werden nur die obersten 4 Adressbits auskodiert, also 16 IO-Adressen belegt.


    Wofuer sind JP7 bis JP10?


    IC16 darfst du dir auch schenken. Die TxC und Rxc brauchen keinen symetrischen Takt.


    Interruptfaehig ist ja schoen, aber warum nur die Rx-Seite?


    Die Teiler fuer die Baudraten habe ich mir noch nicht vollstaendig angeschaut.


    Das soll's erstmal gewesen sein.

    Viel Erfolg

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Ich hatte mal angefangen auf der originalen RS232 Karte einen USB Anschluß (gibt es als Modul USB/RS232 z.B. das hier (FTDI Breakout) als Option anzuflanschen. Habe auch einen Prototypen angefangen, aber dabei blieb es bis dato.


    Vielleicht lässt sich ja noch solch ein Anschluß bei Deiner Karte hinzufügen. Nur eine Idee. Ich werde mich irgendwann mal wieder an meine Version machen.

    Gruß Torsten

    BFZ MFA, ZX80Core, AX81, ZX81, ZX81NU, Spectrum+, Harlequin, MSX VG8010, Amstrad NC100, Cambridge Z88, C64, C128D, Amiga 500 & 1200, Atari Portfolio, HP200LX, IBM PC5155, TP755c, TP755cx, T20, T41, T61, PS/2 (Model 40SX), PS/2E, Accura 101, Apple //e, Sharp PC1401 & PC1403H, TI59 m. PC-100c, HP48SX & HP48GX


    ::matrix::

  • C18 und C30

    Wenn die C's für die Funktion nötig sind, sollten die LS00 gegen LS03 mit Pullup Widerstand ersetzt werden. Dann gibts keine Probleme.

    Bei der zu erwarteten Flanken"steil"heit sollten dann auch Schmitt-Trigger Eingaenge benutzt werden.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

  • Dann fang ich mal den Besserwisser-Modus an. ;)

    Schon ok, bin für Tipps und Korrekturen immer zu haben.


    Dass RxC und TxC vom Systemtakt entkoppelt sind, war schon klar. Aber das dies auch für den /CLK gilt war mir neu. Würde die /CLK-Leitung des 8251 aber schon gerne mit im Systemtakt belassen, denn hier vermute ich Seiteneffekte durch nicht mehr synchronisierte Zugriffe auf den Chip. Denn /CLK aus IC8a zu entnehmen, würde bedeuten, dass dieser mit dem Steuerbus nicht mehr synchron ist (und dabei noch schneller wäre als der Systemtakt)


    Bezüglich der Z180-Karte hat diese doch einen einstellbaren Taktteiler der aus Phi erzeugt wird. Passt der für solche Karten nicht?


    Das mit dem 1/5 des Systemtaktes für RxC/TxC hatte ich nicht bedacht, danke für den Hinweis. Da muss ich wohl den Taktteiler nochmal überarbeiten.


    IC9b (Freigabe des 7485) sowie die Ansteuerung des 8251 habe ich aus den Original-MFA-Unterlagen 4.10 entnommen: BFA 4.10 RS232-Interface

    Aber ich tendiere fast dazu, den Kram (IC9b, IC9c, IC3) aus der Schaltung zu entsorgen, denn ich vermute auch, dass es hier sehr schnell zu Timingproblemen kommen könnte.

    Bei der Gelegenheit: IC3 ist eigentlich peinlich, denn hier habe ich tatsächlich die Seiten verwechselt. Kommt davon wenn man den Plan nimmt und nicht auf die Pinbelegung achtet... :fp:


    Dass nur 4 Adressleitungen auskodiert werden ist aber üblicher MFA-Standard. Denn alle IO-Karten liegen in einem dieser 16 Adressbereiche. Wobei diese Karte ja intern bereits 5 bzw. 6 Adressen aus diesem Bereich vereinnahmt. Ansonsten teile ich Deine Meinung, das ist eigentlich Verschwendung von IO-Adressen.


    C18/C30 sind Teile des Schaltungsentwurfes den ich für den programmierbaren Frequenzteiler entlehnt habe:

    Ursprünglich war ein 7497 geplant, dann musste ich aber feststellen, dass es diesen Chip nicht mehr gibt (von den russischen Alternativen K155/IE8 mal abgesehen). Deshalb bin ich auf den 74193 und dieser Schaltung umgestiegen.


    JP7 - JP10 sind die Anschlüsse für die Anzeige-LEDs auf der Frontblende (aktive Tx/Rx Übertragung)


    IC16 ist meinem inneren Monk geschuldet, denn das aus dem Frequenzteiler schon extrem asymetrische Signal widerstrebt meinem inneren Ordnungssinn... :stupid:


    Bei der Interrupt-Steuerung macht m.E. nur der Empfang sinn. Denn warum sollte ich einen Interrupt beim Versenden auslösen? In dem Augenblick befinde ich mich in der Regel softwaretechnisch eh in einer Senderoutine, bei der Unterbrechungen vermutlich eher störend wären.

    Bei einem Empfang von Zeichen (z.B. Eingabe über ein Terminal) könnte hier ein anderes Programm unterbrochen werden, um die eingetippten Zeichen einzulesen.

    Ich hatte mal angefangen auf der originalen RS232 Karte einen USB Anschluß (gibt es als Modul USB/RS232 z.B. das hier (FTDI Breakout) als Option anzuflanschen.

    Das wird schwierig, denn auf der Platine ist nur noch sehr wenig Platz. Das betrifft leider auch die Frontblende. Denn hier mangelt es auch an dem nötigen Platz für den USB-Anschluss.

    Mal sehen was ich hier noch am Layout und der Frontblende ändern kann.


    Vielen Dank nochmals für Eure Hinweise und Anregungen. Ich werde mich dann nochmal an den Schaltungsentwurf machen ... :kafeee:

    Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt. (Marie von Ebner-Eschenbach)

  • Aber das dies auch für den /CLK gilt war mir neu. Würde die /CLK-Leitung des 8251 aber schon gerne mit im Systemtakt belassen, denn hier vermute ich Seiteneffekte durch nicht mehr synchronisierte Zugriffe auf den Chip. Denn /CLK aus IC8a zu entnehmen, würde bedeuten, dass dieser mit dem Steuerbus nicht mehr synchron ist (und dabei noch schneller wäre als der Systemtakt)

    Im Datasheet des 8251 steht ganz klar, das der CLK Eingang nichts mit den Read/Write Zugriffen zu tun hat.



    Bezüglich der Z180-Karte hat diese doch einen einstellbaren Taktteiler der aus Phi erzeugt wird. Passt der für solche Karten nicht?

    Doch, da hast du recht. Und :thumbup: , gut mitgedacht!

    Der CLK aus der 8085-CPU Karte hat 2 MHz, der Teiler auf der Z180 Karte kann "nur" 2n teilen. Bei Oszillatoren, die nicht mit 2MHz * 2n schwingen haben dann auch der CLK-Leitung einen Takt ungleich 2MHz.

    Im aktuellen Fall ist das nicht wichtig. Wenn man die Baudrate aus diesem Takt erzeugt, wie bei der MFA-ProgSerSchnittstelle, hat man ein Problem.

    Also, für deine Karte will ich meine Aussage zurück ziehen.



    die Ansteuerung des 8251 habe ich aus den Original-MFA-Unterlagen 4.10 entnommen

    Ja, ich weiss,die können das auch nicht richtig. ;)

    Aber ein Fehler abschreiben macht es nicht richtig.


    Gilt auch für die Baudratenteiler und die Kondensatoren.

    Der '192/'193 ist ja schon fast synchron, aber nicht der LOAD Eingang.

    Schau dir mal den '161 an, der ist m.W. komplett synchron. Schau ich mir aber ggf. auch noch mal genau an.

    Damit kannst du BorrowOut/CarryOut direkt auf den LOAD Eingang verbinden.


    7497 muss ich mir anschauen.



    Bei der Interrupt-Steuerung macht m.E. nur der Empfang sinn. Denn warum sollte ich einen Interrupt beim Versenden auslösen? In dem Augenblick befinde ich mich in der Regel softwaretechnisch eh in einer Senderoutine, bei der Unterbrechungen vermutlich eher störend wären.

    Bei einem Empfang von Zeichen (z.B. Eingabe über ein Terminal) könnte hier ein anderes Programm unterbrochen werden, um die eingetippten Zeichen einzulesen.

    Der Rx-Intr ist auf jeden Fall interessanter.

    Mit dem Tx-Intr kann man einen Sendebuffer in Software realisieren. Zeichen, die ich senden möchte die UART aber belegt ist, werden in einem Buffer zwischen gespeichert. Wenn das UART-Senderegister frei ist, wird der Intr ausgelöst und ein Zeichen aus dem Buffer in die UART geschickt. ich Das kann Wartezeiten in der Software verkürzen bzw emiminieren. Und ja, auch ein Sendebuffer kann voll werden.

    Ist ein Nice-To-Have. Früher hab ich sowas standartmässig implementiert.



    Weiterhin viel Erfolg.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)