Beispiele für Games mit Fastloader?

Quote

Original von Unseen
(oder eine Schaltung an der Leitung die mit der in der 1541 vergleichbar ist) fände ich aber weiterhin sehr hilfreich

Was für eine Schaltung soll das sein?
Die Schaltpläne die ich bisher so gefunden habe zeigen nur ein 74LS86 Gatter welches mit dem zweiten Eingang auf +5V als Inverter "missbraucht" wird.

Bin schon wieder auf dem Weg ins Bett um die Woche zu überleben...

>Ja, genau der. Zusammen mit dem 7406-Inverter dahinter zieht der die Datenleitung
>auf Low, wenn die ATN-Leitung und sein zweiter Eingang beide auf Low sind.
>Die 500us-Interrupt-Routine in sd2iec emuliert genau das Verhalten.

Sorry, ich sehe nicht, was Du meinst.
Die Schaltpläne die ich so spontan gefunden habe waren so auf dem Level handgezeichnet, 1000 Jahre alt und mit 75 DPI eingescannt...

Haste mal'n Link oder einen sauberen Ausschnitt?

Quote

Original von Unseen
Sowas ist sogar gerade an meinem AVR angelötet, aber nach ersten Tests mit manuell umgestellten Kalibrierungswerten habe ich das nicht weiter verfolgt. Die Auflösung des OSCCAL-Registers ist leider nicht hoch genug um den gewünschten Zielwert zu erreichen.

Um das darzustellen habe ich mal 6 Scope-Fotos angehängt die den OSCCAL-Wertebereich von 0xb2 bis 0xb5 sowie die Variante mit 8MHz-Quarz dokumentieren,

Na, die Werte sehen doch aber sehr gut aus.
Atmel spricht ja von 1 Prozent erreichbarer Genauigkeit,
mit 0xb4 ist es doch aber sogar besser als 0,2 Prozent.

Ich habe mal die 1.6'er neben die jetzt einwandfrei mit der unmodifizierten 0.9 mmc2iec Firmware funktionierenden 1.7'er gelegt und zusammen mit einem Standard Quarz, einem 8 MHz Resonator und einem 32,768 kHz Uhren-Quarz fotografiert.

So ein Uhren-Quarz ist noch nachrüstbar.
Mit dem Resonator habe ich es versucht, allerdings mit dem ISP-Anschluss im Weg lediglich die XTAL1 und XTAL2 Anschlüsse miteinander verlötet.

Zukunft's Musik:

Für die 1.8'er Version habe ich einen Quarz integriert, damit wird die Leiterplatte allerdings länger als 52 mm und somit die Ausbeute pro Nutzen kleiner und die Platinen teurer pro Stück - mit dem gleichen Anbieter gefertigt aber bis 30x65 mm immer noch unter 4 Euro das Stück.
Die 1.7'er und die noch kommende 1.8'er sehe ich aber ohnehin mehr als Weg zu einer zukünftigen 2.0.

ATXMEGA32A4 - 8-Bit, 32K FLASH, 4K SRAM, 512B EEPROM, 44 PIN -40/+85°C

Quelle: http://www.spoerle.de

Das wäre exakt das richtige für uns, vielleicht auch der ATXMEGA32A5, ATXMEGA64A4 oder ATXMEGA64A5 - wobei die A5 im wesentlichen keinen ADC haben.

Die sollen Pin- und Funktions-kompatibel zu den ATMEGA werden, in SMD allerdings von 0,65 mm Raster auf 0,5 mm Raster geschrumpft.
Versorgung sind maximal 3,6V dabei aber bis 32 MHz.

Bisher sind die ATXMEGA allerdings nicht mal richtig angekündigt von Atmel,
es sickern nur immer wieder Informationen über Distributoren durch.
Wahrscheinlich ist ein "Release" im ersten Quartal 2008.
Wobei ich am 26.11. wieder ein Seminar mitmache, vielleicht erfahre ich da noch was.

Atmel ist ja nun nicht gerade dafür bekannt, dass angekündigte Teile zügig verfügbar werden.
Bin mal gespannt, wann ich die erste 2.0 Test-Platine machen kann, wird wohl nicht vor Ostern sein - mit erbettelten Mustern.

Quote

