Cranking Up The Detail In A Flight Simulator From 1992

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.

Continue reading “Cranking Up The Detail In A Flight Simulator From 1992”

Roll Your Own Python Debugger

Debugging might be the one thing that separates “modern” programming from “classic” programming. If you are on an old enough computer — or maybe one that has limited tools like some microcontrollers — debugging is largely an intellectual exercise. Try a program, observe its behavior, and then try again. You can liberally sprinkle print statements around if you have an output device or turn on LEDs or digital outputs if you don’t. But with a debugger, you can get a bird’s-eye view of your program’s data and execution flow.

For some languages, writing a debugger can be hard — you usually use at least some system facility to get started. But as [mostlynerdness] shows, Python’s interpreter wants to help you create your own debugger, and you can follow along to see how it’s done. This is accessible because Python has a built-in debugging core that you can use and extend. Well, regular Python, that is. MicroPython has some low-level support, and while we’ve seen attempts to add more, we haven’t tried it.

Of course, you may never need to build your own debugger — most of the IDEs have already done this for you, and some of the code is, in fact, lifted from an open code base and simplified. However, understanding how the debugging plumbing works may give you a leg up if you need to create custom logic to trap an error that would be difficult to find with a generic debugger. Plus, it is just darn interesting.

Like many Python things, there are some version sensitivities. The post is in four parts, with the last two dealing with newer API changes.

We can’t promise that Python can debug your hardware, though. We always thought the C preprocessor was subject to abuse, but it turns out that Python has the same problem.

A 6502-based single-board computer with a ROMulator attached

Debug Your Senile Computers With The ROMulator

Some of you may have heard of the ROMulator, a device that can emulate RAM and ROM on 6502-based computers. But how does it work? How do you use it? What computers is it compatible with? [Jeff Tranter] covers that and more in his review of the ROMulator 6502.

The ROMulator is an FPGA-based board that slots between the 6502 and its socket on whatever computer it came from. It can emulate, but not intercept, accesses to RAM and ROM, which can be used to e.g. replace a ROM that you’re swapping very often or expand the RAM available to the CPU.

In his review, [Jeff] shows the ROMulator in action many computers, notably his custom 6502-based computer, a replica of an Apple 1 and two different replicas of the SUPERBOARD 2. He shows how the ROMulator can be configured, tested, used to debug the computers and even expand their RAM. Overall, [Jeff] thinks it’s a useful 6502 debugger that would have saved him lots of time in the past and we definitely agree.

Continue reading “Debug Your Senile Computers With The ROMulator”

A 6502 Overlay Debugger

Retired hardware engineer [Plasmode] recently took on the challenge of building a debugger for the 6502 designed to sit atop the microprocessor while seated in a solder less breadboard. The result is the Diagnostic Overlay for W65C02 Breadboard, consisting of 128 kB SRAM and a 1250-gate CPLD. Except being 0.8 in wide, the overlay debugger is otherwise the same size as the 6502’s 40-pin DIP package, so it doesn’t overhang other portions of your circuit.

Being an initial concept prototype, [Plasmode] mounted the chips dead-bug style on perf board — a process he himself found tiring. If he builds additional debuggers, presumably he will consider making a PCB.

The prototype was constructed using point-to-point soldering with 30-ga wire wrap wire.  It was all done under the inspection microscope.  There are not many connections, but they are rather tedious so I can only do a dozen or so wires per session.  It took me 2 days and several hours total to finish the prototype board.

This design is based on the CRC65 Frugal 6502 Single Board Computer, of course omitting the 6502 itself. Instead of a physical ROM memory chip, he implemented a 64-byte boot loader inside the CPLD and a serial port. This lets him to bootstrap the system over the serial port. He plans on expanding this to include other DIP-packaged retro microprocessors in the future. Check out his Hackaday.io project page ( above ). If you want to dig deeper, he posted the schematics here.

A Usable Arduino Debugging Tool

For as popular as the Arduino platform is, it’s not without its problems. Among those is the fact that most practical debugging is often done by placing various print statements throughout the code and watching for them in the serial monitor. There’s not really a great way of placing breakpoints or stepping through code, either. But this project, known as eye2see, hopes to change that by using the i2c bus found in most Arduinos to provide a more robust set of debugging tools.

