docs: record M6c (Data Matrix, PDF417) results

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2 files changed, 21 insertions, 0 deletions

diff --git a/docs/DEVELOPER_GUIDE.md b/docs/DEVELOPER_GUIDE.md
index 14c4e05..2646e1b 100644
--- a/docs/DEVELOPER_GUIDE.md
+++ b/docs/DEVELOPER_GUIDE.md
@@ -78,6 +78,8 @@ The simulator is a GTK program. The scripts start it on a virtual display (Xvfb
 - Assigning a value above 255 to a ByteArray element throws; mask with `& 0xFF`.
 - Native HMAC supports only SHA-256; HMAC-SHA1 and HMAC-SHA512 go through `Hmac.generic`.
 - Function calls are expensive in the VM; hot loops inline small helpers (SHA-512 went 37 % faster that way).
+- **Long `&&` chains with `instanceof`** can make the compiler's type checker run out of memory: one test condition needed more than 6 GB until it was split into separate `if` statements.
+- **JSON resources over 8 KB** produce a compiler warning, so large tables are split; the PDF417 patterns are three resources, one per cluster.
 - **The watchdog** ("Code Executed Too Long") is not enforced in unit-test runs, but it is in normal simulator runs, with the device's `watchdogCount` per event: 120,000 bytecodes on the Forerunner 255/255S, 240,000 on the others. M4 measured what it means. 200 byte-wise PBKDF2 iterations in one event tripped it on the 255S, and so did two SHA-512 codes in one draw. So:
   - Anything long runs as a `Jobs.Job` with a bounded step (`Kdf.ITERATIONS_PER_STEP` = 100).
   - Screens compute at most one SHA-512 code per event, in a timer event separate from drawing.
diff --git a/docs/TESTING.md b/docs/TESTING.md
index ca72af3..cf9bee0 100644
--- a/docs/TESTING.md
+++ b/docs/TESTING.md
@@ -26,6 +26,24 @@ Test devices (`TEST_DEVICES`): Forerunner 255S (weakest: 218 px round MIP, butto
 
 ## Results
 
+### M6c, 2026-10-20 (Data Matrix and PDF417, in 0.6.0)
+
+Monkey C unit tests: 117 per device.
+
+1. **Reference comparison** (`make codes`):
+   - **Data Matrix:** 27 symbols identical to ppf.datamatrix in ASCII mode, from 10 x 10 to 144 x 144, including multi-region and 10-block interleaved sizes. For 1,100 digits at 88 x 88, the watch, ppf and zint (through zxing-cpp) agree bit for bit.
+   - **PDF417:** 27 symbols identical to pdf417gen at fixed columns and levels. They cover all four text submodes, digit runs below and above 13, UTF-8 bytes, exact 6-byte groups, levels 0 to 6 and 1 to 12 columns.
+2. **Decoding with zxing-cpp:**
+   - 10 Data Matrix codes, including Base256 UTF-8, Upper Shift, 88 x 88 and 144 x 144.
+   - 5 PDF417 codes laid out for the Forerunner 255S, Forerunner 70 and Venu Sq 2 screens.
+3. **Screenshots.** The UI flow opens a Data Matrix card and a PDF417 card after the QR card. All decode on all seven watches, the PDF417 at 1 px per module on the 255S.
+
+Found and fixed along the way:
+
+- **ppf padding bug:** see README 12.4.
+- **Compiler out of memory:** one long `&&` chain of `instanceof` tests in a test made the Monkey C compiler run out of memory (more than 6 GB), and splitting the chain fixed it.
+- **Watchdog on the 255S:** packing an 86 x 87 PDF417 matrix for the cache in the same event as the encoder's last step tripped the watchdog. PDF417 rows are now stored once with a row height of 3, packing does 8 modules per loop, and the cache is saved in its own timer event.
+
 ### M6b, 2026-10-20 (QR, in 0.6.0)
 
 Monkey C unit tests: 111 per device.
@@ -167,3 +185,4 @@ Things the simulator can't verify, done by you on the Forerunner 70. The checkli
 - [ ] M5: in Garmin Connect, paste a few `otpauth://` links of test accounts (not your real ones) into the Import fields, turn "Import now" on and save. Check the result on the watch and in the Result field. Also check that the text fields are emptied afterwards: this answers part of the M1 question.
 - [ ] M6a: with "Debug: demo entries", open "Gym card" (an EAN-13). Scan it with your phone's camera, or a shop scanner if you can, indoors and outdoors. Tell me whether it reads.
 - [ ] M6b: open "Member QR" (a demo entry) and scan it with your phone's camera. The first opening encodes it; note roughly how long that takes. The second opening should be instant (cache).
+- [ ] M6c: scan the "Parcel" (Data Matrix) and "Ticket" (PDF417) demo cards with a phone app that reads them, for example the zxing-based "Barcode Scanner".