Original von AREA51HT
Eine Idee für die Leiterplatte:
Mann könnte doch ein paar Bauteile unter den SD-Kartenleser verlegen oder
auf die andere noch nicht Bestückungsseite...
So könnte man doch die Leiterplatte noch etwas billiger machen.

Unter den SD-Sockel habe ich bisher vermieden da es sich einerseits von den Signalen her nicht anbietet und man andererseits ein Problem hat wenn nach der Bestückung ein Fehler festgestellt wird - man kann weder messen noch die Teile begutachten.

Die Unterseite der Platine habe ich nicht mit Bauteilen versehen weil die Platine dann leichter verbaubar und zudem günstiger Maschinell bestückbar ist.

Nun ja, maschinelle Bestückung scheidet ja ohnehin aus solange es niemanden gibt der die Dinger ernsthaft verkaufen möchte und kann.
Allerdings habe ich mir überlegt das eine teilweise Bestückung eine gute Idee wäre.
Also den Controller und ein paar Kleinteile.
Das wäre immer noch ein Bausatz da nicht in dem Sinne betriebsbereit, wäre von durchgehend guter Qualität, wäre aber auch - abhängig von der Stückzahl - deutlich teurer.

Nun ja, ich - oder jemand anderes - hätte auch erheblich weniger Arbeit damit.

Quote

Original von Unseen

Ja, nur wie schon erwähnt ist das leider nicht gut genug für Turbodisk. Für Lader mit einer Synchronisation pro Byte sollte es aber reichen - die Frage ist nur welche in diese Kategorie fallen. (vermutlich Jiffy, das IEC2IEEE-Projekt von nlq kann AFAIK den Jiffy-Transfermodus und arbeitet auch mit dem internen RC-Oszillator, runterkalibriert auf irgendeinen schrägen Takt)

Ist das nicht ein wenig sehr pessimistisch?
Du hast doch schon, was war das, 60 bis 80 Bytes übertragen?
Und rein rechnerisch sollten 10 Prozent Abweichung vom Takt drin sein.
Immerhin ist der Atmel mehr als 16 mal schneller als der 6502.

Quote

Oh, nettes Spielzeug - und mehr Ram zum sinnlosen verbraten. Ok, zumindest um genug Puffer anzulegen um genauso viele Dateien öffnen zu können wie eine 1541.

4 KB hört sich extrem gut an zusätzlich zu den 32 MHz Takt, nicht wahr?
Damit könnte man auch 2 KB der "Emulation" widmen.
Die Teile sollen auch 4 DMA Kanäle und priorisierte Interrupts haben.

Wäre sehr nett, wenn wir das vor Ostern bekommen könnten...

Quote

Original von Unseen

Für den Einzelbytefall? Ja, das ist ziemlich pessimistisch.

Für Turbodisk? Nicht wirklich, die 60-80 Byte waren schon mit Kalibrierungswert 0xb4. Ich habe den Testlauf gerade mal einfach wiederholt und die Dateien unter http://snowcat.de/transfertest.zip online gestellt - spindizz.prg ist die Orginaldatei die 26x geladen und unter den Namen A-Z (ohne Turbo) gespeichert wird. Die ersten beiden Bytes werden dabei immer einzeln übertragen (die Ladeadresse), dann ein 252-Byte-Block, dann 254-Byte-Blöcke und der Rest wieder einzeln.

Na, das sieht doch aber gut aus, Du bist viel zu pessimistisch.

A 50
B 73
C 87
D 98
E 1240
F 123
G 128
H 132
I 128
J 127

Das ist jetzt nur bis zum jeweils ersten verkehrten Byte.

Quote

Die Rechnung früher im Thread stimmt auch nicht wirklich, da fehlt einiges. Wenn ich anhand des Orginal-Floppycodes nochmal nachrechne, dann braucht der vom Empfang des Startsignals das der C64 sendet bis zu dem Zeitpunkt an dem das letzte Bitpaar auf den Bus gelegt wird
35041 Mikrosekunden(*). Der Floppycode braucht 29 Mikrosekunden von einem Bitpaar bis zum nächsten, daher nehme ich das mal als die Grösse des Zeitfensters in dem das letzte Bitpaar am C64 ankommen muss.

29µs sind doch eine Ewigkeit.

