Eigenbau Speeder

Klingt sehr interessant, ist das denn noch leistbar? Könnte der HC08 denn mit seinen 40MHz eine 6502 Taktgenau emulieren? Ideal wäre noch ne SD Karte als Ergänzung zur Floppy + Systemsoftware zum lesen und schreiben von D64 Image Dateien.

So langsam hört sich das an wie eine 1541U mit einem Port für eine reale Floppymechanik Bis auf den HC08 vielleicht. Hmmm, einige Portpins sind ja noch frei und herausgeführt, da sollte man doch eine Mechanik per Shugart Interface ankoppeln können.

Das Modul hätte sowieso die besten Voraussetzungen um einen ultimativen Speeder zu realisieren. Wenn die Daten erstmal dekodiert im Modul-RAM stehen kann die DMA engine die Daten direkt in den 64er Speicher schieben.

Retro: der eine Prototyp ist hier noch bei mir. Wenn ich nun nur wüsste in welcher Floppy der steckt :rotwerd:

Zitat von Retro

Ich würd' sagen, schau' einfach, welche Floppy beim Laden als erste fertig ist, dort müßte er drinnen stecken

Das ist wohl wahr, aber nicht bei mir weil das Parallelkabel liegt neben dem Kernal ROM sauber aufgeräumt ...

Also irgendeine Floppy hat das Goldstück noch eingebaut muss ich mal bei Gelegenheit suchen.

Ich hab' jetzt den ganzen Thread gelesen und richtig Interesse daran, ein bischen in der Richtung weiter zu entwickeln. Die 2MHz in der Floppy machen sicherlich viele Dinge einfacher, aber beim Nachbau wird's ungleich schwieriger. Ich würde daher vielleicht ein bischen mehr Grips in die Übertragung/Dekodierung stecken, dann kann man die alte CPU und die alten VIAs drin lassen.

Speicher ist heutzutage kein Problem mehr, aber auch damit muß man nicht "herumaasen". Vielmehr würde ich den Ansatz "hardware-bit-shifting für die GCR-Dekodierung" verfolgen, damit man die schnelle CPU vielleicht gar nicht mehr braucht.

Einen Microcontroller (HC08 ) als Transfer-Coprozessor halte ich für übertrieben. Das ist zwar preismäßig kein Thema, aber keine wirkliche Herausforderung mehr.

In Anbetracht der schnellen seriellen Fastloader (Faktor 20!) ist wohl auch das Parallelkabel in Frage zu stellen, wie ich heute hier gelernt habe. Der Speeder würde sich also reduzieren auf eine Platine, die zwischen CPU und 1541-Platine gesteckt wird.

Jens

Zitat von Wiesel

Ich hab' jetzt den ganzen Thread gelesen und richtig Interesse daran, ein bischen in der Richtung weiter zu entwickeln. Die 2MHz in der Floppy machen sicherlich viele Dinge einfacher, aber beim Nachbau wird's ungleich schwieriger. Ich würde daher vielleicht ein bischen mehr Grips in die Übertragung/Dekodierung stecken, dann kann man die alte CPU und die alten VIAs drin lassen.

Ganz meine Meinung. So'n Speeder Eigenbau könnte mich auch begeistern!

Zitat von Wiesel

Einen Microcontroller (HC08 ) als Transfer-Coprozessor halte ich für übertrieben. Das ist zwar preismäßig kein Thema, aber keine wirkliche Herausforderung mehr.

Ganz meine Meinung.

Zitat von Wiesel

In Anbetracht der schnellen seriellen Fastloader (Faktor 20!) ist wohl auch das Parallelkabel in Frage zu stellen, wie ich heute hier gelernt habe. Der Speeder würde sich also reduzieren auf eine Platine, die zwischen CPU und 1541-Platine gesteckt wird.

Naja, ich persönlich bin kein Freund der seriellen Speeder! Allein dass der Schirm abgeschaltet wird stört mich dabei. Was ist gegen ein paralleles kabel einzuwenden?

