Sagt der Mann dem 2 TTL und ein bisschen Glue zu viel sind um high speed DMA zu machen
Hmm, hab ich zwar nie gesagt - kannst du weiter oben auch nochmals nachlesen - aber lass mal gut sein... ich bin jetzt nicht wegen anderer Meinungen bzgl. meiner Entwicklungsentscheidungen gleich auf Krawall gebürstet. 
Jetzt hab ich mich erst mal mit dem Floppy Drive Motor On/Off Problem beschäftigt.
Der Motor darf ja nicht dauern laufen, sollte aber auch nicht zu früh wieder abgeschaltet werden, da man sonst wieder warten muss, bis er vollständig hochgefahren ist. Das könnte man jetzt wunderbar über einen Timer lösen. Allerdings kann ich nicht davon ausgehen, dass eine IO Karte mit VIA (und somit Timer) vorhanden ist. Der zwar immer vorhandene Timer im RIOT ist leider ungeeignet, da er viel zu kurz läuft und auch nicht repetierend ist. Außerdem wollte ich jetzt natürlich auch keine zusätzliche VIA auf dem Floppy Controller verbauen.
Ich hab das Problem nun mit je einem retriggerbaren Monoflop pro Laufwerk gelöst, welches nach drei Sekunden abläuft und dann einen Interrupt auslöst. Beim Aufruf einer Read-. Write- oder Seek- Routine, wird das Monoflop durch lesen oder schreiben auf eine MOTOREN1/2 Port-Adresse neu gestartet, so dass der Motor-Off Interrupt dann wieder für weitere drei Sekunden verzögert wird.
Wenn der IRQ ausgelöst wurde, muss dann nur noch durch Lesen meines pseudo Data Option Registers (das DOR ist ja im Normalfall nur Write Only) der "gewünschte" neue Zustand der Motoren ausgelesen, mit $34 ausmaskiert und in das echte DOR zurückgeschrieben werden. Dann wird der Interrupt durch lesen oder schreiben auf eine MOTORRES1/2 Port-Adresse wieder gelöscht und fertig.
Der Hardwareaufwand hält sich ebenfalls in Grenzen, da im verwendeten 74LS123 zwei Monoflops verbaut sind. Zusätzlich braucht man noch zwei JK Flipflops (74LS112) und nochmals ein GAL16V8, was ich aber für den Graphics Controller so oder so noch benötigt hätte.
Mittlerweile hab ich auch rausgefunden, wie man den FDC nach dem Lesen eines Sektors sauber abwürgt, damit er nicht automatisch den nächsten Sektor liest und falsche Fehlermeldungen zurückgibt.Es geht also voran.
Jetzt geht es bei mir ab Samstag nochmal für eine Woche in den Urlaub und am 30.9. und 1.10. bin ich dann in Dietzenbach auf der CC2023. Ich hoffe, da kann ich endlich mal wieder Antikythera , joshy , fachat und Shadow-aSc und natürlich viele andere wieder sehen. Freu mich schon riesig.
Übrigens: Auch wenn ich mich diesbezüglich noch nicht wirklich geäußert habe. Ich bin immer mal wieder dabei, die Fortschritte von Dietrich s CPM-65 Port auf dem Junior ][ zu verfolgen und auszuprobieren. Ich bin echt begeistert, was da bereits schon alles läuft, ohne das Dietrich einen Junior ][ sein Eigen nennen kann. Super Arbeit! 
Und ebenfalls einen ganz großen Dank an NorbertJ , der statt meiner bisher die ganzen Test gemacht hat, obwohl er gerade (sehr) viel um die Ohren hat. 
Ich hoffe, ihr beide könnt mir verzeihen, dass ich gerade nicht besonders in dem Projekt involviert bin und mich nur um andere Dinge wie den Floppy Controller kümmere. 
Du müsste doch auch das Video vom VCFe München von André's Vortrag noch haben.
Erzähl dass mal besser nicht den Mainframe-Leuten. Scheduler im Interrupt ist eine potentielle potentielle Fehlerquelle und eine mögliche Quelle richtig ekeliger Performanceprobleme. Interrupts sollen so kurz wie möglich sein und nur die Arbeit machen die direkt für die Hardwarebedienung nötig sind.
Ein einigermaßen gut konstruiertes Multi-Task OS hat ja auch nicht seinen Application Process Scheduler in der Interrupt Routine. Das wäre natürlich völliger Schwachsinn. Der Kernel Task Manager wählt aus, welcher der Kernel Tasks - also Memory Manager, Device Manager, etc. oder eben der Application Process Scheduler - Rechenzeit bekommt und braucht dazu nur ein Bit Feld abfragen und ein paar Pointer umschalten und kann dann die INT-Routine wieder verlassen. Da gibt es keine Performance Probleme weil man dazu nur ein paar Befehle benötigt. Das High Level Switching macht dann der APS außerhalb der Interrupt Routine. Dass es auch andere Möglichkeiten gibt ist unbestritten, und wie das bei einem Mainframe gehandhabt wird, weiß ich nicht...
Einen Idle Task basteln ist zwar recht hübsch aus theoretischer Sicht und um gut um Studenten im ersten Semester nicht zu verwirren, in der Praxis isses aber weniger gut.
Sorry, aber ohne Idle Task zu arbeiten ist, wie verkettete Listen ohne Guard, nur mit NIL (NULL) Pointer abzuschließen. Dann wundern sich diese schlauen Konstrukteure wenn ihre Softwarebastelei dann dauernd abschmiert und schöne Sicherheitslücken reißt. Mag sein, dass man das mal irgendwann in grauer IT-Steinzeit so gemacht hat, aber mir ist es lieber die Leute haben da im ersten Semester aufgepasst und wenden das gelernte in der Praxis an.
Entschuldige, aber der Rückpass musste einfach sein.
Ansonsten würde ich vorschlagen, solche Themen auch in einem anderen Thread weiter zu diskutieren und hier wieder zum Junior ][ zurück zu kommen.
Das wird sicher mit jeder Adresse funktionieren
Genau. Und schon hab ich aus meinem schönen Rechner einen Türstopper gemacht, weil ich Angst habe ihn zu benutzen. 
Edit: Und der gute Mann heißt natürlich Andrew S. Tanenbaum und nicht Tannenbaum.
Ich wollte aber nochmal auf den WDC65C02 und was anderes raus - v.a., weil der IC ja doch relativ flott ist
. https://www.reichelt.de/8-bit-…?CCOUNTRY=445&LANGUAGE=de
mit 14 MHz.
Ist der direkt auf den JC2 steckbar ?
Der 65C02 kann (auch in der 14MHz) Version völlig Problemlos im Junior ][ eingesetzt werden. Einer Takterhöhung würde im Prinzip auch nichts im Wege stehen, wenn denn alle Support Chips auch höher getaktet werden könnten. Die 65C22er auf dem IO Board können heute von WDC ebenfalls mit 14MHz geordert werden. Problematisch sind aber der 6532 RIOT und der 6551 UART. Eventuell gibt es die in 4MHz Ausführung, aber dann dürfte auch Schluss sein, weil die nicht mehr produziert werden.
Das Junior ][ BIOS hat nur an einer Stelle einen Delay Routine, die nicht über einen Timer gelöst ist. Dies ist die Time Out Routine im XModem Code, den ich von Deryl Rictor übernommen habe. Hier müsste man also nacharbeiten. Ein Takt von 2MHz sollte aber auch ohne Änderung möglich sein.
Und dann war da noch die Geschichte mit den illegalen Opcodes bzw. den erweiterten - für den WDC65C02
Na ja, illegale Opcodes sollte man generell nicht benutzen, deshalb sind sie ja illegal. Es sind ja eigentlich auch keine Befehle die du da aufgelistet hast, sondern Glitches die zufälligerweise entstehen, weil das Leitwerk des Prozessors nicht vollständig ausgearbeitet wurde. Bei einem Decoder Design muss ich halt nicht nur die gewünschten Codes durchleiten, sondern auch alle anderen ausschließen. Das wurde beim ursprünglichen 6502 Design vermutlich aus Kostengründen (?) nicht gemacht, da es nochmal eine Menge zusätzlicher Gatter bedeutet hätte. Der W65C02 nutzt ja auch noch nicht alle möglichen 256 Befehle aus, hat aber wahrscheinlich einen vollständigen Befehlsdecoder.
Es wäre also evtl günstig, wenn man das ein bißchen im Hinterkopf hat, daß potentielle illegale Opcodes anscheinend die Adressen $C000 bis $C007 benutzen. Man sich also evtl bemühen sollte, da nicht gerade einen Grafikstart oder sowas hinzulegen, sondern den Bereich freizuhalten, bei allem was noch an Software kommt.
Ein nicht Belegen von Speicherbereichen, nur weil dort eventuell ein nicht dokumentierter OP was ändern könnte ist für einen Hobby-Retro-Rechner dann doch etwas zu viel des Guten. Wenn es um Sicherheitsbedenken bei neuen Prozessoren ginge, dann wäre ich da voll bei dir. Denn dann wäre ein solches Verhalten möglicherweise (ganz sicher!) ein offenes Scheunentor für Schadcode. Aber so, ist es für mich nur eine witzige Randnotiz, was der Prozessor noch so alles anstellen könnte.
Edit: Nochmal zum WAI.
Wenn du ein Multitasking OS hast, wird der Scheduler normalerwiese als Interrupt-Routine - angestoßen durch einen Timer IRQ - implementiert. Zum Auswählen des nächsten Tasks wird also der Scheduler geweckt, der nächste Task gewählt der rechenbereit ist und die CPU an diesen Task durch setzen der Rücksprungadresse aus der IRQ Routine durch ein RTI ( ReTurn from Interrupt) übergeben. Falls es aber keinen rechenbereiten Task gibt, wird und muss der Idle-Task ausgewählt werden. Dieser ist meist so aufgebaut
IDLE: WAI
JMP IDLEd.h. der Idle-Task legt den Rechner schlafen, bis der nächste Timer Interrupt (oder auch irgendein Geräte Interrupt) ausgelöst wird. Dieser bringt dann wieder den Scheduler ins Spiel und der Vorgang beginnt von vorne. Der Idle-Taks ist wichtig, um das System am Laufen zu halten. Dazu würde ich dir dann aber Literatur von bevorzugt Andrew Tannenbaum empfehlen.
Ein normaler Interrupt unterbricht ein laufendes Programm. Also zum bsp. durch einen Timer Interrupt oder ein anderes unerwartetes Ereignis.
Manchmal ist es aber besser, einen Prozess vollständig zu blockieren um auf ein einzelnes Gerät zu warten. Eben z.B. auf eine Floppy, oder auf das Drücken einer Taste. Dann ist Idle Waiting mit einem WAI, HLT o.ä. aber wesentlich besser als das pollen eines Flags, da der Prozessor mit diesen Befehlen auch meist weniger Strom benötigt. Außerdem kann es ja sein, dass das zu erwartende Signal sehr kurz ist. Dann hast du das Problem, das Hans vorher angesprochen hatte. Die Trigger Schleife muss dann sehr schnell durchlaufen werden, um das Signal nicht zu verpassen. Mit WAI ist ein Verpassen nicht möglich, da ein Interrupt ja Flanken getriggert ist und die Länge des Signals dann nicht mehr relevant ist. Es geht dann auch direkt nach dem WAI Befehl weiter, ohne sichern der Rücksprungadresse, Register und Status und vice versa. Der Overhead ist also auch wesentlich kleiner.
Ist super nützlich beim Warten auf externe Ereignisse. Bei Microcontrollern gibt es gerne mal ein SLEEP, bei dem sich der Controller dann in einen Stromsparmodus legen kann und durch einen Interrupt wieder aufgeweckt wird.
PHX : push X register on stack
PLX : pull X register from stack
BRA : branch always
STZ : store zero
WAI : wait for interrupt
PHY und PLY gibt es natürlich auch.
STZ ersetzt ein LDA #0 mit folgenden STA adr und ist ziemlich oft nützlich
Na das wär was auf dass Entwickler damals am allerersten verzichtet hätten wenn sie ein Subsystem einsetzen - weil selbiges kann dann gleich den low level Teil dann am besten gleich selbst übernehmen. Weil wenn schon einen Prozessor dazwischen, dann soll er auch Arbeit abnehmen. Das wär für uns damals eher der Grund gewesen einen Controller einzusetzen (wenn es den denn gegeben hätte) als der DMA. Floppyinterface mit logischer Schnittstelle macht die Anwendungssoftware viel einfacher. Das zahlt sich bei der späteren Entwicklung vielfach aus.
Ich hatte ja schon weiter oben geschrieben, dass ein evtl. eingesetzter uC dann durchaus Funktionen wie LBA in CHS Umwandlung und formatieren einer ganzen Floppy statt nur eines Tracks übernehmen kann. Aber das Stack-In/Out Interface kann man ja ohne weiteres beibehalten. Die Ergebnisphase kann man natürlich auch etwas abkürzen und dann gleich ein einzelnes Result Byte zurückgeben.
However...hier wäre es ja nicht drum gegangen den ganzen Rechner durch einen Microcontroller zu ersetzen, sondern ein - letztlich - lästiges Detail mit etwas moderneren Mitteln zu vereinfachen. Ich will da ja keinen RasPi mit Linux auftopfen.
Na ja, wichtiger als die absolute Anzahl der Takte ist ja dass die 4 innerhalb des Triggers gespart werden, also die Reaktionszeit drastisch reduzieren und damit den Jitter beim erkennen. Das wäre selbst dann noch von Vorteil wenn man hinterher wieder 4 Takte ausgeben müsste um das so zu machen.
Ist mir absolut klar...
Natürlich darf die Floppy nicht schneller Bytes liefern als die Schleife insgesamt braucht
...aber das war ja genau meine Befürchtung. Deshalb: Diskusion allenthalber wegen Nerd Faktor interessant.
Eine Alternative ist an der Stelle höchstens die Verwendung des WAI(t).
Ich verzichte im Code ja absichtlich auf 650C02 Befehle um diejenigen nicht zu verprellen, die den Junior ][ mit einer 6502 bestückt haben. Hätte mir zwar oft mal Arbeit gespart - siehe z.B. PHX/PLX, BRA, STZ - ich bleib da aber standhaft. Deshalb ist WAI natürlich auch keine Alternative.
Nur mal so die Gedanken von jemand der damals schon sowas gebaut hat (und sogar noch dafür bezahlt wurde:))
Ja, ja, die gute alte Zeit...
SCANR :)))
auf gut Deutsch der Depp saß mal wieder am Keyboard... 
Ich sollte aber wohl auch nicht mehr nach 3 Uhr morgens an solchen Problemen arbeiten. Demletzt hatte ich bei so einer Aktion versehentlich einen TTL verkehrt herum auf das Bread board gesetzt und ihn so lange durchgeröstet, dass der Kunststoff darunter schon braun wurde. Gemerkt hatte ich es erst nach dezenter Geruchsbelästigung des mittlerweile verblichenen Bausteinchens. Das war dann das Zeichen für "Ab ins Bett". Mr wird hald ed jüngr.
Bedeutet so vie wie "Problem Between Chair and Keyboard"...
so is es...
Äh, die Schleife wird auf jeden fall um 4 Takte schneller durchlaufen (die Dauer des BIT). Davon wieder 2 hergeben ist also immer noch ein Nettogewinn
Hans, da gebe ich dir natürlich vollkommen recht. Ich wollte nur zum Ausdruck bringen, dass die Euphorie durch den Wegfall des BIT Befehls vier Takte zu sparen, durch das unbedingt benötigte CLV etwas gedämpft werden muss, sprich die Einsparung eben nur zwei Zyklen beträgt. Da das ganze aber ja sowieso auf meiner falschen Befürchtung beruhte, dass die Sampling Phase der Schleife zu lange dauert - was ich mir bei einer Datenrate von 250 kb/s eben auch nicht vorstellen konnte - hat sich die Taktzählerei natürlich erübrigt.
Warum so kompliziert? Ein paar TTL tun es auch. 1980 hatte es noch keinen ATMega:)
Da bin ich durchaus pragmatisch, da in den 80ern ja auch schon Microcontroller wie MCS-48 Serie (die es ja glaube ich sogar schon Ende der 70er gab) verbaut und auf allen möglich Tastaturen, etc. eingesetzt wurden. Die AVR Serie ist ja auch schon seit Anfang der 2000er auf dem Markt und somit kein neumodischer Kruscht mehr. Ausserdem ist der DIP 40 Formfaktor ja durchaus klassisch. Das man mit ein paar TTLs die DMA Logik hinbekommt ist unbestritten, in diesem speziellen Fall hätte ein ATmega mir aber mehr Flexibilität geliefert. Ausserdem, wo hört das auf? Man könnte ja auch auf den Floppy Controller verzichten und alles in TTL aufbauen. Da explodiert irgendwann mein Steckernetzteil bei dem zu erwartenden Stromverbrauch 
Vor allem wenn Du eine extra CPU verwenden würdest, dann kann die eh gleich alles alleine machen - dann ist aber auch der 6502 Spaß weg.
Ne ne ne, die 6502 hat noch ne Menge zu tun, und ich hätte das Programmier Interface sowieso genauso gestaltet, wie es der FDC der CPU anbietet.
PEBCAK?
:)) SCNR
Selbst nach Einsetzten eines Babelfisches in meinen Gehörgang und lautem Vorlesens der Acronyme (?) hab ich leider keine Ahnung was das bedeuten könnte 
. Das musst du mir bitte Übersetzen
Ich hatte mich jetzt die ganze Zeit gewundert, warum immer genau 9 Bytes gefehlt haben. Diese waren über den gelesenen Sektor verteilt an drei Stellen - immer drei Bytes, immer an fast der gleichen Position. Und dann fiel es mir wie Schuppen aus den Ohren... 
Ich hatte zwar am Ende der Leseroutine ein CLI gesetzt um den 1/60 Sekunden Interrupt für die Abfrage der Datasetten-Tasten wieder einzuschalten. Den SEI Befehl um den Interrupt Auszuschalten habe ich aber glatt vergessen 
.
Mit gesperrten Interrupt wird der Sektor jetzt fehlerfrei gelesen.
So muss das aussehen
Gestern Abend mal /SO - synchronisiert mit der fallenden Flanke von PHI1 - an den invertierten Ausgang des INT Signals des FDC gehängt. Das Interrupt Signal wird ja - wie ich jetzt noch nachgelesen habe - bei nonDMA Betrieb für jedes anstehende Datenbyte ausgelöst. Von daher ist das also eigentlich ziemlich ideal.
ABER...
leider funktioniert es immer noch nicht. Die Gate Schleife wird jetzt natürlich schneller durchlaufen, dafür benötige ich in der Hauptschleife aber wiederum ein zusätzliches CLV (zwei Takte) um das extern gesetzte Overflow Flag wieder zu löschen. Sonst rauscht mir natürlich der Code gleich wieder durch die Gate Schleife durch. Somit verpasse ich wieder ein paar Byte. Warum das mit dem WD2797 bei Dietrich funktioniert kann ich beim besten Willen nicht beantworten. Sind die Datenträger da womöglich FM formatiert?
Mit MFM Datenträgern sehe ich jetzt gerade keine Chance mehr, selbst wenn ich, wie von Hans angeregt, den FDC Port in die Zero Page lege und damit nochmals einen Takt in der Hauptschleife sparen kann. Nach ein paar gelesenen Bytes ist der zeitliche Offset dann doch so groß, das Daten durchflutschen...
Ich werde jetzt mal den Versuch starten, einen DMA-Controller mit einem ATMega32 zu programmieren. Der ATMega8 hat leider einen IO Pin zu wenig, somit bräuchte ich wieder etwas etxterne TT-Logik um alles rein zu packen.
Die hatten den SO (set overflow) Eingang der CPU (den sie sonst n.W. nie benutzt hatten) verwendet, um irgendein Signal schneller verarbeiten zu können.
Das SO Signal hängt beim Junior ja am Erweiterungsport. Eventuell könnte man ja das DMA signal des FDC damit koppeln. Die 6502 müsste dann nur mit
DMA_LOOP BVC DMA_LOOPeine Warteschleife zum pollen des Overflog Flags durchlaufen. Wenn man das /DMA Signal leicht verzögert wieder auf /DACK zurückführt, könnte sich der FDC dann selber triggern. Die CPU muss dann natürlich trotzdem schnell genug die Daten lesen und abspeichern. Ein Terminal Count Signal müsste dann zum Schluss auch noch erzeugt werden. Mal experimentieren. Danke für den Hinweis Toast_r .
Kurze Frage für Dummies: Hast du Informationen zum 2797? Den kenne ich nicht, daher kann ich wirklich garnichts dazu sagen.
Ansonsten dachte ich auch, dass es funktionieren müsste. Ich hab zum Testen auch schon auf alles verzichtet, was Zeit kosten könnte. Die erste Abfrage, ob der Datentransfer beginnt habe ich noch mit einem CMP gemacht um abzufragen, ob der FDC sich in der Execution Phase befindet. Danach frage ich nur noch das REQUEST FOR MASTER Flag per BIT Befehl ab. Die beiden 256 Byte Seite beschreibe ich ohne Schleife, um beim Wechsel keine Zeit durch ein DEX zu verlieren und beim indizierten Schreiben nutze ich gerade nur STA abs,Y und keine indirekt indizierte Adressierung. Weniger Taktzyklen geht meiner Meinung nach nicht mehr.
INT_LOOP LDA FDC_MSTAT_REG ; read master status register
CMP #$F0 ; request for master and execution mode ?
BEQ READ ; yes, start reading
BNE INT_LOOP ; no, wait for flags
; start of data read
READ_LOOP_1 BIT FDC_MSTAT_REG ; request for master flag set?
BPL READ_LOOP_1 ; no, wait for flag
READ LDA FDC_DATA_REG ; yes, read data
STA $600,Y ; store it in lower page of destination address
INY ; next index
BNE READ_LOOP_1 ; repeat until overflow
; overflow - read into upper destination page
READ_LOOP_2 BIT FDC_MSTAT_REG ; same as above ...
BPL READ_LOOP_2
LDA FDC_DATA_REG
STA $700,Y
INY
BNE READ_LOOP_2Oh, hier war ja fleißig was los über das Wochenende.
Um die Frage nach dem GAL Assembler aus meiner Sicht zu beantworten: Ich benutze auch WINCUPL. Wie MicrotronicHamburg schon gesagt hat, ist WINCUPL nicht mehr ganz auf der Höhe der Zeit (vor allem der Simulator) aber zum Eingeben und Assemblieren ist es völlig ausreichend.
Der TL866 kann bei mir eigentlich alle GAL Typen programmieren. Einfach als Hersteller Lattice statt Atmel wählen, da sind dann auch 22V10 Typen möglich.
Bzgl. Floppy Controller bin ich am Freitag mal mit dem Lesen einer Diskette weitergekommen - zu mindest was meine Erkenntnisse angeht.
Das Einlessen von Sektor 00 war zwar auf den ersten Blick erfolgreich, allerdings sah ich dann schon sehr schnell, dass das Boot Record Tag 55 AA nicht an der richtigen Stelle lag und das hat sich auch nach mehrmaligen einlesen und Optimieren des Codes nicht wesentlich verändert. Offensichtlich flutschen immer wieder ein paar Bytes durch, die nicht schnell genug vom FDC abgeholt werden können. Somit sind die letzen gelesenen neun Bytes immer bereits die sieben Ergebnis Bytes und zwei mal das letzte Byte des Ergebnisses. Das Ergebnis 40 10 lässt auch schon nichts Gutes hoffen (Abnormal Termination und Overrun) ...
Die Erkenntnis ist also dahingehend, dass es selbst bei einer 720KB Floppy nicht möglich ist, die Daten bei 1 MHz CPU Takt schnell genug zu lesen.
Eine DMA Lösung ist also unumgänglich. Nach einiger Überlegung bin ich zu der Überzeugung gelangt, dass die einfachste und vermutlich effizienteste Lösung der Einsatz eines ATMega8 oder 32 wäre, der dann sowohl als Interface als auch als DMA Controller dient und die gelesenen Daten in sein internes RAM buffert. Das GAL wäre dann hinfällig und die Programmierschnittstelle über den ATMega zum Rechner könnte dann genauso aussehen wie zum FDC. Allerdings wären hier dann als Komforterweiterungen gleich Möglichkeiten geboten, wie z.B. statt einer Anforderung von der Floppy via CHS diese gleich per LBA zu machen. Der uC rechnet das dann doch wesentlich schneller um als es eine 6502 macht. Der ATMega könnte auch eine Floppy autonom formatieren, und wenn man einen ATMega1284 nehmen würde, hätte man 16KB internes RAM und könnte somit einen vollständigen Track zwischenspeichern (für wiederum autonomes Kopieren einer Diskette).
Nachteil ist, dass ich dann die Daten für einen gelesenen Sektor wieder Byte weise aus dem uC auslesen muss, was natürlich wiederum Zeit kostet. Aber ich denke das ist verschmerzbar.
Die Möglichkeit ein externes (DMA) RAM zu nehmen, welches dann per Bankswitching direkt im Junior Adressbereich eingeblendet werden kann wäre natürlich auch möglich, was aber nur Sinn machen würde, wenn man dann auch größere Speicherbereiche auf diese Art umschalten und somit ganze Programme per DMA einlesen könnte. Dann bin ich aber natürlich schon bei der Notwendigkeit einer vollständigen MMU angelangt, was ich erst mal nicht unbedingt anstreben wollte.
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.
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.
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.
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.
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.
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.
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.
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.
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! 
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.
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
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.
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.
Welchen FDC Chip hast da denn im Einsatz ?
Den GM82C765B. Der ist recht gut erhältlich und mit dem WD37C65C Anschluss- und Befehlskompatibel. Das Datenblatt sollte man von Letzterem nehmen, da das für den GM82 in echt krudem Englisch verfasst ist und ein paar Fehler drin hat. Das vom WD37 ist zwar auch nicht ganz fehlerfrei, aber immerhin rollen sich einem beim Lesen nicht gleich die Fußnägel hoch.
Heute der erste Basteltag nach dem Urlaub:
Prototyp Schaltung für den Junior Computer ][ Floppy Controller. Nach etwas Ratlosigkeit, weil erst mal wirklich gar keine Signale aus dem Controller kommen wollten, dann der Gedankenblitz - Reset-Eingang am Controller Chip ist nicht invertiert, sprich der Chip war die ganze Zeit im Reset Modus.
Nach der Änderung funktionieren nun schon mal Seek und Recalibrate über manuell im Monitor eingegebener Befehle. Heute Abend dann eventuell mal eine kleine Routine zum Lesen eines Sektors schreiben.
