CADKEY files do not become useful just because a parser can read bytes. The useful question is narrower: what can be recovered reliably, and what still needs review?
This series follows that boundary across a 28-file Gen 2 corpus. The practical output is inspectable DXF, not a claim that every old CADKEY solid has become a modern parametric model.
The short version
- Gen 2 PRT files are heterogeneous binary record streams beginning with
A5 0F F0 5A. - Entity geometry uses little-endian doubles and a shared header.
- Type 2 records are 3D lines; types 1 and 3–14 use a common radial curve layout.
02 02subtype-1 records contain real COEDGE start/end vertices.- Plane IDs separate profile geometry from construction/projection clutter.
- The native CADKEY DXF exporter is the strongest practical oracle.
- FACE ownership, raw NURBS evaluation, and manufacturing-ready solids remain unresolved.
Part 2: What worked, what failed, and where the evidence stops →
What worked
1. Marker-based record parsing
The file is not one opaque blob. Records have markers and size fields, but different record families are interleaved. The safe rule is simple: find a candidate marker, validate its subtype and size, then advance by the record’s own size. Fixed-stride scans and loose byte patterns produced false records.
2. Cross-file checks
A field became a format fact only when it survived multiple files and a geometry check. The most useful examples are:
- the shared entity header at
marker + 20; - little-endian six-double geometry at
+52; - COEDGE vertices at
+72and+96; - cubic coefficient records whose evaluated endpoints match their stored endpoints.
3. The original exporter
CADKEY 98 can load representative PRT files under the controlled Wine runtime and export native DXF. That output is not a raw copy of PRT records—it is the application’s post-load representation—but it is an excellent comparison artifact.
What did not work
- Screen automation as the primary pipeline: VNC, focus-dependent keystrokes, and coordinate clicks were too fragile. Useful for observation; poor for unattended conversion.
- Loose marker searches: payload bytes looked like record headers. Size and subtype validation are mandatory.
- Treating SDK enums as file layouts: the SDK describes API entities, not the serialized database.
- Calling every six-double curve a NURBS: the verified entity records are radial curve storage; the raw surface blocks remain unresolved.
- Calling a renderable mesh a solid: a preview is not proof of watertight topology or manufacturing readiness.
The deliverable
For archive recovery, the honest deliverable is:
original PRT
→ native or parser-generated DXF
→ per-file report
→ explicit exceptions and review notesDXF is the primary inspection artifact. Images are previews. A normalized web scene is a presentation derivative. A recovered drawing is not automatically a modern solid, a STEP model, or a manufacturing-ready package.
Evidence boundary
The parser currently gives us reliable entity geometry, plane-aware filtering, COEDGE vertex networks, and a validated cubic coefficient decode. The following remain open:
- FACE-to-boundary ownership;
- raw NURBS control points and surface evaluation;
- ACIS-object identity mapping;
- TYPE15 semantics and some tail records;
- units, tolerances, and design intent unless independently established.
The maintained Gen 2 format specification contains offsets and corpus notes. The series keeps the story short; the specification keeps the details auditable.