Junior Computer ][

Hallo discmix . War bei dir das Display auch eingeschaltet? Auf dem Bild steht der Display Schalter auf Off, wenn ich das richtig sehe. Außerdem, muss der Step Schalter auf Off stehen.

Grüße Jörg

Hallo zusammen, jetzt muss ich mich doch mal wieder melden und die neuesten Projektfortschritte mitteilen.

Ich hab letzte Woche begonnen mit dem von UTSource bestellten GM82C765B Floppy Disk Controller rum zu experimentieren und war da zu mindest Teilerfolgreich.

Der Chip ist von den Schnittstellen gesehen nicht allzu schwer anzuschließen und benutzt nur vier Hardware Adressen. Bei mir erstmal :

$800 : Read Only - Master Status Register

$801 : Read/Write - Data Register

$802 : Write Only - Disk Control Register (DCR)

$803 : Write Only - Disk Option Register (DOR)

Ich hatte zunächst nur das Problem, dass ich übersehen hatte, das die Reset Leitung des Chips nicht wie beim 6502 invertierend ist, und als R/W Leitung hatte ich zunächst RAM-R/W angeschlossen, was den Chip (besser gesagt das angeschlossene 5 1/4" Laufwerk) zum Stottern brachte. Ausserdem mussten einige

Manche Befehle wie SEEK und RECALIBRATE beenden mit einem Interrupt des FDC, der dann durch den Befehl SENSE INTERRUPT STATUS abgeschlossen werden muss. Da ich keine Interrupt Routine nutzen, sondern lieber alles per Polling machen möchte, habe ich die INT Leitung des FDC mit 74XX Logik als Pseudo-Register über das DOR gelegt, welches ja Write Only ist. Durch Lesen der Adresse $803 kann nun der INT Status ($80 = INT, $00 = kein INT) gelesen werden.

Mein größtes Problem ist zur Zeit, dass die einzelne Eingabe der Befehlsbytes über den System Monitor zwar korrekt abgearbeitet werden, eine Programmgesteuerte Übertragung aber nicht funktioniert, obwohl ich die angegebenen Wartezeiten von 12uS zwischen den Datenbytes einhalte und auch immer brav das Master Status Register zwischen jedem geschriebenen/gelesenen Datenbyte anschaue.

Hat da von euch schon jemand Erfahrung mit der Programmierung des GM82C765B, bzw. des Pin- und Befehlskompatiblen WD37C65C auf einem nicht x86 System gemacht. Ich hatte früher schon unter DOS den Floppy Controller öfters direkt angesprochen und war da eigentlich nie auf solche Probleme gestoßen. Eventuell habe ich da dann doch ein Hardware Timing Problem? Ich werde euch mal den aktuellen Schaltplan mit KiCAD erstellen, vielleicht findet ja irgend jemand einen totalen Bock in meiner bisherigen Schaltung.

Bzgl. Timing: Per Polling bekomme ich die Daten bei einem READ TRACK nur vollständig gelesen, wenn die Datenrate bei 250 kb/s MFM liegt. Dann hat die CPU 24 us Zeit ein einzelnes Datenbyte zu verarbeiten. Bei 500 kb/s sind es dann eben nur noch 12 us, was die 1MHz getaktete 6502 aber nicht hinbekommt. D.h. entweder ist die maximale Datenmenge auf einer Floppydisk dann eben auf 720KB beschränkt, oder ich bastele noch eine minimale DMA Schaltung mit Background Buffer an den FDC. Dazu würde ich dann aber ggf. auf ein GAL zurückgreifen, um nicht zu viele TTL Bausteinchen zu verbraten.

Ich werde das Thema jetzt aber erst mal wieder etwas zurückstellen, und mich wieder um den Command Interpreter für das M/OS 65 kümmern, so dass ich wenigstens mal ein DIR auf das SD-Karten Verzeichnis hinbekomme.

Zitat von felge1966

Den 37C65 hatte doch der Zeta V2 drin. Eventuell gibts bei den RomWBW Quellen da noch Tips oder Lösungsansätze?

Hallo felge1966 , ich hatte befürchtet, dass jemand mit dem Verweis auf den Zeta V2 kommt. Den Code hab ich mir auch schon angesehen, allerdings bin ich überhaupt nicht in Z80 Code drin, und wollte das auch weitgehendst vermeiden mich da irgendwie durch zu wurschteln. Ist aber natürlich eine Option. Auf alle Fälle trotzdem vielen Dank für den Tipp.

Hier übrigens mal der minimale Schaltplan. Der FDC ist jetzt nicht mit drauf, weil ich das Symbol erst noch für die KiCAD Bibliothek erstellen müsste. An die FDC Pins gehen die Label A0, /RD, /WR, /LDOR, /LDCR, /CS, RES und INT. Datenbus ist ja klar und die Floppy Seite ist erst mal Wurscht. Die DMA Schnittstelle hab ich auch nicht in Benutzung, daher ist Terminal Count (TC) einfach auf +5V gelegt. Der 74LS244 übernimmt die Rolle des Read Registers für das Interrupt Signal des FDC.

Zitat von Reinhard

Weiss jetzt nicht, ob K2 schon mit Phi2 verknüpft ist.

Falls nicht, dann ist es der klassische Fehler, beim 6502 den "Phi2 high" als AND in die /CS Bedingung zu vergessen.

A0..A15 und R/W werden zusammen gültig BEVOR dann etwas später die Daten gültig werden und dann erst wird Phi2 high.

Hallo Reinhard . Vielen Dank für die Info. /CS hab ich jetzt tatsächlich noch nicht mit PHI2 verknüpft. Da der FDC die Daten bei steigender Flanke des /WR Signals latched, hatte ich die Befürchtung, dass bei vorherigen inaktiv werden der /CS Leitung dann die Daten garnicht übernommen werden. Denn die PHI2 Phase endet ja vor einer Änderung von R/W. Ich hatte zuerst auch versucht den FDC mit der RAM_R/W Leitung zu steuern. Diese ist ja mit PHI2 verknüpft und würde somit theoretisch den Latch Zyklus mit Ende der PHI2 High Phase beenden. Das mochte der FDC aber garnicht.

Ich werde nachher mal testen, ob eine Verknüpfung von K2 mit PHI2 den Durchbruch bringt.

Ich habe jetzt mal zwischen den Read Data und Write Data Befehlen im Code ein 255ms langes Delay gesetzt. Damit funktioniert es. Ist also ganz klar ein Timing Problem.

Zitat von Reinhard

Meines Wissens gibt es keine Software-Lösung um mit 1 MHz 500kBit/s zu verarbeiten.

Ich denke auch, dass das nicht möglich ist. Ein LDA imm braucht 2 Zyklen, ein STA abs,X 5. Dann noch INX, ein BEQ und dann noch der Vergleich auf einen Page Überlauf wegen der 512 Byte Blocks. Das ist in 12 Zyklen nicht zu machen.

Der MC6844 ist natürlich auch eine nette Variante. Den hatte ich garnicht auf dem Schirm, weil der in meinen Motorola Datenbüchern leider keine Erwähnung findet. Da schaue ich auch immer gerne mal rein, wenn ich was exotisches für 8 Bitter brauche. Ich fürchte aber, dass der DMA Controller recht schwer zu bekommen ist. Hast du da schon irgendwelche Erfahrungen gesammelt?

Hab mir jetzt das Datenblatt gezogen und werde das als Gute Nacht Lektüre durchlesen (man sind wir alle schräg ).

Meine Überlegung eines einfachen DMA war, nicht den Hauptspeicher für den Transfer zu nehmen und somit evtl. die CPU anhalten zu müssen, sondern einen Ein-/Ausblendbaren Speicherbereich soz. offline mit den Daten via DMA Handshake und einem Adresszähler zu befüllen, bzw. davon zu lesen. Wenn die Daten dann im Buffer stehen, blendet man diesen dann per Bank Switching in den Hauptspeicher ein. Das müsste mit überschaubarem Aufwand machbar sein.

Letztlich wäre ich aber auch mit einer 720K Floppy schon zufrieden, DD Disketten hab ich noch zu genüge rumfahren.

Reinhard was hast du da für einen schönen Floppy Controller . Der sieht mir sehr nach Apple // Steckkarte aus. Sehr nett

Zitat von Reinhard

Ja, war/ist für den APPLE ][. Ich weiss aber nicht einmal mehr, ob der von mir entwickelt war, oder ob ich da mithalf, oder überhaupt nicht.

Irgendwann war die Apple ][ Zeit vorbei und 4 MHz Z80 Systeme mit DMA die "Norm"

Ich hab den Umstieg auf Z80 nie geschafft. Ich war da zu sehr 6502 vernarrt. Eine kurze 68000 Phase dann bin ich, was Assembler Programmierung anging, in das x86 Lager umgestiegen.

Zitat von Reinhard

PS: ich denke (ohne jetzt das Datenblatt zu studieren), dass es wie bei den meisten ICs ist: die steigende Flanke von WR oder CS latcht die Daten, was auch immer zuerst passiert.

Ich hab jetzt gerade mal K2 über einen Tristate Treiber mit PHI2 (bzw. PHI1 wg. invertierter Freigabe) synchronisiert. Reinhard du bist genial. Es funktioniert!

Offensichtlich ist es tatsächlich egal, ob /CS oder /WR zuerst inaktiv wird. Die Daten werden jetzt sauber gelatched und mein Programm wartet brav nach einem SEEK, bis das INT Signal auf High geht, bevor es SENSE INTERRUPT STATUS aufruft.

Ich hatte mich tatsächlich schon zu Beginn gewundert, warum der FDC trotz fehlender PHI2 Verknüpfung funktionierte, da bei Änderung des R/W Signals am 6502 die Daten schon lange nicht mehr stabil sein müssen.

Herzlichen Dank Reinhard!

Jetzt gerade mal eine kleine Routine laufen lassen:

- Initialisieren des FDC

- Setzen der Step Rate, Head Load/Unload Time

- Recalibrate

- Seek auf Track 70

- Recalibrate

läuft wunderbar. Fragt man sich nur, warum RECALIBRATE nur 77 Steps Richtung Track 0 fährt und nicht wie der uPD765 255. So muss man um sicher auf Track 0 zu stehen bei einem 80 Track Laufwerk immer zwei mal rekalibrieren. Seltsam...

Weiß eigentlich jemand, was die optimalen Einstellungen für Head Load / Head Unload Time sind? Es geht ja bei den neueren Laufwerken nur darum ein Head Jittering nach der Kopfbewegung zu verhindern. Da müssten doch 16 ms HLT und 2 ms HUT reichen?

Hier der geänderte Schaltplan. Bleibt die Überlegung das TTL Grab in ein GAL zu verfrachten. Wäre ja mittlerweile kein großer Stilbruch, da ja auch schon veraltete Technik.

Zitat von ThoralfAsmussen

TTL kann aber jeder nachbauen - auch ohne passenden "Brenner".

Stimmt natürlich schon, aber mittlerweile hat hier im Forum wahrscheinlich jeder einen günstigen Minipro TL866A o.ä. für seine (E)EPROMS und damit sind dann z.B. auch GAL16V8 programmierbar.

Hallo klaly . Das sieht genauso aus, wie ich mir das vorgestellt hatte. Ein extra Sektor Buffer der via DMA befüllt und dann vom Host eingelesen wird (bzw. umgekehrt bei einem Write). Danke für das Datenblatt. Ich werd mir mal Gedanken machen, wie und ob ich das in den FDC integrieren werde.

Heute Nacht dachte ich, dass es doch noch Probleme mit meiner FDC Schaltung gibt. Ich wollte den Drive Status abfragen - laut Datenblättern von WD und (Unlucky) Goldstar der Befehl $00) - was der Controller standhaft mit Unkown Command quittierte. Zu allem Unglück gab die manuelle Eingabe ein anderes Status Ergebnis zurück, als es die Programm gesteuerte Ausführung machte. Letztlich hab ich dann das Datenblatt des UPD765 zu Rate gezogen und den Befehlscode $04 ausprobiert...und tadaaa... der Drive Status wurde angezeigt.

Echt blöde, da hat WD ein fehlerhaftes Datenblatt rausgebracht und alle schreiben einfach ab. Das ist ja wie in der Grundschule!

Immerhin sind bei Goldstar die Bezeichnungen der Register richtig, die sind nämlich bei WD durchrotiert (MST = ST0, ST0 = ST1 ...).

Jedenfalls scheint die Schaltung jetzt zu tun, was man von ihr erwartet.

Ich bin aber auch nicht vom Fehlerteufel verschont geblieben. Im Schaltplan liegen am 2 zu 4 Decoder die Ausgänge in der Reihenfolge von oben nach unten bei Q0..Q3. Ihr müsst euch da aber die Reihenfolge Q3..Q0 vorstellen, da bei mir wie oben erwähnt ja das MST an $800, Data an $801, /DCR an $802 und /DOR an $803 liegen. Wird natürlich in der endgültigen Schaltung korrigiert.

Zitat von klaly

für diese DMA-Schaltung mit lokalem RAM könnte es zu Problemen bei Formatieren kommen.

Da sehe ich kein Problem. Für die Formatierung benötigt man ja kein DMA. Du musst da ja nur für jeden Sektor im Track die benötigten Daten (ID, GAP3, etc) bereitstellen. Das kann man dann wieder Interrupt gesteuert, bzw. per Polling machen, da die Zeiträume zwischen zwei Anfragen des Controllers ja riesig sind. Ob der Controller irgendwas DMA gesteuert machen soll, kann ich ja per SPECIFY Befehl (Byte 3, Bit 0) angeben und so einzelne Befehle gezielt als non DMA ausführen.

So, bisher erst mal letzte Version des Schaltplans für den Floppy Controller, inkl. des WD37C65B (GM82C765B) und Floppy Connector. Das Pseudo Register (Read DOR) zeigt jetzt dann an Bit 8 den Interrupt und an Bit 7 Disk Changed an.

Zitat von Reinhard

Du musst aber trotzdem pro Sektor 4 Bytes rasch an den Controller senden, damit er das ID-Feld erzeugen kann. Aber das passt natürlich in einen z.B. 2kB DMA-Puffer stets hinein.

Das stimmt schon, aber da komme ich mit wesentlich weniger Befehlen aus nämlich jeweils nur LDA und STA, das sollte dann zeitlich kein Problem sein.

Besser ist das! . Jetzt mal das TTL Grab gegen ein GAL 16V8 ausgetauscht.

ThoralfAsmussen : Ich denke, dass ich das auch so lasse. Falls ich mich entschließe eine DMA Schaltung mit einzubauen, benötige ich sowieso noch min. weitere 8 Bausteinchen (2x Zähler, 2x Adress Bustreiber, 2x Datenbus Transeiver, RAM, GAL) wenn ich dafür dann eben auch ein GAL nehme, sonst wesentlich mehr. Damit ist es dann sowieso egal, ob ein oder zwei PLDs auf der Platine drauf sind. Zusätzlich soll ja auch noch der Grafik Controller samt RAM mit drauf. Da möchte ich so viele TTLs wie möglich einsparen.

Eventuell werde ich aber auch zwei Versionen - eine mit GALs und eine nur mit TTLs - machen, dann kann jeder selbst entscheiden, was er aufbauen möchte. Das dann aber nur, wenn ich mich gegen DMA entschließe.