CALL/RTC trap: no PPAGE/DPAGE/EPAGE banking; 64 KiB flat address space only #3

New issue

Open

opened 2026-08-24 11:42:45 +02:00 by sid · 0 comments

sid commented

2026-08-24 11:42:45 +02:00

Owner

Summary

CALL and RTC — the CPU12 instructions for calling subroutines in expanded
(banked) memory — decode but trap (M68HC12.cs:591-594). There is no
implementation of the program-page register PPAGE (nor DPAGE/EPAGE for
data), so the model is limited to a flat 64 KiB address space.

Current behavior

case "CALL":
case "RTC":
    Trap();
    break;

ComputeCallAddress (M68HC12.cs:878-891) fetches and discards the CALL
operand bytes (extended or indexed form plus the PPAGE operand byte) and never
applies the page. The PAGE register exists in the register set (index 8 in
M68HC12Registers, exposed to GDB as page) but is never read or written by
any instruction.

Impact

Programs using CALL/RTC to reach code above 64 KiB cannot run.
Even in-flat-memory programs that touch PPAGE for bank switching are
silently wrong (register exists but is inert).
Renode has no way to represent the 1 MiB (S12) or 4 MiB (S12X) expansion.

Affected files

src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs
src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12Opcodes.cs (CALL has Call operand format already)
Platform: platforms/cpus/m68hc12.repl

Desired behavior

PPAGE: a real bank register that CALL/RTC (and ideally RTI) read
and write. CALL pushes a 5-byte frame (PC, then PPAGE) and loads the
page operand into PPAGE; RTC pops PPAGE and PC and returns.
Program fetch via bank: the bus/CPU must map the active
PPAGE-selected 16 KiB window into the program address space so FetchByte
sees the banked code.
DPAGE/EPAGE (data banking) as a follow-up once the program-path model
works; they require the data read/write path to consult the page registers.

Acceptance criteria

CALL/RTC no longer trap; round-trip CALL → ... → RTC preserves
caller PC and restores the prior PPAGE.
PPAGE is observable/readable through the monitor and GDB (page
register) and is restored by RTC.
Program fetch honors PPAGE (a banked program executes from the selected
page).
Unit tests for CALL extended form (4A hh ll pg) and indexed form
(4B xb pg), RTC frame layout, and PPAGE restore on RTC.

Suggested approach

Decide the address-translation scheme up front: either give the bus a paged
window (a dedicated memory region remapped by the CPU) or make FetchByte
compute a banked address. Prefer the former so data paths and Renode's
monitor/ELF loading agree.
Start with PPAGE-only (program space); treat DPAGE/EPAGE as a separate
follow-up issue.
The M68HC12 EABI (docs/m68hc12/reference/M68HC12-EABI.txt) documents the
memory-expansion layout.

## Summary `CALL` and `RTC` — the CPU12 instructions for calling subroutines in expanded (banked) memory — decode but trap (`M68HC12.cs:591-594`). There is no implementation of the program-page register `PPAGE` (nor `DPAGE`/`EPAGE` for data), so the model is limited to a flat 64 KiB address space. ## Current behavior ```csharp case "CALL": case "RTC": Trap(); break; ``` `ComputeCallAddress` (`M68HC12.cs:878-891`) fetches and discards the CALL operand bytes (extended or indexed form plus the PPAGE operand byte) and never applies the page. The `PAGE` register exists in the register set (index 8 in `M68HC12Registers`, exposed to GDB as `page`) but is never read or written by any instruction. ## Impact - Programs using `CALL`/`RTC` to reach code above 64 KiB cannot run. - Even in-flat-memory programs that touch `PPAGE` for bank switching are silently wrong (register exists but is inert). - Renode has no way to represent the 1 MiB (S12) or 4 MiB (S12X) expansion. ## Affected files - `src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12.cs` - `src/Infrastructure/src/Emulator/Peripherals/Peripherals/CPU/M68HC12/M68HC12Opcodes.cs` (CALL has `Call` operand format already) - Platform: `platforms/cpus/m68hc12.repl` ## Desired behavior 1. **PPAGE:** a real bank register that `CALL`/`RTC` (and ideally `RTI`) read and write. `CALL` pushes a 5-byte frame (`PC`, then `PPAGE`) and loads the page operand into `PPAGE`; `RTC` pops `PPAGE` and `PC` and returns. 2. **Program fetch via bank:** the bus/CPU must map the active PPAGE-selected 16 KiB window into the program address space so `FetchByte` sees the banked code. 3. **DPAGE/EPAGE** (data banking) as a follow-up once the program-path model works; they require the data read/write path to consult the page registers. ## Acceptance criteria - `CALL`/`RTC` no longer trap; round-trip `CALL` → ... → `RTC` preserves caller PC and restores the prior `PPAGE`. - `PPAGE` is observable/readable through the monitor and GDB (`page` register) and is restored by `RTC`. - Program fetch honors `PPAGE` (a banked program executes from the selected page). - Unit tests for CALL extended form (`4A hh ll pg`) and indexed form (`4B xb pg`), RTC frame layout, and PPAGE restore on RTC. ## Suggested approach - Decide the address-translation scheme up front: either give the bus a paged window (a dedicated memory region remapped by the CPU) or make `FetchByte` compute a banked address. Prefer the former so data paths and Renode's monitor/ELF loading agree. - Start with PPAGE-only (program space); treat DPAGE/EPAGE as a separate follow-up issue. - The M68HC12 EABI (`docs/m68hc12/reference/M68HC12-EABI.txt`) documents the memory-expansion layout.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sid/renode-m68hc12#3

No description provided.

Rows
Columns