Beiträge von Thilo

    Hi,

    cool. Eine solche Karte steht auch noch auf meiner ToDo-Liste. Aber wenn Du eine Karte dafür baust, wäre ich direkt dabei. Den Chip hatte mir schon vor längerem bei Reichelt bestellt, aber noch keine Zeit dafür gefunden, das Projekt anzugehen ...


    Ich denke auf den 245 kannst Du verzichten, denn die wenigsten Karten im MFA haben einen solchen Bustreiber.


    Da die Karte aber vermutlich nur zu einem Bruchteil belegt ist, wie wäre es wenn man Platz und Steckplätze dafür vorsieht um andere I2C-Module mit "aufstecken" kann?


    Was mir beim MFA auch immer fehlt(e): sind ein Uhrenbaustein und ein nichtflüchtiger Speicher (EEPROM). Diesen könnte man hier direkt mit entsprechenden I2C-Bausteinen auf der Platine integrieren. Auch eine Schnittstelle für eine SD-Karte wäre vielleicht sinnvoll.


    Was hälst Du davon?


    Gruß

    Thilo

    Könnte man den Takt nicht auch durch sowas ersetzen?

    Hi,

    keine schlechte Idee. Das spart mir ein komplettes IC ein. Die noch erforderlichen Inverter werden mit freien NANDs ersetzt. Muss gleich mal mein Eagle fragen was das Layout dazu meint ... :grübel:


    Gruß

    Thilo

    Hi Christian,

    mir wurde ein (verdammt) großes MFA-Konvolut angeboten.

    hört sich gut an. :)

    Ich hätte an folgenden Komponenten Interesse:


    1 Stk 19" Rahmen (ohne Trafo/Spannungsregelung)

    1 Stk Trafo-Einschub

    1 Stk Spannungsregelung

    2 Stk Parallel Eingabe

    2 Stk Parallel Ausgabe

    2 Stk CPU 8085

    2 Stk Floppy Controller

    2 Stk Video (welche? Weiß ich noch nicht)

    - Stk RAM/ROM (8K / 16K ? noch unklar)

    2 Stk Drucker-Interface

    2 Stk AD/DA Wandler

    2 Stk Bus-Anzeige

    2 Stk Bus-Verlängerung oder Fehlersimulation

    1 Tastatur


    Bezüglich der Übergabe müssten wir uns dann nochmal separat abstimmen.


    Vielen Dank schonmal für Deine Bemühungen.


    Gruß

    Thilo

    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:

    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:

    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 ;)

    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

    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.

    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)

    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

    CBM_Ba

    Ich finde Deine Idee super und das ist wird bestimmt echt witzig wenn Du das wirklich durchziehst.

    Denn auf der anderen Seite bauen wir hier ja alle auch in den verschiedensten Formen historische Computer nach oder erwecken diese wieder zum Leben.

    Da ist es nur eine logische Konsequenz wenn auch ein Werbeplakat von früher wieder lebendig wird …:)

    Der Designer von Schaffer AG ist aber schon sehr gut, aber das kostet leider auch. Da ist wk-mechanik schon günstiger.


    Eine Kalkulation der Frontplatte ist im Anhang. Kostspielig sind auch die Textgravuren. Hier könnte man z.B. auch mit einem Aufdruck (kostet bei Schaeffer AG pauschal dann m.W. um die 12 EUR) oder mit selbsterstellter transparenter Klebefolie arbeiten.

    Mir persönlich hat aber die Gravur besser gefallen und die Frontplatte sieht dadurch schon etwas hochwertiger aus.

    Pulldown sehe ich mittlerweile auch kritisch.... Deshalb kam ich ja in die Verlegenheit die Schaltung in dem Teilbereich anzupassen und diese späte Erkenntnis mit Fädeldraht zu verinnerlichen. :fp:

    Zu deiner Breakpoint Tabelle.

    BPTREM loescht ja nicht die Tabelle, sondern schreibt gesetzte Breakpoints zurueck (BreakPoinTREMove).

    Das ist schon sinnvoll, das am Anfang zu machen. Sonst laeufst du nach dem Reset evtl. auf einen deiner alten Breakpoint(s).


    Ausserdem ist es egal ob die Breakpoints geloescht werden, alleine der CALL Befehl schreibt die Ruecksprungadresse auf den Stack, der gerade auf 0xFC80 gesetzt wurde. Schon dadurch wird das EPROM abgeschaltet. Wenn du den MAT also aendern willst solltest du das CASINIT auch verlegen.

    Abgesehen davon wurde der MAT ja nicht fuer die EPROM Bootlogik geschrieben. Deshalb wuerde ich das nicht als Fehler ansehen, wenn du diese Funktion hinzufuegst, die einfach nicht vorgesehen ist.

    Das seh ich ein wenig anders.

    Im "Startvorgang" des MAT85 sind gesetzte Breakpoint meines Erachtens irrelevant. Denn das MAT85-System kann sich nicht selbst "Breakpointen". Breakpoints ermöglichen einen gesteuerten Ablauf eines Programmes. Dazu muss dieses durch GO, TRACE oder NEXT INSTRUCTION mit aktivierten Breakpoints kontrolliert gestartet werden. Denn nur so werden ggfl. Registerinhalte jeweils mit ausgegeben. Diese Funktion sehe ich beim MAT85-Startvorgang so nicht. Lasse mich aber gerne vom Gegenteil überzeugen.

    Sorry, ich hatte vergessen in meiner Beschreibung zu erwähnen, dass ich genau diesen Fall (zugriff vom System auf Speicher >= F000h) bereits über die EPROM-Abschaltlogik berücksichtigt habe. Korrekterweise muss der Lesebefehl im Adressbereich 8000h - BFFFh erfolgen um das EPROM abzuschalten.

    A15: 1

    A14: 0

    A13: X

    A12: X

    Aber danke für den Hinweis, ich werde das gleich noch ergänzen.

    Das mit dem Paging hab ich nicht verstanden.

    Du hast 64kB RAM. Ueber einen 4kB Block legst du nochmal 8 4kB Bloecke, von denen du einen selektieren kannst.

    Hab ich das richtig verstanden? Wenn ja, wofuer? Reichen die 64kB nicht?

    Korrekt. In den per DIP-Schalter einstellbaren Bereich, können jeweils bis zu 8 verschiedene 4k-Blöcke eingeblendet werden.


    Ob man diese 32kb nun "braucht" oder nicht, lass ich mal dahin gestellt. Vorstellbar wäre z.B. den COPY oder COMPARE-Befehl zu erweitern bzw. zu patchen um damit auch 32kb-Bereiche transferieren oder vergleichen zu können. Auch beim EPROMmer könnte ich mir die Verwendung des Paging-Bereiches gut vorstellen.


    Aber gerade die MAT85-Programmteile nutzen den gleichen Speicherbereich (E000h). Ein formatieren der Floppy überschreibt z.B. den Speicherbereich für SPS-Programme. Wäre doch schön, wenn das Mini-DOS dafür einen Paging-Bereich verwendet anstatt des "Hauptspeichers". Könnte man mit Sicherheit irgendwie anpassen. Basic im MAT85+ ist auch so ein Kandidat, der Speicher in Anspruch nimmt und das ohne Rücksicht auf "Verluste".

    Speicher satt

    Ein Problem hat mich schon immer beim MFA gestört: Das Speicherbild bzw. der Umgang mit den verschiedenen Speicherkarten. Es gibt die Standard 8K-Karte die man in verschiedene Speicherbereiche einblenden konnte. Dann gab es irgendwann die 16K-Karte, und die Karten mit Boot-EPROM.

    Bei all diesen Karten musste jeweils genau darauf geachtet werden welche mit welcher kombiniert und an welchen Speicherbereich diese jeweils aktiv war.


    Eine Idee

    Die ersten Ideen einer flexibleren Speicherkarte waren relativ schnell geboren. Sie sollte die vollen 64KB abdecken und wenn möglich sogar mehr über ein noch zu entwerfendes Banking-Verfahren. Auch die Boot-Eprom-Funktion sollte irgendwie realisiert werden. Es wäre auch echt cool wenn man das System Inplace editieren könnte, denn gerade in meiner frühen Jugend habe ich da schon öfters ein paar Änderungen vorgenommen und dazu immer wieder Eproms brennen macht ja irgendwie keinen Spaß.


    Für die Auswahl des Paging-Bereiches kamen verschiedene Ideen in Frage. Allen voran über einen Out-Befehl. Doch hier wäre vermutlich irgendwann das Problem aufgetreten, dass es zu Überschneidungen bzw. Überlappung mit bestehenden Interfacekarten kommen könnte. Andere Alternativen mit PAL-Chips wurden ebenfalls verworfen, da aktuell weder entsprechende Programmierumgebung vorhanden ist, noch ausreichendes Know-How und der Charme des MFA hätte vermutlich darunter leiden können. Auch das jederzeitige Auslesen sollte irgendwie machbar sein.


    Heraus kam eine direkte 16-Bit Speicheradressierung die einstellbar ist. Durch das Schreiben in eine Speicherzelle wird die entsprechende Paging-Seite in einen einstellbaren Speicherbereich eingeblendet. Durch das Schreiben und Lesen in die Speicherzelle kann diese im Programmcode jederzeit wieder in Erfahrung gebracht werden.

    Auch eine Anzeige der aktuellen Paging-Seite wäre nett, und so kommt nun auch eine 7-Segment-Anzeige mit auf die Platine.


    Die erste Ideen-Skizze:


    Der erste Entwurf der Platine, der eher einem Prototyp gleicht. Denn dieser hatte 3 grobe Layout und Schaltungsfehler und war noch nicht so richtig perfekt.

    Peinlichkeit 1: Bei der Anzeige-LED zum aktiven ROM wurde doch glatt der Vorwiderstand vergessen.

    Peinlichkeit 2: Beim Verdrahten des 7486 habe ich das falsche Signal genommen und musste dann nachträglich ein paar Leitungen durch einen freien Inverter jagen und das Layout ein wenig "umorganisieren".


    Die überarbeitete Version der RAM/ROM-Paging-Karte


    Die fertige (korrigierte) RAM-Karte


    Die Frontblende mit Anzeige-LED und Schalter für das manuelle aktivieren des EPROMs


    Die Speicherkarte in Betrieb (hier Paging-Seite 7 ausgewählt)

    Funktionsbeschreibung der Karte

    Grundsätzliches

    Die Karte besteht im wesentlichen aus vier 32kb Speicher-Chips (27256 und 2 x 62256 o.ä.). Ein zusätzlicher 32KB RAM-Chip ist das Paging-RAM.


    Paging-Funktion

    Der zusätzliche Paging-RAM-Chip (IC4) wird in 8 jeweils 4kb-Seiten in den vorhandenen MFA-Speicherbereich 8000 - E000 eingeblendet. Der gewünschte Bereich ist dabei über den DIP-Schalter SW1 auswählbar. Achtung: F000 macht beim MFA wenig sinn, denn dieser Bereich ist ja vom System belegt, unter anderen der Stack.

    Die Auswahl der gewünschten Seite wird über einen Memory-Write-Befehl auf eine, über die Hex-Drehschalter (S1-S4) einstellbare, 16-Bit-Adresse vorgenommen. Über folgenden Code wird eine Seite des RAM-Paging aktiviert:

    Code
    MVI A,03h    ; Seite 3
    STA 0FE00h   ; In die per Schalter eingestellte Adress-Selektionsadresse schreiben

    Dadurch dass hier gleichzeitig geschrieben wird (Pageselektor-Chip IC11 und System-Speicher) kann jederzeit die gerade aktuell eingestellte Paging-Seite wieder in Erfahrung gebracht werden.


    Boot-Rom-Funktion

    Die Boot-ROM-Funktion bzw. das Abschalten des EPROM erfolgt, wie beim Original auch, durch einen Lesebefehl auf eine Adresse im Bereich 8000h - BFFFh. Ein aktives EPROM wird zusätzlich über die grüne LED an der Frontblende angezeigt.

    Da auch hier der untere Speicher parallel zur Verfügung wird, kann bei aktivem EPROM in den Speicher 0000h-7FFFh geschrieben werden. Dies kann man dafür nutzen, über ein den KMD+> - Befehl Copy den gesamten Bereich von 0000h-7FFFh in den Bereich 0000h zu kopieren und anschließend mit einem Lesebefehl auf Adresse >= 8000h das EPROM zu aktivieren. Nun befindet man sich dann mit dem MAT-System im RAM. Das hat den Vorteil, nun kann man Inline am Systemcode herumspielen.


    CP/M macht's vor

    Dadurch dass das gesamte MAT85+-System zur Verfügung steht, sind auch alle Floppy-Funktionen vorhanden. Somit kann man sein MAT85+-System, das man sich vorher auf Diskette gespeichert hat, nun im "Boot-Vorgang" in den Speicher laden, auf RAM umschalten und durchstarten. Da die Datei sich den Startbereich ja gemerkt hat, muss man dazu nicht mehr viel auswählen, außer dem gewünschten Dateinamen (sprich "OS"-Variante).


    Entdeckte Fehler

    Bei der ersten Inbetriebnahme ist nach dem Einschalten immer wieder das EPROM abgeschaltet worden und das System lief buchstäblich ins leere.

    Erst nach einiger Suche und Einzelschrittmodus des Startvorganges (waren schon einige Schritte die das System durchführt bevor da was passierte) ist ein "Bug" des Systems aufgefallen. Dazu ein Auszug dem dem MAT85-Quellcodes:

    Die Zeile 192 müsste meines Erachtens an seiner Stelle entfernt und nach der Zeile 212 wieder eingefügt werden. Denn nach der Initialisierung des Systemspeichers (ab Zeile 208 ERAM-BRAM) darf er gerne seine Breakpoint-Tabelle löschen. Direkt nach dem Einschalten eine noch nicht initialisierte Breakpoint-Tabelle zu löschen, macht zum einen wenig Sinn und kann durchaus zu Schreib-/Lesevorgängen in einen Speicher >=8000h führen. Dadurch wird aber "aus versehen" das Boot-Eprom abgeschaltet. Da aber das parallele RAM noch keinen vernünftigen Code enthält, geht das schief und das System bleibt hängen (man könnte auch von einem Blue-Screen reden, das wäre gegenüber dem MFA aber fast eine Beleidigung ... ;) )


    Erweiterungen

    Nichts ist perfekt, so auch diese RAM-Karte. Derzeit sind folgende Erweiterungen geplant:

    • Erweiterung auf 64KB Paging-RAM (Seiten 0-F)
      Dazu muss ich aber noch ein wenig Platz auf der Platine schaffen oder die 62256 in der, nur schwer erhältlichen, schmalen Gehäuseform wählen oder in SMD ausführen
    • Batteriepufferung
      Der komplette Speicher über eine Batterie (oder Akku) puffern. Ich verspreche auch, dass ich dafür keine Freileitungen verwende ... ::heilig:: MFA - Reaktivierung nach über 30 Jahren
      Das hätte den Vorteil, dass das Betriebssystem nicht immer neu gebootet werden muss, z.B. bei Anpassungen am Programmcode (Löschtaste sollte aber noch vorhanden sein)
    • EEPROM-Unterstützung
      Eventuelle Anpassungen zur Nutzung von EEPROM-Bausteinen

    Wenn jemand noch weitere Ideen hat, gerne her damit. Wenn diese umsetzbar sind, kann die Karte ja nur noch besser werden.


    ---


    Auch hier wieder wie gehabt: EAGLE-Projekt und CAM-Daten im Anhang.

    Aktuell habe ich hier noch 1 Platine übrig. Wenn auch hier jemand Interesse daran hat, einfach melden.

    entschuldige bitte - ich wollte lediglich zusätzliche Ideen liefern, das sollte eigentlich kein Genörgel werden - bitte nicht so auffassen:cat2:


    ...werd mich in Zukunft mehr zurückhalten

    Hab ich nicht so aufgefasst, alles gut. Aber so abwegig mit dem vergessenen Vorwiderstand ist das gar nicht. Ist mir nämlich tatsächlich schon passiert. Zwar kein Beinbruch, aber trotzdem peinlich/ärgerlich.

    btw - schön wärs gewesen, wenn die benötigten Vorwiderstände für die LEDs auch gleich noch mit auf die Platine gewandert wären;)

    ..und um den Leuten bei JLCPCB das wegätzen der grossen Flächen nicht allzu schwer zu machen nutzt man am geschicktesten bei Eagle die "Rastnet" - Funktion und legt einfach ein komplettes Polygon über die beiden Leiterplattenseiten - oben dann ohne Anschluss(oder ebenfalls GND) und unten mit GND verbunden:saint:

    Die Vorwiderstände sind doch auf der Platine (R7, R9, R10) oder habe ich da was falsch verstanden?


    Das mit der Kupferfläche ist ein guter Hinweis, danke. Werde ich bei meinen nächsten PCB-Entwürfen berücksichtigen.