Aber C64 seitig würde mir ein Speed-DOS langen.

Eine Blackbox zwischen C64 und 1541 langt eben nicht, sonst ist man wieder inkompatibel. Damit wirklich ALLES geht, sollte auch alles so bleiben wie es ist. Man müsste nur 42 * 8 KB RAM haben und eine super schnelle GCR Dekodierung. Beides kann man erreichen mittels CPLD oder Controller (ATmega).

Zitat von Diddl

Naja, ich persönlich bin kein Freund der seriellen Speeder! Allein dass der Schirm abgeschaltet wird stört mich dabei. Was ist gegen ein paralleles kabel einzuwenden?

Der Schirm wird ja nicht bei allen parallelen Speedern abgeschaltet.
Außerdem halte ich eine Lösung, die ohne Zusatzkabel auskommt, für sehr elegant.

Zitat

Eine Blackbox zwischen C64 und 1541 langt eben nicht, sonst ist man wieder inkompatibel.

Inwiefern? Und mit was?
Vorausgesetzt, die 'Black Box' ist auch abschaltbar...

Zitat von Wiesel

In Anbetracht der schnellen seriellen Fastloader (Faktor 20!) ist wohl auch das Parallelkabel in Frage zu stellen

1570 hat mal mit einem eigenen Speeder für sd2iec experimentiert und kam am Ende auf eine Geschwindigkeit von knapp unter 40x ohne Parallelkabel - höherer Takt auf Sendeseite und damit genauere Synchronisation auf den Empfänger machts möglich.

Wie man an JiffyDos sieht muss ein serieller Speeder auch nicht unbedingt den Bildschirm abschalten, es erhöht allerdings die Geschwindigkeit nochmals ein wenig.

Ja von mir aus seriell angekoppelt. Dann aber gleich Burst kompatibel damit der 128er auch was davon hat.

Die "Blackbox" soll also

• in der 1541 "unsichtbar" verbaut sein
• 170KB RAM haben
• schnelle GCR Kodierung/Dekodierung haben
• ganze Disketten möglichst rasch lesen und updaten können
• den Bustransfer zum C64 übernehmen

Damit das ganze 100% kompatibel ist, muss der 6502 und das 1541 DOS bleiben.

Eine sehr schöne Lösung wäre, wenn ein Atmega den Diskcontroller machen würde. Block lesen/schreiben und Spur formatieren. Blöcke die bereits im RAM sind werden von da übertragen. Die Interrupt Routinen in der 1541 (also der 'alte' Diskcontroller) ist nur noch Kommunikation zum Atmega.

Zitat von Unseen

1570 hat mal mit einem eigenen Speeder für sd2iec experimentiert und kam am Ende auf eine Geschwindigkeit von knapp unter 40x ohne Parallelkabel - höherer Takt auf Sendeseite und damit genauere Synchronisation auf den Empfänger machts möglich.

Der begrenzende Faktor bei neuer Floppy-Hardware ist dabei denke ich eher, dass die Sendeseite die Daten kontinuierlich liefern muss. sd2iec macht zwischendurch immer mal wieder Pausen, um wieder einen Buffer mit Daten von der SD-Karte zu füllen. Der Bus steht dann still, und der C64 dreht Däumchen. Wie auf der sd2iec-Seite geschrieben, schafft der serielle Bus an sich mindestens 20kB/Sek, also 50fach. Zum Nachprüfen einfach mal z.B. die Empfangsroutine vom Action Replay ausdrucken und Zyklen zählen - für den Experimentierspeeder hatte ich diese Routine genommen und seltener synchronisiert. Das kann man aber auch mit alter Hardware machen, Turbo Disk z.B. macht das ja auch so bzw. noch extremer.

Diddl:
Bildschirm abschalten hat mit seriell oder nicht nichts zu tun. Es bringt halt etwas Geschwindigkeit, wenn man Badlines nicht abfängt, sondern sie einfach vermeidet. Ist bei einem Parallelspeeder auch nicht anders. Neben Jiffy schaltet übrigens z.B. auch das Final Cartridge II (nicht III) den Bildschirm nicht aus.

