Hier bitte Wünsche an die 1541-Emul Firmware einbringen und diskutieren. Bitte keine Bugs einmelden, dazu dient der 1541-Emul Betatest Beitrag.
Todo's aus der Wunschliste:
- -
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Ace am
Hier bitte Wünsche an die 1541-Emul Firmware einbringen und diskutieren. Bitte keine Bugs einmelden, dazu dient der 1541-Emul Betatest Beitrag.
Todo's aus der Wunschliste:
Todo's aus der Wunschliste:
1. Direkter Zugriff auf der SD Karte unter Basic mittels Jiffidos Kurzkommandos (wie bei der 1541 Ultimate)
Direkter Zugriff auf der SD Karte unter Basic mittels Jiffidos Kurzkommandos (wie bei der 1541 Ultimate)
Kannst du das etwas näher spezifizieren?
Jiffy Kurzkommandos? Damit meinst du einfach @9 oder?
Direkter Zugriff? Du meinst Datei erstellen, löschen, lesen schreiben? Ist so vorgesehen. Gerät #9 ist die SD Karte direkt und #8 ist das "eingelegte" Disketten Image.
Kannst du das etwas näher spezifizieren?
Jiffy Kurzkommandos? Damit meinst du einfach @9 oder?
Direkter Zugriff? Du meinst Datei erstellen, löschen, lesen schreiben? Ist so vorgesehen. Gerät #9 ist die SD Karte direkt und #8 ist das "eingelegte" Disketten Image.
Bei der 1541U gab es zu Anfang die Möglichkeit, im Basic Modus direkt auf die SD Karte zuzugreifen und sich zu bewegen, also ohne Browser. Die dort abgeladenen D64 Images uind andere Dateien konnte man so problemlos betrachten und die Images konnte man dann direkt mit dem Kurzkommande @ Befehl mouten. PRG Dateien liessen sich direkt starten. Also quasie kompletter SD Speicherplatznutzung im Basic wie eine grosse Festplatte halt.
Bei der 1541U gab es zu Anfang die Möglichkeit, im Basic Modus direkt auf die SD Karte zuzugreifen und sich zu bewegen, also ohne Browser.
Du meinst so wie im SD2IEC?
Der "perfekte EMU Ansatz" lässt sowas eigentlich nicht zu. Wenn du der Emulation (sagen wir auf device #8) etwas auf Kanal 15 sendest, dann bekommt das nur der virtuelle 6502 mit. Wenn man da zusätzliche Befehle wie "CD" oder so hinzufügen würde, dann wäre die Emulation nicht mehr "perfekt".
Das ist der Grund, warum man bei der U2 auch auf ein zweites IEC device ausgewichen ist. ich finde die Idee genial.
Und man kann trotzdem uneingeschränkt auf die SD zugreifen, halt nur auf device #9.
Du meinst, auf Device 9 wäre das möglich ? Auch gut
32 KB Rom Support für ggf. S-JIFFY?
Der "perfekte EMU Ansatz" lässt sowas eigentlich nicht zu. Wenn du der Emulation (sagen wir auf device #8) etwas auf Kanal 15 sendest, dann bekommt das nur der virtuelle 6502 mit. Wenn man da zusätzliche Befehle wie "CD" oder so hinzufügen würde, dann wäre die Emulation nicht mehr "perfekt".
Das ist der Grund, warum man bei der U2 auch auf ein zweites IEC device ausgewichen ist. ich finde die Idee genial.
Und man kann trotzdem uneingeschränkt auf die SD zugreifen, halt nur auf device #9.
Sowas sollte nur ggf. abschaltbar sein (am besten auf Knopfdruck), sonst hat man ggf. Probs mit 3-bit Fastloadern.
Sowas sollte nur ggf. abschaltbar sein (am besten auf Knopfdruck), sonst hat man ggf. Probs mit 3-bit Fastloadern.
Ja gute Idee, abschaltbar und freie Wahl der Gerätenummer.
Klasse Sache. Mein Wunsch: So 'ne Art "Virtual Device Traps" auf Floppy-Seite für ausgewählte Fastloader (Jiffy, FC3, AR, GEOS oder so). Also dass der ARM dann "nativ" an bestimmten Stellen übernimmt und optimiert die jeweiligen Aktionen ausführt, statt das alles 100%ig zu emulieren. Hintergrund: Dadurch wird das Ganze massiv schneller. Jiffy mit einer echten 1541 schafft etwa 2,5kB/Sek, das reimplementierte Jiffy des sd2iec schafft fast 9kB/Sek.
Nebenbei: Mit Traps könnte man auch weitere Funktionalität wie zusätzliche DOS-Befehle implementieren, ohne das ROM ändern zu müssen => bessere Kompatiblität.
Mein Wunsch: So 'ne Art "Virtual Device Traps" auf Floppy-Seite für ausgewählte Fastloader (Jiffy, FC3, AR, GEOS oder so). Also dass der ARM dann "nativ" an bestimmten Stellen übernimmt und optimiert die jeweiligen Aktionen ausführt, statt das alles 100%ig zu emulieren. Hintergrund: Dadurch wird das Ganze massiv schneller. Jiffy mit einer echten 1541 schafft etwa 2,5kB/Sek, das reimplementierte Jiffy des sd2iec schafft fast 9kB/Sek.
An sowas habe ich auch schon gedacht. Allerdings nur in Form zusätzlicher, virtueller Hardware:
All diese Dinge würden aber eine Änderung des DOS benötigen. Also zusätzlichen 6502 Code. Die zusätzlichen IO's werde ich bereitstellen, es braucht nur noch Freiwillige 6502 Coder ...
Nebenbei: Mit Traps könnte man auch weitere Funktionalität wie zusätzliche DOS-Befehle implementieren, ohne das ROM ändern zu müssen => bessere Kompatiblität.
Wenn du mit Traps irgendwelchen ARM Code meinst, dann wird es sehr schwierig.
Über dieses Thema habe ich lange nachgedacht. Es wäre ganz easy eine Art Breakpoint zu machen, wenn die virtuelle CPU eine bestimmte Adresse fetcht passiert irgendwas. Das wäre aber ein totaler Konzeptbruch, weil es bedingen würde, dass der Code im DOS für Befehlsauswertung auf $C146 liegt.
Das Ziel ist aber klar: es verhält sich exakt wie eine 1541, egal was für ein DOS drin ist. Jeder selbstgeschriebene 16K Code funktioniert im 1541-Emul, ganz genau gleich wie in einer echten 1541.
Zusätzliche IO oder Hardware ist ok, es muss nur kompatibel bleiben.
Bei VICE ist das so gemacht, dass die Traps das CRC des ROM überprüfen. Ist es ein unbekanntes ROM, werden die Traps deaktiviert (AFAIR).
Wobei ich es auch "Fehler des Benutzers" nennen würde, ein Nicht-Standard-ROM reinzufrickeln UND die Traps anzulassen. Also auf jeden Fall lässt sich das ziemlich kompatibel basteln.
Sowas wie zusätzliche virtuelle Hardware würde ich nicht machen, das vereinigt nur die Probleme der verschiedenen Welten nach meiner Einschätzung (6502-Code nötig, inkompatibel, und doch bei Weitem nicht so schnell wie es möglich wäre).
Was auch ganz nett wäre: Zoomfloppy Funktionalität inkl. über USB ? zum PC. Dann kann man sich das Zoomfloppy und die anderen Kabelsorten sparen.
Wie schaut es denn aus, dort ein schönes grosses Display daran zu betreiben ?
Sowas wie zusätzliche virtuelle Hardware würde ich nicht machen, das vereinigt nur die Probleme der verschiedenen Welten nach meiner Einschätzung (6502-Code nötig, inkompatibel, und doch bei Weitem nicht so schnell wie es möglich wäre).
Hier ist die Sache anders wie beim VICE.
Der 1541-Emul läuft an einem echten C64. Da hat man immer das Nadelöhr IEC Bus. Daher ist die virtuelle CPU mit einem MHz niemals zu langsam. Speziell dann nicht, wenn virtuelle Hardware das alles unterstützt. man kann sowieso nie schneller übertragen, als der C64 empfangen kann.
Außerdem wird das 1541-Emul im Endausbau Professional DOS können. Mit 202 Blöcken in 3 Sekunden kann man dann nicht über Speed jammern ...
Och ich hatte mal gerechnet, so etwa 20kB/Sek bekommt man auch über Serielle theoretisch hin, und die 202 Blöcke in drei Sekunden haben wir beim sd2iec in einem Wochenendexperiment mit einem angepassten speziellen Speeder auch schon in der Praxis über die Serielle geschafft.
Aber mir geht's hier auch gar nicht um Serielle vs. Parallele, sondern um höhere Geschwindigkeit mit dem FC3, mit Jiffy und unter GEOS. Das erreicht man mit virtuellen Hardware-Erweiterungen halt nicht. Oder man muss nachher noch angepasste FC3-ROMs etc. bauen. Brr.
Oh, und natürlich helfen solche Traps auch bei parallelen Speedern weiter. Wieviel schafft eine parallele Empfangsroutine auf dem C64 maximal? Timingbasiert sollte ein Byte pro 10 Takte, also 100kB/Sek möglich sein, oder? Da ist also auch bei den bestehenden Speedern noch einiges an Luft drin.
Och ich hatte mal gerechnet, so etwa 20kB/Sek bekommt man auch über Serielle theoretisch hin, und die 202 Blöcke in drei Sekunden haben wir beim sd2iec in einem Wochenendexperiment mit einem angepassten speziellen Speeder auch schon in der Praxis über die Serielle geschafft.
Aber mir geht's hier auch gar nicht um Serielle vs. Parallele, sondern um höhere Geschwindigkeit mit dem FC3, mit Jiffy und unter GEOS. Das erreicht man mit virtuellen Hardware-Erweiterungen halt nicht. Oder man muss nachher noch angepasste FC3-ROMs etc. bauen. Brr.
Oh, und natürlich helfen solche Traps auch bei parallelen Speedern weiter. Wieviel schafft eine parallele Empfangsroutine auf dem C64 maximal? Timingbasiert sollte ein Byte pro 10 Takte, also 100kB/Sek möglich sein, oder? Da ist also auch bei den bestehenden Speedern noch einiges an Luft drin.
Schauen wir mal, jetzt muss das Emul-1541 erst mal zum fliegen kommen ...
An dieser Stelle hätte ich noch ne Fragen:
Wenn sich das 1541 Projekt bewerkstelligen lässt, dann sollte doch auch ein 1581 Clone realisieren lassen oder ?
Wenn sich das 1541 Projekt bewerkstelligen lässt, dann sollte doch auch ein 1581 Clone realisieren lassen oder ?
Läuft mit 2MHz und Burst, könnte knapp gehen aus jetziger Sicht.
Nur ist die Emulation einer 1581 witzlos:
- man kann das 3 1/2" Laufwerk ersetzen durch einen Floppy Emu
Ok, wenn sich das D81 Format umsetzen lässt, dann ist ne Hardwareemu in der Tat witzlos.
Eine D81 Umsetzung ist auch fraglich. Nur so in der Form wie es im SD2IEC läuft. Ein 1541 DOS, auch kein emuliertes DOS, kann mit D81 umgehen.
Aber auf #9 (Emu IEC Umgebung) ist natürlich alles anders.