Forum64

OK,
also gehe ich recht in der Annahme, dass es zwar möglich aber sinnfrei wäre?

man könnte halt nur einen sehr niedrigen level an kompatibilität erreichen, daher letztendlich sinnfrei, ja.

Schade, und Danke für die Aufklärung.

Oha, es gibt keine Changelog mehr auf der Homepage?

Quoted from "retroK"

Oha, es gibt keine Changelog mehr auf der Homepage?

Weil das momentan nur eine temporäre Seite ist, während der Server momentan aufgrund eines Vorfalls schrittweise komplett neu aufgesetzt wird.

Und ich überarbeite gerad die 1541 Emulation, so dass die dann auf der Magnetic-HighToLow(+ nach -)/LowToHigh(- nach +)-Transition-NRZI-Pulse Ebene arbeitet (aus den NRZI Pulses werden dann die GCR Bits), als statt über wie momentan direkt auf der darüber liegenden GCR Bitstream Ebene. Ich benötige zudem für einen neuen Build zudem halt noch etwas Zeit, bevor ich es auf die Menschheit loslassen kann.

Die alte GCR-Bitstream-Ebene-Emulationslogik wird dann weiterhin für D64, X64 und G64 Disk Images verwendet (damit diese in erster Linie weiterhin auch GCR-bitweise-perfekt beschreibbar bleiben, und sowie aus Performancegründen), so dass die neue NRZI-Pulse-Ebene-Emulationslogik dann nur für P64 & FDI Disk Images zum Einsatz kommen wird bzw. bei mir im privaten Build schon kommt.

Die Samplerate der NRZI Pulses ist in Micro64 zudem intern flexibel (da die Pro-Trackrotation-Zeiteinheit intern auf einen vollem unsigned-32-Bit Wertebereich hoch geskaliert und beim zurück-schreiben des P64/FDI Images wieder zurück runter geskaliert wird) (default ist aber 16 MHz, also 3200000 Samples (16MHz geteilt durch 5 Umrundungen pro Sekunde, da eine Umrundung bei 300RPM als Nennwert in einer Sekunde ~200ms dauert), aus der Sicht eines P64 Images auf dem Datenträger, wenn aus FDI, G64, X64, D64 oder NIB konvertiert. Micro64 bietet dann dafür ConvertTools CmdLine Parameter an), jedoch als SparseArrays mit DeltaTimeWerten pro Rotation zwischen den Pulses, damit der RAM Verbrauch möglichst niedrig bleibt.

Und ich werde mein P64 Format zudem dann wohl dokumentieren, da es speziell auf die Gegebenheiten der 1541 optimiert ist und zudem da es viel einfacher und handlicher aufgebaut ist als das FDI Dateiformat, welches (also FDI) unter anderem auch Hoxs64 unterstützt, damit das P64 Format nicht für andere Emulatorentwickler verschlossen bleibt.

Das P64 Format enthält zudem wirklich nur die Pulses pro Halftrack, keine BitSync Informationen etc., sprich die Emulationslogik muss beim Thema NRZI Bit-Synchronisation hier exakt genauso mit dem entsprechenden ClockReset innerhalb eines virtuellen 62.5 nanosekunden Zeitrahmens wie eine reale 1541 funktionieren.

Mit P64 sollte dann wie beim FDI Dateiformat zumindest die zwei Hauptknackpunkte des G64 Dateiformats soweit behoben sein, und zwar 1. der Support für variable Bitdichten / verschiedene Speedzonen innerhalb eines Halftracks und sowie 2. Weakbits (da jeder Pulse bei P64 ein unsigned-32-bit PulseStrengthWert hat, von weak bis strong), die durch niedrige Schreibspannung oder was auch immer ursacht wurden, und sowie weitere einige andere Dinge.

Und das P bei P64 steht übrgins für Pulse.

Danke für die ausführliche Erklärung!

Danke BeRo!

Quoted from "BeRo"

2. Weakbits (da jeder Pulse bei P64 ein unsigned-32-bit PulseStrengthWert hat, von weak bis strong), die durch niedrige Schreibspannung oder was auch immer ursacht wurden