Also ich für meinen Teil stehe nicht so auf die "brute force"-Methode und würde dazu tendieren, mit dem Speicher lediglich so weit zu gehen, dass er noch preiswert zu beschaffen ist. 512K in einem Chip sind nett, aber definitiv teurer und schwieriger zu beschaffen, als 128K in einem Chip. Selbst um das adressieren zu können, muß man sich ein Banking ausdenken, was wieder Resourcen kostet und im Grunde niemandem nützt, weil Banking nur dann wirklich sinnvoll eingesetzt werden kann, wenn's keine zusätzliche CPU-Zeit verbraucht. Das würde eine richtige Hardware-Schlacht werden, bei der ich lieber einen Teil eines 128K-Chips unbenutzt lassen würde, als dass ich massig Logik einbauen würde, die nur dazu dient, Speicher zu adressieren.

Wichtig wäre aber auch, dass jemand "mit Ahnung" die 1541-Seite programmiert, deswegen habe ich in diesem Thread geschrieben. Der Herr Retro aus dem Land mit den vielen Bergen hat mit seinem Speeder schon was geleistet, was sich nicht hinter anderen Hardwarespeedern verstecken muß. Wenn wir darauf aufbauen wäre das schonmal wesentlich effektiver, als das Rad gleich dreimal neu zu erfinden. Aus dem Grund lehne ich auch einen Microcontroller als Coprozessor ab.

Ich würde vielmehr einen preiswerten Logikbaustein und ein Flash geschickt so miteinander verdrahten, dass die immer wiederkehrenden Aktionen wie "aus 40 GCR-Bits mach' 4 Bytes" sinnvoll in Hardware unterstützt werden. Beim Auslesen des VIA-Ports an dem das Schieberegister hängt muß die CPU eigentlich gar nichts mit den Daten machen, die kann sich die Speeder-Hardware selbst abgreifen und zwischenspeichern.

Die VIA ist an diversen Stellen gespiegelt. Man könnte der Speeder-Hardware über die Wahl der Spiegelung mitteilen, was man gerade mit den Daten machen will. Beispielsweise kostet das Ermitteln der Prüfsumme auch Taktzyklen, auch wenn's nur ein paar wenige sind. Die Daten fliegen aber ohnehin an dem CPLD vorbei wenn ich sie da GCR-dekodiere, da kann ich auch ein EOR-Register mitlaufen lassen. Am Ende eines Blockes macht man nur nen LDA auf das EOR-Register; ein BEQ springt in die "alles OK"-Routine, ein BNE springt in die "load error"-Routine, und schon ist wieder Speed in der inneren Schleife gewonnen.

Zusätzlich hat das Schieberegister in der VIA den "shift under control of timer 2"-mode (mode 001). Timer 2 ist der, der auch negative Pulse auf PB6 zählen kann (wenn diese Pulse weniger als 500KHz schnell sind). PB6 ist für die DIP-Switches beim Setzen der Geräteadresse missbraucht, oder anders: Den können wir uns greifen. Da speisen wir einen Takt ein, der wesentlich syncroner mit dem C64 läuft, als alles, was man sich in der 1541 per Software "bauen" kann, nämlich 985khz/4 um mit einem PAL-C64 zu sprechen, oder 1,02MHz/4, um mit einem NTSC-C64 sprechen zu können. Auf die Weise ist auch die Sync-erei mit dem C64 kein Speed-Problem mehr, damit sollte man die seriellen Leitungen richtig zum Glühen bringen können.

Soweit zum Brainstorming

Jens
(Edit: Sprachliche Korrekturen)

Weiter brainstormen:

