Hello, Guest the thread was called4.6k times and contains 56 replays

last post from Shadowolf at the

Beispiele für Games mit Fastloader?

  • Quote

    Original von Rio
    Nur mal nebenbei: Hast du den Speedloader der RetroReplay auch mit dabei?


    Nö, ich habe keine RetroReplay.


    Ist wahrscheinlich auch ein Nachlader.
    Dazu müsste man erstmal das Problem lösen, wie man an den restlichen Code rankommt.


    Als Erstes nehme ich mir vielleicht auch besser einen nicht so tollen Fastloader vor der dafür aber mit weniger Code auskommt...

  • Quote

    Originally posted by Shadowolf
    Ist wahrscheinlich auch ein Nachlader.
    Dazu müsste man erstmal das Problem lösen, wie man an den restlichen Code ranzukommt.


    "dev 8:" gefolgt von "watch load <Adresse des Sprungs zu Teil 2>" im Monitor von VICE?


    Quote

    Als Erstes nehme ich mir vielleicht auch besser einen nicht so tollen Fastloader vor der dafür aber mit weniger Code auskommt...


    Tip: Nimm nicht FLOAD/Turbodisk/Fastload (Einsprung bei 0x303, 493 Byte Codelänge).

  • Quote

    Original von Unseen
    "dev 8:" gefolgt von "watch load <Adresse des Sprungs zu Teil 2>" im Monitor von VICE?


    Ja, vielleicht sollte ich mir VICE auch mal wieder installieren...
    Hmm, gibt es das RetroReplay eigentlich für VICE?


    Quote

    Tip: Nimm nicht FLOAD/Turbodisk/Fastload (Einsprung bei 0x303, 493 Byte Codelänge).


    Ooookaay dann... :)

  • Quote

    Originally posted by Unseen


    Tip: Nimm nicht FLOAD/Turbodisk/Fastload (Einsprung bei 0x303, 493 Byte Codelänge).


    Nettes Teil, 183 Blöcke in etwa 8 Sekunden wenn man nicht durch so lästige Kleinigkeiten wie eine Mechanik gebremst wird. Es könnte sogar noch etwas schneller sein wenn ich die seriellen Debugmeldungen komplett entfernen würde (Weglassen mindestens des M-E-Kommando-Dumps ist Pflicht, sonst reagiert sd2iec zu langsam für den C64-Teil), es dauert ca. eine Sekunde nach Eingabe des LOAD-Befehls bis der Bildschirm abgeschaltet wird.


    [size=5]Das ganze wäre auch viel schneller gegangen wenn ich nicht bei einem Befehl des Orginals eine um einen Zyklus kürzere Zeit danebengeschrieben hätte...[/size]


    Zwei Probleme gibts aber noch:

    • Im Augenblick ist es totaler Spaghetticode der in doscmd.c reingehackt wurde und die regulären Open-Routinen auf interessante Art missbraucht (und den Puffer nicht schliesst) - aber das lässt sich relativ leicht beseitigen.
    • Das Timing ist kritisch. Mein Entwicklungschip verwendet einen 8MHz-Quarz und überträgt fehlerfrei, auf einer MMC2IEC-Platine mit (fehlkalibriertem) RC-Oszillator im Chip werden nur die ersten 5 Byte korrekt übertragen - eine Synchronisation zwischen C64 und "Floppy" erfolgt nur einmal pro Sektor, also pro 254 Byte.


      Dieses Problem lässt sich nicht so leicht beseitigen sofern man die Nutzer nicht zu einer bei den SMD-Platinen fiesen Lötakrobatik (8MHz Quarzoszillator an einen oder normalen Quarz an zwei nebeneinanderliegende Pins des Chip anschliessen) und Umprogrammierung des Chips (Oszillatortyp ändern geht nur mit externem Programmierer) bringen will.


    Aber vielleicht reicht es ja doch aus, den RC-Oszillator einmal zu kalibrieren - wofür aber ein stabiler und bekannter Takt benötigt wird.

  • Hmm, die Kalibrierung könnte man mit einer speziellen Firmware einerseits und einem Programm auf dem C64 andererseits machen.
    Wird aber auch nicht besser als +/- 1 Prozent, wenn überhaupt.


    Alles andere läuft auf eine Änderung im Design hinaus, was denen nicht hilft, die jetzt bereits ein Gerät haben.



    Hmm, wenn das trotz grob gesehen 16x Speed gegenüber dem 6502 ein Problem ist dann ist das bestimmt auch keine gute Idee, die Spannung am Controller zu senken.
    Der RC-Oscillator ist auf 5V/25°C kalibriert, bei 3V sind das noch so 7 MHz laut Datenblatt.
    Da hat man durch weniger Bauteile letztlich auch nichts gewonnen.
    -> Ich muss mal messen, wie schnell meine Mega32 wirklich laufen, leider hat der keine Fuse dafür -> der Mega32 ist ja noch 1. oder 2. Generation AVR...


    Ein Quarz ist auch leider viel zu gross für das Design.
    Ein Keramik-Resonator wäre wahrscheinlich die bessere Alternative.
    Die liegen aber auch "nur" so um die 0,5 Prozent Genauigkeit.


    Sowas Nachzurüsten erfordert aber nicht nur Fingerspitzengefühl sondern auch einen Programmier-Adapter da die Fuses verändert werden müssen.



    Seufz, vielleicht muss eine 2.0 Version von dem Ding wirklich auch etwas weiter oben ansetzen.
    So Mega328P-20, Mega644P-20, AT32UC3B164...AT32UC3B0256, XMega...

  • von NLQ gibt es ja das C64 Flashprogramm das kann doch auch kalibrieren? Für MMC2IEC und IEC2IEEE ...


    Da würde dann ein Kabel IEC auf die Programmierbuchse ausreichen :)


    EDIT: IEC2ATA mein ich natürlich nicht MMC2IEC!!!

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

  • Quote

    Originally posted by Shadowolf
    Hmm, wenn das trotz grob gesehen 16x Speed gegenüber dem 6502 ein Problem ist dann ist das bestimmt auch keine gute Idee, die Spannung am Controller zu senken.


    Das Problem liegt einfach nur darin, dass das Turbodisk-Protokoll sich genau einmal synchronisiert und dann 254 Byte Daten in 2-Bit-Päckchen alleine durch Timing über den Bus schaufelt. Die Haltezeit eines Bitpaares liegt dabei bei 29 Mikrosekunden und pro Byte werden 22 Mikrosekunden für Laden, Vorbehandlung und Schleifenzähler benötigt. Zusätzlich gibt es IIRC 7 Mikrosekunden Ungenauigkeit bei der Synchronisation von Rechner und Laufwerk, mit den Zahlen sollte man bestimmen können ob +/-1% reicht oder nicht.


    sd2iec 0.2.1 scheint übrigens noch einen Bug beim Speichern zu haben, in sehr seltenen Fällen (empirisch ca. einmal alle 500 Blöcke) geht ein Bit verloren und damit sind die Daten ab dem Punkt hinüber. Wäre mir das früher aufgefallen hätte ich nicht zwei Stunden in die Suche nach dem Fehler im Fastloadercode investiert. =(


    Quote

    Der RC-Oscillator ist auf 5V/25°C kalibriert, bei 3V sind das noch so 7 MHz laut Datenblatt.
    Da hat man durch weniger Bauteile letztlich auch nichts gewonnen.
    -> Ich muss mal messen, wie schnell meine Mega32 wirklich laufen, leider hat der keine Fuse dafür -> der Mega32 ist ja noch 1. oder 2. Generation AVR...


    Die Tatsache, dass der eigentlich 4 RC-Oszillatoren mit unabhängigen Kalibrierungswerten verwendet, die aber nur via Programmierer auslesbar sind macht das ganze noch ein wenig lästiger.


    Falls ich hier noch irgendwo einen 32768Hz-Quarz finde löte ich den mal an TOSC1/2 und teste ob eine Kalibrierung nach Appnote AVR055 reicht.


    Quote

    Seufz, vielleicht muss eine 2.0 Version von dem Ding wirklich auch etwas weiter oben ansetzen.
    So Mega328P-20, Mega644P-20, AT32UC3B164...AT32UC3B0256, XMega...


    Och nöö, bitte keinen Chip mit 22 Bit PC - dann müsste ich mein Assemblermodul nochmal umbauen... (auf denen brauchen einige Sprungbefehle einen Zyklus mehr)


    Ein Interrupt für ATN (oder eine Schaltung an der Leitung die mit der in der 1541 vergleichbar ist) fände ich aber weiterhin sehr hilfreich, oben genannter Save-Bug liegt sehr wahrscheinlich am alle 500us aufgerufenen Timerinterrupt der genau den emuliert.

  • Quote

    Original von Unseen


    Das Problem liegt einfach nur darin, dass das Turbodisk-Protokoll sich genau einmal synchronisiert und dann 254 Byte Daten in 2-Bit-Päckchen alleine durch Timing über den Bus schaufelt. Die Haltezeit eines Bitpaares liegt dabei bei 29 Mikrosekunden und pro Byte werden 22 Mikrosekunden für Laden, Vorbehandlung und Schleifenzähler benötigt. Zusätzlich gibt es IIRC 7 Mikrosekunden Ungenauigkeit bei der Synchronisation von Rechner und Laufwerk, mit den Zahlen sollte man bestimmen können ob +/-1% reicht oder nicht.


    Hmm.
    254 * 4 = 1016
    29µs / 1016 = 28,54 ns
    8 MHz = 125 ns / Takt
    8,08 MHz = 123,78 ns / Takt
    7,92 MHz = 126,26 ns / Takt
    8,32 MHz = 120,19 ns / Takt
    7,68 MHz = 130,21 ns / Takt


    125 ns + 14 ns -> 7,194 MHz


    Oder um das mal in Worte zu fassen.
    Bei 1016 2-Bit Übertragungen zu jeweils 29µs sollten pro Übertragung 28,54 ns Versatz drin sein bevor das Timing aus dem Ruder läuft.
    Wenn man in die Mitte vom Zyklus geht also etwa 14 ns.
    Insofern müsste man auch mit 11 Prozent Genauigkeit hinkommen.


    Theoretisch.
    Rein praktisch ist das schon sehr eng.
    Helfen würde ja schon wenn man wüsste, ob der Takt nach oben oder nach unten abweicht.


    Bitte nicht schlagen wenn das Quatsch ist... :)



    Quote


    Die Tatsache, dass der eigentlich 4 RC-Oszillatoren mit unabhängigen Kalibrierungswerten verwendet, die aber nur via Programmierer auslesbar sind macht das ganze noch ein wenig lästiger.


    In der Tat. Das habe ich vorhin auch mal ausgelesen, die 4 Werte sind in dem Mega32 hier auch unterschiedlich.
    Blöd, dass immer der Wert für 1 MHz geladen wird...


    Quote

    Och nöö, bitte keinen Chip mit 22 Bit PC - dann müsste ich mein Assemblermodul nochmal umbauen... (auf denen brauchen einige Sprungbefehle einen Zyklus mehr)


    Welche meinst Du jetzt? Die UC3B0256? Dafür müsste noch erheblich mehr umgebaut werden. :)
    Der AT32UC3B164 hat dann aber wieder "nur" 64K FLASH. ;)


    Der 644P ist sehr teuer, der 328P ist genauso wie die Mega32 und die XMega noch nicht verfügbar, den 324P habe ich noch vergessen (müsste man auch erstmal bekommen können...).


    Quote


    Ein Interrupt für ATN (oder eine Schaltung an der Leitung die mit der in der 1541 vergleichbar ist) fände ich aber weiterhin sehr hilfreich, oben genannter Save-Bug liegt sehr wahrscheinlich am alle 500us aufgerufenen Timerinterrupt der genau den emuliert.


    Wie wäre es denn, Pin37-ATN mit Pin42 (Int2) zu verbinden?
    Die liegen ja schon einmal dicht beisammen.
    Weniger fummelig ist vielleicht noch den Widerstand R16 zu entfernen und von dem Pad eine Leitung zu Pin42 zu ziehen.
    Das halte ich noch für relativ leicht durchführbar.

  • Quote

    Original von Unseen
    Zusätzlich gibt es IIRC 7 Mikrosekunden Ungenauigkeit bei der Synchronisation von Rechner und Laufwerk


    Der Teil stimmt zwar wenn der Code auf der 1541 läuft, aber da der Rechner zuletzt die Bereitschaft signalisiert stimmt das gar nicht - ich meine es würde in einer maximalen Abweichung von 2 AVR-Zyklen gehen (label: SBIS, RJMP label).


    Quote

    Originally posted by Shadowolf
    Hmm.
    254 * 4 = 1016
    29µs / 1016 = 28,54 ns


    Das sind nur die Bitzeiten, da fehlen noch die 22 Mikrosekunden pro Byte für Laden+Vorbereitung+Schleife.


    Quote

    Insofern müsste man auch mit 11 Prozent Genauigkeit hinkommen.


    Theoretisch.
    Rein praktisch ist das schon sehr eng.


    Hast du einen geeigneten durchstimmbaren Frequenzgenerator da um das einfach durchtesten zu können? =)


    Quote

    Wie wäre es denn, Pin37-ATN mit Pin42 (Int2) zu verbinden?
    Die liegen ja schon einmal dicht beisammen.


    Sicherlich eine interessante Alternative, die allerdings Änderungen an allen bisherigen Platinen erfordern würde. =(


    Meine Behauptung, dass ich Fehler beim Speichern hätte, die durch den ATN-Poll-Interrupt entstanden seien ziehe ich vorläufig zurück, meine Lade+Speicher-Testschleife erzeugt ohne Fastloader 26 identische Dateien. Andererseits kann das Problem eigentlich nicht im Fastloadercode stecken, der entstehende Datenfehler ist ein Versatz um ein Bit nach links (d.h. ein Bit wird beim Transfer ausgelassen) - Turbodisk sendet aber immer Bitpaare.

  • Quote

    Originally posted by Rio
    ich möchte euch ja ungern unterbrechen, aber gibt es keinen Weg, Fastloader ohne umbauten zu integrieren?


    Ohne Umbauten an der Hardware? "Wir arbeiten daran."


    Ich suche erstmal noch nach dem Grund wieso ich gelegentlich ein Bit verliere und wenn der Teil geklärt ist wird geprüft zuverlässig man Fastloader ohne Hardwareänderungen hinbekommt - vorher lohnt sich der Aufwand nicht.

  • Quote

    Original von Unseen
    Ich suche erstmal noch nach dem Grund wieso ich gelegentlich ein Bit verliere


    Ja, das ist echt Mist, wenn die BIT einfach so verloren gehen... Kenne ich: Ich ärgere mich auch immer darüber, wenn der Kasten BIT leer ist, und es keiner gewesen war ... Ich trinke die nämlich auch immer am liebsten selber...
    :bia:bgdev:drink:


    Oliver W.

  • Quote

    Originally posted by Unseen
    Ich suche erstmal noch nach dem Grund wieso ich gelegentlich ein Bit verliere und wenn der Teil geklärt


    Ist geklärt: Mein Testaufbau hatte eine furchtbare Signalqualität auf den Leitungen zu der SD-Karte weil ich eine recht obskure Art der Pegelwandlung verwendet habe. Die Fertigplatinen wird das bestimmt nicht betreffen, aber es war immerhin hilfreich um die Sache mit den CRCs beim Datentransfer zu testen.


    Dummerweise hatte ich dadurch keine Zeit[1] mich mal den Kalibrierungsmöglichkeiten des mega32[2] zu widmen, aber falls jemand trotzdem mit dem Fastloader-Code experimentieren will (zB weil er die Möglichkeit hat einfach einen Quarz an den Controller anzuschliessen) ist der jetzt via git oder CVS verfügbar.


    [1] Und dieses Wochenende ist wegen come2linux auch mehr oder weniger belegt.


    [2] Eines meiner beiden Platinchen läuft übrigens mit 8,16+/-0,08MHz (Messtoleranz, nicht etwa Schwankungen) bei 5V und Raumtemperatur, das andere ist im DTV zu schlecht zu erreichen.

  • Aus irgendeinem Grund komme ich nicht mehr an das .git Repository ran.


    git clone http://snowcat.de/mmc2iec/sd2iec.git/ f:\!sd2iec


    -> fatal: not a git repository
    Failed to find a valid git directory.


    Äh, okay, das war mit der GIT-Shell.
    Mit der Winblöd-Eingabe-Aufforderung ging das ohne Probleme.


    Hmm, jetzt wären der 15 MHz Generator und der 225 MHz Frequenzzähler von der Arbeit vielleicht hilfreich, nicht zu vergessen das Digital Scope mit Logik-Analyser... ;)
    Aber vorher möchte ich lieber mal was eigenes probiert haben.

  • Quote

    Originally posted by Rio
    ich möchte euch ja ungern unterbrechen, aber gibt es keinen Weg, Fastloader ohne umbauten zu integrieren?


    (einige Tests später...)


    Auch mit dem besten Kalibrierungswert den ich für meinen Chip gefunden habe ist eine fehlerfreie Übertragung mit dem Turbodisk-Protokoll nicht möglich. Für Fastloader, die sich nach jedem Byte synchronisieren sollte es reichen, es wurden immerhin *FIXME* Bytes von 254 fehlerfrei übertragen. Laut der Messfunktion im Oszilloskop (jaja, Schätzeisen...) war dabei der SPI-Takt (der 1/8 des CPU-Takts beträgt) 1.001MHz, mit den danebenliegenden Kalibrierungswerden ergaben sich 998.x kHz und 1.004MHz.


    Die Temperaturstabilität des internen Oszillators ist übrigens auch eher mies, ein paar Sekunden den Chip mit dem Finger zu berühren veränderte die auf dem Scope angezeigte Frequenz schon um 1kHz.

  • Quote

    Originally posted by Unseen
    es wurden immerhin *FIXME* Bytes von 254 fehlerfrei übertragen.


    Ich wusste doch das ich irgendwas vergessen habe. "*FIXME*" schwankt zwischen 40 und 80.

  • Ich sehe mir gerade mal wieder Quarze an.
    Nachrüsten ist ganz schlecht, die Dinger sind ja vergleichsweise riesig und die benötigen ja auch noch Kondensatoren zusätzlich.
    Ausserdem sind die Anschlüsse am Mega32 auf der Seite an der auch der SD-Sockel sitzt.


    Ein Resonator wäre einfacher nachzurüsten da die Kondensatoren bereits eingebaut sind.
    Allerdings hat man dabei mechanisch das gleiche Problem und muss zudem noch zwei von den drei Pins des Resonators kreuzen da die Belegung am Atmel blöd ist:


    GND/XTAL1/XTAL2


    Nett wäre ja: XTAL1/GND/XTAL2


    Ausserdem ist so ein Resonator mit 0,5 Prozent auch nicht so sehr viel genauer
    und ebenfalls temperatur-abhängig.



    Okay, wie wäre es denn alternativ mit einem Uhren-Quarz?
    http://www.reichelt.de/?;ACTIO…98c175ca631838de5091fd687


    Die laufen direkt ohne Kondensatoren am Atmel und die Anschlüsse dafür sind auf der anderen Seite, am Rand, TOSC1 und TOSC2 sind Pin 25 und 26.
    Also von der roten LED aus weitergehend der dritte und der vierte Pin.
    Die sind klein und bedrahtet, die könnte man auf den Mega32 kleben und anlöten.


    Okay, der wäre "nur" zum Kalibrieren, es könnte aber immer wieder kalibriert werden.
    In einem weitem Temperatur-Bereich.


    Man könnte den RC-Oscillator per Kalibrierung auch absichtlich verstimmen um ein Unter-/Über-Takten des Controllers bis etwa 10 Prozent hinzubekommen.