You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(dim): die Sonde nahm 512 Nullbytes an — die Kennung war ungeprueft (MF-1019)
Zwei Defekte behoben, und einer ausdruecklich NICHT: die Stufe bleibt
T3, weil die Medientabelle ungeklaert ist.
Befund 1: die Kennung bei 0xAB wurde nie geprueft
-------------------------------------------------
Der Dateikopf von `uft_dim.c` sagte „0xAB 1 Overtrack flag", und weder
`dim_probe()` noch `dim_open()` sahen dort hin. Bei 0xAB steht aber die
**Kennung des Formats**.
Gemessen am Vorzustand, mit einem Puffer aus 512 Nullbytes und einer
plausiblen Dateigroesse:
ohne Kennung : Sonde JA, Konfidenz 45
mit Kennung : Sonde JA, Konfidenz 45
Die Sonde nahm also **jede** hinreichend grosse Datei an, die mit einer
Null beginnt — und die Kennung machte keinen Unterschied.
Drei Stellen sind sich einig, wo sie steht:
MAME `dim_dsk.cpp` read_at(io, 0xab, h, 16);
strncmp(h, "DIFC HEADER", 11) == 0
src/formats/pc98/dim.c:37 // 0xAB..0xB7 = "DIFC HEADER " (13 bytes)
memcmp(hdr + 0xAB, mark, 13) == 0
src/formats/misc/dcp_dcu.c:51 nennt dieselbe Kennung
**Die richtige Pruefung lag in der Datei, die niemand ruft** —
`src/formats/pc98/dim.c` steht in `docs/orphan_baseline.txt`. Das ist
in dieser Runde der **dritte** Fall dieser Gestalt nach `udi`
(MF-1015: die richtige Pruefsumme lag in `uft_udi.c`) und `scl`
(MF-1014: das TR-DOS-Layout kannte `uft_trd.c`).
Genommen werden **11** Byte, nicht 13: MAME vergleicht 11, `pc98/dim.c`
13. Die schwaechere Annahme nimmt auch eine Datei an, bei der die zwei
Leerzeichen fehlen — und der Test haelt das fest.
Befund 2: `open` prueft die Dateigroesse nicht
----------------------------------------------
`dim_probe()` verlangte `file_size >= 256 + cyl*heads*spt*ss`,
`dim_open()` verlangte nichts davon. Wer eine DIM ueber `open` anfasst,
bekam fuer eine zu kurze Datei die volle angesagte Geometrie und
Sektoren, die nicht in der Datei stehen.
Was NICHT geaendert wurde, und warum
------------------------------------
**Die Medientabelle bleibt, wie sie ist, und `dim` bleibt T3.**
Drei Umsetzungen, drei Tabellen, keine zwei gleich (gemessen):
Medienbyte hier pc98/dim.c MAME
0x00 8 spt/1024 9/512 8/1024
0x01 8/1024 9/512 9/1024
0x02 8/1024 15/512 15/512
0x03 8/1024 18/512 9/1024
0x09 18/512 abgewiesen 18/512
0x11 8/512 abgewiesen 26/256
0x19 9/512 abgewiesen Vorgabe 8/1024
Dazu die Spurzahl: MAME nimmt fuer **jeden** Typ 77, das registrierte
Plugin 77 oder 80 je Typ, `pc98/dim.c` immer 80. Uebereinstimmung gibt
es allein bei `0x02` — und dort widerspricht das **registrierte**
Plugin beiden anderen.
Bei fuenf von sieben Werten waere ein Umschreiben auf eine Quelle eine
Wette, und genau so sind die fuenf fabrizierten Parser entstanden
(FMT-2/3/10/11/12). Die Tabelle wird deshalb **festgenagelt, nicht
bewiesen**: `tests/test_dim_kennung_und_groesse.c` haelt den heutigen
Stand, damit eine Aenderung absichtlich geschieht. Der Test sagt das
ausdruecklich von sich.
**Was die Groessenpruefung dabei leistet:** ist ein Tabelleneintrag
falsch, passt die angesagte Geometrie nicht zur Dateigroesse, und die
Datei wird abgewiesen statt falsch zerlegt. Sie ersetzt die Klaerung
nicht, aber sie macht den Fehler **laut statt still**.
Gefuehrt als **P3-325** mit dem, was ihn aufloesen wuerde: eine echte
DIM je Medientyp (dann entscheidet die Dateigroesse ohne Werkzeug), die
Formatnotizen, auf die sich `pc98/dim.c` beruft, oder ein
X68000-Emulator, der DIM schreibt.
Und die Referenzzeile trug nicht
--------------------------------
Im Dateikopf stand „Reference: X68000 DIM format specification" — ohne
Fundstelle. Eine Referenz, die man nicht nachlesen kann, ist keine
(MF-636: eine Attribution ist eine Aussage). Jetzt stehen MAME und
`pc98/dim.c` mit Pfad und Zeile da.
Abnahme
-------
`tests/test_dim_kennung_und_groesse.c` — **10 gruen, 0 rot**:
512 Nullbytes werden abgewiesen
mit Kennung angenommen, Konfidenz 88 (vorher 45)
ein verfaelschtes Byte der Kennung laesst sie fallen
die zwei Leerzeichen dahinter sind nicht verlangt
open weist eine Datei ohne Kennung ab
die Daten beginnen hinter dem 256-Byte-Kopf
eine zu kurze Datei wird abgewiesen
die sieben Medienwerte liefern den heutigen Stand (festgenagelt)
ein unbekanntes Medienbyte wird abgewiesen
Kennzahl (Regel 9): **keine.** `dim` bleibt T3, und das ist der Punkt —
zwei Defekte sind weg, aber die Frage, die die Stufe entscheidet, ist
nicht beantwortet. Eine Hebung waere hier eine Zusage ohne Deckung.
Nebenbefund fuer das Gedaechtnis: `cat -A` im Bash-Werkzeug hat die
CRLF-Zeilenenden dieser Datei **nicht** angezeigt, und ein
Textmuster-Ersatz schlug deshalb zunaechst fehl. Verlaesslich ist nur
Python mit `newline=""`.
Tests: 401/401 gruen (ein benannter Skip: test_freezer).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHdqfaZ5RFb1HPcw7NYoEY
Copy file name to clipboardExpand all lines: docs/OPEN_ITEMS.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -516,6 +516,7 @@ offen).
516
516
| P3-322 | **SCL liest jetzt richtig — aber die zwei Dinge, die danach offen bleiben, sind benannt statt vergessen.** (a) Die SCL-Archiv-API `uft_scl_parse()` / `uft_scl_get_file()` / `uft_scl_build()` in `src/formats/scl/uft_scl.c` (226 Z.) hat **keinen Produktions-Aufrufer**; das Plugin baut die Diskette selbst aus und braucht sie nicht. (b) Fuer **T1b** fehlt eine SCL von fremder Hand im Korpus | **gemessen MF-1014.** Zu (a): `grep` ueber `git ls-files` findet ausserhalb von `src/formats/scl/` und `include/` nur **eine** Nennung, und die ist ein Kommentar in `tests/test_schranken_die_nie_greifen.c`. Seit MF-1014 ist die API **richtig** (das verschluckte Eintragsbyte 12 ist behoben und durch einen Rundlauf bewacht) — aber richtig und unerreichbar. Klasse **P3-223**: ein Modul, dessen Tests es rufen, saettigt das Modul-Tor — und **der Test aus MF-1014 ist jetzt genau dieser Aufrufer**, was den Fall besonders klar macht: die Erreichbarkeit hat sich durch die Reparatur nicht verbessert, nur die Richtigkeit. Zu (b): kein `.scl` im Korpus, und **kein Orakel-Binary verfuegbar** — `samdisk`, `hxcfe`, `gw`, `floptool` sind in dieser Umgebung keines im PATH und keines ueber die Umgebungsvariablen des Registers gesetzt | ⚠ **offen, beide Teile mit Kennzahl (Regel 9).** Zu (a) bewegt **keine** der vier Zahlen — Fundus, nicht Auftrag. Der ehrliche naechste Schritt ist eine **Entscheidung, nicht Arbeit**: entweder bekommt die API einen Aufrufer (ein Archiv-Browser fuer SCL waere die natuerliche Fassung, denn genau das ist eine SCL), oder sie wird nach MF-699 („erst der Ersatz, dann die Loeschung“) entfernt. Nicht entscheiden heisst sie behalten, und dann steht sie in der naechsten Runde wieder hier. <br>Zu (b) bewegt **T3 ↓** beziehungsweise T2→T1b und ist **Beschaffung** (P3-2): `hxcfe` kann SCL laden **und** schreiben (`scl_loader.c` liegt geklont vor), `samdisk` liest es. Ein Binary von einem der beiden genuegt; UFTs Leser ist gegen **SAMdisk** geschrieben, also muss nach der Richtungsregel aus MF-806 **hxcfe erzeugen** und SAMdisk oder UFT zuruecklesen — nicht umgekehrt |
517
517
| P3-323 | **UDI liest jetzt echte Dateien — aber seine Taktmarken sind erreichbar, nicht verwertet.** UDI speichert je Spur **dekodierte Bytes plus eine Taktmarke je Byte** (0 = normaler Takt, 1 = Marken-Takt, also die „missing clock“ der Adressmarken). Seit MF-1015 gibt `uft_udi_track_clk()` sie heraus — aber nichts im Baum wandelt sie in einen echten MFM-Bitstrom um, wie SAMdisk es mit seinem `BitstreamTrackBuilder` tut | **gemessen MF-1015.** `udi_read_track()` liefert die Datenbytes in `track->raw_data` mit `raw_bits = tlen * 8`. Das ist fuer UDI richtig gezaehlt (Datenbits, keine MFM-Zellen), aber es ist **kein Bitstrom**: ohne die Taktmarken sind die Adressmarken `0xA1`/`0xC2` nicht von gleichlautenden Datenbytes zu unterscheiden, und kein Dekoder findet die Sektorkoepfe. Verloren ist dabei nichts — die ganze Datei liegt im Puffer, und die Marken sind seit MF-1015 abrufbar. Was fehlt, ist ein Encoder, der ein Byte **mit vorgegebenem Taktmuster** ausgibt (`0xA1`/`0x0A`, `0xC2`/`0x14`); `src/core/uft_mfm_encoder.c` arbeitet sektorweise und kennt das nicht | ⚠ **offen, Kennzahl benannt (Regel 9).** Bewegt **keine** der vier Zahlen unmittelbar — `udi` steht seit MF-1015 auf T2, und die Wandlungsmatrix hat keinen UDI-Eintrag. Es ist der Baustein, der aus UDI eine **Fluss-Quelle** machen wuerde: erst dann traegt das gesetzte `UFT_FORMAT_CAP_FLUX` mehr als die Verlustmeldung, und erst dann koennte ein UDI→HFE-Pfad in die Matrix (dort waere die Kennzahl *angebotene Wandlungspfade* ↑). <br>**Zwei Dinge, die vorher zu messen sind:** (a) ob der bestehende IBM-MFM-Encoder (`uft_mfm_encoder.c`, seit MF-938 als **vorhanden** belegt) um ein Byte-mit-Takt erweitert werden kann, ohne seinen gepruefen Sektorpfad zu beruehren; (b) ein UDI von fremder Hand im Korpus, sonst ist der erzeugte Bitstrom nur gegen die eigene Umsetzung geprueft — die Selbstbestaetigung aus MF-992. Beschaffung: die Spezifikation nennt Alex Makeev als Urheber; im **geklonten Stand** von HxC (`tools/uft-scout/work/HxCFloppyEmulator`) gibt es **keinen UDI-Lader** — gemessen mit `find` ueber den ganzen Baum, Treffer nur in `expat` und `zlib`. Welches freie Werkzeug UDI schreibt, ist damit **nicht geklaert**, und das ist der erste Schritt, nicht der Code |
518
518
| P3-324 | **Zwei Referenzen, zwei verschiedene Adressmarken fuer TRS-80-Spur 17 — und keine Messung, die entscheidet.** Auf einer TRS-80-Diskette traegt Spur 17 das Verzeichnis, und ihre Sektoren sind mit einer **nichtstandardmaessigen** Datenadressmarke formatiert. Tim Mann nennt `0xFA`, MAME setzt `FM_DDAM` — das ist `0xF8`, „deleted“ | **gemessen MF-1016.** Tim Mann, `dskspec.html`, woertlich: „All sectors on track 17 are formatted with the nonstandard data address mark **0xFA**, indicating a TRSDOS 2.3 directory.“ MAME, `formats/trs80_dsk.cpp`: `int jv1_format::get_track_dam_fm(...) { return (track == 17 && head == 0) ? FM_DDAM : FM_DAM; }`. Beide sind sich einig, DASS die Marke nichtstandardmaessig ist; WELCHE es ist, sagen sie verschieden. **Fuer den heutigen Leser folgt daraus nichts**, denn in einer JV1-Datei steht ueberhaupt keine Adressmarke — sie ist ein reiner Sektorabzug, und beide Werkzeuge SYNTHETISIEREN die Marke erst beim Erzeugen eines Flussbildes | ⚠ **Fundus, nicht Auftrag (Regel 9).** Bewegt keine der vier Zahlen. Die Frage wird erst scharf, wenn JV1 in einen Bit- oder Flussstrom geschrieben wird — dann steht die Marke wirklich in der Ausgabe, und eine falsche macht die Verzeichnisspur fuer ein echtes TRSDOS unlesbar. <br>**Was sie entscheiden wuerde:** ein echter TRS-80-Flussabzug im Korpus (dort steht die Marke auf der Diskette, nicht in einem Werkzeug) — derselbe Weg wie MF-869 beim FM-Pfad. Solange der fehlt, bleibt die Divergenz **benannt** statt entschieden; eine der beiden auszuwaehlen waere eine Wette, und `jv3` traegt seine DAM-Kodierung ohnehin ausdruecklich im Flagbyte (Bits 5-6), also gibt es dort eine messbare Gegenprobe |
519
+
| P3-325 | **Drei Umsetzungen der DIM-Medientabelle, drei verschiedene Tabellen, und keine zwei stimmen ueberein.** Das Medienbyte an Versatz 0 einer X68000-DIM sagt Sektoren je Spur und Sektorgroesse. `src/formats/dim/uft_dim.c` (registriert), `src/formats/pc98/dim.c` (verwaist) und MAMEs `formats/dim_dsk.cpp` widersprechen sich bei **fuenf von sieben** Werten | **gemessen MF-1019:**<br>`0x00` — hier 8 spt/1024, pc98 9/512, MAME 8/1024<br>`0x01` — hier 8/1024, pc98 9/512, MAME **9**/1024<br>`0x02` — hier 8/1024, pc98 **15**/512, MAME **15**/512<br>`0x03` — hier 8/1024, pc98 18/512, MAME **9**/1024<br>`0x09` — hier 18/512, pc98 abgewiesen, MAME 18/512<br>`0x11` — hier 8/512, pc98 abgewiesen, MAME **26**/256<br>`0x19` — hier 9/512, pc98 abgewiesen, MAME Vorgabe 8/1024<br>Dazu die Spurzahl: MAME nimmt fuer **jeden** Typ 77, das registrierte Plugin 77 oder 80 je Typ, `pc98/dim.c` immer 80. Uebereinstimmung gibt es allein bei `0x02` (spt 15) — und dort widerspricht das **registrierte** Plugin beiden anderen | ⚠ **offen, und ausdruecklich NICHT geraten.** Bei fuenf von sieben Werten waere ein Umschreiben auf eine Quelle eine Wette — und genau so sind die fuenf fabrizierten Parser entstanden (FMT-2/3/10/11/12). Deshalb ist `dim` mit MF-1019 **T3 geblieben**, obwohl der Commit zwei echte Defekte behoben hat: die fehlende Kennungspruefung und die fehlende Groessenpruefung beim Oeffnen. <br>**Was MF-1019 stattdessen getan hat:** die Groessenpruefung macht einen falschen Tabelleneintrag **laut statt still** — passt die angesagte Geometrie nicht zur Dateigroesse, wird die Datei abgewiesen. Und `tests/test_dim_kennung_und_groesse.c` **nagelt** den heutigen Stand fest (ausdruecklich als Festnagelung bezeichnet, nicht als Beweis), damit eine Aenderung absichtlich geschieht. <br>**Was es aufloesen wuerde, in dieser Reihenfolge:** (a) eine echte DIM je Medientyp — dann entscheidet die Dateigroesse, denn Spurzahl × Koepfe × spt × Sektorgroesse + 256 ist pruefbar, ohne dass ein Werkzeug mitspielen muss; (b) die Formatnotizen, auf die sich `pc98/dim.c` beruft („based on pc98.org notes“) — als **Spec** nach MF-695 lesbar, aber die Fundstelle steht dort nicht; (c) ein X68000-Emulator, der DIM selbst schreibt. Kennzahl: **T3 ↓** fuer `dim`, blockiert auf Beschaffung (P3-2) |
0 commit comments