1541-Emul (zweiter Anlauf)


  • Diddl
  • 28696 Aufrufe 147 Antworten

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

  • 1541-Emul (zweiter Anlauf)

    Mein erster Versuch mit Atmega1284 ist fehlgeschlagen, vom hoffnungsvollen Open1541 Projekt hört man leider auch nix mehr. Das Thema läßt mich irgenwie nicht los, deshalb habe ich einen neuen Anlauf gestartet, mit einem Cortex M4 (Discovery Board).

    Ich denke jetzt, dass es machbar ist mit dem Discory Board. Und ich werde das Projekt voran treiben. Zur Zeit entwickle ich die Software aber am PC und portiere das ganze später zum Discovery. Am PC lässt es sich einfach wesentlich komfortabler arbeiten.

    Man wird sowohl das 1541 DOS als auch das aktuelle Image File ganz einfach wechseln können. Neben dem standard 1541 DOS wird Speed-DOS und evt. Proffessional DOS unterstützt werden. Natürlich sollen alle seriellen Protokolle funktionieren, wie Jiffy DOS und auch alle Exoten die fix in diversen Spiele und Demos implementiert sind.

    Das Imagefile Format ist etwas, das mich noch beschäftigt. Natürlich wird D64 unterstützt, aber das ist ja das ungünstigste Format überhaupt. Speziell für einen 1541 Emulator, der die GCR Daten liest und daher am liebsten pure GCR Daten aus einem Imagefile bekommen würde.

    Was wäre denn für ein bestehenden Imageformat zu empfehlen? Ich möchte ungern ein neues Format in Umlauf bringen, obwohl mir der Gedanke durchaus schon gekommen ist. Einfach ein plain 1541 GCR Format, je nach Spur mit maximalen Anzahl an GCR Daten die vorkommen kann plus etwas Reserve. Was meint ihr?
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • jackdaniels schrieb:

    wobei eine native unterstützung von d64 schon top wäre!

    Die native Unterstützung gibt es bereits. Die Umwandlung erfolgt "on the fly".

    Das ist gar nicht das Problem. Will man hingegen Kopien von originalen Disketten abspielen, muss man halt erst ein Imagefile haben. Ein D64 versagt in der regel schon bei einfachen Schutzmethoden kläglich.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • das weiß ich. mir gings grade nur drum, daß man sowohl ein neues format als auch d64 zusammen nutzen sollte.
    einfach weils praktisch ist. ich würde sagen die meisten games (mehr interessiert mich persönlich nicht) sind auch als d64 lauffähig.
    für die "speziellen" sachen mit kopierschutz wäre dann eine konvertierung am pc gut und nicht übermäßig viel arbeit wie ich finde.

    für 95% der nutzer würde das neue format also keine rolle spielen (persönliche meinung), für alles andere gibt es trotzdem eine bequeme und nicht zu aufwändige methode es zu nutzen.

    die 1541u spielt bei mir nur d64 ab, was anderes habe ich noch nie gebraucht :D

    (wie gesagt ich rede nur von mir und meiner meinung!)
  • Ein möglicher Schwachpunkt des G64 ist, dass es nur eine Speedzone für den ganzen Track gibt: ($015C-015F: Speed zone entry for track 1)

    Wenn jemand mehr als eine Speedzone auf einem Track verwenden würde, könnte man das nicht darstellen ...


    Aber gut, nothing is perfect.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    Ein möglicher Schwachpunkt des G64 ist, dass es nur eine Speedzone für den ganzen Track gibt: ($015C-015F: Speed zone entry for track 1)

    Wenn jemand mehr als eine Speedzone auf einem Track verwenden würde, könnte man das nicht darstellen ...

    Du hast die Specs nicht vollständig gelesen. ;)

    Tatsächliche Schwäche ist meines Wissens, dass alles auf GCR-codierte Bytes ausgerichtet ist - d.h. ein Track kann nur ein Vielfaches von 8 Byte enthalten und die Bitrate ist auch nur Byteweise angebbar.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Unseen schrieb:

    d.h. ein Track kann nur ein Vielfaches von 8 Byte enthalten und die Bitrate ist auch nur Byteweise angebbar.

    Aha interessant. Aber ist das bei einer 1541 überhaupt relevant?

    Die Bitrate lässt sich bei einer 1541 ja sowieso nur mit 2 Bit (4 Bitraten) einstellen.

    Ein Vielfaches von 8 Byte oder 8 Bit? Eine 1541 kann ja Folgen von Syncs nicht wirklich trennen, insofern kann man die Tracklänge ja beliebig "faken"?


    Ich sag mal so, G64 wird in den allermeisten Fällen sehr gut reichen.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Diddl schrieb:

    Aber ist das bei einer 1541 überhaupt relevant?

    Die Bitrate lässt sich bei einer 1541 ja sowieso nur mit 2 Bit (4 Bitraten) einstellen.

    Ich bin mir nicht sicher ob man das nicht noch "indirekt" ausrechnen kann, aber es könnte evtl. für Short/Long Tracks interessant sein. Erzeugen lassen sich die auf einer 1541 indem man an der Motorgeschwindigkeit dreht, die kommerziellen Kopiermaschinen konnten das dann problemlos vom Master replizieren.

    Ein Vielfaches von 8 Byte oder 8 Bit? Eine 1541 kann ja Folgen von Syncs nicht wirklich trennen, insofern kann man die Tracklänge ja beliebig "faken"?

    Man kann die Länge der Syncs mittels Timer ausmessen, manche Kopierschutzmechanismen machen das wohl. Ob die "Ungenauigkeit" von G64 da ein Problem ist oder nicht müsste jemand beantworten, der sich mit sowas besser auskennt.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Es geht nur langsam weiter, wegen Zeitmangel. Die Emulation der 1541 am PC läuft jetzt mal rund. Es läuft jetzt die 6502 Emulation, die beiden VIA inklusive Timer und IEC Bus Hardware.

    Damit ich es testen kann, habe ich einen kleinen Monitor implementiert. Neben single step, disassemblieren, memory dump kann der Monitor auch DOS Kommandos senden und Status abfragen. Die IEC Routinen dafür stammen direkt aus dem XS-1541 Code.

    Die virtuelle 1541 spricht mit mir ...




    Muss ich mir jetzt Sorgen machen um meinen PC? Er wirkt so schizophren: :gruebel
    • ein Teil des PC glaubt er ist eine 1541
    • der andere Teil glaubt ein XS-1541 zu sein
    • die beiden Teile sprechen miteinander mittels einem uralten 8 Bit Protokoll in urlangsamer Geschwindigkeit von 400 Byte pro Sekunde ...
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Sektor lesen und schreiben geht nun tadellos, Aber das Kommando zum Formatieren einer Diskette (N0:xxx,ii) erweist sich als echter Prüfstein für die Emulation ...

    Eigentlich dachte ich, dass ich die 1541 schon vorher ziemlich gut gekannt habe. Doch man kann/muss immer dazu lernen, man kann immer noch tiefer ins Detail gehen. An der Stelle möchte ich mich bedanken bei den Erstellern der Doku "All avbout your 1541", ohne dieser Seite könnte ich das Emulator Vorhaben vermutlich nicht weiter führen.

    Jedenfalls eignet sich der PC Emulator hervorragend zur Analyse. Ich werde ihn auch nach dem Projekt behalten und weiter entwickeln. Denn er ist auch nützlich für die Analyse von beliebigem anderen Floppy Code: Dolphin DOS, Prologic DOS, Professional DOS, Speeder ...
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • und das sogar wenn die rotationsgeschwindigkeit total falsch ist, ja.... wobei die sektoren nie vollkommen gleichmässig verteilt werden, es gibt am ende eine relativ grosse lücke (verglichen mit den andren)
  • sauhund schrieb:

    wobei die sektoren nie vollkommen gleichmässig verteilt werden, es gibt am ende eine relativ grosse lücke (verglichen mit den andren)

    Aha, dann ist es ja ok so.

    Ich dachte eigentlich, genau DAS sollte verhindert werden mit der komplizierten herumrechnerei, die Commodore da fabriziert. Ich hätte da einfach einmalig pro Bitrate die Anzahl Bytes für eine Umdrehung gemessen, dann die Restbytes errechnet und durch die Anzahl Sektoren +1 dividiert. Dabei tut der da seltsame Dinge, mal zwei, wieder ausprobieren ... eher ne empirische Ermittelung.
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Am PC läuft es jetzt ziemlich sauber. Reiner C Code (Pelles C). Es sind noch einige Tests zu machen, um die Dinge noch zu optimieren.

    Allerdings geht zur Zeit nur D64 und auch da kein zurückschreiben. Ich lese D64 in ein internes Format, wo lesen und schreiben ziemlich perfekt läuft. Diese Datei ist quasi das Abbild der aktuell eingelegten Diskette. Solange ich kein neues Disk Image mounte, arbeitet der Emulator mit dieser Datei direkt.

    Da ich D64 in ein internes GCR Format wandle, ist G64 sehr leicht unterstützbar. Offen ist also
    • D64 zurückschreiben
    • G64 lesen
    • G64 zurückschreiben
    • so kleiner Dinge wie Schreibschutz (wegen Diskettenwechsel)


    Diese Dinge werde ich aber zur Zeit nicht implementieren. Zuerst wird es auf die Zielplattform portiert. Das ist der nächste große Milestone.


    Allerdings beschäftigt mich noch das "exakte GCR Timing". Exaktes Timing ist implementiert, aber leider auch etwas CPU lastig. Ich beschäftige mich mit Optimierungen, die den Ablauf nicht negativ beeinflussen. Es wird aber darauf hinaus laufen, dass man den 6502-Emul einstellen kann, wie exakt die Emulation gemacht wird. Je nach dem ist es Zyklusgenau (aber langsam) oder eben ungeanau (dafür viel schneller).


    Die Timeline ist also:
    • Code Cleaning und Optimierung
    • Umsetzung auf die Zielplattform STM32F407
    • STM32F407 Adapter auf arm2iec anfertigen
    • testen, testen, testen ...
    • bugfix, bugfix, bugfix ...
    • restliche Dinge wie G64, Sonderbefehle (@CD, @MD, @RD, @LR, @LK, @OPT, @...)
    • Evaluierung LPC1768/1769, damit das arm2iec direkt unterstützt wird
    • Verbesserungen: andere Kernel (Jiffy, Speed-DOS, Dolphin, Prof-DOS), Sonderlösungen (eigene Kernelverbesserungen ...)
    Letztlich ist alles nur Illusion
    Es gibt hier nichts von Bedeutung
  • Ich dachte eigentlich, genau DAS sollte verhindert werden mit der komplizierten herumrechnerei, die Commodore da fabriziert

    jein. die sektoren werden schon "gleichmässig" über die umdrehung verteilt - allerdings will man aus verschiedenen gründen das die "tailgap", die grosse lücke am track ende bzw anfang ein bischen grösser ist als die anderen.