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.
Ja mei, man selbst ist halt mit weitem Abstand die häufigste aller möglichen Ursachen wenn was nicht klappt.
Ä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.
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.
Die beiden kritischen Zeitabschnitte bei Echtzeitreaktionen sind nunmal Erkennung, also wie schnell man merkt das was zu tun ist, und Abholung, also den faktischen zugriff auf die Daten. Ersteres wird durch die BVC Schleife auf das absolute Minimum (*1) gesenkt, während zweiteres durch den LDA direkt nach dem BVC erfolgt. Der CLV liegt erst dahinter und damit nicht mehr kritischen Pfad (Natürlich darf die Floppy nicht schneller Bytes liefern als die Schleife insgesamt braucht). Besser gehts also nicht ...
*1 - Eine Alternative ist an der Stelle höchstens die Verwendung des WAI(t). Anstelle SO wird die Daten-Da Meldung des FDC mit INT verbunden. In der Leseschleife geht die 65C02 dann in den WAI welcher garantiert 3 Takte, nicht mehr nicht weniger, braucht (also theoretisch einen länger als der nicht erfüllte BVC) und dann innerhalb eines Taktes aufwacht. Also wenn der INT kommt:
LDY #00
SEI
** FDC für "Interrupt" vorbereiten (Latche etc.)
READ_LOOP_1 WAI ; Warten auf "Interrupt"
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
... Nochmal für 2. Hälfte ...
** FDC als Quelle für Interrupt abschalten
CLIoder so ähnlich. Im Prinzip kein unterschied zur Nutzung von SO, aber mit absolut fixem Zeitraster.
(SO könnte theoretisch einen takt schneller sein - aber auch nur wenn das nächste Byte schon vor dem Ende der Schleife bereitsteht.)
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
Tastaturen und so. Und das ist genau der Punkt. Diese 8048/51 und Abarten waren stocklangsam (z.B. braucht der 'schnelle' 8051' 6 Takte um auch nur ein Byte von einer externen Adresse zu lesen (also nur der Zugriff. der Lesebefehl selber brauchte nochmal ein paar Takte mehr). Ganz davon ab, dass sie keine Protokolle für gemeinsamen Zugriff oder so haben. Sprich sie brauchen ein TTL Grab außen rum um den Bus zu übernehmen und dann einen Zugriff zu machen. Ganz zu schweigen von dem zusätzlichen Softwareaufwand. Damals hätte kein Entwickler sich hingesetzt und Software gemacht für etwas das man mit 3-4 TTL machen kann (CPU-Anhalten, Adresse auf den BUS, FDC kitzeln, fertig). Software entwickeln war aufwändig und brauchte viel Zeit - und teuere EPROM Versionen - das ging nicht mit Mausklick wie heute. Und zu guter Letzt war so ein Microcontroller genauso teuer wie ein vollwertiger DMA-Baustein (welcher auch noch langsamer ist als die eigene Lösung, da er 2 Takte pro Byte braucht).
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.
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.
:)) Nur mal so die Gedanken von jemand der damals schon sowas gebaut hat (und sogar noch dafür bezahlt wurde:))
. Das musst du mir bitte Übersetzen 
