If you just want to use a debugger for your microcontroller project, you buy some hardware device, download the relevant driver software, and fire up GDB. But if you want to make a hardware debugger yourself, you need to understand the various target chips’ debugging protocols, and then you’re deep in the weeds. But never fear, Sean [Xobs] Cross has been working on a hardware debugger and is here to share his learnings about the ARM, RISC-V, and JTAG debugging protocols with us.
He starts off with a list of everything you need the debugger hardware to be able to do: peek and poke memory, read and write to the CPU registers, and control the CPU’s execution state. With that simple list of goals, he then goes through how to do it for each of the target chip families. We especially liked [Xobs]’s treatment of the JTAG state machine, which looks pretty complicated on paper, but in the end, you only need to get it in and out of the shift-dr and shift-ir states.
This is a deep talk for sure, but if you’re ever in the throes of building a microcontroller programmer or debugger, it provides a much-appreciated roadmap to doing so.
Nostalgia is a funny thing. If you experienced the early days of video games in the 1980s and 90s, there’s a good chance you remember those games looking a whole lot better than they actually did. But in reality, the difference between 2023’s Tears of the Kingdom and the original Legend of Zelda is so vast that it can be hard to reconcile the fact that they’re both in the same medium. Of course, that doesn’t mean change the way playing those old games actually makes you feel. If only there was some way to wave a magic wand and improve the graphics of those old titles…
Well, if you consider Ghidra and a hex editor to be magic wands in our community, making that wish come true might be more realistic than you think. As [Alberto Marnetto] explains in a recent blog post, decompiling Stunt Island and poking around at the code allows one to improve the graphical detail level in the flight simulator by approximately 800%. In fact, it’s possible to go even higher, though at some point the game simply becomes unplayable.
The same hack also allows ground details to be turned off.
Even if this is the first time you’ve ever heard of this particular 1992 flying game from Disney, the write-up is a fascinating read and contains some practical tips for reverse engineering and debugging older software from within the confines of DOSBox. By strategically setting break points, [Alberto] was able to follow the logic that reads the desired graphical detail level from the configuration file, all the way up to the point where it influences the actual rendering engine.
It turns out the detail level variable was capped off, but by studying the way the engine used that variable to modify other parameters, he was able to tweak the math from the other side of the equation and go beyond the game’s intended 100% detail level.
Looking at the side by side comparison with modern eyes…even the tweaked version of the game leaves a lot to be desired. But there’s only so far you can push the engine, especially given the limited resolution it’s able to run at. But there’s no question that the patch [Alberto] has developed greatly improves the density of objects (buildings, trees, etc) on the ground. The video below shows off the patched game running at full-tilt to give you an idea of what it looks like in motion.
Conectar
