./runtests.shmust stay green.cd test && node runner.jsmust stay231/233.CALLMandRTMremain explicitly deferred and untouched.
The next CPU-facing block is now explicit.
Immediate next CPU blockers:
MOVEM- replace the current stub with real register-mask semantics
- cover register-to-memory and memory-to-register paths properly
NBCD- replace the current stub with real decimal negate semantics
- verify
X,C,Z, and result behavior
ABCD- replace the current stub with real decimal add semantics
- cover register and predecrement-memory forms
- memory rotates
ROLmemoryRORmemoryROXLmemoryROXRmemory
Acceptance for this CPU block:
- no semantic stubs remain for the above instructions
- targeted CPU tests are added or strengthened for each one
./runtests.shstays greencd test && node runner.jsstays231/233CALLM/RTMremain deferred
The small j68 software environment has reached a clean checkpoint:
- ROM monitor is stable
source/+loadasmworkflow is stable- host-built binaries in
work/programs/build intosave/ - reusable guest-side output helpers now exist
- guest-side polling input helpers now exist
- a minimal cooperative guest runtime now exists
- visible formatted output works from real 68k binaries
- interactive guest input works from the real launcher
Current reusable guest-side helper layer:
work/programs/lib/console.incputcputsnewlineputhex32puts_hex32
work/programs/lib/input.incgetcput_promptreadline
work/programs/lib/task.incscheduler_startyieldtask_exit
Current visible proof binaries:
hello_uart.binputhex.binprint_pi16.binprint_status.binram_checksum.binpi16_nilakantha.binecho_line.bincoop_demo.bin
This is now a proper little software environment, not just isolated probes.
The next clean subsystem is input polish and then interrupt-driven input, not CALLM/RTM.
Current completed order:
- guest-side input helpers
getc- prompt helper
- simple line read
- polling against UART status/data
- one interactive demo binary
echo_line.bin
- minimal cooperative multitasking
- fixed two-task setup
- explicit
yield coop_demo.bin
Recommended next order:
- input niceties
- backspace handling
- bounded line editing polish
- interrupt-driven input
- cleaner IPL exposure first
- no JS-side scheduler
- richer cooperative demos
- still no preemption
Immediate acceptance for the next block:
- guest input remains polling-clean in the launcher
- a richer interactive demo works end to end
- cooperative runtime remains guest-side only
The machine has a useful memory API and device map, but it is still growing from a memory map into a 68k-style external bus model.
The most important missing semantics are:
FC[2:0]IPL[2:0]BERR
Near-term impact:
FC[2:0]- useful for fuller machine fidelity
- not blocking the first polling-based input path
IPL[2:0]- should be exposed more cleanly before interrupt-driven input work
BERR- important for machine fault semantics
- not blocking the first happy-path input helpers
Related lower-priority concepts that should remain deferred until needed:
ASUDS/LDSDTACKVPA/VMARESET/HALT- bus arbitration (
BR/BG/BGACK)
Keep the public API:
read8/read16/read32write8/write16/write32
Under that, model transactions with:
addrsizewritevaluefciplkind- result fields such as:
valueberr
The bus must distinguish at least:
- user data
- user program
- supervisor data
- supervisor program
- instruction fetch vs data access
- Add transaction metadata under the current bus API.
- Expose resolved current IPL cleanly.
- Add machine-visible
BERRresult path. - Leave timing and handshake details for later.
For the next implementation block, input may start in polling mode without waiting for more IPL work. The IPL exposure work becomes more important when moving from polling input to interrupt-driven input.
- existing tests still pass
- add focused system tests for:
- transaction carries
fc - unresolved access produces
berr - highest active
IPLwins
- transaction carries
DTACKtimingAS/UDS/LDSpin modelingDMA- storage/sound expansion
- more device families
CALLM/RTMFPUwork
68K-Monitor.X68 guest bring-up is paused at the correct boundary:
- machine map and UART remap are no longer the first blocker
- guest RAM/layout rebase is no longer the first blocker
- startup reaches real guest code
Current exposed blocker:
FAULT PC=000917FC OP=C240
This is AND.W D0,D1 reached from the adapted guest monitor.
Required next CPU-facing work:
- build a tiny standalone repro around
AND.W D0,D1 - determine whether the problem is:
- decode missing
- execute missing
- PC advance corruption
- flags or register writeback
- only return to the guest monitor after that path is understood
Guest adaptation must stay paused here to avoid turning porting into repeated workarounds for core gaps.