This is cool. In the old days... computers came with these things built into the ROM (BIOS, Firmware, etc.). They were mostly called a 'ROM Monitor' or just the 'Monitor'. I never knew why they were called that, but I would guess that it was probably a term DEC or IBM invented.
On a Sun, NeXT, or Cisco box, you could hit a magic keyboard sequence (or send an RS-232 BREAK over the console) to get to the monitor. It was a very powerful thing to be able to interrupt the running OS, modify it, and then resume it. On the NeXT, you could even work with OS structures or sync the disks. The monitor typically had a disassembler and a simple single step debugger.
Earlier microcomputers also had these, and were helpful, but less powerful. For example, the Apple ][ had a monitor, but later ROMs did not allow you to invoke it with a key sequence.
On the later Suns and Power Macs, the monitor was implemented as a standard called Open Firmware. This was basically a standardized Forth acting as a Monitor. Device drivers could be embedded as a bytecode like sequence of Forth words for ethernet or display cards. That way, you could use newer devices even with old firmware and with any CPU. Very cool.
Monitors were also an integral feature of most "freezer" cartridges for the C64, like Action Replay and The Final Cartridge I/II/III (you could get monitors you'd load into RAM as well, but the freezer cartridges had lots of extra capabilities and of course the advantage of having the monitor in ROM). For a couple of years, until I got hold of Turbo Assembler (no relation to the Borland PC assembler), I wrote most of my assembler straight into memory using the Action Replay monitor.
Not just cool, but useful. "UEFI" should have been a Forth-like REPL like Sun, FreeBSD, OLPC, etc.
The output of rappel reminds me of an "assembly level debugger" I used for many years called "ald". Maybe I am just stupid, but when I'm writing assembly I like to verify the contents of registers as a program executes.
From user.h:
"Fuck computers, multiarch is bullshit."
Agreed.
I need something that compiles easily on NetFreeOpenBSD x86. Mo multiarch bullshit. Meanwhile I will stick with as, objcopy and ald.
On the old Sun gear if you sent a break signal over serial you wold interrupt the OS sure and be at the ROM monitor but you couldn't "resume" the OS, you could boot back up to single user or run level 3 but all of your previous state would be gone of course. Is that was you are referring to? I don't remember a disassembler being available from the prom monitor I do remember there a FORTH(sp?) interpreter though. Could you elaborate?
The OpenFirmware system used on old Macintosh and Sun machines used an extended FORTH for the bootstrapping and hardware management. FreeBSD's bootloader has a similar system as well.
I remember issuing "call -151" on an Apple IIe to enter the monitor. I was too young to understand how it worked, but I was using the examples from the manual to define fast-drawing code for shapes (defined with an existing language made of combinations of down, left, right, up etc. commands) that could be called from Basic.
This sounds similar to kernel debugging- is that what you have in mind? Windows (the OS I'm most familiar with) has a couple different styles of kernel debugging, which allows you to introspect various levels of system state:
Same could be done using radare2 [1] tool in debug mode ("r2 -d") and using "dxa" command, to write an opcode using assembly language and execute it in place. Or even using simple C-like language (called regg [2]) to do the same.
P.S. It's always better to try radare2 from git, since it's very actively developed.
Cool! I did something very similar to this a couple of years back: https://github.com/osandov/asmase. Instead of assembling to a file, I used the LLVM libraries to assemble in memory, then used ptrace to get a child process to point its instruction pointer at that machine code.
Would seem useful idea to restrict the print only changed registers and have a command to print all registers. Right now you can fit like 3-4 operations in 80x25 terminal window.
On a Sun, NeXT, or Cisco box, you could hit a magic keyboard sequence (or send an RS-232 BREAK over the console) to get to the monitor. It was a very powerful thing to be able to interrupt the running OS, modify it, and then resume it. On the NeXT, you could even work with OS structures or sync the disks. The monitor typically had a disassembler and a simple single step debugger.
Earlier microcomputers also had these, and were helpful, but less powerful. For example, the Apple ][ had a monitor, but later ROMs did not allow you to invoke it with a key sequence.
On the later Suns and Power Macs, the monitor was implemented as a standard called Open Firmware. This was basically a standardized Forth acting as a Monitor. Device drivers could be embedded as a bytecode like sequence of Forth words for ethernet or display cards. That way, you could use newer devices even with old firmware and with any CPU. Very cool.
I wish this functionality would come back.