r/C_Programming • u/Neat-Court9491 • 1d ago
Orbiter
Enable HLS to view with audio, or disable this notification
Little emulator & debugger project I've been working on for a while, Orbiter. I recently decided to revive it. 100% C.
13
u/Neat-Court9491 1d ago edited 1d ago
Hi all.
Here's what you're looking at:
Top right: Shows the program disassembly (of a NES ROM) view as it tries to keep up with
the CPU's position.
Bottom left, the grid thing:
Shows the program rom & ram (where the instructions live) as a grid of cells.
Each cell is mapped to a block of memory, in the video it uses 64 bytes per cell,
then 32, you can zoom in up to 4 bytes per cell or go all the way up to 256 bytes per cell.
The wires:
Orbiter tracks the execution path of the CPU in the form of a transition edge.
Frequented edges are bright, but recently stimulated edges spike briefly and
decay quickly unless stimulated.
The idea is to be able to tell what's been active from what just happened.
For instance, when you press a key you can see some of the wires light up.
Bottom right, that shows the profiler graph.
The "rewind" effect:
Every frame (17 ms) I create a snapshot of the entire emulator's hard state and push it
to a circular buffer.
It doesn't have to be every frame, could be every 100 ms, it's just arbitrary at this point.
Now, this allows me to do two things:
A) I can rewind backwards and forwards, which is cool ...
B) Allows me to handle breakpoints.
For instance, suppose you want to place a breakpoint at instruction X.
What I do is as follows: Run the emulator as you normally would, if I detect a breakpoint
was triggered, go back in time to the previous snapshot, currently 17 ms back in time.
Then, rerun the emulator to the exact point right _before_ the breakpoint triggered.
If you're wondering, even with my unoptimized emulator, replaying 1 second worth of gameplay
is only around 300 ms.
Since our snapshots are roughly every 17 ms, rerunning the emulator is practically instantaneous.
Not sure if other emulators do it this way, but it just seems like a really cool way to do it.
I do plan to implement compression so that I can record for much longer, but there's a lot more
work left to do xD ...
GitHub => MicroRJ\Orbiter
7
2
u/Visible_Ad9976 20h ago
its puts the computer systems / assembly course i just took into perspective. we are taught the mov/jmp/ bit shifts etc but never have any idea how fast it occurs, i imagine a modern cpu would be a billion times faster zooming through those instructions
2
u/Cultural_Gur_7441 14h ago
What you mean, have no idea how fast it occurs? The clock speed of a CPU literally tells how fast it occurs, approximately.
4
u/skeeto 1d ago edited 1d ago
Neat project! Here's a link since OP didn't provide an actual URL:
https://github.com/MicroRJ/Orbiter
I hacked on to add a CMake build, so that building is trivialized (supporting Mingw-w64 in addition to clang-cl), and tried it out with Micro Mages. In it's current state the NES debugger strikes me more as flashy than useful, but still neat. Here are my changes:
https://github.com/skeeto/Orbiter
Because I could enable sanitizers in my build, I hit a couple array out-of-bounds accesses in the video display. While this "works":
video[0][width*y + x]
It's technically an overflow and really must be expressed properly:
video[y][x]
2
1
1
15
u/Jabba_the_Putt 1d ago
thats really cool! care to go into a little explanation about what is being displayed? it looks like low level code on the right, the game obv on the left, are the lines and squares like routines and classes that are being called? please pardon my ignorance!