1541 Ultimate II mit Parallelkabel

Genauso... hauptsache er macht es

Wer patcht denn das?

Ich frage gerade intern mal rund wer es machen mag.

Verstehe ich nicht - wieso muss da was im ROM gepatcht werden? Das Teil emuliert doch die Floppy komplett? Wenn ich Speeddos oder Dolphindos auf der U2+ als alternatives Floppyrom installiere, läuft das doch schon? Nur halt ohne Speed, weil das Parallelkabel "fehlt".

Auf dem Ultimate rennt das richtig gut, aber da gibt es auch die Möglichkeit, ein Parallelkabel zu emulieren.

Aber wo wird normalerweise das Parallelkabel am C64 angeschlossen?

Ja richtig, am Userport und wo hat nun die 1541 Ultimate II eine Verbindung zum Userport?

Ja richtig, die gibt es nicht, daher muss das "C64" Rom gepatched werden, um z.B. die Signale auf den Expansions-Port "umzubiegen".

So hab ich das zumindest verstanden.

Danke für die nette Erklärung. Ich hatte es so verstanden, dass das Rom für die Floppy gepatched werden soll. Hatte nicht einer weiter oben geschrieben, dass die Userport-Signale auch am Expansionsport anliegen? So hatte ich das verstanden und das würde ein Patchen unnötig machen.

Zitat von Kosmas

Hatte nicht einer weiter oben geschrieben, dass die Userport-Signale auch am Expansionsport anliegen?

FALLS das jemand geschrieben haben solle war das definitiv FALSCH !

Das hätte mich auch gewundert, habe aber noch keine Zeit gefunden, im Schaltplan zu schauen. Ich glaube aber nicht, dass es möglich ist, das Speeddos im C64 so zu patchen, dass die Signale über den Expansionsport geleitet werden können. Immerhin sind am Userport die CIA-Anschlüsse herausgeführt, und die sind für das Parallelkabel zuständig. Das U2 müsste dann eine Verbindung zum Userport bekommen, und das ist so sicher nicht vorgesehen.

Am Userport werden die Signale vom CIA U2 benutzt, die liegen am Expansionsport nicht an. Am letzteren gibt es gar keine Leitungen, die als I/O vorgesehen und benutzt werden können, oder?

Das U2 emuliert die Floppy doch vollständig, sodass es theoretisch möglich wäre, die notwendigen Ports des entsprechenden 6522 VIA auf (möglicherweise noch freie) Pins zu legen, damit man diese mit dem Userport verbinden kann. Das ist aber ins blaue hinein gedacht, weil ich die Technik hinter dem U2+ nicht kenne.

Es wird wohl genau so laufen wie bei den anderen Parallel-Speedern (Professional DOS, Prologic Dos, Turbo Trans ...), die auch auf dem Expansionport laufen und unterschiedliche Kernal fuer User- oder Expansionport haben.

Ein "externer" 6522 wird benutzt fuer die parallele Uebertragung und der wird im U2+ nachgebildet. Dafuer wird dann das SpeedDos ROM entsprechend gepatched.

Zitat von BananaJoe

Ich könnte damit leben, wenn meine Speeddos Floppy sich den Userport mit einem Adapter (ähnlich dem Tape Stecker) der von der 1541u kommt teilt.

Und wo sollten dafuer auf einmal die notwendigen Anschluesse auf dem U2+ herkommen? Oder sollen die Benutzer den Loetkolben schwingen und ein entsprechendes Interface auf der U2+ nachruesten? Das istwohl eher unrealistisch. Von einer externen Variante kannst Du dich denke ich verabschieden, das wurde aber bereits Oben am Anfang von MarkusC64 geschrieben.

Du meinst, der externe 6522 würde dann über den Expansionsport gesteuert? Und statt dem bisher verwendeten 6526 wird im C64 dieser 6522 benutzt, der dann im U2+ drinsitzt bzw. als FPGA nachgebildet wird? Dass würde tatsächlich einiges an Patches benötigen. Die U2+ könnte aber auch einen 6526 nachbilden, dann ist der Aufwand vielleicht nicht so groß.

Alternativ könnte das U2+ die Leitungen des in der Floppy verwendeten 6522 nach außen legen, wenn noch Pins frei wären. In einer zukünftigen Version könnte man dann ein paralleles Kabel zusätzlich anschließen. Dann müsste man auch keine ROMs patchen.

Im Ultimate 64 ist alles zum Glück sehr einfach: ROMs laden, Parallelkabel einschalten und es funktioniert.

Falls wir Gideons Andeutungen nicht missverstanden haben, will er einen Zwischenweg gehen: Vom VIA bzw. CIA nur genau die Anteile nachbauen, die die verwendeten Protokolle benutzen.

Mutmaßliche Idee dahinter: Den benötigten FPGA-Platz dadurch kleinhalten. Und nur wenige Bytes im I/O brauchen, die man idealerweise hinter dem REU-I/O-Bereich findet, so dass möglichst viel parallel laufen kann - sprich: Nur die verwendeten Adressen unterstützen und die dichter zusammen als im Original. Bisher haben wir aber nur Andeutungen, die IMO in diese Richtung gehen.