Du scheinst eine andere Definition für "weak bits" zu verwenden als sonst im Kontext der 1541 üblich.

Quoted from "Unseen"

Quoted from "BeRo"

2. Weakbits (da jeder Pulse bei P64 ein unsigned-32-bit PulseStrengthWert hat, von weak bis strong), die durch niedrige Schreibspannung oder was auch immer ursacht wurden

Du scheinst eine andere Definition für "weak bits" zu verwenden als sonst im Kontext der 1541 üblich.

Unter Weakbits verstehe ich wahrscheinlich das gleiche, nur eben aus einer anderen Sichtweise, dass z.B. Stellen der Diskette schwach magnetisiert wurden, wo man beim lesen dieser Stellen dann eher mehr zufällige Bits als eindeutige Bits erhält, so etwa wie bei ungültigen GCR Bitsequenzen (durch Out-Of-Sync etc.) mehr oder weniger auch. Ich habe das einfach nun erklär-formulier-technisch auf die NRZI-Pulse Ebene übergetragen, wie das FDI Format es zudem auch genauso tut, nur eben in viel geringerer Weak/Strong-Abstufung als bei meinem P64 Format.

Und die 1541 Elektronik filtert zudem ja auch Pulses, die kürzer als 2.5 Mikrosekunden sind, heraus um Rauschen über 400 kHz weg zu filtern.

Quoted from "BeRo"

Unter Weakbits verstehe ich wahrscheinlich das gleiche, nur eben aus der anderen Sichtweise, dass z.B. Stellen der Diskette schwach magnetisiert wurden

Weak bits sind im 1541-Kontext lange Sequenzen von 0-Bits, in die die Laufwerkselektronik gelegentlich 1-Bits einstreut. Ein (grosser) Teil der 1-Bits ist komplett deterministisch durch den Aufbau der Leselogik bedingt, einfach mal in einen 2031-Schaltplan schauen (von denen gibts gute Scans im Netz, im Gegensatz zum Schaltplan der ersten 1541-Revisionen bei denen der Teil noch diskret aufgebaut war). Beim Rest weiss ich leider gerade nicht auswendig was den Effekt erzeugt - es war nicht nur einfach das Rauschen in der Verstärkerlogik bei abklingendem Signal vom Kopf, weil es immer noch einem recht deutlichen Muster folgt.

Auf dem Medium selbst sind diese 0-Bit-Sequenzen Bereiche mit konstanter Magnetisierung, entweder durch gezieltes Schreiben von solchen Zonen oder Nichtbeschreiben auf bislang unformartierten Disketten. So wie ich deine Beschreibungen lese verwendest du aber nicht Stärken von Magnetisierungen sondern Stärken von Pulsen - man könnte da jetzt zwar noch an die Differenz zweier aufeinanderfolgender Magnetisierungswechsel denken, aber werden dann in dem Format 0-Bits durch Auslassung repräsentiert? 32 Bit scheinen mir auch deutlich übertrieben zu sein, der Kopfverstärker ist ja auch nicht rauschfrei.

Quoted from "Unseen"

Quoted from "BeRo"

Unter Weakbits verstehe ich wahrscheinlich das gleiche, nur eben aus der anderen Sichtweise, dass z.B. Stellen der Diskette schwach magnetisiert wurden

Weak bits sind im 1541-Kontext lange Sequenzen von 0-Bits, in die die Laufwerkselektronik gelegentlich 1-Bits einstreut.

Das meiste davon weiss ich ja, so dass z.B. auch nie mehr als drei Low-Bits in Folge kommen, da spätendes nach 3-Bits immer ein High-Bit folgt, egal ob durch einen Impuls oder einen Timer Clock Overflow Wrapround, bzw. dass maximal zwei Low GCR Bits in Folge timingstabil möglich sind.

