Hello, Guest the thread was called111k times and contains 1935 replays

last post from angryking at the

Denise 1.0.x Emulator

  • Ich suche noch die Firmware für ProDOS 1571 (ist wohl PrologicDOS für 1571)

    Es heißt Prospeed 1571.


    neues nightly:


    - DolphinDos v2 Ultimate, DolphinDos v3 (1541, 1571), PrologicDos, PrologicDos Classic

    - Expansionsport Variante für ProfDOS, PrologicDOS


    Zum Anschluss an den Expansionsport steht eine neue Rubrik Schnelllader zur Verfügung. Nun gibt es mehrere Möglichkeiten. Wichtig ist, dass der Userport Kernal und der Expansionsport Kernal verschieden sind.

    • Easyflash³
    • Kernal im C64 tauschen (unter Firmware an gewohnter Stelle)
    • Kernal in die Expansion einsetzen (unter Software/Steckmodule/Schnelllader)
      • Jumper 'Kernal Ersatz' übergeht damit den C64 Kernal. Zudem wird das Hiram Kabel simuliert.
      • damals musste für ein echtes Kernal Replacement noch ein extra Kabel aus dem C64 zur Expansion geführt werden. Erst EF³ kommt ohne dieses Kabel aus.


    ProfDOS R1-R4: R3 ist die Expansion Variante.


    PRG (165 Blocks)

    Normal: ca 1:47 min

    JiffyDOS: ca 18.5 Sek

    SpeedDOS: ca 13.9 Sek

    ProfDOS v1: ca 5.4 Sek (1 Mhz)

    ProfDOS v1: ca 4.8 Sek (@D1: Speed variiert, durch Hardware vorgegeben)

    ProfDOS v1: ca 4.7 Sek (2 Mhz)

    Prologic classic: ca 4.5 Sek (PIA)

    Prologic original: ca. 4.4 Sek (VIA)

    DolphinDOS v2: ca 4.4 Sek

    DolphinDOS v3: ca 4.4 Sek

    ProfDOS R4: ca 3.4 Sek (@D1: Speed variiert, durch Hardware vorgegeben)

    ProfDOS R4: ca 3.2 Sek (1 Mhz, hält sich aber nicht dauerhaft dran und wechselt ab und an in den 2Mhz Modus per Firmware (nicht wie @D1 durch die Hardware bei Zugriff bestimmter Adressen) )

    ProfDOS R4: ca 3.2 Sek (2 Mhz)

    - 1571

    DolphinDOS v3: ca 4.4 Sek

    ProfDOS R6: ca 3.5 Sek

    Burst Mode: ca 19.8 Sek


    ProfDOS bleibt der Gewinner. Neben dem 2 MHz Betrieb wird ein kleiner Teil der Dekodier Logik in Hardware ausgelagert. Das liefert den entscheidenden Vorteil.

    PrologicDOS setzt für die 1541, ebenso wie ProfDOS, auf 2Mhz. DolphinDOS tut dies nicht, außer v3 für die 1571 natürlich. Diese verwendet es auch im 1541 Emulations Modus, was leider die Kompatibilität verringert.

    PrologicDOS classic verwendet, wie DolphinDOS v3, einen PIA Chip. PrologicDOS original erledigt das mittels dem bereits vorhandenen VIA.

    Die Expansion Variante von PrologicDOS verwendet einen 2. PIA und die Expansion Variante von ProfDOS einen zusätzlichen VIA.


    Weiß jemand, ob es von DolphinDOS eine Expansion Variante gibt? Ich konnte nirgends einen Hinweis darauf finden.

    Ich packe mal alle Firmware images in einem Zip zusammen.

  • Was ich noch interessant finde, sind zwei Funktionen die der schon etwas ältere CCS64 Emulator hat ...

    ...

    Und dann noch die Art, wie man im CCS64 Videos des Emulationsbildes aufzeichnen kann, also etwa ein Spiel von sich aufnehmen kann. Das sind dort keine echten Videos...

    ...

    Die entstehenden Aufzeichnungsfiles sind winzig im Vergleich zu Files in echten Videoformaten.


    Eben bemerkt, dass ich das total falsch in Erinnerung hatte und dass es gar nicht der CCS64 Emulator ist, der das in dieser Form kann (der speichert nämlich ebenfalls in einem Videoformat ab), sondern der ZSNES Super-NES Emulator. Hatte das Feature schon jahrelang nicht mehr genutzt und mich hier total vertan.


    Also der ZSNES kann in einem speziellen Format (zmv) abpeichern, welches total klein ist und 100% Bildqualität bietet beim wiederanschauen. Jedoch kann die Aufzeichnung dann auch nur im ZSNES wiedergegeben werden. Nun ist dieser Emulator in Sachen Emulationsgenauigkeit zwar schon länger nicht mehr auf Höhe der Zeit, aber die Aufzeichnungsfunktion



    in diesem Emulator ist wirklich eine feine Sache, vor allem für Longplays, da eben die entstehenden Files viel viel kleiner sind als echte Videos. Wirklich winzig. Ich habe vorhin mal vom SNES-Spiel "Jimmy Connors Pro Tennis Tour" eine halbe Minute aufgezeichnet und das entstandene zmv-File gezippt hier mit angehängt. Vielleicht kann man sich das Format mal ansehen zu Analyse-Zwecken, was da wie gespeichert wird und wie es funktioniert, dass diese Files so klein sind? Um es wiederzugeben im ZSNES, benötigt man auch das Spiele-Rom, welches dann den gleichen Namen haben muss, also "Pro Tennis Tour" heissen muss.

  • Aaaaaaah interessant, die Inputs werden gespeichert. Ich dachte immer, er speichert vielleicht irgendwie den Standort der ganzen Objekte am Screen und deren Veränderung, oder sowas in der Art, also was sich wie am Bildschirm wie bewegt. Aber dann geht das also über die Inputs. Okay, cool.


    Das ist wirklich eine supergeile Sache für richtig langes Aufzeichnen von Spielen, etwa wenn ich eineinhalb Stunden an einer einzigen "Dig Dug" Partie sitze. Man nimmt eine Stunde Spiel auf und das Endfile ist immernoch relativ klein, als Video wäre es ein Riesenfile, selbst gepackt noch viel viel größer. Sowas wäre ein Knaller im Denise. Wenn man dann zusätzlich auch noch ein echtes Video des aufzeichneten Spiels haben will, etwa um es überall abspielen zu können, dann kann man das von einem Fremd-Tool erledigen lassen, während Denise das kleine Input-Aufzeichnungsfile wieder abspielt.

  • Aber das kann doch nur funktionieren, wenn im Grunde auch ein Snapshot des Moduls mit hinterlegt ist?

    Bzw. geht das nur bei statischen Leveln, wo immer alle Gegner zur selben Zeit am selben Ort auftauchen und alle Levelelemente sich nie verändern.....?

    Sobald was dynamisch erzeugt wird, müsste es doch schon schiefgehen.

    Man stelle sich ein "Input-Recording von Giana Sisters vor und eine Plattform ist bei der Wiedergabe mal einen Hauch woanders^^...

  • Echte Zufälle, wodurch z.B. eine Plattform in einem Spiel trotz der exakt gleichen Eingaben bis zu diesem Punkt, in ihrer Position variiert sind schwierig ohne eine Quelle für den Zufall, wie z.B. Echtzeituhr. Die Maschine wird immer das gleiche Ergebnis unter den gleichen Eingaben/Bedingungen errechnen. Deswegen funktioniert das Konzept.

    Möglicherweise könnte der C64 eventuell unter Zuhilfenahme der Laufwerks Mechanik echte Zufälle generieren. Aber das macht natürlich kein Spiel. Gibt vielleicht noch ein paar andere Möglichkeiten.

  • Als Beispiel: Handbuch-Kopierschutzabfrage.

    Gebe von Seite x Wort y ein. Hier muss doch ein Zufallsprinzip werkeln?

    Wenn ich hier also, ohne nun genau zu wissen, wie die Funktion arbeitet, als Vorgehensweise mal annehme:


    "Lade Image, führe dann die gespeicherten Inputs aus...."

    Dann kommt nach 3 x Space drücken die Kopierschutzabfrage nach dem beliebigen Wort aus dem Handbuch... Und an dieser Stelle war es das dann schon mit dem Longplay...


    Es sei denn, das Spiel selbst läge auch schon als kompletter Snapshot im Speicher, wodurch im Grunde genommen auch schon immernur dieselbe Seite und dasselbe Wort abgefragt würden... Aber würde dies zum Beispiel ein Snapshot sicherstellen, wenn der Freeze nicht schon genau an der Stelle passiert ist/wäre, wo gerade schon der "Zufallsgenerator" einen bestimmten Wert ermittelt hat?"...


    Klar, mag nun jetzt nicht auf SNES-Roms passen, dieses Prinzip... aber woanders...

    Kann der SID nicht über Rauschen auch so eine Art Zufallsgenerator erzeugen? Deswegen funktionieren doch manche Elemente in Emulatoren nicht bzw. erzeugen immer denselben Wert. Meine imho, das mal hier gelesen zu haben.

  • Dann kommt nach 3 x Space drücken die Kopierschutzabfrage nach dem beliebigen Wort aus dem Handbuch... Und an dieser Stelle war es das dann schon mit dem Longplay

    die exakte Länge zwischen den Button Presses stellt schon eine Quelle für den Zufall dar.

    Der Spieler drückt nicht immer exakt gleich lang.

  • Vermutlich kommt der gute AW182 jetzt alle 5 Tage damit. :D

    Na wenn ich einen Fehler bemerke, wie den hier, indem ich fälschlicherweise den CCS64 als Quelle für diese Aufzeichnungsart nannte obwohl es der ZSNES ist, muss ich ihn ja korrigieren. Und wenn ich eine Sache gut finde, habe ich auch kein Problem damit, sie vorzuschlagen. :)



    Als Beispiel: Handbuch-Kopierschutzabfrage.

    Gebe von Seite x Wort y ein. Hier muss doch ein Zufallsprinzip werkeln?

    Wenn ich hier also, ohne nun genau zu wissen, wie die Funktion arbeitet, als Vorgehensweise mal annehme

    Ich habe mich eben gefragt, wie es mit dem Input-Prinzip funktioniert, wenn Gegnersprites im Spiel in ihrem Handeln (etwa ihren Laufwegen) vom Zufallsprinzip beeinflusst sind und nicht auf die Inputs, also das Handeln, des Spielers reagieren, bei dem was sie machen? Wie also dann das Video insgesamt immer genau gleich ablaufen kann, auch was die genauen Laufwege der gegnerischen Sprites betrifft. Aber scheint ja zu funktionieren.


    Steht dann alles, was in einer Partie des Spiels von Gegner-Seite passiert, schon vorher fest, wenn man von einem im Speicher befindlichen Snapshot des Spiels als Startpunkt ausgeht? Auch wenn Gegnersprites und andere Effekte die im Spiel passieren, im Zufallsprinzip programmiert sind?




    Wegen der Frage mit den Snapshots, ob immer davon ausgegangen wird. Hab mir eben nochmal genau angesehen, welche neuen Files der ZSNES erzeugt, wenn man aufnimmt und das sind immer drei Files. Einmal dieses schon erwähnte zmv-File und zusätzlich legt der Emu dann in demjenigen Ordner den der User als "Saves" ausgewählt hat, immer noch einen neuen Ordner mit dem Spiele-ROM-Namen an, in dem sich dann nochmal zwei neue Files befinden. Das ist einmal ein zst und ein mzi File. Gut möglich, dass eines davon sowas wie ein Snapshot ist, von dem ausgegangen wird. Ich habe mal solche Beispiel-Files, die eben erstellt wurden, hier angehängt, diese wurden vom ZSNES erstellt bei einer Aufzeichnung.

  • Hier scheint es ein leichtes Verständnisproblem zu geben: Sicherlich kann ein Spiel diverse Dinge als Quelle für benötigten Zufall verwenden und auf echter Hardware ist manches davon auch wirklich mehr oder weniger zufällig. Aber in einem Emulator wird die komplette "Computerwelt", in der das Spiel ausgeführt wird vom Emulator kontrolliert. Dinge, die aus Sicht des Spiels zufällig sind kann der Emulator so erzeugen, dass sie bei einer späteren Wiedergabe nochmal exakt so auftreten wie bei der Aufnahme.

  • Ein Emulator, der allen Zufall ausschließt, wäre aber kein guter Emulator.


    Denke doch z.B. mal daran, das prinzipiell jedesmal beim einlegen einer Diskette die Disk anders gedreht sein kann. Oder wie schon geschrieben, die Zeit die die Floppy benötigt für einen Spurwechsel. Das sind dann genau die Idealisierungen, die teilweise verhindern, dass Originale korrekt laufen.


    Input recording ist sicher für einfache Software durchaus eine Option. Ich würde aber nicht den Emulator auf künstliche Reproduzierbarkeit optimieren, nur damit Input recording in jedem Fall funktioniert. Da verliert man vermutlich einiges an Kompatibilität.

  • In Denise und sicherlich auch in anderen Emulatoren werden einige Situationen, welche auf echter Hardware zufällige Werte liefern, simuliert. Bestes Beispiel sind RAM Init patterns. Sicherlich ist es nicht möglich in Software Emulatoren oder FPGA's genau das Zufalls Muster echter Hardware nachzubilden. Das entsteht durch die physische Existenz der Bauteile.

    Es ist also durchaus möglich in der Emulation, nur durch das Abspulen aufgenommener Inputs eines Spieles die Plattform zu verfehlen, welche man bei der Aufnahme noch erwischt hat.

    Input recording ist sicher für einfache Software durchaus eine Option. Ich würde aber nicht den Emulator auf künstliche Reproduzierbarkeit optimieren, nur damit Input recording in jedem Fall funktioniert. Da verliert man vermutlich einiges an Kompatibilität.

    sehe ich genau so. Eventuell eine Option zwecks Ersatz aller Zufälle durch feste Werte.

  • Ich würde aber nicht den Emulator auf künstliche Reproduzierbarkeit optimieren, nur damit Input recording in jedem Fall funktioniert.

    Normalerweise macht man das so, dass der Seed-Wert für den Zufallszahlengenerator ebenfalls in der Aufnahme landet - ist ja im Prinzip auch eine "Eingabe" für den Emulationszustand.

  • Anmerkung: Durch die vielen Speeder mit ihren 40 Track modes werden derart formatierte Disketten in der Vorschau des Emulators nicht sauber angezeigt, erst in der Emulation wird das Format richtig wieder gegeben.

    Das hebe ich mir für später auf. Zudem weiß ich aktuell nicht, ob sich jedes Non Standard Format ohne Kenntnis der verwendeten Software erkennen lässt.

  • Zudem weiß ich aktuell nicht, ob sich jedes Non Standard Format ohne Kenntnis der verwendeten Software erkennen lässt.

    Wenn ich mich recht entsinne geht das bei D64 nicht so leicht, weil mindestens ein Speeder seine Disketten mit Extra-Tracks nur im Sektorheader markiert. Wenn man genug CPU-Zeit auf das Problem werden kann, könnte man evtl. sowas wie ein Validate versuchen und dann testen, ob die für Tracks 36-40 berechnete Belegungs-Bitmap zu einer der Varianten der Extended-BAMs der verschiedenen Speeder passt - aber da zweifle ich spontan ein wenig an der Zuverlässigkeit.