An Open Hardware Sega Genesis Cartridge Dumper

You might be wondering why anyone would build device to dump Sega Genesis and Mega Drive cartridges. Perhaps they want to play their well-worn copy of The Lost Vikings on their phone, or they want to keep their QVC Limited Edition Maximum Carnage box set in near mint condition. Maybe. But we’re betting that [tonyp7] was just looking for a challenge, and as an added bonus, the world gets another cool open hardware gadget in the process. Sounds like a good deal to us.

Based on the ATmega324PB, the GenDumper can take those dusty old Sega cartridges and back them up to an image file on your computer. Right now the hardware depends on a Windows program, but according to the documentation, [tonyp7] is working on a platform-agnostic Python script so everyone can play along. What you do with the image file after you’ve dumped it is your business, but presumably loading it up in an emulator would be the next step.

Considering how easy it is to find ROMs for these old games online, do you actually need a GenDumper of your own? Probably not. But it’s still an interesting piece of hardware, and if you look close enough, you just might learn a thing or two from the design. For example, [tonyp7] shows how a relatively easy to work with 12 pin USB-C connector can be used on your USB 2.0 projects to embrace the new physical connector without diving into a full USB 3.0 implementation. The keen-eyed reader might also note there’s a lesson to be learned about finalizing the name of your project before sending off your PCBs for manufacturing.

A perusal of the archive uncovered a similar project from 2012 that, believe it or not, was also tested on a copy of Madden 96. Whether that means the game is so beloved that hackers want to make sure its preserved for future generations, or so despised that they are secretly hoping the magic smoke leaks out during testing, we can’t say.

Download A Bit Of Sinclair History

If you are a devotee of the Sinclair series of 8-bit home computers then a piece of news from the Centre For Computing History in Cambridge may be of interest to you, they’ve released a copy of the ROM from their ZX Spectrum prototype. This machine surfaced last year as part of a donation form the company originally contracted to write the Spectrum ROM and has been given pride of place int heir exhibition ever since. They’ve been doing some very careful work on it, and while The Register reports they can’t yet make the board boot, they have extracted the code for study. In the video below the break, we see it running on the Speccy emulator on an older Windows PC.

The ROM comes with an invitation to the ZX Spectrum community to analyze it against the stock version, in the hope of revealing ossified fragments of code such as that for the Microdrive storage peripheral which never made it into the stock Spectrum. But should you simply want to try your favorite games with the earliest possible version of the ROM, you can do that too.

We covered the machine’s emergence last year, meanwhile, if you haven’t been to the Centre for Computing History yet, we suggest you take a look at our review from a few years ago.

Continue reading “Download A Bit Of Sinclair History”

All The Games In One Cartridge

The original Game Boy was a smash success for Nintendo and has an amazing collection of games. You might relive some childhood nostalgia by booting up a Game Boy emulator, but to really get the full experience you’ll need the battery-draining green-tinted original hardware. Thanks to modern technology you can also load all of the games at one time on the original hardware with this STM32 cartridge that fits right in.

The device can load any Game Boy game (and homebrews) and ROMs can be sent to the cartridge via USB. There were are a lot of hurdles to getting this working properly, the largest of which is power management. A normal cartridge has a battery backup for save data, but using a small coin cell to run an STM32 would kill the battery quickly. To get around that, the cartridge writes the states to nonvolatile memory and then shuts itself off, although this has the side effect of crashing the Game Boy.

The creator of this project, [Emeryth], noted that we featured a similar project from [Dhole] a few years ago, also involving an STM32. [Emeryth] decided that it would be fun to build his own project anyway, and it’s certainly an interesting take on GameBoy hacking. He also has the files for this project available on his Git Hub page.

Tic-Tac-Toe, In TTL

We’ll all be familiar with Tic-Tac-Toe, or Noughts and Crosses, a childhood pencil-and-paper diversion which has formed the basis of many a coding exercise. It’s an easy enough task to implement in software, but how many of us have seen it done in hardware alone? That’s just what [Warren Toomey] has done using TTL chips, and his method makes for a surprisingly simple circuit.

At its heart is an 8 kB ROM that contains precomputed move sequences that are selected via an address composed of the game states for both player and machine. A series of flip-flops control and buttons to make the board, and a 555 provides a clock.

The technique of using a ROM to replace complex logic is a very powerful one that is facilitated by the low price of relatively large devices that would once have been unaffordable. We’ve seen the technique used elsewhere, including as an ALU in a TTL CPU, and even for an entire CPU in its own right.

You can see the result in operation in the video below the break, and should you wish to have a go for yourself all the relevant information can be found in a GitHub repository.

Continue reading “Tic-Tac-Toe, In TTL”

Steamed Hams Localized Entirely Within A Printed Circuit Board

Maybe you’ve heard of a TV show called The Simpsons. Steamed Hams make a one-gag appearance in an unforgettable luncheon where Principal Skinner poker-faces his way out of a disaster with Superintendent Chalmers. Meanwhile, over on imgur, [Agumander] has put a black and white screencap from Steamed Hams in a printed circuit board.

The memory for this chip is an AT28C64, a 64 kilobit or 8 kilobyte steamed RAM. You call it a steamed RAM despite the fact that it is obviously a ROM. There is no microcontroller on this board or really anything resembling programmable logic. Everything is just logic chips. This board displays a 256×256 1 bit per pixel image over composite video. The sync is generated with the help of a 14MHz crystal and some circuitry taken from the original PONG board. Other than that, it’s just a bunch of NANDs and ORs that roll through the address space of the ROM and spit values out over a composite video port.

The build began by breadboarding everything save for a nifty solderless breadboard power adapter. Three ROM chips were programmed with different images — a cat, something to do with vaporwave, and some guy that looks like the poster from Eraserhead. Everything worked on the breadboard — yes, even at 14 MHz — so the build moved on to a printed circuit board.

The result is fantastic, and should work well on anything with a composite video port. We’re awarding bonus points for putting a socket on the ROM, simply so [Agumander] can change the image without whipping out the desoldering braid. If you need a refresher on Steamed Hams, it’s from the 7th season Simpsons episode ’22 Short Films About Springfield’.

Analog Failures On RF Product Cause Production Surprise

A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.

Surprise VCC glitching causing CPU reset

The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.

The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.

New Game, Old Ways: Cramming An NES Game Into 40 KB

Why would anyone bother to create new content for a console system that’s staring down its 40th birthday? Perhaps just for the challenge of fitting a game into 40 kilobytes of storage.

That at least seems to be the motivation behind [Morphcat Games] pending release of Micro Mages, a new game for the Nintendo Entertainment System console that takes its inspiration from Super Mario Bros. The interesting bit here is how they managed to stuff so much content into so little space. The video below goes into great detail on that, and it’s a fascinating lesson in optimization. The game logic itself is coded in assembler, which of course is far more efficient than higher level languages. Even so, that took 32 kB of ROM, leaving a mere 8 kB for background elements and foreground sprites.

Through a combination of limited sprite size, tiling of smaller sprites to make larger characters, and reusing tiles by flipping them horizontally or vertically, an impressively complete palette of animated characters was developed. Background elements were similarly deconstructed and reused, resulting in a palette of tiles used to generate all the maps for the game that takes up just 60 bytes. Turning those into playable levels involves more mirroring and some horizontal shifting of tiles, and it looks like quite an engaging playfield.

Yes, there’s a Kickstarter for the game, but we’re mainly intrigued by what it takes to cram a playable game into so little space. Don’t get us wrong – we love the Retro Pie builds too, but seeing the tricks that early game developers relied upon to make things work really gets the creative juices flowing.

Continue reading “New Game, Old Ways: Cramming An NES Game Into 40 KB”