Der Lesezugriff auf die VIA kann schon 395ns nach der steigenden Flanke von phi2 abgebrochen werden, weil dann schon die Daten gültig sind. Startet man dann einen Zugriff auf ein 70ns schnelles Ram, das z.B. eine GCR-table enthält, hat man das Ergebnis im gleichen Zyklus wie das Auslesen des VIA-Registers. Das Extrahieren von 4 nutz-Bytes könnte dann so aussehen:

...und das Ganze wieder von vorn. Damit hat man sich das Verschieben der Daten (load/store) gespart, das Shifting, und wenn man jetzt wirklich noch über ein EOR-Register im CPLD geht, wird die Prüfsumme gleich mit gecheckt. Wie klingt das?

Jens

Klingt fantastisch, obwohl es auch wurscht wäre wenn die Daten aus dem VIA noch ins CPLD Register schreiben und nochmals lesen müsste.

Das würde sich auch noch locker ausgehen.

Zitat von Wiesel

Der Lesezugriff auf die VIA kann schon 395ns nach der steigenden Flanke von phi2 abgebrochen werden ...

Wie kann man im CPLD so einen Delay von exakt 395ns produzieren?

Einen höherfrequenten Quarz und ein paar FlipFlops als Zähler?

Zitat von Diddl

Klingt fantastisch, obwohl es auch wurscht wäre wenn die Daten aus dem VIA noch ins CPLD Register schreiben und nochmals lesen müsste.

Code

1. LDA VIA
2. STA CPLD_R0
3. LDA CPLD_R1

Das würde sich auch noch locker ausgehen.

Naja, sind glatt 8 Taktzyklen mehr. Sollte es nicht ein Speeder werden, der gleichzeitig von Disk lesen und zum C64 übertragen kann? Da braucht man doch jeden Zyklus, oder nicht?

Zitat von Diddl

Wie kann man im CPLD so einen Delay von exakt 395ns produzieren?

Einen höherfrequenten Quarz und ein paar FlipFlops als Zähler?

Theoretisch würde ein 5MHz-Takt der syncron mit dem 1MHz läuft schon reichen, dann könnte man (je nach verwendeter Flanke) schon 100ns auflösen. Das wäre recht simpel mit einem 74HC4046 und ein paar Makrozellen des CPLD aufgebaut. Eine andere Alternative wäre ein Monoflop, das auf ca. 400ns eingestellt ist. Das müsste man im Einzelfall ausprobieren, aber ich würde mehr zur PLL tendieren.

Jens

Zitat von Wiesel

Naja, sind glatt 8 Taktzyklen mehr. Sollte es nicht ein Speeder werden, der gleichzeitig von Disk lesen und zum C64 übertragen kann? Da braucht man doch jeden Zyklus, oder nicht?

8 Zyklen sind gar kein Problem.

Es kommen maximal 21 Sektoren in 200ms vorbei. Ein Sektor hat 350 Byte (GCR kodiert) + Zwei Sync Strecken + Headerdaten, macht ca. 382 Byte. Im Stressfall 382 * 21 * 5 = ca. 40KB / s, sprich man hat mindestens 25µs zeit ein Byte abzuholen.

Aber ganz was anderes: Die 1541 hat ja einen generellen Konzeptionsfehler, - der VIA Schieberegister Fehler. Sprich in der 1541 fehlt es an einem CIA. Das wäre eine Aufgabe für den CPLD!

Die CPU wartet auf das V Flag, liest ein Byte, legt es in den CPLD. Der CPLD wandelt jeweils 5 Bit in 4 Bit (GCR Dekodierung) und sendet jeweils 8 Bit über ein Schieberegister zum C64.

Problematisch wirds, wenn der Sektor nicht der gewünschte Sektor ist (IL != 1). Dann kommt das RAM in Form eines FIFO ins Spiel.

Ich glaube fast ein Microcontroller + viel SRAM kann hier mehr leisten.

Zitat von Diddl

Aber ganz was anderes: Die 1541 hat ja einen generellen Konzeptionsfehler, - der VIA Schieberegister Fehler. Sprich in der 1541 fehlt es an einem CIA. Das wäre eine Aufgabe für den CPLD!

CMD hat das Problem irgendwie mit ein wenig externer Beschaltung der VIA gelöst. Das könnte man in der Tat in den CPLD packen oder wolltest Du da ein Schieberegister nachbilden?

Zitat von Diddl

Die CPU wartet auf das V Flag, liest ein Byte, legt es in den CPLD. Der CPLD wandelt jeweils 5 Bit in 4 Bit (GCR Dekodierung) und sendet jeweils 8 Bit über ein Schieberegister zum C64.

Problematisch wirds, wenn der Sektor nicht der gewünschte Sektor ist (IL != 1). Dann kommt das RAM in Form eines FIFO ins Spiel.

Ich stelle mir das so vor, und hier kann Zyklensparen wichtig sein:
sektor angefordert: - direkte Dekodierung und Übertragung UND ablegen im RAM
sektor nicht angefordert (IL != 1): direkte Dekodierung UND ablegen im RAM

d.h. nach einer Umdrehung hat man die ganze Spur im RAM und schon alle Sektoren übertragen, die in der richtigen Reihenfolge vorbeikamen

nun kann man die restlichen Sektoren aus dem RAM senden. Das wird dann nochmal ne halbe Umdrehung dauern oder so, währenddessen kann man den Kopf ja schonmal Richtung nächste Spur schicken

ob man nur eine Spur oder ne ganze Disk puffern will, oder ob man das RAM Handling beschleunigen kann durch autoinkrementierende RAM Adressen, muss man sich überlegen. War da nicht was bei Professional DOS oder war es Turbotrans?

Zitat von Diddl

Ich glaube fast ein Microcontroller + viel SRAM kann hier mehr leisten.

Selbstverständlich kann er das, aber das ist keine Herausforderung (aka kein Spaß). Ich sehe die Herausforderung darin, dass die Hardware leicht (nach-)zubauen ist, dass man den Ansatz auch in die 1541U programmieren kann, und dass ich's auch in Chameleon programmieren kann.

Ein Schieberegister im CPLD ist zwar kein Thema, aber das ist hinterher nicht so elegant, weil der Einbau dann nicht mehr *nur* auf der CPU stattfindet, sondern man muß an die VIA.

Von dem "Schieberegisterfehler in der VIA" hat natürlich jeder schon gelesen, aber waren das nicht nur die allerersten VIAs, die in der 1540 und in den ersten VC20 zum Einsatz kamen? Die VIAs in den 1541 Floppies haben IMHO keinen Fehler mehr in den Schieberegistern und es gibt einen Mode, in dem die CB1 Leitung als shift-clock benutzt werden kann. Ist das nicht das ganze "Geheimnis" der Burst-Zugriffe von 1571 und 1581? (OK, die haben jeweils nen 6526...).

In Sachen "falscher Interleave" reichen die 8K Ram, die Dolphin schon so schnell gemacht haben. Die kann man nicht mehr kaufen, also werden's wohl 128K Ram, für die man sich noch andere coole Dinge ausdenken könnte, wie z.B. ein Banking für die Zeropage; wenn wir Zyklen knausern müssen, wäre es super, wenn man eine alternative Zeropage einschalten könnte, um darauf seine schnellen Transfer/Decode-Routinen laufen zu lassen (Programmierer, bitte Kommentare!).

Wie Du siehst, ziele ich mehr auf Eleganz als auf brute-force-Performance ab. Sollte es sich nicht vermeiden lassen, auch an die VIA zu gehen, dann wäre ich gleich mit einem Speeddos-kompatiblen Parallelkabel dabei. Was aber bei einem Selbstbau-Speeder vermieden werden sollte, ist "hier noch ne Lötbrücke" und "da noch ein Käbelchen", denn das macht den potentiellen Nachbauern zu viele Probleme. Oberstes Ziel sollte IMHO sein, dass die vorhandene Hardware so clever wie möglich ausgereizt wird.

Jens

Zitat von Wiesel

