jake/SplitBit-Emulator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Stage 0: the emulator carries the ROM, so a disk is enough

Browse Source 
./SplitBit --disk system.img
  stage two
  CosmOS
  >

No boot image named. The emulator shadows its built in stage one into
Program Memory - boot vector included - and the CPU then does exactly what
it has always done: reads the boot vector and starts where it points.
NOTHING ABOUT THE CPU CHANGED to make a machine that starts itself, which
is what picking shadowing over a mapped ROM bought.

The ROM is generated from Programs/Boot/stage1.asm by the makefile rather
than committed beside it, because a copy of a program kept next to the
program is a copy that goes stale. That makes the assembler a real
dependency of the emulator, which it always sort of was and now says so.
od and awk rather than xxd, which is not everywhere, or python, which the
README does not ask anybody to install in order to build this.

loadROM is loadFile given bytes instead of a path: both go through one
reader over an fmemopen stream, because a ROM is a boot image and there is
no reason for the machine to have two ways of understanding one.

Naming an image still works and is what every other test here does. That
path is not a shortcut to apologise for - placing memory from outside is a
real thing real machines allow, and it is a debugger. The help says so now.
No image and no disk is the one case with nothing to run, and it says that
rather than printing a usage message about a missing file.

run.sh gained a "rom" mode which hands the emulator a disk and nothing
else. The source column still names stage1.asm, because that is what is IN
the ROM: assembling it there says the thing the emulator carries is a thing
that still assembles.
This commit is contained in:
Anachronaut
2026-08-27 14:41:33 -04:00
parent c312853f8e
commit 54ff7196c9
11 changed files with 177 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+23
View File
@@ -94,6 +94,29 @@ Then `dir` to see what is there, `load Snake.sbx` and `run` to play something, o
| `-W`, `--write-protect` | Attach the disk read only. A disk whose image the host will not let you write is read only whether you ask for this or not. |
| `-h`, `--help` | Show help and usage information. |
**The boot image is optional now.** Named one, the emulator places it into memory and
starts it, which is what a debugger does and how every test here runs - a real thing real
machines allow, not a shortcut to apologise for. Given only a disk, the machine starts the
way hardware would:
```
./SplitBit --disk system.img
```
The emulator carries `Programs/Boot/stage1.asm` as a **shadowed ROM**: at reset its bytes
are copied into Program Memory, boot vector included, and the CPU then does exactly what it
has always done - reads the boot vector and starts where it points. Nothing about the CPU
changed to make a machine that starts itself.
Because it is a copy rather than a mapping, those bytes are ordinary Program Memory once
stage one has jumped away. The system may write over them, and a reset puts them back,
which is why rebooting has to be a reset rather than a jump - and `SWI SoftReset` is the
instruction for it.
The ROM is generated from the assembly by the makefile rather than kept beside it, because
a copy of a program stored next to the program is a copy that goes stale.
**A cycle is one access to memory**, not one instruction. Fetching an opcode is a cycle,
fetching each byte after it is another, reading or writing Data Memory is one, every byte a
CALL pushes or a RET pops is one, and reaching a device port is one. Nothing overlaps -