letzter Beitrag von WalkThatWay am
Floppy Speeder auf Basis FE3
- WalkThatWay
- Erledigt
-
-
Hallo @Diddl, könnten wir dein VC-20 FE in die 1541 einbauen? So als RAM Disk, Cache funktion und/oder so? Vielleicht auch im Zusammenspiel mit Professional DOS 2016?
Oja das wäre cool.
Ich könnte die CPLD Logik entsprechend anpassen ...
Ich hab schon mal eine eine Träumerei gedanklich durchgespielt:
Eine universelle RAM /Flash Erweiterung für 6502 Systeme
- ausgeführt als Ersatz für die 6502 CPU
- CPU raus, Universal cartrigde rein, 6502 auf die Universal Cartrigde
- Beliebig ein und ausblendbare Speicherbereiche
-
Also ich bin dein Mann. Müssen wir nur noch @Tommi_nrw mit ins Boot holen, der ist momentan aber irgendwie unpässlich.
Nehmen wir zum Start diese Version FE512Ver5.zip ? Welche Codebasis? -
-
@Diddl beim CPLD sind s02, io3, Ram1, Ram2, Ram3, Blk1, Blk2, Blk3 aufgelegt die ersetzt werden müssen gegen RDY, Phi0, Phi2, Phi3, s̅.o̅., N̅M̅I̅, Sync. Wie tauschen wir die am Besten, so das der Code gut hinkommt ?
A13, A14, A15 kommen ja vom 6502. Die schenken wir uns, oder? Wir brauchen doch nur "neu" A16, A17 und A18 vom CPLD erzeugen ?
-
Mal langsam ...
Zu allererst müssen wir mal diskutieren, was wir am Ende gerne haben würden.
Wenn wir A0 bis A15 vom Prozessor holen dann können wir nur ganze 64kb Seiten adressieren.
Nicht dass es ein Problem wäre, aber man muss sich darüber im klaren sein, das man sich da selbst limitiert.
Schöner wäre es, wenn man 8 oder 16 KB Seiten hätte die man beliebig einblenden kann.
Also für eine reine 1541 Erweiterung wäre das Konzept Recht simpel.
Eine allgemein gehaltene Erweiterung für ein beliebiges 6502 System hingegen, da müsste man ganz andere Dinge behirnen ...
- die "alte" Hardware müsste ausblendbar sein.
- die "alte" Hardware müsste weiter verwendbar sein.
Das bedeutet, man müsste den Daten Bus abkoppeln können.
Den Adressbus im Grunde auch.
Sowie Teile vom Control Bus.Dann, nehmen wir die Atmel Krücke?
Den ATF1504?Oder eine modernere CPLD Variante.
Einen Xilinx zum Beispiel.Es gibt halt nicht so viele 5V CPLD ...
-
Gut, ich denke man muss von der "alten Hardware" weder RAM noch ROM verwenden.
Das haben wir mehr als ausreichend.Aber der IO Bereich ist unumgänglich.
Wollen wir den IO Bereich ausblenden können?
Oder kann der immer sichtbar sein?Bus trennen geht natürlich mit Bus Treiber.
Es geht aber auch mit einem ganz großen CPLD.
Einem CPLD mit ganz vielen IO.
Oder mit zwei CPLD ...Oder gleich ein kleiner FPGA der die CPU gleich mit nimmt???
-
Die Frage ist auch ...
Im Falle der 1541, beim Prof Dos könnte man die Logik des Prof Dos bleib mit nehmen. Spart ein paar Käfer.
Und, man könnte auch die GCR Kodierung gleich mit machen.
Und zwar richtig.Genau so wie die professionellen Commodore Floppys.
Die schreiben einfach 8 Bit und lesen 8 Bit.
Da wird alles in einem TTL Grab verarbeitet. -
Also ich bin dein Mann. Müssen wir nur noch @Tommi_nrw mit ins Boot holen, der ist momentan aber irgendwie unpässlich.
Nehmen wir zum Start diese Version FE512Ver5.zip ? Welche Codebasis?unpässlich??!
Oje, der Arme, was hat er denn?
-
@Diddl ich weis nicht, er antwortet halt nicht.
Ich kann schon ein wenig mit Cyclone V und Quartus. Falls es zur Entscheidung wichtig sein sollte ....(6502 CPU im FPGA hätte ich auch lust zu)
Also ich hab nur Angst davor, das die Sache zu komplex wird für mich.
In Summe:
-> 6502 CPU
-> Professional Dos, mit richtiger GCR Decodierung ohne Tabellen
-> An professionellen Commodore Floppys orientieren.
-> IEEE 488 bzw. IEC 625 BUS ?
-> 512KB RAM oder mehr ?
-> ....Ich glaube wir bauen ein komplett neues Mainboard für die Floppy, wenn wir so weitermachen.
Meine Gedanken gingen ursprünglich mehr in Richtung Postmodernes RAM DOS Professinal, weil das alte halt verschwunden ist. Mit ein paar netten Eigenschaften noch neu dazu. (z.B. Cachen der Floppy-Disk ...)
-
Wir haben 500 ...
Aber es langen ja schon 170 KB um eine Diskette zu buffern.Nee, kein neues Motherboard für die 1541.
Nur ein ProfDos++ das man einfach installieren kann.
Einfach CPU raus und Platine im CPU Sockel rein stecken.Möglichst simpel.
Die GCR Enkodierung/Dekodierung könnte man mit zwei Register im CPLD machen.
- man schreibt 4 Bytes und liest 5 GCR Bytes (encode)
- Man schreibt 5 GCR Bytes und liest 4 Bytes (decode)
-
Nur ein ProfDos++ das man einfach installieren kann.
Einfach CPU raus und Platine im CPU Sockel rein stecken.Möglichst simpel.
Voll dafür. Steigern im Abstraktionsgrad können wir uns später dann immer noch ....
Ich poste hier mal einen Link, für alle diejenigen hier draußen im Internet, die gerne mitmachen/mitdenken wollen als Bastlerservice.
https://archive.org/details/64er_1985_06/page/n115 -
@Diddl also wir machen aus dem Bitstream, der aus Quintuples besteht, vom Schreib/Lesekopf der Floppy, Nybbles für die CPU?
Und die CPU setzt diese dann wieder normal zu 8Bits bzw. 1Byte zusammen, so wie sie es immer schon tat?Und den Rückweg auch so?
Oder setzen wir mit unserer Black Box (verschlüsseler/entschlüsseler) auch gleich das Byte für die CPU zusammen?
-
@Diddl und dann brauchen wir noch eine Abzweigung des Ladevorganges. Wenn es sich im Ram befindet, lade es. Befindet es sich dort noch nicht, dann hole es von Floppy-Disk.
Wir könnten die Befehlssequenz zum Laden des Inhaltsverzeichnisses dazu benutzen, die ganze Diskette ins Ram zu laden.
So ne Art Kontroller der sich zwischen der Floppy-Disk und der RAM Disk befindet. Arbeiten tun wir mit der Ram-Disk und der Kontroller arbeitet unabhängig Veränderungen auf die Diskette ab. (Spielstände oder so)
-
Und, man könnte auch die GCR Kodierung gleich mit machen.
Und zwar richtig.Klingt alles prima,
aber wer kann den FloppyKernal entsprechend anpassen?
Professional Dos macht die GCR codierung schon halb in HW,
zumindest schon "on the fly" - das könnte 8und müsste) dann ja raus.Und dann müssen wie gesagt noch die Routinen für die Benutzung
der RAM-Disk hinzugefügt werden: Bankswitching, Verwaltung der RAMdisks
und umleiten des Datenstoms um die RAMdisks von der Diskette zu füllen.Gleich immer große Bank-Bereiche einzublenden klingt erst mal vernünftig,
aber z.B. TurboTrans nimmt kleine Bänke (2 x 256 x 1kb), schaltet immer einfachpro
Block um und spart sich so eine Speicherverwaltung ... (TurboTrans Handbuch Seite 44)unpässlich??!
@Diddl ich weis nicht, er antwortet halt nicht.
Ich war erst im Kurzurlaub und anschließend auf einer Konferenz und zu allem Überfluss ist noch mein
PC-Netzteil abgeraucht. Also einfach keine Zeit. Und das wird auch dich nächsten Wochen möglichweise
noch weiter gehen da ich einiges um die Ohren haben. Ab und zu in der Mittagspause kann ich dann mal
reinschauen und auch etwas schreiben.Wir haben 500 ...
Aber es langen ja schon 170 KB um eine Diskette zu buffern.Meiner Meinung nach brauchen wir:
512kb Ramdisk (2 Disketten(seiten), unschaltbar)
+8kb Spurcache bei Diskettenbetrieb
+2kb Ersatz für FloppyRAM (wegen eigener 2MHz Takterzeugung auf dem Speeder)Wir könnten die Befehlssequenz zum Laden des Inhaltsverzeichnisses dazu benutzen, die ganze Diskette ins Ram zu laden.
Das halte ich eigentlich für eine Super Idee! - ausser natürlich Du stellst nach dem lesen das Inhalts fest,
dass Du die falsche Diskette eingelegt hast ... dann käme eine nervige Wartepause bis die Diskette ganz eingeledsen ist...
Also vielleicht auch eine zweite Funktion um nur die Directory von der Diskette zu lesen - und dann ist es wieder einfacher
eine Funktion zum Einlesen und eine für Direktory des gerade aktiven LW zu nehmen.So ne Art Kontroller der sich zwischen der Floppy-Disk und der RAM Disk befindet. Arbeiten tun wir mit der Ram-Disk und der Kontroller arbeitet unabhängig Veränderungen auf die Diskette ab. (Spielstände oder so)
Das gibt zuviel Schreibverkehr auf der Diskette. Besser ist da ein "sync-Befehl" der die Diskette schreibt.
-
@Tommi_nrw na endlich wieder da.
"sync-Befehl" -> OK, also Benutzer gibt via Tastatur Kombination den Startschuß, aber dann muß er auch wissen, welche der beiden Disketten im Ram gerade aktiv ist. Da sollte der Benutzer nicht in Tüdel kommen. (Idee dazu: Mehfarb LED, also irgendwie unterscheiden können)@Diddl könntest du auch die Turbo Trans TTL Logic im CPLD nachbilden? Einen Schaltplan hat @Tommi_nrw schon.
Da müsste dann noch Professional Dos dazu und dann wär es das schon bald.
-
@Diddl könntest du auch die Turbo Trans TTL Logic im CPLD nachbilden? Einen Schaltplan hat @Tommi_nrw schon.
Um Gottes Willen nein!
Das geht besser! Und kein DRAM mit Refresh-quatsch ...
-
Das geht besser! Und kein DRAM mit Refresh-quatsch ...
Also doch lieber die vc20 FE mit dem statischen RAM anpassen?, oder ganz was anderes?
-
@Diddl also wir machen aus dem Bitstream, der aus Quintuples besteht, vom Schreib/Lesekopf der Floppy, Nybbles für die CPU?
Und die CPU setzt diese dann wieder normal zu 8Bits bzw. 1Byte zusammen, so wie sie es immer schon tat?Naja, dazu müsste man das Schieberegister für den Bitstrom austauschen.
Dazu wäre mehr nötig als nur die CPU raus, Platine rein.
Das wäre ein separates CPLD projekt, unabhängig vom anderen ...
=============
Ich dachte an eine verbesserte Rechenhilfe für die CPU.
-
Wir könnten die Befehlssequenz zum Laden des Inhaltsverzeichnisses dazu benutzen, die ganze Diskette ins Ram zu laden.
Wir könnten, da ProfDOS ja ohnehin immer ganze Spuren liest, jede gelesene Spur cashen.
Und wir könnten die Idle Loop nutzen ...
... immer wenn die Floppy gerade nichts zu tun hat, keinen Job ausführt, könnten wir den Cashe füllen.