Ich meinte hier näturlich die Stärken von den Magnetisierungen, die aber aufgrund dem Prinzip von NRZI auch direkt in die Pulse Informationen selbst mit-ein-enkodiert werden können (denn ob -128 -128 -128 127 127 127 (8-bit signed, magnetic field samples) oder 0 0 0 255 0 0 (8-bit unsigned, NRZI pulses) ist dabei hier bei NRZI zumindest aus der Sicht der Softwareemulationslogik nahezu egal), da bei NRZI nur die Nulldurchgänge innerhalb einem Zeitrahmen entscheidend sind, ob 1 oder 0. Ein HighBit also Bit 1 ist wenn ein Nulldurchgang/High<->LowTransition innerhalb einem Zeitrahmen erfolgt, und ein LowBit also Bit 0 ist wenn innerhalb diesem Zeitrahmen kein Nulldurchgang/High<->LowTransition erfolgt, aber nie mehr als zwei Low-Bits in Folge, da dann es möglich ist, dass das Timing dann out-of-sync läuft. Das ist das Prinzip von NRZI (http://de.wikipedia.org/wiki/Non_Return_to_Zero#NRZI).

Ich habe hier zig PDFs, "Magnetic storage handbook", "C1541 TROUBLESHOOTING & REPAIR GUIDE", etc. welche ich zudem schon alle auch nahezu durch habe. Alles wohl nur eine Sache der verschiedenen Sichtweisen. Ich bin halt eher der Softwaremensch, der halt mal ab und zu einen Abstecher in die Hardwarewelt macht, z.B. wenn ich an Micro64 arbeite.

Und die 32-bit Weak-to-Strong-Genauigkeit ist in erster Linie nur aufgrund Alignment der internen Datenstruktur so hoch, damit das Alignment wenigstes kein Platz vollkommen verschwendet.

So Micro64 Build 652 ist raussen, und die statische HTML Seite + das kurze gestrippte Changelog + temporärer statischer ZIP-Link sind immer noch temporär.

Micro64 ist nach Hoxs64 damit jetzt auch nun der zweite C64 Emulator, der das FDI Dateiformat lesend und sowie schreibend unterstützt. Der Schreibsupport bei FDI ist aber noch experimentell, obwohl es schon recht gut tut, von daher besser dafür noch eher P64 nehmen, wo das schreiben stabiler tun "sollte" als bei FDI.

Und die P64 Dateiformat Spezifikation Dokumentation folgt noch in den nächsten Tagen. P64 und FDI sind vom Informationsgehalt her soweit identisch, denn beide Dateiformate verwenden 16 MHz als interne Sample-Rate für 1541 Raw NRZI Pulse Tracks (16 MHz geteilt durch 5 TrackUmrundungenProSekunde = 3200000 Samples/Track), nur dass P64 etwas besseren Support für WeakPulses hat und sowie einfacher zu lesen & zu schreiben ist als FDI, wenn man erstmal den RangeCoder Kram davon korrekt implementiert hat, welches auch einfacher und schneller zu implementieren ist, als der Huffman-Kram beim FDI Dateiformat, da der Code für den P64-RangeCoder-Kram um vielfaches kürzer und verständlicher ist, als der Code für den FDI-Huffman-Kram. Zudem ist der P64-RangeCoder-Kram auch einiges effektiver als der FDI-Huffman-Kram, bezüglich kleinere Output-Dateigröße. Beispiel:

• SummerGames.g64 = 333744 bytes
  
  
• SummerGames.p64 = 221804 bytes
  
  
• SummerGames.fdi = 297984 bytes (von Hoxs64 geschrieben)
  
  
• SummerGames.fdi = 279040 bytes (von Micro64 geschrieben, die Huffman-Encoder-Implementation von Micro64 ist da wohl eventuell auch was effektiver als die von Hoxs64, aber kann ansonsten evtl. implementationstechnisch näturlich auch Zufall sein, dass die geschriebene FDI von Micro64 was kleiner ist als die geschriebene FDI von Hoxs64, zumindest läuft diese FDI dann auch in Hoxs64 einwandfrei wie die Hoxs64 eigene-geschriebene FDI auch)
  
  

Changelog:

Quoted

• micro64 ide/debugger now temporary removed until a rewrite in the next year 2012
  
  
• Implemented a second very exact floppy emulation logic with 16 MHz clockrate with all relevant internal clock counters from a real 1541, extra for FDI and P64 disk images, so the primary old but stable and faster floppy emulation is still used for D64, X64, G64 and NIB images.
  
  
• Added support for FDI (read&write), P64 (read&write) and NIB (readonly) disk images
  
  
• NIB support is only temporary and highly experimental, so it can be remove at any time again, because the NIB file format can change from NIBtools release to NIBtools release!
  
  
• Added "+g642p64 in.g64 out.p64", "+p642g64 in.p64 out.g64", "+g642d64 in.g64 out.d64", "+d642g64 in.d64 out.g64", "+nib2g64 in.nib out.g64", "+fdi2p64 in.fdi out.p64" and "+p642fdi in.p64 out.fdi" command line parameters.
  

Hallo Bero, schöner Build ich habe ein d64 image in g64 und dann in p64 umgewandelt merke aber keinen Unterschied beim Laden! Was verändert ich bei dem neuen p64 Format so alles, außer das die Datei kleiner ist und 42 Tracks da sind? Beim G64 format sagt er "Out of Memory" obwohl ich 6 GB RAM hab

Quoted from "Tracker5423"

Hallo Bero, schöner Build ich habe ein d64 image in g64 und dann in p64 umgewandelt merke aber keinen Unterschied beim Laden! Was verändert ich bei dem neuen p64 Format so alles, außer das die Datei kleiner ist und 42 Tracks da sind? Beim G64 format sagt er "Out of Memory" obwohl ich 6 GB RAM hab

Bei P64/FDI Images, die einfach so aus D64/X64/G64/NIB Images heraus konvertiert wurden, wirst du nie keinen Unterschied bemerken

Der Sinn von FDI/P64 liegt eher bei Disketten, die mit einem Kopierschutz auf niedrigster Ebene versehen sind. Die müssen halt dann entsprechend mit den passenden Tools und passender Hardware zu FDI/P64 Images digitalisiert werden.

Wann tritt der "OutOfMemory" Fehler genau auf? Beim Attachen (und wenn ja, dann wäre das entsprechende Image nützlich, um den Bug im GCR Pre-Decoding für den Attach Image Menu File Directory Lister zu fixen)? Beim Konvertieren (und wenn ja, von welchem Ursprungsimage)? etc.?

Es ist ein konvertiertes d64 image und beim attachen tritt es auf! das image was ich aus der g64 nach p64 konvertiert habe funktioniert! Hab die Dateien mal auf meinen Webfolder geschoben: http://webdrive.goober.com/view.php?wd=6…0be3729ea2ce6d6

Ok, ist nun in Build 653 gefixt, ich muss nun warten, bis die statische temporäre HTML Seite inkl. ZIP auf dem Server, der immer noch im Notzustand ist, aktualisiert wird. Also wer bereits vorher die ZIP will, muss in den Chat kommen

Es war nur ein kleiner Bug im Dateiheader-Parser vom G64 Loader, der sich wohl ab irgendwelchem Build eingeschlichen hat, denn ich habe unter anderem den G64 Loaderkram in den letzten Tagen bezüglich für die Imag-Convert-Command-Line-Tools mehrfach erneut übergearbeitet.

So Micro64 Build 658 ist online, die "dynamic-pixel-block-wise" VIC-II Emulation sollte seit diesem Build nun bezüglich Genauigkeit noch was näher zu der "single-pixel-dot-clock-exact" VIC-II Emulation sein.

@BeRo wäre es möglich eine MIDI Schnittstelle in den Emulator einzubauen damit man den SID mit externen MIDI Geräten steuern kann? So eine Art MIDI Synth. Das wäre echt Hammer!

@wishi ich glaube das ist so gewollt weil der Emu Pixelexakt arbeitet und das die Originalauflösung des C64 ist! Das der Emu die Ränder nicht abschneidet liegt daran, dass ein Fernseher mit Overscan arbeitet und der Emu da halt etwas mehr an den Rändern anzeigt, weil der das Bild 1 zu 1 ausgibt!