HJ-RESER floppy filesystem analysis
==================================

The decoded raw image can be parsed as a FLEX filesystem. The original
server image was not changed. This archive includes an exact byte copy as
original.img, with its original server filename recorded in report.json.

Image SHA-256:
09683af63fceb7e5ed0f5fba32f88ef56ac05b62016a1245545d5b4fada4a43d

Geometry and volume
-------------------
Image: 733,184 bytes = 2,864 sectors of 256 bytes.
The successful sector mapping is:
  Track 0: 20 sectors total (consistent with 10 per side).
  Tracks 1-79: 36 sectors each (consistent with 18 per side).
  Offset for track 0, sector s: (s - 1) * 256.
  Offset for track t > 0, sector s: (20 + (t - 1)*36 + s - 1)*256.
Tracks are zero-based; filesystem sector numbers are one-based in this map.
This is a decoded, sector-linear image; it contains no physical interleave,
CRC status, flux timing or reliable read-quality information.

Volume label: HJ-RESER
Volume number: 11
Volume date: 1988-01-18 (interpreting stored year 88 as 1988).
The SIR declares highest track 39, highest sector 36: a 40-track filesystem.
The raw image nevertheless includes 80 tracks. This mismatch is preserved,
not silently repaired or cropped. Extra tracks may contain earlier disk
contents; the cause and history cannot be established from this image alone.

Live directory
--------------
FLEX_DD.SYS     26 sectors   6552 payload bytes  1984-10-25  entry $C850
COPY.CMD         5 sectors   1260 payload bytes  1981-03-09  entry $C100
DELETE.CMD       2 sectors    504 payload bytes  1980-01-30  entry $C100
DIR.CMD          5 sectors   1260 payload bytes  1989-06-16  entry $C100
LIST.CMD         3 sectors    756 payload bytes  1980-01-30  entry $C100
RENAME.CMD       1 sectors    252 payload bytes  1980-01-30  entry $C100

All six file chains match their directory sector count and ending address.
Their logical sector numbers run consecutively from 1. There are no file
cross-links, no overlap with the free chain and no unaccounted-for data
sectors inside the declared filesystem. The directory chain has 16 sectors.
42 allocated + 1,362 free = 1,404 data sectors (39 tracks x 36).
No deleted directory entries are present in the live directory.

The recovered OS payload contains the exact banner:
  FLEX - Version 2.8:4 -
This is the embedded banner, not a claim that the disk label's FLEX 9_0
text is wrong. CPU family, distributor naming and software release labels
must be distinguished. The kernel also contains machine-specific code,
including appended load records; it has not been executed or boot-tested.

files/ contains each file's concatenated 252-byte sector payloads, with
sector linkage/record headers removed, including original null padding.
FLEX does not supply an exact byte-length field in these directory entries.
These are FLEX load-record files, not flat executable images.
load-records/ contains separate memory ranges decoded from those records.
Null records between appended modules are skipped. Transfer addresses and
record boundaries are in report.json. Gaps are not filled or invented.
All six payloads parse successfully as FLEX binary load records.

Additional source recovery outside the live filesystem
-----------------------------------------------------
Tracks 40-79 contain 566 sectors with nonzero payloads. They are outside
the filesystem's declared extent and are not live named directory files.
Following links from logical record 1, requiring consecutive record numbers
and a terminating 00/00 link, recovered 53 complete text chains spanning
365 sectors. There are 52 distinct payload hashes, so some are duplicates
or different saved versions, not necessarily 53 different original files.

The text includes assembly source with NAM labels such as NUMREG, GETKEY,
WHICHKEY, DECODE, NOKEY, READCHAR, WRITESTR, INITPIA and VISATID. Many source
headers say hjoel and give dates in 1987-88. These are strong indications
of Hakan's development work, but the original directory filenames and
file dates cannot be recovered from these chains alone. NAM is a source
label, not proof of the filename.

There are also 18 partial candidate chains. Recovery stops on a broken
sequence, cycle, or link outside the extra area. Their extracted text is
explicitly marked partial and must not be assumed complete.

extra-area-recovery/ contains:
  unnamed-TRACK-SECTOR.payload : complete chain, exact 252-byte payloads.
  unnamed-TRACK-SECTOR.txt     : readable text from the same chain.
  partial-TRACK-SECTOR.*       : incomplete chain prefix, as described above.
  index.csv                  : complete-chain labels, source dates, hashes.
  recovery.json              : sector-by-sector provenance and failure reasons.
TRACK and SECTOR in these generated names are hexadecimal.
Text conversion expands FLEX 09/count space compression and converts CR
line endings; it strips null padding and stops at 1A if present. Original
payloads remain alongside the readable copies. Files were not executed.
There may be further fragments not starting at logical record 1; this is
conservative linked-chain recovery, not exhaustive forensic reconstruction.

Reproduce (Python 3, standard library only)
------------------------------------------
python3 parse_flex.py original.img fresh-output
python3 recover_extra.py original.img fresh-output

The parser's geometry is specific to this image layout. It does not
attempt to guess other image formats or change any source bytes. Compare
the fresh report's SHA-256 and allocation checks with report.json.

Format references
-----------------
Technical Systems Consultants, FLEX Advanced Programmer's Guide:
https://deramp.com/swtpc.com/Setton/apg09.pdf
See printed pages 43-46 for disk initialization, directory/data sectors,
binary records and text files. Directory entries follow FCB bytes 4-27.
The extraction was checked against this documented format and the actual
sector linkage and record sequence in the image.

Neal Crook's own FLEX image utility and implementation notes:
https://github.com/nealcrook/multicomp6809/blob/master/flex/flex_vfs
https://github.com/nealcrook/multicomp6809/wiki/FLEX-internals
Used as a comparison for SIR offsets and null padding between binary modules;
no third-party code was run against or allowed to modify this image.

CPU identification follow-up
----------------------------
Boot loader: 6809 (TFR A,DP reached at raw image offset $000C).
All six live binaries: 6809 (see byte-checked examples in cpu-evidence.json).
FLEX_DD.SYS transfer address $C850 starts ORCC #$50; LDS #$C080.
38 of 53 complete source chains have distinctive 6809 instructions or
addressing forms; 15 generic short chains are contextual identifications,
not independent instruction-set proof. cpu-evidence.json lists every
source hit with its decoded-text line number. No boot test was performed.
