When we talk about video games on an oscilloscope, you’d be pardoned for assuming the project involved an analog CRT scope in X-Y mode, with vector graphics for something like Asteroids or BattleZone. Alas, this oscilloscope Tetris (Russian language, English translation) isn’t that at all — but that doesn’t make it any less cool.
If you’re interested in recreating [iliasam]’s build, it’ll probably help to be a retro-oscilloscope collector. The target instrument here is a Tektronix TDS5400, a scope from that awkward time when everything was going digital, but CRTs were still cheaper and better than LCDs. It’s based on a Motorola 68EC040 processor, sports a boatload of discrete ICs on its main PCB, and runs VxWorks for its OS. Tek also provided a 3.5″ floppy drive on this model, to save traces and the like, as well as a debug port, which required [iliasam] to build a custom UART adapter.
All these tools ended up being the keys to the kingdom, but getting the scope to run arbitrary code was still a long and arduous process, with a lot of trial and error. It’s a good story, but the gist is that after dumping the firmware onto the floppy and disassembling it in Ghidra, [iliasam] was able to identify the functions used to draw graphics primitives on the CRT, as well as the functions to read inputs from the control panel. The result is the simple version of Tetris seen in the video below. If you’ve got a similar oscilloscope, the code is up on GitHub.
Care for a more hardware-based game-o-scope? How about a nice game of Pong? Or perhaps a polar breakout-style game is what you’re looking for. Continue reading “Tetris On An Oscilloscope, The Software Way”
Believe it or not, building a tiny compiler from scratch can be as fun as it is accessible. [James Smith] demonstrates by making a tiny compiler for an extremely simple programming language, and showing off a
Here’s what happens with a compiler: human-written code gets compiled into low-level machine code, creating a natively-executable result for a particular processor. [James]’ compiler — created from scratch — makes native x64 Linux ELF binary executables with no dependencies, an experience [James] found both educational and enjoyable. The GitHub repository linked below has everything one needs, but [James] also wrote a book, From Source Code to Machine Code, which he offers for sale to anyone who wants to step through the nitty-gritty.
The (very tiny) compiler is on GitHub as The Pretty Laughable Programming Language. It’s tiny, the only data types are integers and pointers, and all it can do is make Linux syscalls — but it’s sufficient to make a program with. Here’s what the code for “Hello world!” looks like before being fed into the compiler:
; the write() syscall:
; ssize_t write(int fd, const void *buf, size_t count);
(syscall 1 1 "Hello world!\n" 13)
Working at such a low level can be rewarding, but back in the day the first computers actually relied on humans to be compilers. Operators would work with pencil and paper to convert programs into machine code, and you can get a taste of that with a project that re-creates what it was like to program a computer using just a few buttons as inputs.
The super tiny compiler itself is about 200 lines of code. The source code is well, over 1,000 but that’s because of the literate programming comments. The fancy title comments are about half as large as the actual compiler.
The compiler’s goal is to take Lisp-style functions and convert them to equivalent C-style function calls. For example:
(add 5 (subtract 3 1) would become
Of course, there are several shortcut methods you could use to do this pretty easily, but the compiler uses a structure like most full-blown modern compilers. There is a parser, an abstract representation phase, and code generation.
Continue reading “Create A Compiler Step-By-Step”
Keeping source code to programs closed is something that is generally frowned upon here for plenty of reasons. Closed source code is less secure and less customizable, but unfortunately we won’t be able to convince everyone of the merits of open source code any time soon. On the other hand, it is possible to decompile some of those programs whose source remains behind locked doors in an attempt to better understand that code, and one of the more impressive examples of that of late is this project which has fully decompiled The Ocarina of Time.
To get started with the code for this project, one simply needs to clone the Git repository and then use a certain set of software tools (depending on the user’s operating system) to compile the ROM from the source code. From there, though, the world is your rupee-filled jar. Like we’ve seen from other decompiled games, any number of enhancements to the original game can be made including increasing the frame rate, improving the graphics, or otherwise adding flourishes that wouldn’t otherwise be there.
The creators of this project do point out that this is still a work-in-progress as only one of the 18 versions have been completed, but the fact that the source code they have been able to decompile builds a fully-working game when recompiled speaks to how far along it’s come. We’ve seen similar processes used for other games before that also help to illustrate how much improvement is possible when re-writing old games from their source code.
Thanks to [Lazarus] for the tip!
Continue reading “The Legend Of Zelda: Decompiled”
Part of the reason that retrocomputers are still so popular despite their obsolescence is that it’s possible to understand the entire inner workings of a computer like this, from the transistors all the way up to the software. Comparatively, it will likely be a long time (if ever) before anyone is building a modern computer from discrete components. To illustrate this point, plenty of 8-bit computers are available to either restore from original 80s hardware or to build from kits. And if you’d like to get even deeper into the weeds you can design your own computer including the instruction set completely from the ground up using an FPGA.
This project, called the Moncky project, is a step above the usual 8-bit computer builds as it is actually a 16-bit computer. It is built around an Arty Spartan-7 FPGA dev board running around 20 MHz and has access to 2 x 128 kB dual-port RAM for memory. To access the outside world there is a VGA output, PS/2 capability, SPI, and uses an SD card as a hard drive. This project really shines in the software, though, as the project creator [Kris Demuynck] builds everything from scratch in order to illustrate how everything works for educational purposes, and is currently working on implementing a C compiler to make programming the computer easier.
All of the project files, as well as all of the code, are available on the project’s GitHub page if you’d like to follow along or build on this homebrew 16-bit computer. It’s actually the third iteration of this computer, with the Moncky-1 and Moncky-2 being used to develop the more basic building blocks for this computer. While it’s not the first 16-bit computer we’ve seen implemented on an FPGA, it is one of the few that builds its own RISC instruction set and associated software rather than cloning a known existing processor. We’ve also seen some interesting x86 implementations on an FPGA as well.
Thanks to [koen-ieee] for the tip!
What do you do whilst your code’s compiling? Pull up Hackaday? Check Elon Musk’s net worth? Research the price of a faster PC? Or do you wonder what’s taking so long, and decide to switch out your build system?
Clamber aboard for some musings on Makefiles, monopolies, and the magic of Ninja. I want to hear what you use to build your software. Should we still be using
make in 2021? Jump into the fray in the comments.
Continue reading “Ask Hackaday: What’s Your Favourite Build Tool? Can Make Ever Be Usurped?”
The compiler is free to use for GPLv2 projects. If you aren’t open yourself, it looks like you have to cut a deal to use Cheerp with its maker, Learning Technologies.
Continue reading “C++ Compiler Targets The Web”