Hmm, 35041 µs pro 256 Byte sind ja gerade mal 7 KB pro Sekunde.

>4 + 253*(12+4*(24+5)+10) +12 + 3*(24+5)+24 = 35041

Also weitere 12 µs vor jedem Byte und 10 µs nach jedem Byte?
Kann man die nicht nutzen, um sich zusätzlich zu synchronisieren?
Hmm, 32768 kHz sind 29,5 µs.
Wenn der asynchrone Zähler also nicht um 1 hochgezählt hat macht man
die Warte-Schleife 1 NOP länger.
Solange er um 1 hochzählt macht man die Warteschleife um 1 NOP kürzer.

Wobei die 29 µs doch im wesentlichen auch aus NOP's bestehen, oder?

Quote

Nehmen wir mal oBdA an, dass der AVR zu langsam läuft, d.h. von einem Zeitfenster zum nächsten wandert der Zeitpunkt an dem das Bitpaar im erlaubten Zeitfenster erscheint ein wenig nach hinten. Im Optimalfall wäre der Samplingzeitpunkt des C64 beim Transferstart möglichst weit hinten im Fenster und der vom AVR möglichst weit vorne - nehmen wir t_avr=0us und t_64=29us an (eigentlich 29us minus epsilon, aber ich habe gerade keine Lust auf Grenzwertbetrachtungen).

Unter diesen Annahmen darf der AVR während der Übertragung des kompletten Blockes maximal auf t_avr=29us wandern, also die 35041 Floppyzyklen in maximal 35041us+29us=35070us ausführen. Das ist ein Faktor von (35070/35041) = 1.0008276.

Das klingt nicht so gesund.
Andererseits sind 29µs auch 232 Taktzyklen bei 8 MHz, alle paar Byte einen draufzulegen oder abzuziehen wäre also drin.

Quote

Tatsächlich ist die Sache noch einen Tick komplizierter, weil der C64 nicht mit exakt 1MHz läuft und deshalb auf jeden Fall mit etwas anderem Timing einliest als die Floppy sendet. In der Praxis kommen dann noch die üblichen Dreckeffekte wie Laufzeiten im Kabel, ungenaue Synchronisation (bis zu 3 AVR-Takte Abweichung beim Start) und Ungewissheit ob man gerade langsamer oder schneller ist hinzu.

Seufz, ich schlimmsten Fall bewegen wir uns hier im Rahmen der Grundlagen-Forschung wenigstens auf eine neue Hardware zu die robuster ist.

Also Quarz ist Pflicht für die 2.0.
Würde es helfen, wenn der Takt ein gradzahliges Vielfaches des Floppy-Taktes wäre?
Also 10, 20 MHz statt 8, 16 MHz?

Quote

Hmm, man könnte zumindest 2KB reservieren um darin das Ram einer 1541 abzubilden (und die Puffer da an Orginalposition reinlegen).

Viel mehr hatte ich mit "Emulation" auch nicht im Sinn.

Quote

Eine komplette 6502-Emulation wäre natürlich richtig genial (müsste übrigens nicht 100%ig zyklensynchron sein - wenn man schneller emuliert als die Orignal-CPU ausführt muss man nur die Zyklen mitrechnen und bei I/O-Zugriffen abwarten bis der richtige Zeitpunkt da ist), aber 32KB Flash werden dafür nicht reichen.

Nun, 32 MHz und 4 KB SRAM werden dafür auch nicht reichen da der zu emulierende Code ja auch den Rest der Hardware erwartet.

Quote

Ja, ohne Warteschleifen könnte die Bitschleife in 10 AVR-Takten laufen - aber da käme kein C64-Programm mehr hinterher.

Das Problem ist also wirklich, dass das Protokoll von dem Fastloader schlichtweg
nicht robust genug ist.
Ein Quarz macht die Geschichte kalkulierbar und mehr MHz als 8 wären ja wohl nur nice-to-have um die Auflösung zu verbessern.

Quote

Wenn man denn einen guten Zeitgeber hätte um zu wissen wann das nötig ist. Der C64 ist nach dem Startsignal nur noch ein stiller Zuhörer, ein 32768Hz-Quarz an Timer2 ist meiner Meinung nach zu langsam und was anderes ist daran laut Datenblatt nicht erlaubt.