Edit: Falls wer mitliest, der sich recht gut mit dem C64 auf Assemblerebene auskennt: Ich suche jemanden, der ein Dolphin-DOS-Quelltext des C64 Kernals kommentieren könnte... Bei Bedarf gibt es das Ersuchen noch in einer thematisch besseren Ecke - hier sei es nur erwähnt, weil es gerade zum Thema passt.

Thanks. That should help Gideon.

I resp. we altready have source code for dolphin dos rom. Just comments are missing in the parts that differ from commodore's unpatched kernal. The goal is to make it understanable. Source code of teh rom makes patching more easy. And the assembler can generate a rom listing from that - giving better cvontext than vice monitor does.

Ok, von den englischen Postings poste ich hier die maschinelle Übersetzung - und damit bitte zurück zum Thema:

Ok, from the English postings I am posting the machine translation - and please go back to the topic:

Zitat von FeralChild

Better yet, it would be nice to have the reverse-engineered documentation of these protocols.

I've started work on DolphinDOS support in Open ROMs, but got distracted by some serious problem needing urgent fix. What I know so far:

- looking at the UserPort connections, protocol uses $DD01 (CIA2 PRB - most likely for data) and $DD0D (CIA2 ICR - most likely for handshake), enabling watches on these ports using VICE monitor confirmed that they are used; for now my experiments to detect the protocol using the ICR register alone failed (but these were quick & dummy attempts) - I don't fully understand how SD2IEC does this yet

- protocol is probably timing tolerant (contrary to JiffyDOS) - VICE monitor watches revealed that it doesn't touch the VIC-II RASTER/SPENA registers ($D012/$D015), so neither badlines nor the sprites should hurt the data transfer; if I understand the SD2IEC code correctly, data synchronization/acknowledgement is done solely using the UserPort lines

- most likely the protocol is extremly simple and the GCR decoding is done fully within the drive (again, SD2IEC source code)

Alles anzeigen

Besser noch, es wäre schön, die Reverse-Engineered-Dokumentation dieser Protokolle zu haben.

Ich habe mit der Arbeit an der DolphinDOS-Unterstützung in Open ROMs begonnen, wurde aber durch ein ernsthaftes Problem abgelenkt, das dringend behoben werden muss. Was ich bisher weiß:

- Wenn ich mir die UserPort-Verbindungen ansehe, verwendet das Protokoll $DD01 (CIA2 PRB - höchstwahrscheinlich für Daten) und $DD0D (CIA2 ICR - höchstwahrscheinlich für Handshake), wodurch Uhren an diesen Ports mit dem VICE-Monitor bestätigt werden, dass sie verwendet werden; im Moment sind meine Experimente zur Erkennung des Protokolls mit dem ICR-Register allein fehlgeschlagen (aber das waren schnelle & Dummiversuche) - ich verstehe nicht ganz, wie SD2IEC das noch macht.

- Das Protokoll ist wahrscheinlich zeittolerant (im Gegensatz zu JiffyDOS) - VICE-Monitoruhren haben ergeben, dass es die VIC-II RASTER/SPENA-Register ($D012/$D015) nicht berührt, so dass weder Badlines noch die Sprites den Datentransfer beeinträchtigen sollten; wenn ich den SD2IEC-Code richtig verstehe, erfolgt die Datensynchronisation/Quittierung ausschließlich über die UserPort-Linien.

- höchstwahrscheinlich ist das Protokoll extrem einfach und die GCR-Dekodierung erfolgt vollständig innerhalb des Laufwerks (wiederum SD2IEC-Quellcode).

Übersetzt mit http://www.DeepL.com/Translator (kostenlose Version)

Zitat von markusC64

Thanks. That should help Gideon.

I resp. we altready have source code for dolphin dos rom. Just comments are missing in the parts that differ from commodore's unpatched kernal. The goal is to make it understanable. Source code of teh rom makes patching more easy. And the assembler can generate a rom listing from that - giving better cvontext than vice monitor does.

Danke. Das sollte Gideon helfen.

Ich bzw. wir haben bereits Quellcode für Dolphin dos rom. Nur Kommentare fehlen in den Teilen, die sich von Commodores ungepatchtem Kernal unterscheiden. Ziel ist es, es verständlich zu machen. Der Quellcode des Rom macht das Patchen einfacher. Und der Assembler kann daraus ein Rom-Listing generieren - mit einem besseren Cvontext als der Vice Monitor.

Zitat von FeralChild

Yes, but for legal reasons we don't want to look into the disassembly - that's why I only used VICE monitor to check whether the watch on the register will be triggered during disc operations, or not. I will probably modify VICE code to log the values sent/read, just like IEC logs.

Ja, aber aus rechtlichen Gründen wollen wir uns nicht mit der Demontage befassen - deshalb habe ich nur mit dem VICE-Monitor überprüft, ob die Uhr im Register während des Diskettenbetriebs ausgelöst wird oder nicht. Ich werde wahrscheinlich den VICE-Code ändern, um die gesendeten/gelesenen Werte zu protokollieren, genau wie die IEC-Protokolle.

So, ich habe das ganze Offtopic hier jetzt entfernt! Macht bitte den Thread nicht mit solch unnoetiger Diskutiererei kaputt!

Was sollen Gaeste, die etwas Wesentliches zu diesem Thema beitragen, ueber so ein Verhalten denken?