Hello, Guest the thread was called928 times and contains 25 replays

last post from markusC64 at the

WD177x und MFM - 1570 1571 1581

  • Quote from markusC64

    PS: Ich gehe davon aus, dass die von Dir o. g. Zeiten für Double Density sind, für High bzw. extra density sind andere Zeiten anzunehmen.

    101 -> 4 micro

    1001 -> 6 micro

    10001 -> 8 micro


    Ja die Zeiten gelten für Double Density. Für HD jeweils die Hälfte. SD (FM) und DD (MFM) basieren auf der gleichen Hardware.


    FM wird aktuell nicht emuliert. Der Controller unterstützt es zwar aber der entsprechende PIN zwingt den Controller im Rahmen der 1571/1581 permanent auf MFM.

    <FM>

    Clockbit ist immer 1.


    Datenbit : 1 => FM : 11 [4 + 4 micro]

    Datenbit : 0 => FM : 10 [4 + 4 micro]

    ergibt 2 mögliche patterns im FM stream


    <MFM>

    Clockbit ist nur 1, wenn Daten Bit davor eine 0 ist


    Datenbit : 1 => MFM : 01

    Datenbit : 0 => MFM : 10 oder 00 (wenn Bit davor eine 1 ist)


    ergibt 3 mögliche patterns, siehe Anfang des postings


    Da niemals zwei Einsen direkt nebeneinander stehen, kann die Bit Zelle von 4 micro auf 2 reduziert werden ohne das Flusswechsel zu dicht nebeneinander stehen und erreicht somit eine Verdopplung der Datendichte von FM zu MFM.


    Der MFM Controller prüft die Zeit zwischen 2 Flusswechseln.

    Vergehen zwischen 2 Flusswechseln 3.4 - 4.4 micro wird es als MFM Folge 101 gewertet.

    Vergehen zwischen 2 Flusswechseln 5.4 - 6.4 micro wird es als MFM Folge 1001 gewertet.

    Vergehen zwischen 2 Flusswechseln 7.4 - 8.4 micro wird es als MFM Folge 10001 gewertet.

    Alles darüber hinaus sind Weak Bits.


    Quote from markusC64

    Analog zum GCR müsste man daraus ja Sektorheader und Sektordaten extrahieren sowie Prüfsummen berechnen und prüfen... und im Idealfall (nein, eigentlich für ein universelles Tool notwendig) die Sektorgröße erkennen... kann ja verschieden groß sein. Was im Wesentlichen einer Formatbeschreibung des "Sektors" bedarf (also raw, nicht auf Nutzdatenebene).


    Und ganz wichtig: Welche Fehler kann der in der 1570/1571/1581 eingesetzte Controller liefern... während ich alles andere eher allgemein für MFM behandeln möchte, muss man an der Stelle wohl doch auf konkrete Fehler zurückgehen - die U2+/U64 wird die bei der 1571 wohl nur durchschleusen, und Du hast ja die selbe G71 Erweiterung...

    Ich würde das durch kurze Beschreibungen der 5 Lese/Schreib Kommandos beantworten. Fehler Status Beschreibungen sind mit enthalten.


    typischer Aufbau eines Tracks

    ------------------------------------

    Index Adreßmark (optional) -> Lücke (80x $4e), 12x $0, 3x $f6 ($C2 mit fehlendem Clock Bit), 1x $fc, 50x $4e


    - jeweils pro Sektor -

    ID Feld des Sektors -> 12x $0, 3x $f5 (A1 mit fehlendem Clock Bit), 1x $fe, Track, Seite, Sektor, Sektor Größe, CRC1, CRC2, 22x $4e

    Daten Feld des Sektors -> 12x $0, 3x $f5 (A1 mit fehlendem Clock Bit), 1x $fb, SEKTOR DATEN, x $4e (Anzahl festgelegt beim Formatieren)


    Sync Marks: A1 entspricht MFM: $4489, C2 entspricht $5224

    Code
    1. data 0xA1 1 0 1 0 0 0 0 1
    2. MFM sync 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 ?
    3. - (removed clock bit)
    4. data 0xC2 1 1 0 0 0 0 1 0
    5. MFM sync 1 0 1 0 0 1 0 1 0 1 0 0 1 0 0 ?
    6. - (removed clock bit)

    <Write Track>

    Beim Formatieren Kommando wird jedes übergebene Byte auch geschrieben und der CRC berechnet. Ausnahme sind die Bytes F5, F6 und F7.

    Kommando startet Schreibvorgang bei nächster Index Hole und läuft bis die Index Hole ein zweites Mal erkannt wird.


    F5

    --

    schreibt $A1 mit fehlendem Clockbit, so dass die MFM Folge LMLM entsteht. (hint: 101 => S, 1001 => M, 10001 => L)

    initialisiert CRC zu 0xcdb4


    F6

    --

    schreibt $C2 mit fehlendem Clockbit, so dass die MFM Folge SMLM entsteht.

    initialisiert CRC NICHT.

    dient zum Kennzeichnen des Index Adreßmarks, dieser muss beim Formatieren aber nicht zwingend gesetzt werden.

    hint: dieses Muster ist nicht weise gewählt (Design Fehler) und kann auch in Sektor Daten vorkommen. Es ist aber nur ein Problem bei Verwendung des Read Track Kommandos.

    Beim Read Sector Kommando wird der AM Detector innerhalb des Lesens von Sektor Daten deaktiviert.


    F7

    --

    schreibt den bis dahin selbst berechneten CRC (2 bytes). Damit das Sinn macht, sollte vorher also ein F5 geschrieben worden sein, zwecks CRC Initialisierung.

    F7 maskiert direkt folgende F5, F6 und F7 z.B:

    F7 F5 -> schreibt 2 CRC bytes und dann F5, nicht A1 mit fehlendem Clock Bit

    F7 F7 F7 -> schreibt 2 CRC bytes, dann zweimal F7


    <Read oder Wtite Sektor>

    --- für Read und Write gleichermaßen ---

    Das Read Sektor Kommando sucht nach dem A1 Sync Mark mit fehlendem Clockbit. Das ergibt die MFM Folge: 0x4489

    Außerdem weiß der Controller nun, das das nächste Bit ein Clock Bit sein muss.

    Es müssen zwingend 3 A1 Bytes (mit fehlendem Clock Bit) in Folge sein, gefolgt von $fc, $fd, $fe oder $ff. Nun ist der Mark als ID Feld erkannt.

    Im Anschluss folgen die Bytes für Track, Side, Sektor, Sektor Größe und CRC. Track u. Sektor Register werden mit dem gelesenen abgeglichen um zu schauen ob der gewünschte Sektor erreicht ist.

    Jedes der 3 A1 initialisiert den CRC zu $cdb4. Der Controller cheatet hier. Ein CRC, initialisiert mit 0xFFFF gefolgt von 3x A1 ergibt den CRC $cdb4.

    1x $fe, Spur, Seite, Sektor, Sektor Größe müssen dann den CRC ergeben, welcher in den nächsten 2 Bytes gelesen wird. Andernfalls wird der entsprechende Status 'CRC ERROR' gesetzt und der Controller

    beginnt von vorne. Das Kommando läuft also weiter. Wenn 5 mal der Index Hole erreicht wurde, ist allerdings Schluss und das entsprechende Status Bit wird gesetzt. 'RECORD NOT FOUND'

    --- Read ---

    Nach erfolgreich erkanntem ID Feld für den angeforderten Track/Sektor muss der Controller innerhalb von 44 gelesenen Bytes das Datenfeld finden, ansonsten geht es zurück zum Anfang, bis 5 Index Holes erreicht sind.

    Es müssen zwingend 3 A1 Bytes (mit fehlendem Clock Bit) in Folge sein, gefolgt von $f8, $f9, $fa oder $fb. Nun ist der Mark als Daten Feld erkannt.

    $fa und $fb gelten als DAM (Data Adreß Mark)

    $f8 und $f9 gelten als DDAM (Deleted Data Adreß Mark) -> Status Bit für Record Type wird gesetzt.

    Wichtig: Nun wird der AM Detektor deaktiviert. Für $A1 wäre es nicht so schrecklich wichtig, da das pattern sowieso nicht durch Sektor Daten entstehen kann. $C2 jedoch

    kommt ab und an vor und würde das nächste Bit als Clock Bit interpretieren und den Bit Counter mit 0 initialisieren. Folgende Bytes würden falsch eingelesen werden.

    Nun fordert der Controller über ein Flag im Status Register die CPU auf das gelesene Byte abzuholen (Data Request). Sollte dies nicht passieren bis zum nächsten fertigen Byte

    wird das Status Flag 'LOST' gesetzt aber das Kommando läuft weiter.

    Im ID Feld steht die Sektor Größe. Ist die entsprechende Anzahl Bytes gelesen, werden die nächsten 2 gelesenen Bytes als CRC betrachtet und mit dem berechneten CRC verglichen.

    Passt das nicht wird das Kommando beendet und das CRC Error Flag im Status Register gesetzt.

    --- Write ---

    liest 2 dummy Bytes, setzt Data Request Flag im Status Register, check nach weiteren 9 dummy Bytes ob CPU erstes Sektor Byte übergeben hat, wenn nicht setzt 'LOST' Flag im Status Register

    und beendet Kommando. Nach weiteren 11 gelesenen dummy Bytes wird endlich das write gate aktiviert, schreibt 12x 0, 3x $A1 (mit fehlendem clockbit), 1x $F8 oder $FB, abhängig

    von Bit 0 des Kommandos (DAM oder DDAM). Schreibt jetzt das bereits übergebene erste Sektor Byte und fordert nun entsprechend der Sektor Größe aus dem ID Feld über das

    Status Flag 'Data Request' die CPU auf weitere nachzuschieben. Sollte die CPU es nicht rechtzeitig schaffen, wird das Status Flag 'LOST' gesetzt. Das Kommando läuft allerdings

    weiter und schreibt eine 0. CRC wird für alle geschriebenen Bytes nach der Initialisierung ($F5) berechnet und am Sektor Ende ergänzt.

    --- für Read und Write gleichermaßen ---

    Wenn im Kommando das Bit für multiple Sektoren gesetzt ist, wird das Sektor Register um eins erhöht und der Prozess beginnt von vorne, Kommando läuft also weiter.

    Sollte das Sektor Register nun den höchstmöglichen Sektor überschreiten, versucht er erfolglos im Rahmen von 5 index holes den Sektor zu finden und beendet das Kommando.


    <Read Address>

    stimmt mit der Suche des ID Feldes von Read/Write Sektor überein. Nur hierbei wird der Track und Sektor nicht mit den beiden Registern verglichen, sondern das nächste Sektor ID Feld gelesen.

    Nachdem Sync Mark wird der AM Detektor abgeschalten und die folgenden 6 Bytes gelesen.

    Track, Seite, Sektor, Sektor Größe, CRC1, CRC2. Für diese wird im Gegensatz zu Read Sector das Data Request Bit im Status Register gesetzt und erwartet, dass die CPU die

    Daten abholt. Passiert das nicht, läuft das Kommando weiter, setzt jedoch das 'LOST' Flag.

    Zudem wird der gelesene Track ins Sektor Register kopiert, zwecks späteren Vergleichen der CPU mit dem Track Register.

    Type 1 Kommandos, welche dem Track Stepping dienen, aktualisieren das Track Register. Nun kann mittels diesem Kommando überprüft werden ob vom angenommenen Track im Register auch

    tatsächlich gelesen wird. Die Pins für stepping und direction sind in der 157x nicht angeschlossen. Dennoch können Type 1 Kommandos verwendet werden, da beide Pins auf Output stehen. Der Controller

    hat keine Ahnung, dass diese ins Leere führen.

    CRC wird validiert und bei fehlender Übereinstimmung das entsprechende Status Bit gesetzt.

    Das Kommando läuft endlos, wenn kein ID Feld erkannt wird und muss dann mittels einem Force Interrupt beendet werden.


    <Read Track>

    dient der Analyse. Läuft von Index Hole zu Index Hole, wie Write Track. Alles wird der CPU zur Verfügung gestellt. Wie immer gilt, dass bei nicht rechtzeitig abgeholtem Byte

    der LOST Flag im Status Register markiert wird.

    Doch Vorsicht der AM Detektor wird hierbei nicht abgeschalten. Jetzt kann es passieren, dass ein $C2 mit fehlendem Clock Bit einen Sync auslöst.

    Der Controller wird dann das nächstes Bit als Clock Bit werten und den Bit Counter auf 0 setzen.

    Das MFM pattern 0x5224 ($C2 mit fehlendem Clockbit) kann durchaus in Sektor Daten vorkommen.

    CRC wird nicht berechnet und geprüft.


    -------------------------

    Fuzzy Bits

    Diese sind noch interessant zu erwähnen, da sie nicht im Rahmen der GCR Hardware vorkommen.

    Der Controller verwendet ein Inspection Window und verschiebt dessen Phase ständig in Abhängigkeit von Motor Schwankungen derart, dass der Flusswechsel mittig bleibt.

    Was passiert nun aber wenn der Flusswechsel z.B. zwischen 4.5 und 5.3 micro liegt. Dieser Bereich ist nicht sicher und befindet sich nun am Rand des Inspection Windows.

    Je nach Motor Schwankung detektiert der Controller den Flusswechsel in diesem oder nächsten Window. Entweder wird das MFM pattern 101 oder 1001 erkannt.

    Natürlich ist der Controller rein digital und erzeugt keine Zufälle. Die Motor Schwankungen verursachen das indirekt.


    Z.b. Dungeon Master auf dem Atari hat Flusswechsel Abstände von 5 micro. Der Controller liest mehrfach über den gleichen Bereich und die Software prüft ob die Werte

    sich unterscheiden. Unterscheiden diese sich nicht, handelt es sich um eine Kopie. Der Controller kann keine Abstände von 5 micro schreiben.


    Der Controller schreibt 4, 6 oder 8 micro (+/- 128 nano für write precompensation in den inneren Tracks) Das liegt noch gut in der Toleranz.

    Auf 3.5 Zoll Disketten wird write precompensation in der Regel auf allen Tracks angewandt.


    In der Emulation besteht aktuell der selbe Zufall beim Lesen zwischen 4.5 u. 5.3, entweder 101 oder 1001.

    Noch besser wäre es den Zufall nahe 5 micro maximal werden zu lassen und an den Rändern minimal. 4.5 wird sicherlich in den meisten Fällen 101 liefern

    und 5.3 in den meisten Fällen 1001


    Write Precompensation

    ...

  • Super. Danke. Das muss ich mir am Wochenende genauer ansehen, schaut aber auf den ersten Blick sehr gut aus.

  • Quote

    die U2+/U64 wird die bei der 1571 wohl nur durchschleusen, und Du hast ja die selbe G71 Erweiterung...

    Aus der MFM Struktur im G64 gehen CRC Fehler im Moment unter. Man könnte jetzt eine info im error Byte setzen.

    Beim Einlesen der dekodierten Sektor Daten erzeuge ich ein neues CRC, was natürlich richtig ist.


    Im Rahmen eines P64 sind natürlich die echten CRC Werte enthalten.

  • 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

  • Daten Feld des Sektors -> 12x $0, 3x $f5 (A1 mit fehlendem Clock Bit), 1x $fb, SEKTOR DATEN, x $4e (Anzahl festgelegt beim Formatieren)

    CRC vergessen

    Daten Feld des Sektors -> 12x $0, 3x $f5 (A1 mit fehlendem Clock Bit), 1x $fb, SEKTOR DATEN, CRC1, CRC2, x $4e (Anzahl festgelegt beim Formatieren)


    Write Sektor Kommando

    vergessen zu erwähnen das am Ende nach den beiden CRC Bytes 0xff vom Controller geschrieben wird, bevor das write gate deaktiviert wird.

    Big Blue Reader versucht das zu verhindern und bricht das Kommando ab, während das 2. CRC Byte geschrieben wird. Da Kommandos nur zwischen den Micro Code Zyklen gekickt werden können, schreibt er das 2. CRC Byte noch fertig.

  • Japp, das error Byte im G64 ist darin auch irgendwie unterspezifiziert

    Verwechselst du das evtl. mit D64? Bei G64 gitbs meines Wissens keine Error-Bytes weil die Fehler alle schon im Bitstrom darstellbar sind.

  • Es gab ne inoffizielle Ergänzung zwecks MFM.

    Aber warum macht man das dann nicht gleich vernünftig und nimmt ein Flux-basiertes Format? Dann ist es egal ob die Disk mit GCR (Commodore, Apple, etc), FM, MFM, RLL oder sonstwas beschrieben wurde...

  • 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.

  • 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? Dann ist es egal ob die Disk mit GCR (Commodore, Apple, etc), FM, MFM, RLL oder sonstwas beschrieben wurde...

    Ein Flux basiertes Format wird in Denise für MFM unterstützt und das G64 mit dekodierten Sektor Daten.

    Ich hatte Rücksprache mit dem VICE Team und die werden die dekodierten Daten im G64 nicht akzeptieren, wenn es dann irgendwann in VICE Einzug erhält. Ich muss an der Stelle sagen, dass ich im G64 auch lieber einen MFM stream sehen würde. Dann müsste man das Format nicht ändern. (*)

    Weil das Gideons Hardware nicht packen würde von der Leistung her...

    Ich baue das entsprechend um, werde aber das G64 U2+/64 dennoch unterstützen.

    Ich stelle mir eine Option vor, z.B. MFM Ultimate kompatibel G64, wo beim Schreiben eines MFM Tracks das Format mit den dekodierten Sektor Daten + MSB in der Tracklänge verwendet wird.

    Beim Lesen ist dieses Format anhand des gesetzten MSB in der Tracklänge erkennbar, andernfalls ist es ein MFM/GCR stream. so in der Art...


    (*) Die MFM Track Länge übersteigt die typische Max Length im Rahmen des GCR, aufgrund der notwendigen 2 micro Auflösung. Wenn in einem frisch erstellten G64/G71 das erste Mal ein MFM Track geschrieben wird, müsste das gesamte Image einmalig neu gebaut werden. Sollten später alle MFM Tracks wieder verschwinden, würde ich das image nicht mehr verkleinern. (zu viel Aufwand)

  • 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.

  • (also solche Sachen wie RAW MFM) dann zur Aktivierung Bit 14 der Träcklänge benutze

    Die MFM Tracklänge müsste bei 12500 Bytes liegen. Bit 14 ist zwar immer noch frei aber ich versuche es im ersten Schritt so zu bauen, dass entweder die GCR bzw. MFM Hardware was damit anfangen kann und es aus Sicht des Images keine Rolle spielt ob ein MFM oder GCR stream hinter der Tracklänge folgt.

    Ich behalte das im Hinterkopf.

  • 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

    Ihr habt aber schon mitbekommen, dass das G64-Format ziemlich an Anfang ein Versionsbyte hat?

  • 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.

  • Das Problem ist halt, dass existierende Programme mit den MFM-Tracks eh nichts anfangen können und eher die Gefahr besteht, dass sie durch die "übergrossen" Per-Track-Längenangaben crashen, weil vermutlich im Header immer noch die reguläre maximale Track-Länge drinsteht. Dann kann man das IMHO besser einmal richtig machen als es mit Tricks (aber doch inkompatibel) ins bestehende Format zu pressen.


    Wenn es doch kompatibel bleiben soll könnte ich mir eher vorstellen, für MFM-Tracks eine weitere Offset-Tabelle (und ggfs. ein zweites Tracklängen-Feld) vorzusehen und den Offset für den jeweils "unpassenden" Datentyp auf 0 zu belassen. Für ein Nur-GCR-Programm sieht es dann so aus, als ob der Track leer wäre. Falls beide Offsets vorhanden sind sollte dabei GCR bevorzugt werden, falls das Image mal mit einem Nicht-MFM-Tool bearbeitet wurde. Aber auch so löst das natürlich noch nicht das Problem, wie man einen Track mit gemischten MFM/GCR-Daten darstellt.


    (und wenn man G64 eh grösser umbaut könnte man mal die Speedzone per Bit einstellbar machen...)

  • (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.

  • Die max track Länge muss angepasst werden, sobald nur ein MFM Track geschrieben wird, bzw. das komplette image einmalig anhand der neuen max länge neu gebaut werden.

    Beim Wechsel zwischen MFM und GCR Track werden dann die Standard Längen angenommen.

    Ich würde davon absehen MFM und GCR in einem Track zu mixen, was im Flussformat problemlos möglich ist. Das nicht variable Bitcell timing gestaltet das schwierig.

    aber die MFM Speed könntest Du als Speedzone 8 hinterlegen - das ginge natürlich.

    ok, der Bereich ist safe, da nicht wirklich in Verwendung.

  • (und wenn man G64 eh grösser umbaut könnte man mal die Speedzone per Bit einstellbar machen...)

    Ich denke es ist der falsche Weg hier Energie reinzustecken. Man benötigt erstmal ein Konzept Non Standard Speedzones auszuweisen.

    Das schöne an Flussformaten ist die zeitliche Zuordnung des Flusswechsels innerhalb der Rotation.