Disk game, welches während es lädt, Sound produziert ?
Hot Wheels - dport der Nachladevorgang auf der Autobahn.
Posts by markusC64
-
-
Die Bilder bei Beitrag #80 zeigen, dass es wohl einseitige Disketten sind: Seiten-Einkerbung nur auf einer Seite und die dort ebenfalls vorhandene Darstellung der Informationen auf den Floppies zeigt dementsprechend, dass auf den Rückseiten (B-Seiten) keine Nutzdaten enthalten sind.
Ich seh doch deutlich auf den Bildern die Syncmarkierkungen auf der Rückseite... das müsste man sich noch einmal genauer ansehen.
-
ist das richtig?
38736D2B.D64 und 38736D1B.D64
sind 0 Byte groß?
gar nicht bemerkt - wie viele andere... heruntergeladen und weggelegt... -
Beeindruckend. Auch wenn es ein 65C02 kompatibler ist - Stichwort "Illegale Opcodes" - die dürften also nicht unterstützt werden.
-
aber erstmal soll es so original wie möglich werden
Aber bitte auch nicht zu original. Ich erinnere mich noch an das Posting von Jim Brain hier, wo er zu kleinen Modifikationen in der Hardware geraten hat - wegen seinem Verständnis vom (US-) Copyright.
-
Dem ist nichts hinzuzufügen
toms01 Eine fantastische Leistung. Wegen der Ultimate 2+ Kompatibilität mach Dir keinen Kopf. Das wird schon wer austesten. Und falls es da Probleme gibt, so wäre doch eher die Ultimate 2+ anzupassen. Was vermutlich möglich ist, wenn Gideon (der Schöpfer der Ultimate 2+) mit Details zur Funktionsweise der SuperCPU versorgt wird. Ob er es dann macht und wenn ja, wann - ja, das ist freilich eine andere Frage.
Edit: Vielleicht geht das Menü dann zwar nur in 1 MHz Modus - aber vor dem Menüaufruf der Ultimate könnte man die SuperCPU ja problemlos heruntertakten.
-
wie darkvision hier zumindest andeutet (x64 und x64sc)
Wenn ich gtkvice für Windows 64 bit selbst compilliere, fällt neben x64sc da auch x64 ab - was gerade im Warpmodus noch etwas mehr Performance rauskitzelt.
-
Daher macht es dann für mich schon mehr Sinn die 128er-Version unter x64 zu assemblieren als andersherum. Über eine Stunde kann ich da nicht warten. Bei 8 Versionen sind das ja fast 10h
Trotzdem Danke für die Vergleichswerte.Da geht natürlich sehr stark die Leistungsfähigkeit der eigenen CPU ein... daher bin ich jetzt beim Mitlesen vorsichtig und vergleiche nicht Deine Werte (x64) mit Werners (x128).
-
Was mich wundert: Der 128er ist nur ca. 15% schneller als der C64 ? Ich dachte der hat 2MHz ?
Aber ich glaube bei den ganzen RAM-Zugriffen schaltet die REU auf 1MHz, und da hier fast die ganze Zeit auf Disk zugegriffen wird kommen die 2MHz nicht voll zur Geltung. Hast Du eine CREU verwendet ?
Davon gehe ich auch aus. Und der Zugriff auf die FD1581 dürfte auch nur mit 1 MHz erfolgen...
PS: Werner hat bestimmt eine 1541 Ultimate II+ für die REU Emulation benutzt. Aber auch die nutzt nur 1 MHz für die REU.
-
-
Eventuell nur interessant, wenn man das P64 auf eine echte Disk zurückschreibt, wobei dann wohl besser das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte.
Davon gehe ich auch aus ("das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte") - denn das selbe Tool wird beim Einlesen ja gespeichert haben, wie die Flux anscheinend liegen und nicht, wie sie wirklich liegen.
Gut, auch wenn die Emulatoren und Konvertierungstools das nicht brauchen: Es wäre schon mal interessant zu wissen, wie man damals tatsächlich kompensiert hat...
-
- Write Precompensation fehlt noch (dient der Langlebigkeit echter Disketten)
Um Bit Shifting auf den inneren Tracks zu verhindern und somit die Langlebigkeit der Disks zu erhöhen, verwendet der Controller Write Precompensation.
Hierbei wird der Flusswechsel je nach eingehendem Bitmuster um 128 nano nach recht oder links verschoben.
Muss man das überhaupt emulieren?
Ich habe dazu mal etwas recherchiert: Die Write-Compensation dient dazu, den physikalischen Peak-Shift-Effekt auszugleichen. Kurz zusammengefasst sorgt der Effekt dafür, dass die gemessene Position der Flusswechsel nicht der physikalischen Position auf dem Datenträher entspricht. Damit die gemessene Position der entspricht, die man gerne auf den Datenträger haben will, schreibt man leicht anders.
Nun ist es aber so, dass in einer P64 Datei geschriebene und gelesene Position übereinstimmt. Wenn man dann aus praktischen Gründen annimmt, dass P64 Dateien immer die Position enthalten, die beim Lesen festgestellt würde, so gibt es nichts zu korrigieren beim Schreiben, wenn die Korrektur bei der echten Hardware 100% wäre. Ist die WPcom dagegen nur in etwa passend, so bräuchte es umfangreiche Messungen an original Hardware, um überhaupt die Unterschiede zwischen mit WPcom geschriebenen und anschließend gelesenen Daten festzustellen.
Kurz: Die kann man so einfach gar nicht emulieren, und braucht es vermutlich auch nicht.
Literatur: https://books.google.de/books?…20sektor%20aufbau&f=false
-
wird zwangsweise irgendwann über das Pufferende hinaus gelesen oder geschrieben.
Recht wahrscheinlich: Ja. Zwangsweise: Nein. Denn die Größe kann auch als "signed int16" vom Tool aufgefasst worden sein... da keine Werte größer als 8k bei den betrachteten Floppies vorkommen, gibt es dazu i. d. R. keine Angabe, ob das signed oder unsigned zu sein hat.
Nun, das ganze G64 Format ist voll von Kompromissen - der wichtigste ist: Einen bestehenden Track zu schreiben ändert nur den lokalen Bereich der Trackdaten. Und zumindest bei der jetzigen G64 Erweiterung (PiCiJi's neue Erweiterung also außen vorgelassen) kann die Größe beim Umformatieren zwischen GCR und MFM beibelassen werden (außer Bit 15, ist klar, oder?), da eigentlich eh die im Header angegebene Größe im Image freigelassen sein muss (macht man das nicht, gibt es Probleme mit derzeitigen Emus). Das sorgt dafür, dass man damit was brauchbares effizient auch auf schwächerer Hardware inpolementieren kann.
Nun, da die schwächere Hardware abgedeckt ist, braucht eine weitere Erweiterung die nicht mehr abdecken, die schwächere Hardware muss nur einfach erkennen können, dass die das Image nicht mögen will...
-
(und wenn man G64 eh grösser umbaut könnte man mal die Speedzone per Bit einstellbar machen...)
Meine Meinung dazu: Solange man keine Idee hat, wie man das im Emulator ausnutzen könnte, bleibt der Nutzen sehr beschränkt. Scheinbar einfache Sachen wie Trackwechsel werden dadurch kompliziert - und Schreibvorgänge noch komplizierter - es werden dann ja nicht immer so viele Bits überschrieben, wie geschrieben werden - sondern je nach Speedzonen ändert sich die Anzahl der Bits...
Und sowieso: Viele Originale haben Speeds, die nur in etwa den Speedzonen der 1541 entsprechen, das kann man dann weiterhin nicht abbilden...
Und wenn man dann noch die stochastischen Abweichungen beim Einlesen eines Datenträgers auf Fluxebene beachtet, so bekommt man aus einem Dump die Speedzonen so genau (d. h. bitweise) auch nicht raus... also solche Images von bestehenden Disketten bekommt man nicht genauer erstellt als mit dem derzeitigen G64.
-
Danke für den Hint... Müssen wir glaub ich mal sacken lassen, wie man so sagt. Anderseits will man ja, dass sobald die Floppy alle Tracks mit GCR "überformatiert" hat, dass das Image wieder möglichst kompatibel wird.
Da jedoch die überlagen RAW MFM Tracks zu schrumpfen in der Tat ein Aufwand ist, den man nicht mal so eben macht, hat man da eher den Fall, das es sowieso nicht abwärtskompatibel wird. Da könnte man in der Tat drüber nachdenken.
-
Stimmt eigentlich - jedoch haben die Bits ein anderes Timing, so dass der MFM Stream irrtümlich als GCR (ohne GCR Dekjodierung) eingelesen nur Garbage erzeugt. Ohne allzutief reingeschaut zu haben, denke ich, man braucht die Info, welches Timing den Rawbits in den Stream zugrunde liegt...
Na gut, die Speedzones 4 bis 7 (*) möchte ich gerne als reserviert betrachten - aber die MFM Speed könntest Du als Speedzone 8 hinterlegen - das ginge natürlich.
Die ergeben, wenn man 0 bis 3 logisch fortführt in der naheliegenden Weise (pro Speedzone 0,25µs weniger) die Speedzones der SFD 1001... keine Ahnung, ob man das mal braucht, aber die Werte sollte man deswegen IMO nicht "verbrennen" durch Andersbenutzung.
-
Gideon hat sich in einer privaten E-Mail vorgestellt, dass weitere G64 Erweiterungen (also solche Sachen wie RAW MFM) dann zur Aktivierung Bit 14 der Träcklänge benutzen... die für GCR dann noch zulässigen Träcklängen sind dann noch immer oberhalb dessen, was eine 1541/70/71 schafft. Zumal man ja die Kombination Bit 14 und Bit 15 beide '1' nehmen kann...
Wenn man die echte Tracklänge dann nicht dorthin bekommt, macht man halt einen Platzhalter und die Tracklänge anschließend.
-
Da im Betreff die 1581 auch drinsteht... hier die 1581 Testdemodiskette als Fluximage... Endung ist aus Toolchaingründen P64, sollte man aber besser nach P81 unbenennen, um klarzumachen, dass es für die 3,5 " 1581 Floppy ist.
-
Aber warum macht man das dann nicht gleich vernünftig und nimmt ein Flux-basiertes Format?
Weil das Gideons Hardware nicht packen würde von der Leistung her... Das ist nun mal ein Totschlagargument, aber am Ende muss ein Format auf der gewünschten Zielhardware umsetzbar sein. Und das erweitertgte G64 bzw., G71 läuft auf der U2+ und auf dem U64 ab Firmware 3.10.
Und ich möchte hier PiCiJi explizit danken, dass er die Erweiterung auch in seinen Emulator aufnimmt, das erleichtert das Verwenden beider Systeme mit Tausch der Images zwichen denen erheblich.
-
Aus der MFM Struktur im G64 gehen CRC Fehler im Moment unter. Man könnte jetzt eine info im error Byte setzen.
Japp, das error Byte im G64 ist darin auch irgendwie unterspezifiziert... habe ich das Gefühl
