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)