TA PC-8, dies und das

    Hallo Hobi,
    sehr schöne Arbeit.
    Soll ich meine ROMs mal auslesen und hier rein stellen ?

    Ich war ein bischen auf dem 3D-Druck Trip gewesen, werde aber das Zeug bald wieder zur Seite stellen.
    Evtl. kommen nächste Woche bereits meine ROM-Modul Platinen, die liegen laut Traking bereits in Deutschland.


    mfG. Klaus Loy

    Ich habe experimentell versucht ein USB drive an den ROM Port zu stecken. So richtig gut funktioniert es nicht.

    Es gibt kein Signal, das eindeutig den Zugriff auf das ROM anzeigt. Leider ist das cs-Signal immer aktiv, wenn die Adresse A000 oder C000 anliegt. Lediglich der Bustreiber auf den Board schaltet je nach Einstellungen den Datenbus zwischen RAM und ROM.

    Also entweder man legt noch ein Auswahl Signal mit in den Slot oder ich geh über den 50pol. Erweiterungsport ran.


    Momentan habe ich es so gelöst, das man die Hardware über einen Schalter zuschaltet. Das gefällt mir nicht sonderlich gut. Eine Alternative wäre eine bestimmte read-sequenz zu implementiert, die diese Funktion übernimmt. Das erhöht allerdings den Aufwand.

    2 Mal editiert, zuletzt von Hobi ()

    @Hobi, schöner Aufbau.
    Was hast da für eine USB drive Platine im Einsatz ?

    Warum sagst du das der Zugriff ist nicht eindeutig ist ?


    Lesezugriff ist dann, wenn CS & RD beide LOW sind das ist aus meiner Sicht erstmal eindeutig.
    Weil die ROMs kommen damit ja auch klar.


    Dumm ist halt, dass wenn RD zu LOW wird, erst die Adressen ausgewertet werden müssen und dann wenige ns später die gewünschten Daten auf den Bus müssen. Beim Schreiben dieser Zeilen denke ich jetzt erst drüber nach. D.h. RD geht auf LOW dann dauert es halt wie bei einem ROM noch z.B. 200ns und dann MÜSSEN die Daten anstehen. Wenn die Daten durch einen Controller bereit gestellt werden sollen, ist das natürlich eine harte Forderung. Andererseits, wenn RD auf LOW geht, dann sind ja die Adressen "hoffentlich" bereits stabil. Mehr fällt mir grad dazu nicht ein.

    mfG. Klaus Loy

    Zitat von klaly
    Lesezugriff ist dann, wenn CS & RD beide LOW sind das ist aus meiner Sicht erstmal eindeutig.

    Nein, leider sicht. Diese Signale CS&RD kommen auch wenn der BASIC Interpreter von der Adresse C000 liesst, auch wenn der ROM ausgeschalten ist. Es liegt daran dass CS nur von den Adressen gebildet wird und OE ist das /RD Signal. Der Eprom wird also immer angesprochen. Lediglich der Bustreiber "blockt" die Ausgabe.


    Für den Rest hast du recht kurz nach dem CS anliegt, sind die Adressen schon stabil. Einen halben Taktzyklus später kommt das RD. Mit der steigenden Flanke wird dann gelesen. Das ist heutzutage sehr entspannt.


    Mein Problem ist, dass ich für den Schreibzugriff einen Trick angewendet habe: Ein Lesezugriff auf C0xx wird als Schreibzugriff Byte XX an den Controller gewertet. Ich habe lediglich A8 and WR geklemmt und A0-A7 an den Datenbus. Wenn also der Basic-Interpreter oder CPM da rumlesen, wird also wild auf dem Controller "geschrieben".


    Der Controller ist ein CH376. Der hat den Vorteil, dass FAT schon implementiert ist, was wohl für CPM keine Rolle spielt, aber eventuell für BASIC ok.

    Jetzt verstehe ich es,
    es kommen auch "Leseanfragen" an das ROM, wenn das ROM gar nicht gemeint ist.
    ROM Liefert die Daten bis zum Bustreiber, aber der liefert diese "Dummy Daten" nicht weiter.

    Das ist allerdings ziemlich Blöd.

    Wie hätte dein Konzept ausgesehen ?

    Für den Controller hätte es ja wohl auch Schreiboperation gebraucht.
    Wie hättest das machen wollen ?


    mfG. Klaus Loy

    Hallo Hobi - in deinem Beitrag hast du ja

    einen "U disk and SD card file management controlchip CH376" auf offenbar eine alphaTronic PC-8 ( Z80 System) ROM Pack Karte angebunden.

    Wenn du die momentanen Hardwareanbindung-Problem hinbekommst, und jeweils ein Byte in beide Richtungen schicken könntest, ist noch nicht für mich erkennbar- wo das Ziel ist?


    In der CH376 Karte ist ja zum USB Anschluß ein File-System FAT12 oder FAT16, oder.mehr!

    Was und welche Datenformate möchstes du eigentlich damit auf einem Z80 System anfangen?

    Klar - fast alles läßt sich meist per Assembler und viel Detailarbeit realiesieren.

    Hast du schon überlegt was auf dem TA PC-8 wie ein Treiber aussehen müsste, und was sollte der leisten?


    Oder du hast eine andere geniale Idee für den Einsatz auf einem TA PC-8?

    Viel Freude beim "bohren von dicken Brettern".

    helwie44 †

    Ziel ist es das CPM zu starten und dann den USB-Stick als zusätzliches Laufwerk einzubinden.


    Was das Low-Level format anbetrifft, könnte man die Disketten-Images aus Mame verwenden. Es gibt auch die Möglichkeit sich in die BIOS/BDOS einzuklinken und dort die Fileoperationen zu bedienen.


    Aber du hast insofern recht, ich möchte erst einmal probieren, ob ich den USB-über den ROM Port mounten kann.

    Ich hab mir grad ein bischen den Schaltplan angeschaut und dort ein paar Signal hervorgehoben.
    Siehe Bild.


    Verstanden hab ich es zwar noch nicht, aber ich denke die Zugriffe auf die einzelnen ROMs müssen eindeutig sein.


    OE# aller ROMs einschließlich der im ROM Pack werden von MEMR# angesteuert.
    Und nur wenn ROMPE# aktiv (LOW) ist, dann schaltet der Treiber IC14 das externe ROM auf den internen Datenbus durch.
    Aber wenn ein internes ROM selectiert ist, durch IC34, 74LS138, dann kann ja das externe ROM nicht selektiert sein.
    Ansonsten, wenn gleichzeit ein internes und das externe ROM selektiert wären und MEMR# = LOW, dann würde es eine Bus Kollision auf dem Datenbus geben.

    Also verstehe ich aktuell dieses Selektier Problem nicht.


    mfG. Klaus Loy

    Meine China Platinen liegen nun schon eine Woche beim Zoll in Deutschland, in SCHKEUDITZ :(
    Da hilft nur warten...

    Der USB-Stick funktioniert. Ich kann sofort ins DISK-BASIC gehen. Leider spielt mir da der BASIC Interpreter einen Streich und initialisiert das Diskettenlaufwerk und bleibt dort hängen, mangels HW.


    Plan a: ich kann meine Logik aus der Simulation "return: Alles Ist Gut!" nehmen und als Hardware anschliessen.

    Plan b: Patch des BASIC Interpreters.


    oder egal, ich schaue das ob ich da CPM zum Laufen bekomme.

    @Hobi,
    welcher deiner beiden Pläne der bessere ist kann ich dir leider nicht sagen.

    Wie hast das mit dem "Adressierungsproblem" nun lösen können ?
    Du meintest ja das die Adressdekodierung nicht eindeutig wäre.

    mfG. Klaus Loy

    1. Das Schreiben ist recht einfach gelöst, in dem ich A8 als Write Leitung verwendet habe und so eine Lesezugriff auf C155, schreibt 55 in den Kontroller.


    2. Das Problem des vagabundierenden CS Signals habe ich vorerst mit einem Jumper umgangen. Ist der Jumper offen, wird das CS Signal an den Controller weiter geleitet. Wahrscheinlich werde später ich ein FlipFlop einbauen, dass dann schaltet, wenn eine bestimmte Sequenz vorliegt.

    Also lesen auf C1xx schreibt den Wert XX in eine immer gleiche Zelle.

    Das vagabundierende CS-Signal verstehe ich nach wie vor nicht.
    Ich hatte mir ja vor ein paar Tagen mal den Schaltplan angesehen und hierfür keine Erklärung gefunden.

    Hast du eine Erklärung ?
    Oder ist an deinem PC8 etwas kaputt.


    mfG. Klaus Loy

    Zitat

    Also lesen auf C1xx schreibt den Wert XX in eine immer gleiche Zelle.

    C1 = Aktiviert nicht nur dass WR Signal, es legt auch noch A0...A7 auf den Datenbus.


    Zitat

    Das vagabundierende CS-Signal verstehe ich nach wie vor nicht.

    Ich hatte mir ja vor ein paar Tagen mal den Schaltplan angesehen und hierfür keine Erklärung gefunden.

    Den Schaltplan hast du schon wunderbar aufbereitet. Wie du am 138er sehen kannst ist das CS2 Signal immer aktiv, wenn der Interne ROM aktiviert ist. Sprich bei aktiviertem BASIC, ist ROMINH L aktiv und damit leider auch die Zugriffe auf die Adresses Axxx/Cxxx .

    Oder sehe ich da was falsch?

    Ich verstehe es nicht.
    CS1# hängt am 138 an Y5 und CS2# am Y5
    CS1# kann nur LOW werden, wenn Adresse A000 - BFFF anliegt und ROMINH# LOW ist.

    CS2# kann nur LOW werden, wenn Adresse C000 - DFFF anliegt und ROMINH# LOW ist.


    D.h. wenn ein internes ROM angesprochen wird, wir CS1# und auch CS#2 nicht low, d.h. bleiben inaktiv.

    Es könnte sein, dass bei RAM Zugriffen auf A000 - DFFF die CS1# bzw CS#2 aktiviert würden, da müsste man sich die ROMINH# Leitung mal näher ansehen.

    Aber bei ROM Zugriffen können die CS1# und CS2# nur kommen wenn auch die externen ROMs gemeint sind.


    mfG. Klaus Loy

    Zitat

    D.h. wenn ein internes ROM angesprochen wird, wir CS1# und auch CS#2 nicht low, d.h. bleiben inaktiv.

    das ist schon halb richtig. Wenn aber das Basic Rom aktiv ist, ist logischerweise auch rominh aktiv. Wenn man dann mit aktiviertem Basic auf den Bereich Cxxx zugreift, dann wird auch CS2 aktiv. Sehe ich das richtig?

    Klar, aber das soll ja auch so sein, weil ja da das externe ROM eingeblendet ist.
    Und wenn du drauf zugreifs, vermutlich PEEK und POKE aus dem Basic, dann müssen die CS1# und CS2# aktiv werden.
    Also so würde ich es erwarten und OK finden.
    Weil Zugriff auf A000 .... DFFF soll ja gerade das externe ROM ansteuern.

    Und wenn ROM enabled ist, dann liegt bei A000 ... DFFF natürlich kein RAM, der ist dann abgeschaltet.


    Warum "gefällt dir das nicht" ?
    Oder wie würdest du das erwarten ?

    Zitat

    Klar, aber das soll ja auch so sein, weil ja da das externe ROM eingeblendet ist

    dies ist nicht korrekt. Der externe Rom ist normalerweise abgeschalten, d.h. Basic hat den RAM zur Verfügung.

    Wenn also rominh L ( Port 10, bit 7) ist, kann mit Rompe (Port 10 bit 6) der externe Rom zu oder abgeschalten werden.

    Rominh ist bei aktiviertem Basic immer L.

    Eine Sache hatte ich natürlich nicht bedacht, CSx# kommt natürlich auch bei Schreiben in diesen Bereich.
    Was ich oben gesagt (geschrieben) hatte galt nur für Lesen, d.h. man müsse da CSx# mit OE# zusammen betrachten.

    ... und du hast recht, der IC31, LS20 der hat mit der "RAM Freigabe" für lesen zu tun.

    Das heißt vermutlich BASIC ROMs sind enabled, externer ROM ist über ROMPE# abgeschaltet, dann ist das RAM im Bereich A000 ... DFFF tatsächlich ansprechbar und die CS1# und CS2# würde rum wackeln, aber der OE# dürfte in diesem Falle niemals gleichzeit dazu kommen.

    Wenn man lange genug diskutiert, sieht man eventuell die Lösung. Das vagabundierende CS Signal tritt im Umkehrschluss nur beim ROM Basic auf, nie bei CPM und nie beim DISK-BASIC.


    In dem Sinne lade ich beim Booten den ROM in den RAM um und schalte das BASIC ROM ab. Jetzt geht es und niemand stört mehr.

    Sollte so passen.
    Evtl. solltest es noch in den anderen Thread, wo es um TA8 ROMs geht rüber linken.


    mfG. Klaus Loy

    Echt tolle Arbeit und sogar in Farbe, ...
    Kommt das Bild aus dem TA8 ? (vermutete Antwort: JA)


    mfG. Klaus Loy

    Ich hatte mich vor ein paar Tagen mal dran gemacht den PC-8 Floppy Controller möglichst 1:1 in KiCad mal nachzuzeichnen, um dann mal eine Platine machen zu können. Hier vorab mal mein Entwurf als PDF und den Schaltplan aus dem PC-8 Servicemanual.

    Wenn jemand Lust hat, bitte durchschaun und Fehler melden. Es fehlen noch die ganzen Abblock Kontensatoren und am Floppy Controller ist eine Diode D101, evtl hat jemand Ahnung für welchen Zweck die ist und welcher Typ da geeignet wäre (evtl. Schottky Diode).


    Hier das Vorab KiCad Projekt TA8-FDC.zip


    TA-8_Floppy_Controller_V0.0.1.pdf


    mfG. Klaus Loy

    Hier noch grad der original Schaltplan.

    Es fehlen noch die Seiten mit dem Netzteil, welches auf der FDC Platine mit drauf ist.
    Aber das möchte ich sowieso nicht so machen.

    Ich möchte ein externes Netzteil 12V / 5V oder vieleich nur 12V vorsehen mit zusätzlichem 5V Regler.


    TA_PC8_Floppy_Controller_original.pdf


    mfG. Klaus Loy