Populous
Xenon 2
Ultima 8
Beiträge von Kroko
-
-
Also sollte man wohl selber auch noch eine 8 Bit Latch auf einem Lese-Board haben, wenn man die Daten in jedem Fall gemütlich mit einem µC lesen will ...
-
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)
-
1541 Steppersteuerung und Datentransport
Hier hatten wir schon mal über das latchen des bytes in der VIA diskutert. Ich glaube Du hast immer 8 Bit Zeit das aktuell gespeicherte Byte aus der VIA auszulesen.
-
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 ... -
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 ?
-
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.
-
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. -
Die andere Plattform könnte ein Raspberry zero sein. Das Teil kostet 15€ beim Pollin und hat alles was man sich nur wünschen kann: SD Karte, USB, HDMI ...
Man könnte Display anschliessen oder WLAN oder Blutooth.Mein Problem zur Zeit ist, dass ich von Raspberry Programmierung gar keine Ahnung haben.
Und auch von Linux habe ich nur sehr wenig Ahnung.
Meine ersten Gehversuche sind kläglich gescheitert, weil der Raspi kein Echtzeitverhalten zeigt.
Der Datenstrom ist zu ungenau, weil Unterbrechungen und das Multitasking rein pfuschen.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 ...
-
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.
-
Hab die Diskussion über die Verfügbarkeit von Retro Hardware mal abgespalten
-
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.
-
Dann wirds wohl doch die Logik auf dem Modul sein. Wie sie funktioniert ist in diesem Patent beschrieben:
http://www.google.com/patents/EP0116455A2?hl=de&cl=en
Evtl. kannst Du ja daran sehen welcher chip was ist. Die kleinen Kondensatoren entstören natürlich auch den Chip, also wenn die defekt sind ist das auch nicht gut.
-
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.
-
das sind 3.5" Disks.....
und da es 135TPI (Tracks per Inch) sind es eindeutig HD Disketten:
http://www.athana.com/html/diskette.htmlIch dachte erst es sei eine 5.25" Packung, aber DDs haben da 48 TPI und HD 96 TPI
Ich dachte 135 TPI heisst nur dass es 3.5'' Disketten sind. Ob es jetzt HD oder DD sind, sieht man das auch am TPI ? Auf der Seite die Du verlinkt hast gibt es auch 135TPI DD Disketten ..
-
Auf Wunsch EF2 Diskussion ausgelagert
-
Albert ist wer?
Albert Yarusso, der Betreiber von AtariAge.com ... -
Willkommen im Forum64
-
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.
-
Ich kann Dich schon verstehen, aber wenn es nicht um neue Dinge gehen soll, dann bitte in einem anderen Thread, nicht in diesem hier.