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.

  • Quote

    Originally posted by Shadowolf
    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.


    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, der AVR sollte dabei eine relativ stabile Temperatur gehabt haben. 0xb4 wäre genau der Wert aus den von Atmel bestimmten Kalibrierungsdaten für 8MHz. Mangels CLKOUT-Fuse im mega32 habe ich einfach den SPI-Takt der SD-Karte gemessen, der auf f/8 eingestellt ist.


    Quote


    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.


    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.

  • 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?


  • Von der alten 1541-Version in der das noch diskret realisiert war kenne ich keine besseren Schaltplanscans als die unter ftp://ftp.zimmers.net/pub/cbm/schematics/drives/new/1541/ verfügbaren (short-*). Von der 1541-II gibt es zwar einen modernen, im Rechner erstellten Schaltplan unter der gleichen Adresse, aber da ist der Teil der Schaltung in einen der Commodore-ASICs gewandert.


    Ist aber eigentlich egal, Pinchange-Interrupt reicht vollkommen und wie man an sd2iec sieht kann man sogar ohne den auskommen wenn man nur oft genug pollt.

  • 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

    Originally posted by Shadowolf
    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.


    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)


    Quote

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


    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.

  • 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

    Originally posted by Shadowolf
    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.


    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.


    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.


    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.


    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.


    Quote

    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.


    Hmm, man könnte zumindest 2KB reservieren um darin das Ram einer 1541 abzubilden (und die Puffer da an Orginalposition reinlegen). 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.



    (*) Beschreibung des Protokolltimings und/oder kommentiertes Disassemblat auf Anfrage - ich hatte es hier hingetippt, scheiterte aber an fehlenden verschachtelten Listen (zwei Schleifen!) um es lesbar zu machen. Rein den Zahlen nach berechnet sich das ganze als 4+253*(12+4*(24+5)+10)+12+3*(24+5)+24 = 35041

  • 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

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


    Sogar noch etwas schneller weil nur 254 Byte übertragen werden - die ersten zwei sind bei der 1541 ja für den Zeiger auf den nächsten Sektor reserviert.



    Hmm, ich komme auf 30,51us? Prinzipiell ist die Idee gar nicht mal so schlecht, allerdings würden sich die 0,5us Abweichung in der inneren Schleife über den ganzen Block hinweg wieder zu sehr aufaddieren - 254*4 Durchläufe.


    Quote

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


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


    Quote

    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.


    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. 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.


    Den AVR von Anfang an sauber takten klingt weiterhin nach der einfachsten Lösung und wird wohl das sein was ich nächste Woche mit meinen beiden Platinchen mache.


    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 - ich habe mal Dallas 1-Wire in Software auf einem PIC implementiert der wegen der benötigten seriellen Schnittstelle mit 3,6864MHz getaktet wurde. Den Taschenrechner habe ich dabei kaum aus der Hand gelegt.


    Erst bei Chips ab 128KB Flash könnten 10MHz evtl. hilfreich sein, da brauchen rcall und ret jeweils einen Takt mehr was das Schreiben einer 1us-Verzögerungs-Unterroutine vereitelt (besteht aktuell aus "nop;ret"). Andererseits verwende ich die gerade 3x im bisherigen Code und zwei Aufrufe sind "geschummelt".



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

  • 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

    Originally posted by Shadowolf


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


    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).


    Quote

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


    Och, mit genug Lötakrobatik... ;-)


    Quote

    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?


    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.


    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.

  • Quote

    Originally posted by Unseen
    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.


    Jiffy hat aber leider Probleme auf dem PAL C128DCR. Hier kommt es zu Fehlübertragungen von der internen 1571. Da ist wohl einfach das "Kabel" zu kurz, sind ja nur ein paar Leiterbahnen. Hängt man ordentlich Last auf den Bus durch zusätzliche Geräte, klappt plötzlich die Übertragung wieder.


    Das Jiffy für VC20 hat auch ein anderes Kernal als der NTSC VIC20, da hier die PAL Maschine mit ca. 1,1MHz deutlich schneller läuft.


    Bei den 264er Jiffy Versionen weiß ich nicht ob es da Unterschiede gibt, die hatte ich nie in der Hand.

    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 x1541
    Jiffy hat aber leider Probleme auf dem PAL C128DCR. Hier kommt es zu Fehlübertragungen von der internen 1571. Da ist wohl einfach das "Kabel" zu kurz, sind ja nur ein paar Leiterbahnen. Hängt man ordentlich Last auf den Bus durch zusätzliche Geräte, klappt plötzlich die Übertragung wieder.


    Gut zu wissen, das könnte sd2iec auch betreffen wenn jemand mal dazu kommt, Jiffy dafür zu implementieren. Wenn etwas Buslast schon reicht sollte es wohl funktionieren wenn man das Timing minimal zu verlangsamt - auf dem AVR ist das ja quasi in 1/8-Floppytakten einstellbar. =)

  • 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.