Von dem "Schieberegisterfehler in der VIA" hat natürlich jeder schon gelesen, aber waren das nicht nur die allerersten VIAs, die in der 1540 und in den ersten VC20 zum Einsatz kamen? Die VIAs in den 1541 Floppies haben IMHO keinen Fehler mehr in den Schieberegistern und es gibt einen Mode, in dem die CB1 Leitung als shift-clock benutzt werden kann. Ist das nicht das ganze "Geheimnis" der Burst-Zugriffe von 1571 und 1581? (OK, die haben jeweils nen 6526...).

Da wäre ich mir nicht so sicher. Jetzt mal umgekehrte Logik: Hat/hätte es es sich gelohnt, vom 6522 eine neue Revision zu machen, wenn das Feature in keinem Gerät tatsächlich benutzt wird und es für neue Gerätetypen schon den 6526 gab? Ist nur Spekulation, da hilft vielleicht nur genau hinsehen oder ausprobieren.

Und noch was ganz anderes: Macht auch einen schönen schnellen asynchronen Transfermodus mit rein. Also ich meine für einen "IRQ-Loader", bei dem der Host das Timing vorgibt.

Zitat von Wiesel

In Sachen "falscher Interleave" reichen die 8K Ram, die Dolphin schon so schnell gemacht haben. Die kann man nicht mehr kaufen, also werden's wohl 128K Ram

128KB oder 512KB, bei einem Preis von 3,50 für 512KB ist es egal.

Da der Adressraum beim 6502 beschränkt ist würde sich ein Spur Banking anbieten. Es gibt 35 Spuren, die Sonderformate haben 42 Spuren. Ich würde gerne pro Spur 8KB verwenden: 336KB bei 42 Spuren also 42 Banks zu 8KB

Eigentlich braucht man ja nur noch 2 Disk Routinen zu schreiben, wie in der 1581:

• Ganze Spur lesen
• Ganze Spur schreiben

Die ganze Diskette im SRAM zu haben fände ich genial! Der Motor würde nicht beansprucht, die Stepper für den Trackwechsel würde stillstehen.

Sollte ein LOAD stattfinden, bevor die Diskette gebuffert ist, dann gehen wir for wie X1541 vorgeschlagen hat:

+ sektor angefordert: - direkte Dekodierung und Übertragung UND ablegen im RAM
+ sektor nicht angefordert (IL != 1): direkte Dekodierung UND ablegen im RAM

Beim Spur lesen muss man nur die richtige RAM Bank selektieren und Byte für Byte in den RAM schreiben.

Beim Spur schreiben muss man nur die richtige RAM Bank selektieren und Byte für Byte auf die Diskette schreiben.

Zitat von Diddl

Die ganze Diskette im SRAM zu haben fände ich genial!

Genial daneben, ja. Wo ist da die Eleganz? Die Gewaltmethode gab's doch schon bei TurboTrans.

8K pro Spur sind auch übertrieben. Wenn, dann sollte man auch ein bischen Grips ins Banking stecken, also 6K Bänke, dann bekommt man in 256K auch 42 Tracks rein. Kleines Bischen Arithmetik im CPLD, und wir können das auch als Luxusfassung "Tracknummer ins Register schreiben und 6K ab $6000 benutzen" auslegen.

Wenn wir dann noch ein masked-write auf den Speicher realisieren, ist wieder ein bischen Eleganz gewonnen. Damit meine ich, dass man beim Schreiben auf eine Adresse entweder das obere, oder das untere Nibble unverändert lässt. Wenn man das per CPU machen wollte, müsste man erst laden, dann ANDen um das zu verändernde Nibble zu Nullen, später das "neue" nibble wieder drauf-odern und das neu gebastelte Byte ins Ram schreiben. Einfacher wäre es, wenn das 6K-Fenster noch zwei mal gespiegelt wird, und je nach benutzter Spiegelung entweder das obere, das untere, oder beide Nibbles verändert werden.

Jens