The eye2see software is set up to run on an Arduino or other compatible microcontroller, called the “probe”, which is connected to the i2c bus on another Arduino whose code needs to be debugged. Code running on this Arduino, which is part of the eye2see library, allows it to send debugging information to the eye2see probe. With a screen, the probe can act as a much more powerful debugger than would otherwise typically be available, being able to keep track of variables in the main program, setting up breakpoints, and outputting various messages on its screen.

The tool is not without its downsides, though. The library that needs to run on the host Arduino slows down the original program significantly. But for more complex programs, the tradeoff with powerful debugging tools may be worth it until these pieces of code can be removed and the program allowed to run unencumbered. If you’d like to skip needing to use a second Arduino, we’ve seen some other tools available for debugging Arduino code that can run straight from a connected PC instead.

HP1973 Project Highlights Workings Of HP-45 Calculator

[Sarah K Marr] dabbles in retrocomputing and has a fascination with the Hewlett Packard HP-45 calculator, the second calculator in HP’s series introduced in 1973. Over a year ago, she wrote an HP-45 emulator for use on a terminal, dubbed HP45TERM. Not content with success, she upped the challenge and decided to build an even better emulator with a full-featured GUI written in Python. Oh, and she made it multi-platform as well. The result is the HP1973 project.

[Sarah] thought it would take just a few days, but it grew into a much bigger project, as often happens. We’re glad it did because the results are fantastic. The emulator gives you access not only to the calculator itself but can see everything under the hood. The emulator provides full ROM visibility, hardware registers, and standard debugging operations like single stepping. ROM images are available for the HP-45, the HP-35, and the HP-80. The GUI display is configurable, and there’s a plethora of help and information explaining the calculator’s internals. Pre-built binaries are available for MacOS, Windows, and Python source code (3.10.10+) for all operating systems (you’ll need to `pip install numpy` first). The emulation is faithful to the original calculator, and even the hidden timer function can be accessed.

Check this out if you’re into retro calculators. Our own Al Williams wrote about the history of the HP-35 back in 2018 if you want to learn more. Thanks to [J Peterson] for sending in the tip.

The Orbtrace debugger hardware connected to a development board t hrough a 20-pin ribbon cable. The development board has a green LED shining.

ORBTrace Effort: Open Tool For Professional Debugging

There are some fairly powerful debugging facilities available on today’s microcontrollers — if your code crashes mysteriously, chances are, there’s a debugging interface that could let you track down the exact crash circumstances in no time. Sadly, debugging tools for these powerful interfaces tend to be prohibitively expensive and highly proprietary, thus, not friendly for hobbyists. Now, there’s a community-driven high-capability debugging platform called ORBTrace, brought to us by [mubes] and [zyp].

With parallel trace, you get a constant stream of consciousness, every exact instruction executed by your CPU. [mubes] and [zyp] set out to tap into the power of parallel trace debugging for Cortex-M processors. and the ORBTrace project was born. Relying on the Orbuculum project’s software capabilities, this FPGA-based debugger platform can do parallel trace and the more popular high-speed SWO trace – and way more. ORBTrace has the potential to grow into a powerful debug helper tool, with enough capabilities for anyone to benefit. And of course, it’s fully open-source.

The ORBTrace board, with a FPGA in the center of it, a USB-C connector on the left, and two IDC debug connectors on the right (one ten-pin and one twenty-pin)The ORBTrace platform has plenty of untapped potential. There’s the battle-tested JTAG and SWD that you can already use with all the open tools you could expect. However, there’s also plenty of available resources on the FPGA, including even a currently unutilized RISC-V softcore. If you wanted to add support for any other family of devices to this debugger, sky’s the limit! And, of course, there’s cool software to go with it – for example, orbmortem, which keeps a ring buffer of instructions in memory and shows you the last code executed before your CPU stops, or orbstat, a tool for profiling your embedded code.

If you’re looking to purchase effortless feature parity with Segger or Lauterbach devices, the ORBTrace doesn’t promise that. Instead, it’s an open debugging toolkit project, with hardware available for purchase, and software just waiting for you take control of it. This project’s community hangs out in the 1BitSquared discord’s #orbuculum channel, and gateware’s advancing at a rapid pace – welcoming you to join in on the fun.

ORBTrace is a powerful tool for when your goals become large and your problems become complex. And, being a community-driven experimental effort, we’ll undoubtedly see great things come out of it – like the Mooltipass project, originally developed by Hackaday community members, and still going strong.