Man könnte den Timer vor jedem Byte anhalten und neu starten und nach jedem Byte darauf warten, dass ein Wert von 4 erreicht wird.
Das sind 138 µs pro Byte und 122 µs für den Timer.

Das wird aber so nichts da es nicht geligen dürfte, den Timer zu synchronisieren.
Laut Datenblatt braucht der Uhren-Quarz etwa 1 Sekunde um stabil zu schwingen,
immer wieder abschalten und neustarten funktioniert also nicht.

Quote

Alternativ könnte man über einen 1MHz-Quarzoszillator an T0 oder T1 (=PB0/1, Pin 40/41) nachdenken - dann könnte man den Zähler pollen bis genug Zeit vergangen ist.

Ich bestelle einfach mal einen bei Reichelt mit.
Ich fürchte nur, dass die Dinger viel zu riesig sind, um nachgerüstet zu werden.

Also zumindest diesen Fastloader wird man mit den 1.6'er Platinen wohl nie benutzen können.

Quote

Würde es helfen, wenn der Takt ein gradzahliges Vielfaches des Floppy-Taktes wäre?
Also 10, 20 MHz statt 8, 16 MHz?

Auch 8 ist ein ganzzahliges Vielfaches des Floppytakts, das reicht schon. Zyklen zu zählen wird nur dann richtig eklig wenn das Verhältnis "schräg" ist
[/quote]

Okay, ich hatte nur gerade in Nano-Sekunden gedacht und nicht in Zyklen.
8/16/32 lassen sich ja sogar besser zählen als 10/20/30.

Quote

Edit: Übrigens, Jiffy synchronisiert wirklich bei jedem Byte. Hätte ich das doch als erstes eingebaut...

Wie werden die Daten jetzt eigentlich übertragen?
Wir haben doch drei Leitungen und übertragen 2 Bits, zum wackeln der Takt-Leitung reicht die Geschwindigkeit in der 1541 nicht aus?

Quote

Original von Unseen

Es gibt auch recht kleine SMD-Quarzoszillatoren, aber die sind nicht leicht zu bekommen (na gut: Digikey) und nicht ganz billig (IIRC ab 4USD aufwärts).

Eine Nachrüst-Lösung muss vor allem durchführbar sein.
Winzig und schwer beschaffbar kommen da nicht so gut.

Auf meiner ersten Platine hatte ich einen winzigen 16 MHz Resonator drauf,
den hätte nur kaum jemand verlöten können.

Nun ja. Und dann hiess es, dass der RC-Oscillator genau genug sei.

Quote

Och, mit genug Lötakrobatik...

Nun ja, das wäre immer noch besser als gar keine Lösung.
Man könnte auch einen 8 MHz Oscillator an XTAL1 hängen.
Dazu muss man wenigstens nur an einem einzigen Controller-Pin löten.
Allerdings müssen dafür auch die Fuses eingestellt werden.

Bestelle ich auch mal von Reichelt mit.

Quote

Wir haben zwar drei Leitungen, aber die ATN-Leitung ist beim C64 Write-Only und bei der 1541 Read-Only und wird daher maximal zur Bereitschaftssignalisierung verwendet - gute Speeder haben die überhaupt nicht angerührt weil dann andere Geräte am Bus die Übertragung gestört haben. Damit bleibt effektiv gar keine Taktleitung übrig und alles muss über definiertes Zeitverhalten synchronisiert werden.

Tja, gut und schlecht.
Je mehr Einschränkungen die Schnittstelle hat, desto besser für uns.
Aber desto mehr wurde bestimmt auch getrickst, um das zu umgehen.

Quote

Solche Blocktransferfastloader müssten übrigens auch von dem Frequenzunterschied zwischen PAL- und NTSC-C64 betroffen sein während ich beispielsweise für Jiffy weiss, dass es überall den gleichen Kernal verwendet hat. Evtl. kann man sowas als Indiz verwenden, ob eine AVR-Umsetzung auf 1.6er-Platinen möglich ist oder nicht.

Naja, wenn sich das jedes Byte neu synchronisiert dann sollte das überall laufen.
Während das "30x Imported by BKS Odenwald" aka "Speed-Load II" wohl unter NTSC auch nicht laufen dürfte.