ZitatCodeThe sources are written in ANSI-C, so it should be possible to compile them on any platform.
Wo hast du das gelesen? Der Source Code lässt sich für fast jedes Gerät kompilieren.
Wenn du magst, schicke ich dir eine Kompilierte Version für Windows.
Wäre ich auch dran interessiert, denn ich hatte schon mehrfach versucht, da was brauchbares zu erzeugen.
Gruß Jörg
WinCUPL ist zwar Müll, funktioniert aber immer noch. Und ist inwzischen auch umsonst. Für die paar Gleichungen die man in der Regel für ein GAL hat (ein paar Dutzend) ist das auch egal dass die WinCUPL IDE nicht komfortable ist. Und dann einfach den TL866. Wobei, der kann bestimmte GALs nicht (entweder die "D" oder "B" Variante, vergessen welceh!) Dafür habe ich dann den Genius G540, der kann alles.
Wenn du magst, schicke ich dir eine Kompilierte Version für Windows.
Hi, an einer unter Windows lauffähigen EXE hätte ich auch Interesse. Denn leider habe ich gerade keinen installierten GCC oder was vergleichbares greifbar.
Gruß
Thilo
... ich auch.
Ich hab auch DOS GAL Assembler.
Da müsste ich aber erst suchen um da was passendes zu finden.
Bitte melden falls gewünscht.
Win ist aber bequemer, falls vorhanden.
Leider hab ich keinen Win GAL Assembler, daher mein Interesse an der compilierten Version.
mfG. Klaus Loy
Moin, moin,
WinCUPL ist zwar Müll, funktioniert aber immer noch. Und ist inwzischen auch umsonst. Für die paar Gleichungen die man in der Regel für ein GAL hat (ein paar Dutzend) ist das auch egal dass die WinCUPL IDE nicht komfortable ist. Und dann einfach den TL866. Wobei, der kann bestimmte GALs nicht (entweder die "D" oder "B" Variante, vergessen welceh!) Dafür habe ich dann den Genius G540, der kann alles.
habe ich mir angesehen und ein wenig mit gespielt, sieht doch recht gut aus.
Für ein paar GAL16V8 wohl völlig ausreichend, die kann mein GALEPIII auch "brennen".
Danke für den TIP
mfG Werner
Oh, 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.
Hmm, der 2797 kann das bei 1 MHz per Polling . Was ist da anders?
Hier mein Code - definitiv langsamer als deiner. Da muß etwas anderes sein…
READ1 BIT FLSTAT ;GET STATUS
BMI READ2 ;DONE
BVC READ1 ;NO DATA
LDA FDDAR ;GET BYTE
STA (DMA),Y
INY
JMP READ1Der ganze Quellcode liegt unter https://github.com/Dietrich-L/…/main/System/BOOTPROM.ASM
Das Datenblatt vom 2797 findest du im Netz - ist nicht besonderes. Die Schaltung, die ich benutze ist die UDC-Karte von Elektor. Doku dazu am besten bei Hans Otten.
Commodore hatte doch teilweise in ihren Floppys einen Hardware-Trick genutzt, um schneller Daten zu holen.
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.
So tief stecke ich in der Materie nicht drin, das ist aber hängengeblieben.
Vielleicht kannst Du damit ja was anfangen...
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 .
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
CodeDMA_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 .
Jup, SO ist der Arme-Leute-DMA-REQ der 6502. Der Hautvorteil obiger Schleife ist, dass sie Dauer und Jitter des Tests von 6..12 Taken auf 2..5 Takte verkürzt. 7..10 Takte weniger im Worst Case (und 4 im Best Case) bedeutet eine enorme Beschleunigung
Die andere offensichtliche Beschleunigung ist den FDC in die Zero Page zu legen - das spart feste einen Takt beim 'LDA FDC_DATA_REG' - und wenn Du das mit dem SO nicht machst nochmal einen bei der Warteschleife.
Letzteres wär eh das was ich als erste Maßnahme vorschlagen würde: FCD in ZP legen - meinetwegen temporär einschaltbar- und ein Byte und einen Takt bei jedem Zugriff sparen.
---
Und wenn Du an DMA denkst, dann am besten gleich eine STT nur für den FDC. Unter der Voraussetzung dass es immer nur zum gleichen Buffer geht braucht das nur einen rücksetzbaren 8 bit Zähler (74LS590 o.ä.) und etwas Gluelogik. Past auch besser zu einem Minimalsystem als ein dicker DMA Baustein. Und schneller isses auch noch: 1 MByte/s max :))
Warum das mit dem WD2797 bei Dietrich funktioniert kann ich beim besten Willen nicht beantworten. Sind die Datenträger da womöglich FM formatiert?
Ich arbeite mit MFM, 16 x 256 byte/Sector = 4k / Track. Macht bei 2x80 Tracks dann 640 kB. Das 720 kB Format hat 9 x 512 Byte = 4,5 kB/ Track und ist ebenfalls Standard-MFM (IBM 34).
Ich schlage vor, die Datenblätter beider Controller mal genau anzusehen. Entweder hat der 82C765 da höhere Anforderung, was ich nicht glauben kann, da das der neuere und intelligentere Chip ist oder die Schaltung hat noch einen Bug , möglicherweise im Timing.
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
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?
Ä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
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.
Warum so kompliziert? Ein paar TTL tun es auch. 1980 hatte es noch keinen ATMega:)
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.
Und dann fiel es mir wie Schuppen aus den Ohren...
PEBCAK?
:)) SCNR
Ä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
PEBCAK?
:)) SCNRSelbst nach Einsetzten eines Babelfisches in meinen Gehörgang und lautem Vorlesens der Acronyme (?) hab ich leider keine Ahnung was das bedeuten könnte
Bedeutet so vie wie "Problem Between Chair and Keyboard"...
Bedeutet so vie wie "Problem Between Chair and Keyboard"...
so is es...
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.
Schaue dir mal das Interface vom WD1002-05 an. Das ist der Vorläufer vom PATA und hat 8 Register (A0..A2) und unterstützt mit seinen Kommandos Festplatten und Floppy Laufwerke. Antike WD1002-05 tauchen auch noch gelegentlich auf und könnten dann ebenfalls direkt angeschlossen werden. Ebenso hat der Multicomp von Grant Searle auch intern das WD1002 Interface.
PEBCAK?
:)) SCNRSelbst nach Einsetzten eines Babelfisches in meinen Gehörgang und lautem Vorlesens der Acronyme (?) hab ich leider keine Ahnung was das bedeuten könnte
Bedeutet so vie wie "Problem Between Chair and Keyboard"...
Problem Exists Between Chair And Keyboard auch bekannt als LEL bzw L8L, PEBMAC, ID-10-T issue und einige andere mehr oderweniger nette 'Abkürzungen :))
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.
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:))
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 :)))
Was ist denn WAI ? (unter PHX, PLX kann man sich ja noch was vorstellen, wobei es das dann auch für Y geben sollte; bei BRA und STZ versagt die Phantasie aber auch)
Das Bild ist SEHR nett
edit: https://patpend.net/technical/…02ref.html#InstructionSet ; BRA branch always, STZ store zero ; wofür immer das gut sein soll ...
(es fehlen, wenn man sowas anfängt dann aber durchaus noch ein paar Sachen)(und es stellt sich nun natürlich noch die Frage, was mit 7501 und 8501 ist)(und ob der der späte C64 einen 65C02 oder einen 6502 hatte (also in Form des 6510 natürlich) - immer diese Rätsel in dem Bereich ...)
WAI ... Wait for Interrupt
wer denkt sich sowas aus ...
sehr skurril
(Schreib heut Abend mal noch was dazu ... Thema WDC65C02 und Speicherstellen $00-$07)
WAI ... Wait for Interrupt
wer denkt sich sowas aus ...
sehr skurril
Praktisch jeder Prozessorhersteller:
RCA 1802: IDLE (00)
Valvo 2650: HALT ($40)
Intel 8080: HLT (76h)
Zilog Z80: HLT (76h)
8086: HLT (F4h)
68000: STOP
Und auch der Papa der 6502, die 6800 hatte sowas, und das hies sogar auch schon WAI. War in dem Fall sogar schon ein halber interrupt der alle Register sicherte und dann erst wartete.
Die 6502 hat das dann weggelassen und die 65C02 das wieder behoben - wobei es wurden dann gleich zwei Befehle eingebaut:
WAI und STP. WAI wacht bei jedem Interrupt auf, STP kann man nur mit RESET beenden.
