# Chapter 01 u32calc - r001 HD61 handoff

STATUS: NEW SOURCE CANDIDATE ONLY. NOT ASSEMBLED. NOT EMULATOR-TESTED. NOT HARDWARE-TESTED.
TARGET: PB-2000C ONLY. No AI-1000 compatibility claim.
SOURCE: src/apps/u32calc/u32calc_r001.s
SOURCE_SHA256: 13788f0e55b332dcaf25e22bc3eb713f9f25e221897bee618ed293b23dd6c677
FROZEN_D4: archive/CS617_Numeric_CALC_FINAL.zip (read-only, unchanged)
FROZEN_D4_SOURCE_SHA256: 318eb6aca4c6a15421f9fe7ef79ad00bf27b1b3b0fe6760fb4b31e48a4ba315b
ROM_ID_CANDIDATE: 34 10 at both 0008-0009 and 0DB9-0DBA

## Alex: first assemble, then test

1. Assemble the exact `src/apps/u32calc/u32calc_r001.s` using HD61700 ASSEMBLER Rev. 0.45, invoking it from the `src/apps/u32calc/` working directory so its `../../lib/*.inc` includes resolve. Do **not** edit `src/`. Keep the source revision stable throughout this handoff.
2. In **your own** `build/` directory, return both the full `.bin` and `.lst`. Preferred names are `u32calc_r001.bin` and `u32calc_r001.lst`, or name the actual files explicitly if HD61 picks other names. Do not replace the frozen D4 evidence.
3. Inspect the assembler result. If it errors, return the **actual** listing/error text unchanged, and stop. No need to test a failing candidate.
4. On error-free assembly, run the read-only `src/test/verify_u32calc_r001.py` on the returned files if convenient. Otherwise just return them; Sol will perform the audit after you say `Done`.

## Runtime checklist after a clean assembly

Use the PB-2000C emulator first; physical PB-2000C is separately qualified only if actually tested.

- **Fresh boot:** complete 65,536-byte image recognized; `Xandrian Labs`, `CS617 U32 CALC`, `version r001` are visible. It continues automatically in approximately 2-3 seconds without EXE. Note actual timing, not just 'looks good'.
- **Arithmetic smoke:** `7 / 2 = 3`, `7 % 3 = 1` (red S, then `]` for `%`), unsigned wrapping `0 - 1 = 4294967295`; divide by zero reports `DIVIDE BY ZERO`; an eleventh decimal digit is rejected. Preserve exact observed keys and result.
- **Warm BRK on unfinished work:** enter several digits (for example OP1 `12345`), press BRK. Calculator returns **without splash**, retains the operand, and can continue. This is the key behavioral witness that `CLR_STATE` was skipped.
- **Warm BRK on result:** compute an expression and BRK. Result remains represented and the application can perform another operation.
- **MENU:** press MENU while entering a value. Expect `CS617 - MENU` with FK1/EXE choices. EXE or FK1 returns to calculator with the original value preserved; no splash. Menu should not show an editing cursor. Press BRK while in the menu and report behavior.
- **CAL:** not implemented here. Record the actual response, verify no accidental cold initialization or corruption, but do not infer universal historical CAL semantics.
- **Card owner:** after core behavior passes, test an ordinary transition with a different known language card and back if practical; report whether initialization/ownership is sensible. Do not treat a simple return screen as proof of RAM compatibility.

## High-priority risk

D4's raw direct scanner used a restart-to-MAIN on physical BRK, and its late ROM vector did the same. r001 redirects both to `APP_ENTRY`. Chapter 08 showed that firmware BRK may reach the correct numerical address in the *wrong ROM bank*. An apparent normal return or menu **does not prove** the firmware/bank route. If BRK crashes, hangs, returns with lost state, or shows splash, preserve the exact ROM, listing, and emulator observation, and report it. We will diagnose rather than invent a passing result.

The timed splash uses a Tiny-style stable read of the `TM` register. Its actual duration and impact on OFF/keyboard behavior are runtime questions, not assumed facts.

## Source ownership

Sol writes `src/`, Alex writes `build/`. Sol does not touch `build/` even for cleanup. Alex says **Done** only when the returned artifacts and observations are in his build directory (or tells Sol that the assembler failed).