Angepinnt 1541-Emul - Wunschliste


  • Diddl
  • 4088 Aufrufe 39 Antworten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Ace schrieb:

    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.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    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.
  • Ace schrieb:

    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.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • 32 KB Rom Support für ggf. S-JIFFY?

    Diddl schrieb:


    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.
  • 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.
  • 1570 schrieb:

    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:
    • zusätzliches RAM geht sowieso. 1541 Emul kann überall RAM einblenden.
    • GCR Unterstützung: im ARM habe ich sowieso schon GCR encoder/decoder drin. Ein virtuelles IO wo man 5 Bytes rein stellt und 4 raus liest, geistert mir im Kopfe rum (auch umverkehrt natürlich)
    • denkbar wäre auch ein virtueller DMA Chip: man sagt nur welche Sektoren man haben will und bekommt die in beliebige Buffer geschrieben.


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


    1570 schrieb:

    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.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • 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).
  • 1570 schrieb:

    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 ... ;)
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • 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. :)
  • 1570 schrieb:

    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 ... :)
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Ace schrieb:

    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:
    • das Laufwerk ist von Natur aus schnell.
    • man kann das 3 1/2" Laufwerk ersetzen durch einen Floppy Emu
    • es gibt kaum problematische Software für dieses Laufwerk
    • es gibt keinen Kopierschutz für das Laufwerk
    • es gibt keine Software für den C64 der eine 1581 erfordern würde
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung