The bsnes emulator has a new overclocking mode to eliminate slowdowns in SNES games while keeping the gameplay speed accurate. We’re emulating old SNES hardware on modern machines that are vastly more powerful. Eliminating slowdowns should be trivial, right? For an emulator such as bsnes, which is written to achieve essentially pixel-perfect accuracy when emulating, the problem is decidedly non-trivial. Stick around to learn why.
Usually when writing emulation software for a system like the Game Boy, one makes sure to take as many shortcuts as possible in order to reduce the resources required for the emulation. This has however the unfortunate side-effect that it reduces the overall accuracy of the emulation and with it the compatibility with games on the system.
This is the basic reasoning behind projects which seek to abandon simplistic abstractions in favor of cycle-accurate, full compatibility approaches, of which MetroBoy is probably the most extreme one. Instead of abstracting away the hardware, it instead does the emulation at the circuit level. As with such other projects, this means that the emulator requires a lot more CPU cycles to get things just right. On the bright side, one can likely still run this emulator on any modern system.
As the MetroBoy author explains, he implemented code in C++ which allowed him to construct circuits in an HDL-style manner, which should theoretically also allow him to generate a Verilog (or VHDL) softcore out of the project. As a demonstration of implementing HDL in C++ it’s decidedly interesting.
An approach like this is pretty much the exact opposite of a project like the UltraHLE (ultra high-level emulator) Nintendo 64 emulator, which used the knowledge that Nintendo 64 games are written in C as a first step to creating libraries that the code in the Nintendo 64 ROMs would call instead of the native (Nintendo) libraries. This allowed N64 games to directly run on the target system, with the graphic and system calls translated by UltraHLE into native OS calls, using the 3dfx Glide API for accelerated graphics.
While an approach like UltraHLE took allows for the most minimal use of system resources by essentially foregoing emulation completely, for retro systems like the Game Boy where games were implemented in assembly on bare hardware, using this circuit-level emulation ensures that one gets the most accurate match with the original handheld console experience.
As a word of caution to those who are now itching to try out MetroBoy, its Github site notes that it currently lacks support for game saves, uses a mixture of original Game Boy (DMG) and Game Boy Advance SP (AGS) hardware that confuses some games and has rather buggy sound support.
If playing around with software-defined Game Boy circuits isn’t enough and would like to literally look inside a real Game Boy, the X-ray image from the top of the article is something Chris over at Elektronaut pulled off several years ago.
If there’s one thing tiny Linux Systems on a Chip are good for, it’s emulation. There’s nothing like pulling out an emulation console on the bus for a quick game of old-school NES Tetris, or beating the next level in Super Mario World. This is the smallest emulation console ever. It’ll fit in your pocket, and it has a bright, vibrant screen. It doesn’t get better than this.
This project is an improvement on two projects, both of which are some of the top projects on hackaday.io, the best place on the Internet for hacks and builds. The Keymu is (or was, at the time) the smallest emulation console ever, built as a miniaturized version of the Game Boy Advance SP in a 3D printed case and powered by the Intel Edison. The Edison doesn’t exist anymore, so after that development moved over to the Funkey Zero, a tiny console built around the AllWinner V3s chip and a 240×240 display. Both of these are tiny, tiny consoles, but as silicon gets better there’s always better options, so it’s back to the drawing board.
The design of the Funkey Project is again built on the AllWinner V3S SoC with 64MB of DDR2 DRAM. There’s a 1.5″ display with 240×240 resolution, and of course this retro emulation console retains the classic and very useful clamshell form factor of the famous Game Boy Advance SP.
Already, this project is in the works and it’s shaping up to be one of the most popular projects on hackaday.io ever. Everyone wants an emulation console, and this is the smallest and tiniest one yet. Whether or not this project can carry through to production is another matter entirely, but we’re eager to find out.
The Digital Equipment Corp. PDP-11/70 is a masterpiece of Cold War-era industrial design. This microcomputer was the size of one or two modern server racks depending on configuration, and the front panel, loaded up with blinkenlights, was clad in a beautiful rose and magenta color scheme. The switches — the ones you used to toggle bits in memory — were actually custom designed covers made to match the shape of the completely unnecessary bezel. The aesthetic of the 11/70 is the intersection of baroque and modernism on the design Venn diagram.
[Oscar Vermeulen] built a miniature version of the PDP-11/70 that houses a Raspberry Pi, and [rricharz] has been hard at work bringing an original copy of BSD to this system. The first great project to come out of this effort? It’s a weather station, and it’s exactly as cool as you think it is.
A bit of ground work went into this build, including getting a historical Unix system up and running, in this case 2.11 BSD. Armed with a Pi and the PiDP-11/70 front panel, [rricharz] had a complete BSD system up and running, and with cool-retro-term, the interface looked the part. Doing something useful was another question entirely, but the Pi in the PiDP had some GPIOs free, so this ancient machine got an I2C temperature and pressure sensor.
The completed build is basically just a breadboard, a tiny diagnostic OLED, and a python script that grabs the data and sends it over to the sim. This is pressure and temperature data shoved into an emulation of a Tektronix 4010 terminal. It’s marginally useful work done by an ancient BSD system wrapped in an emulation on a Raspberry Pi. It doesn’t get better than that.
Microcontrollers come in a broad swathe of capabilities these days. There are the venerable 8-bit micros that have been around forever and valiantly crunch away, all the way up to modern 32-bit powerhouses with advanced peripherals and huge amounts of RAM and ROM. If you’re blinking a few LEDs or opening a garage door, the former is fine. For what [Jared] had in mind, a little more horsepower was required.
[Jared]’s project started out as an experiment with composite video output on a STM32F446RE microcontroller. Using a 4-bit resistor DAC, the device was able to output NTSC signals, using interrupts and NOPs to handle timing. The hardware worked, and was tested by playing the entirety of Star Wars: A New Hope from an SD card.
Attention then turned to creating a Game Boy emulator for the platform. After many hurdles with various bugs and edge cases, things started working, albeit slowly. The Pokemon game ROM wouldn’t fit in the microcontroller’s limited flash storage, so [Jared] implemented a complicated bank switching scheme. This combined with the limited computational resources meant the game was playable, but limited to just 10 FPS.
Enter the STM32H7. With over double the clock speed and capable of 856 DMIPS versus 225 of the original chip, things were coming together. Pokemon now ran at 60 FPS, and the built-in DAC greatly improved the sound. The DMA subsystem allowed further performance gains, and even running in debug mode, performance far exceeded that of the previous hardware.
With unit prices of most microcontrollers being remarkably low, it goes to show that once you’ve tapped out on performance on one platform, there’s usually a faster option available. It’s possible to emulate the Game Boy on the ESP-32 too, as Sprite_TM showed us in 2016. Video after the break.
[Thanks to Ben for the tip!]
Continue reading “Playing Pokemon On A CRT Thanks To A Powerful Microcontroller”
If you’ve ever wanted to sit at the console of the machine that started the revolution in interactive computing, your options are extremely limited. Of the 53 PDP-1 machines that Digital Equipment Corporation made, only three are known to still exist, and just one machine is still in working order at the Computer History Museum. So a rousing game of Spacewar! on the original hardware is probably not something to put on your bucket list.
But thanks to [Hrvoje], there’s now an FPGA emulation of the PDP-1 that lets you play the granddaddy of all video games without breaking into the CHM. The project was started simply to give [Hrvoje] a sandbox for learning FPGAs and Verilog, but apparently went much further than that. The emulation features the complete PDP-1 instruction set, 4kB of core memory, and representations of the original paper tape reader, teletype, operator’s console, and the classic Type 30 CRT. All the hardware is displayed on a standard HDMI monitor, but it’s the CRT implementation that really sells this. The original Type 30 monitor used a CRT from a radar set, and had long-persistence phosphors that gave the display a very distinctive look. [Hrvoje] replicated that by storing each pixel as three values (X, Y, and brightness) in a circle of four chained shift registers. As the pixels move through the shift registers, the brightness value is decreased so it slowly fades. [Hrvoje] thinks it doesn’t look quite right, but we’ll respectfully disagree on that point.
We’ve argued before that the PDP-1 is the machine that started hacker culture, and we think this project is a fitting tribute to the machine as we enter the year in which it will turn sixty. Having the chance to play with it through this emulation is just icing on its birthday cake.
Continue reading “FPGA Emulates A PDP-1, Breathes New Life Into Classic Video Game”
With surface-mount technology pushing the size of components ever smaller, even the most eagle-eyed among us needs some kind of optical assistance to do PCB work. Lots of microscopes have digital cameras too, which can be a big help – unless the camera fights you.
Faced with a camera whose idea of autofocus targets on didn’t quite coincide with his, [Scott M. Baker] took matters into his own hands – foot, actually – by replacing mouse inputs to the camera with an outboard controller. His particular camera’s autofocus can be turned off, but only via mouse clicks on the camera’s GUI. That’s disruptive while soldering, so [Scott] used an Arduino Pro Micro and a small keypad to mimic the mouse movements needed to control the camera.
At the press of a key, the Arduino forces the mouse cursor up to the top left corner of the screen, pulls down the camera menu, and steps down the proper distance to toggle autofocus. The controller can also run the manual focus in and out or to take a screenshot. There’s even a footswitch that forces the camera to refocus if the field of view changes. It looks really handy, and as usual [Scott] provides a great walkthrough in the video below.
Like it or not, if shrinking technology doesn’t force you into the microscope market, entropy will. If you’re looking for a buyer’s guide to microscopes, you could do worse than [Shahriar]’s roundup of digital USB scopes. Or perhaps you’d prefer to dumpster dive for yours.
Continue reading “Arduino Provides Hands-Free Focus For Digital Inspection Scope”
