Beiträge von Diddl im Thema „TurboTrans+ / Turbo Access“

    Deine GCR-Dekodierung im CPLD kostet 16 Makrozellen?


    Ich habe mir jetzt schon zweimal sagen lassen müssen, dass ich bei der CPLD Programmierung umdenken muss. Meine Art vorzugehen sei typisch für einen Programmierer und so kann/soll man es nicht machen.

    Mein Problem ist wahrscheinlich die Art wie ich denke. 35 Jahre Softwareentwicklung hinterlassen Spuren die man nicht verbergen kann.

    Meine CPLD Designs funktionieren, aber es würde viel besser gehen, das ist mir schon klar. Vermutlich fehlt es mir an Fantasie oder einfach an Hardware Kenntnissen? Aber ich werde schon auch noch raffinierter werden mit dem Zeugs ... ;)

    Die Schaltbilder der 8050 sind äußerst interessant. Man sieht wie sie die GCR Dekodierung/Kodierung mit einem wahren TTL Grab gemacht haben. 74LS133, 164, 157, was es da alles für Zeugs gab ...


    Die 6502 bekommt nie GCR Daten zu sehen. Man kann per Software gar keine üblen Sachen machen, weder schreiben noch lesen. Gab es denn keinen Kopierschutz damals? Auch ein Nibblecopy kann es so gar nicht gegeben haben?

    Ok mit den Sektor Header, Prüfsummen und Blocklängen könnte man vielleicht Unfug treiben ...

    Das wird nur klappen, wenn du die Daten wieder über $1c01 in der Orginalgeschwindigkeit einspeist.


    Das habe ich auch schon am Laufen mit einem Xilinx CPLD mit 128KB SRAM (Pollin Board): Bitte melde dich an, um diesen Link zu sehen.


    Aber übertreiben wollen wir es nicht. Ich sprach ja von "eher" ...

    Wenn ich GCR Daten im RAM habe, dann gehen mal alle Sachen die "simpel" geschützt sind. Lesefehler (CRC, Header, short blocks, Sync Fehler).

    Wenn jemand Code in die Floppy lädt, dann funktioniert es ja auch, denn dann greifen die "normalen" Zugriffe auf die Diskette (langsam).

    So eine Lösung wäre sehr Inkompatibel.

    Zudem ist es kein Problem, wenn 2 Umdrehungen nötig sind. Weil der Spurwechsel benötigt sowieso die Zeit der zweiten Umdrehung. Und es ist ganz selten so dass ein Programm auf einer Spur Platz hat. Und wenn, ist es so kurz dass es eh schnell geht.

    Wichtig ist, dass man in einer Umdrehung eine Spur liest und teilweise dekodieren kann. Weil dann kann man den Lesekopf schon mal zur nächste Spur schicken die man benötigt.

    Wenn man die ganze Diskette im RAM hat, spielen auch Spurwechsel, Motorhochlauf und Sektor suchzeit keine Rolle mehr. Darum ist TT schon am richtigen Wege!

    Vorsortieren der Daten wäre ein Masterplan.


    Ich check noch nicht ganz, was du meinst mit dem "vorsortieren". Du meinst wegen der Sektor Verkettung beim LOAD?

    Ich beginne eine Spur zu lesen und nehme den ersten Block den ich kriegen kann. Es ist kein Problem die Sektor Nummer zu ermitteln, um dann gleich in die richtige Stelle im Trackbuffer zu schreiben. Aber selbst wenn die Blockreihenfolge nicht stimmt (wie jetzt) ist das kein Problem, weil ich danach einen Sektorindex drauf setze.

    Wenn erst mal eine ganze Spur im Speicher ist, dann spielt die Sektorverkettung keine Rolle mehr?

    ====

    Aber ganz was anderes:

    Es ist lehrreich für einen Anfänger wie mich, die GCR Dekodierung per CPLD zu machen.

    Allerdings hat es auch seine Vorteile, die GCR Daten undekodiert im RAM zu haben. Am besten ziemlich roh, mit originaler Sektor Reihenfolge und eventuellen CRC Fehlern!

    + eine interne RAM Disk kann man optimal zum kopieren einer Diskette verwenden (Zusatzfeature)

    + Kopiergeschützte Spiele würde eher funktionieren direkt aus der RAM Disk (Kompatibilität!)

    - Kein Vorteil ohne Nachteil: Jedes mal wenn der C64 einen Sektor liest muss erst dekodiert werden.


    Wäre schon fast zu überlegen, zwei Modi zu machen oder die Daten kodiert UND dekodiert abzulegen ...

    Auf der anderen Seite, kann der CPLD auch helfen beim Dekodieren, wenn man erst beim Senden zum C64 dekodiert.

    Beim Schreiben macht der CPLD nun nichts mehr. Es wird immer abwechselnd CPLD-Register 0 und 1 geschrieben. Beim Lesen passiert die Dekodierung, - super easy! Warum bin ich nicht schon gestern auf den Dreh gekommen?

    Da wird der 6502 ja richtig langweilig ... :)


    Mittlerweile bin ich schon wieder weg von der Idee, das GCR en/decoding im CPLD zu machen, weil man doch ohnehin ROM braucht.


    Warum, ich brauch ja jetzt schon kein Byte aus dem ROM. Der CPLD hat alle Tabellen gefressen, zuvor benötigte ich 2K (was ja auch nicht tragisch war).


    Jetzt hab ich es weiter vereinfachen können, weil das Bit 2 ist ja immer gleich:

    0000 --> 01010
    0001 --> 01011
    0010 --> 10010
    0011 --> 10011
    0100 --> 01110
    0101 --> 01111
    0110 --> 10110
    0111 --> 10111
    1000 --> 01001
    1001 --> 11001
    1010 --> 11010
    1011 --> 11011
    1100 --> 01101
    1101 --> 11101
    1110 --> 11110
    1111 --> 10101

    Im Grunde ist es ja ein 3 aus 4 Bit ... :)

    Cool, GCR Dekodierung im CPLD ist gar nicht so schwierig. Ich hab es aber mit 16 FlipFlop und ein paar Gatter gemacht:


    Allerdings brauch ich jetzt A2 auch am CPLD.

    Eigentlich gibt es nur ein GCR Register mit 16 Bit. Es sind aber 6 GCR Register zu 8 Bit sichtbar. Je nachdem wo man schreibt wird es unterschiedlich behandelt. Vielleicht nicht elegant, aber es funktioniert super. :)


    Wiesel

    Ich glaub du wolltest es so machen, dass man überhaupt nur ein LDA braucht? Und der CPLD lädt vom VIA und dekodiert und stellt sofort die dekodierten Daten bereit.

    Man muss PD gar nicht schlagen. Zweistufig ist eigentlich leicht ausreichend.

    Wichtig ist nur, dass man GCR dekodiert und speichert ehe der nächste Sync kommt. Und genau das schafft PD ja. Oder schafft es das nur bei 2MHz?


    Mal rechnen: 21 Sektoren, 350 Bytes Nettodaten und ein bisschen verlust durch Sync Bytes ...

    ... Also etwa 7500 Bytes in 200ms. Entspricht etwa 27 µs Zeit, ein Byte zu übernehmen, zu dekodieren und zu speichern.

    außer Monster-Tabellen zu schaffen?


    Was hast du gegen Monster Tabellen ... ;)

    Ne im Ernst, ich habe mir genau darüber schon ziemlich den Kopf zerbrochen. GCR Dekodierung/Kodierung im CPLD.


    Allerdings komme ich immer wieder auf die Monstertabelle zurück, es ist einfach zu effektiv und Platz ist ja da.

    Außerdem ist die gar nicht sooo Monster, wenn man es gut behirnt:

    + Es sind ja nicht 10 aus 8 sondern 5 aus 4

    + Ein Bit ist ja immer 1.

    ====

    Trotzdem, schön wärs schon schon, so ne elektronisch optimierte Dekodierung, wie beim Proffessional DOS ...

    Ich bin nur leider nicht so fix wie du in den CPLD Belange. Für mich ist das immer noch recht suspekt im Gegensatz zu Software, das habe ich viel besser im Griff.

    weil man dem C64 noch einen zusätzlichen Parallelport verpassen muss.


    Sollte es jemand in einer kleinen Serie bauen, dann wird man wohl auch 2 Patches entwickeln:

    + Jiffy Patch - damit spart man sich den parallelen Port

    + SpeedDos Patch - damit kann man bestehende SpeedDos Kabel verwenden. Weil es halt der am meisten verbreitete parallel Standard ist.


    Sauhund hat die Arbeit aber immer mit in den VICE übernommen - ich kann mir vorstellen, dass das bei TurboTrans auch passiert, wenn wir fertig sind.


    Das wäre cool! :thumbsup:

    Die gefundene Routine muss nicht unbedingt was zu tun haben mit "Daten von Disk --> DRAM", es könnte auch ein Schreibvorgang "C64 --> $300 buffer --> DRAM" sein, - theoretisch.

    Dagegen spricht aber, dass der C64 nicht immer Buffer #0 verwendet.


    Die Zugriffe auf $6bfc und $6bfd kann das PAL nicht unterscheiden - das kennt nur 2K-Blöcke. Die letzte Version von Dolphin-DOS (V3) hat an der Stelle die 8K Ram gehabt - vielleicht ist das hier auch so? Das erklärt dann die drei von Dir gefundenen Zugriffe. Wenn das Ram sonst nicht gebraucht wird, müssen wir mutmassen, dass Du Trashcode gefunden hast.

    RAM an der Adresse $6000 würde bedeuten, dass ein Konflikt mit dem internen RAM da ist. Es sei denn, an der internen Dekodierung wird was geändert. Ich muss mal die Einbauanleitung studieren.


    [Gewagte Theorie - Modus]
    Ich glaube zur Zeit eher, der SRAM ist im oberen 32K Block!

    Wenn der SRAM sich die Adresse $8000 mit dem Eprom teilt, dann wäre auch alles klar. Der SRAM dient dazu, eine ganze Spur in einer Umdrehung lesen zu können. Es kann nur SRAM oder Eprom eingeblendet sein, daher muss die Routine "Spur lesen" im oberen Teil des Eprom stehen.

    Nachdem eine Spur gelesen wurde kommt der Schrittmotor für den Spurwechsel. Man hat also endlos Zeit das SRAM in den DRAM zu kopieren.

    Das Hardware Design ist aber im Wege, weil zuwenig Platz im Eprom ist. Also muss man tricksen:

    SRAM --> ($300) --> DRAM
    [/Gewagte Theorie - Modus]

    Es kann aber trotzdem falsch sein, denn da sind zwei unbeschaltete Pins am PAL, die irgendeinen Zustand speichern könnten. Wenn wir Pech haben, gibt es eine Init-Sequenz, mit der man das erweiterte Rom und die Ram-Bänke freischalten muss. Und wenn wir Glück haben, sind die Pins überhaupt nicht benutzt. Die Antwort bekommen wir nur per logic analyzer.


    Oder durch Analyse der Firmware.

    Ich habe eine JMP Table gefunden die im Eprom ab $8000 liegen muss. So 20 Funktionen werden da angesprungen.

    Ich habe auch viele Stellen gefunden wo die JMP Table angesprungen wird. Es wird immer davor eine STA $1000 (oder so ähnlich) gemacht. Möglicherweise wird da das
    Eprom eingeblendet bevor die Routinen aufgerufen werden. Vielleicht werden da aber auch nur das AC gerettet statt PHA?


    Ich würde mich aber freuen, wenn sich noch jemand an der Aktion hier beteiligen würde und den Schaltplan des Expansionsport-Moduls zeichnet. Außerdem fehlt uns noch die Belegung des Parallelkabels.


    Ich werde es versuchen sobald meine TT da ist ...

    Wiesel, ich bin immer wieder fasziniert von deinen umfassenden Hardwarekenntnissen und deinem messerscharfen Verstand. Es ist mir unbegreiflich, wie du aus einem Schaltplan das alles erkennen und analysieren kannst!


    2 x 2K würden auch gut in mein Konzept passen, wenn der DRAM im unteren Speicherbereich liegt (unter $8000). Commodore hat den unteren Speicherbereich ja leider nur unzureichend dekodiert, sodass sich dummerweise die ersten 8K viermal spiegeln.

    Aber 2 x 2 K wären ja gerade frei von $800 bis $FFF und von $1000 bis $17FF.

    Ich muss dringend den Code finden wo der DRAM angesprochen wird.

    Blödes Wetter, da hat meine bessere Hälfte null Verständnis für meinen Wissensdurst. :encolere20:

    Diddl: ich könnte Dir die auch leihen.


    Vielen Dank, ein sehr freundliches Angebot. Aber Ich sollte die nächsten Tage ein TT von Semperfi2010 bekommen. Sonst hätte ich sehr gerne dein Angebot angenommen.

    Aber so können wir vielleicht gemeinsam was rausfinden. Mit Hardware habe ich es leider nicht so.


    Btw. : anhand des Schaltplans müsste man den PAL doch mit Signalen beschalten und zumindest schon mal die dazu passenden Pegel aufzeichnen können ?


    Ich habe auch schon mit dem Gedanken gespielt, den PAL mit Hilfe eines Mega 644 zu analysieren.

    Bzw. könnte man natürlich auch ganz einfach die 6502 durch einen 644er ersetzen: Einfach R/W, Phi2, A0 - A15 und D0 bis D7 an die Ports des Mega legen.

    Ich halte das Vorgehen für Unfug bei einer 1541 Hardware. Es gibt schon Speeder die SEI machen und dann auf den c64 warten ...


    Gut im Grunde wäre es egal ...

    ... man müsste nur nach einem "M-E" oder "Ux" den Speicher für ungültig erklären. Muss man ja sowieso, weil man ja nicht weiss was die User Routine gemacht hat!