QuoteOriginally 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?
QuoteAls 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).
QuoteOriginal 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?
QuoteTip: Nimm nicht FLOAD/Turbodisk/Fastload (Einsprung bei 0x303, 493 Byte Codelänge).
Ooookaay dann... 
Der RR Fastloader wird beim RR Menu durch F7 aktiviert. Bei Start durch Configure memory/Normal Memory (F1/F3) ist der Fastloader deaktiviert.
QuoteOriginally 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:
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.
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!!!
QuoteOriginally 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. =(
QuoteDer 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.
QuoteSeufz, 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.
QuoteOriginal 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...
QuoteOch 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.
QuoteOriginal 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).
QuoteOriginally 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.
QuoteInsofern 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? 
QuoteWie 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.
ich möchte euch ja ungern unterbrechen, aber gibt es keinen Weg, Fastloader ohne umbauten zu integrieren?
QuoteOriginally 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.
QuoteOriginal 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... 
Oliver W.
QuoteOriginally 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.
QuoteOriginally 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.
Warum gibt es eigentlich keine kleinen, bedrahteten, 8 MHz Quarz-Oscillatoren? 
Physik? Ach was. 
QuoteOriginally 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.
