Beiträge von Kroko

  • 1541 :: Lese Elektronik von VIA 6522 bis zum Schreib- Lesekopf

    Ich glaube ich habe Dich falsch verstanden. Das Byte das gelatcht wird ist in der original Elektronik wirklich sofort wieder weg. Du kannst es also nur für die Dauer eines Bits dort abgreifen. Wenn es in der 1541II länger als 1 Bit anliegt müssen sie dort was am 74LS245 geändert haben (was Du ja schon vermutet hast)

  • Idee für einen FPGA-"C64-FBAS zu TFT"-Konverter (Brainstorming)

    Zitat von Freak

    Nebenbei bemerkt: Warum überhaupt eine PAL-Emulation realisieren?

    Also wenn man alles so ausgibt auf dem neumodischen TV wie es gesendet wird, dann hat man alles perfekt dargestellt. Aber wenn ich es richtig verstanden habe, dann würde
    man die Farbeffekte die durch Farbmischung entstehen evtl. auf dem neumodischen TV ganz anders sehen als es auf unseren alten PAL TVs ausgesehen hat ? Die Frage wäre
    also ob es überhaupt gut is, alles "perfekt" auszugeben ...

  • Idee für einen FPGA-"C64-FBAS zu TFT"-Konverter (Brainstorming)

    Ich hätte eine Frage zu dem Ruckeln wegen der Bildwiederholfrequenz. Wenn man immer 2 Frames vom C64 speichern würde, könnte man dann nicht
    diese beiden Frames so interpolieren, dass kein Ruckeln mehr erkennbar ist ?


    Ich glaube jemand hatte geschrieben dass das ein schlechtes Bild ergibt ? Wieso genau ist das so ?


    Und wegen der Farben: Wie schwierig wäre eine PAL Emulation in Hardware ? Ist das realistisch oder zu aufwändig ?

  • Laufwerk der 1541 emulieren

    Zitat von zschunky

    Ich denke schon dass evt. einige Speed-Loader auf diesen Zonen aufsetzen. Es gibt einige Speedloader, die sich nicht auf jeden byte-ready syncronisieren und falls hier unterschiedliche Implementierungen von (Anzahl Zyklen im Code) pro Zone verwendet werden, könnte es ein Timing-Problem geben.

    Beim Lesen bestimmen die Speedzonen wirklich nur wie lange kein Flusswechsel auftreten darf um eine "0" ins Schieberegister zu schieben. "0" wird ja durch das Ausbleiben des Wechsels auf der Diskette realisiert. Sobald ein Flusswechsel kommt, wird sowieso eine "1" reingeschoben und der 74LS193 der den Takt für die Speedzonen realisiert wird neu geladen. Also so lange ein "Speedloader" gültigen GCR Code von der Diskette lädt, werden die Speedzonen beim Lesen keine praktische Rolle spielen. Da wird immer das selbe gelesen werden. Damit kann der Atmel den Lesetakt einfach aus der Tracklänge bestimmen. Die Anzahl und der Takt des Byte Ready wird nur durch die Datendichte auf dem Track bestimmt.


    Anders sieht es eben aus, wenn da kein gültiger GCR Code auf dem Track ist, nämlich wenn zu lange kein Flusswechsel kommt ...nur dann hängt das Ergebnis theoretisch von den Speedzonen und vom Gleichlauf des Laufwerks ab.

  • Laufwerk der 1541 emulieren

    Zitat von Diddl

    Diese Speed Einstellung, - ist die eigentlich relevant in Bezug auf Kopierschutz?

    Beim Lesen bestimmt sie wie schnell vom Laufwerk "Byte Ready" kommt. Außerdem, wie lange das Laufwerk ein "0" Bit liest, solange kein Flusswechsel vom Lesekopf kommt. Das können ja maximal 2 mal 0 in Folge sein, dann kommt 1.
    Das ganze interessiert Dich also nur, wenn Du ein Datenformat als Input hast, bei dem nicht fertig codierte GCR Bytes drin sind, sondern die Flusswechsel und die Tracklänge. Dann würde nämlich abhängig von der eingestellten Speedzone und der Drehgeschwindigkeit ein möglicherweise verschiedenes Gcr Muster pro Umlauf entstehen können (falls da gar keine Flusswechsel im Track sind oder eben künstlich oft 0). Aber wie schon gesagt wurde: Sowas ist vermutlich nie als Kopierschutz verwendet worden.

  • Laufwerk der 1541 emulieren

    Ich hab den Raspberry Pi B+ kürzlich dafür verwendet, ein Modul für eine 2600 Konsole zu emulieren. Da ist der Takt < 1 MHz und ich muss den Adressbus pollen und in spätestens 500ns ein Byte auf den Datenbus ausgeben. Mit Linux geht da natürlich nichts, aber ohne Linux, quasi zu Fuß ist es möglich. Aber dann ist eben Linux weg und man muss alle Treiber per Hand schreiben ...

  • Geschwindigkeiten, Speedzones etc. bei der 1541

    Also ich glaube beim Lesen ist die Bitrate nicht so wichtig. Ein Bit auf der Floppy ist entweder 4, 3.75, 3.50 oder 3.25 µS "breit".


    Da die Decoder Clock bei jeder "1" neu gestartet wird und nur 2 mal "0" nacheinander kommen können würde ich sagen, dass die zwei Nullen (egal welche Bitrate eingestellt ist) immer richtig gelesen werden.


    Ich würde also erst mal nicht unterschreiben, dass da was falsch emuliert wird. Die Speed-Zones sind vor allem beim Schreiben wichtig. Und was Die Daten im g64 Format angeht: Was ist denn da drinnen ? Das was am Schieberegister ankommt oder wirklich die Flusswechsel ? Das ist ein riesiger Unterschied und 100% tig konnte es mir noch niemand sagen. Das müsste man erst mal abschliessed definieren bevor man zu emulieren anfängt. Meine Vermutung ist, dass es das ist , was am Schieberegister ankommt. Und damit wäre dann glaube ich die Einstellung der Speedzone beim Lesen beinahe sinnlos.Das würde dann nur noch bestimmen wie schnell Byte Ready kommt, aber man könnte auf keine Weise die Daten selbst durch Ändern der Speedzone beeinflussen. Anders sieht es aus, wenn da wirklich Flusswechsel drin sind denn dann könnte man tatsächlich auch illegale GCR Codierung abhängig von der Speedzoneneinstellung emulieren.

  • Atari 2600 Decathlon zum Laufen bringen

    Falls ja, weiss ich nichts davon. Ich gehe davon aus dass es so aufgebaut ist wie in dem Patent beschrieben... Aber einen richtigen Schaltplan ? Also ich kenne leider keinen. Ich dachte das Patent könnte helfen um die chips zu identifizieren (Falls es nicht eh klar ist anhand der Nummern)


    Könnte auch sein, dass die Widerstände das Problem sind. Falls sie am Timing beteiligt sind, wäre das auch eine mögliche Fehlerquelle. Also wenn irgend ein Delay über ein RC-Filter eingestellt wird... um das zu sehen müsstest Du mal den Schaltplan zeichnen und sehen wo die Widerstände und Kondensatoren angeschlossen sind.

  • Atari 2600 Decathlon zum Laufen bringen

    Decathlon benutzt FE Bankswitching was mit zu den kompliziertesten Methoden zählt. Das kleinste Kontaktproblem kann wohl schon das Modul aus dem Tritt bringen. Das gilt auch auf der "Atari" Seite. Mach mal die Konsole stromlos und zieh es 20 mal rein und raus. Dann das Modul nochmal säubern.


    Dass ein Chip so kaputt geht, dass es manchmal geht und manchmal nicht ist nicht so wahrscheinlich. Ich tippe eher auf ein Kontakt oder ein Timing Problem. Timing ist bei FE Bankswitching ziemlich kritisch.


    Wenn Dein Daumen hilft, dann könnte es sein, dass Störungen auf den Adressleitungen das Bankswitching triggern (oder verhindern dass es triggert). In dem Fall kann es auch sein, dass Du in Deiner Konsole Hand anlegen musst (Die großen Kondensatoren tauschen etc. einfach alles tun um Noise auf den Leitungen zu reduzieren). Für andere Module ist das nicht so kritisch, aber speziell FE ist da extrem anfällig.


    Was Du auch probieren kannst ist ein anderes Netzteil zu nehmen. Klingt blöd, aber wenn es die Störungen auf den Leitungen sind, dann unterscheiden sich Netzteile da teils erheblich.

  • ATARI 2600 Cartridges selber machen

    Für Bobby needs Food brauchst Du doch ein F4 Board. Hatte das Spiel denn SARA (Superchip) ? Ich dachte nicht dass dort extra RAM verwendet wurde.
    BNF wird in einem SARA Board meiner Meinung nach gar nicht laufen, weil es nur Standard F4 Bankswitching braucht.


    Ich kenne im Moment keine Quelle für die Pixels-Past boards mit EEPROM. Aber hier ist alles zu finden was man für den Nachbau braucht:
    http://www.grandideastudio.com/portfolio/pixels-past/


    Edit: Oder Du schickst Albert Dein Rom und er macht Dir ein Cartridge. Aber Du solltest vorher Belial um Erlaubnis fragen.