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”
Wheel of Fortune is a television game show, born in the distant year of 1975. Like many popular television properties of the era, it spawned a series of videogames on various platforms. Like many a hacker, [Chris] had been loading up the retro NES title on his Raspberry Pi when he realized that, due to the limitations of the cartridge format, he was playing the same puzzles over and over again. There was nothing for it, but to load a hex editor and get to work.
[Chris’s] initial investigation involved loading up the ROM in a hex editor and simply searching for ASCII strings of common puzzles in the game. Initial results were positive, turning up several scraps of plaintext. Eventually, it became apparent that the puzzles were stored in ASCII, but with certain most-significant-bits changed in order to mark the line breaks and ends of puzzles. [Chris] termed the format wheelscii, and developed an encoder that could turn new puzzles into the same format.
After some preliminary experimentation involving corrupting the puzzles and testing various edge cases, [Chris] decided to implement a complete fix. Puzzles were sourced from the Wheel of Fortune Puzzle Compendium, which should have plenty of fresh content for all but the most addicted viewers. A script was then created that would stuff 1000 fresh puzzles into the ROM at load time to minimize the chances of seeing duplicate puzzles.
ROM hacks are always fun, and this is a particularly good example of how simple tools can be used to make entertaining modifications to 30-year-old software. For another take, check out this hack that lets the Mario Bros. play together.
For many of us, being given a big old DIP ROM from nearly thirty years ago and being told to retrieve its contents would be a straightforward enough task. We’d simply do what we would have done in the 1980s, and hook up its address lines to a set of ports, pull its chip select line high, and harvest what came out of the data lines for each address.
But imagine for a minute that an old-fashioned parallel ROM is a component you aren’t familiar with, as [Brad Dettmer] did with the ROM from a SNES Zelda cartridge. We’ve seen plenty of reverse engineering stories with ancient computing gear as their subject, but perhaps it’s time to accept that some of the formerly ubiquitous devices are edging towards that sort of status.
So [Brad] takes us through the process of using the Saleae logic analyser to interrogate the chip while an Arduino stepped through its address lines, and the lesson is probably that while it seems like a sledgehammer to crack a nut it is important to factor in that unfamilarity. If you’d never worked with a 1980s ROM, it would make sense to use the tool you are familiar with, wouldn’t it?
Anyway, all’s well that ends well. While we’re on the subject of Nintendo ROMs, have a read about extracting the boot ROM from a cloned Game Boy.
There’s something powerful about reliving the experience of using a game console from our personal good old days, especially the tactile memories stored up from hundreds of hours handling a chintzy joystick or the sound and feel of inserting a game cartridge. Emulators have their place, but they fall far short of period-correct hardware in the nostalgia department.
That’s not to say that the retro gear can’t use a little help in terms of usability, which is why [Scott M. Baker] built this Raspberry Pi multi-cartridge for his Atari 5200. The idea is to maintain the experience of the cartridge interface without having to keep stacks of cartridges around for all the games he wants to play. [Scott] leveraged the approach he used when he built a virtual floppy drive for a homebrew PC/XT: dual-port memory. The IDT7007 is a 32k chip that lives between the Atari 5200 and a Raspberry Pi Zero and can be addressed by both systems; the Pi to write ROM images to the memory, and the console to read them. He had to deal with some fussy details like chip select logic and dealing with the cartridge interlock signals, not to mention the difference in voltage between the memory chip’s logic levels and that of the Pi. Retro game-play occupies the first part of the video below; skip to 6:45 for build details.
The one quibble we have is trying to jam everything into an old cartridge. It’s critical to replicating the tactile experience, and while we don’t think we’d have gone so far as to injection mold a custom cartridge to house everything without any protrusions, we might have 3D-printed a custom cartridge instead. In the end it doesn’t detract much from the finished project, though, and we appreciate the mix of old and new tech.
Continue reading “Dual-Port Memory And Raspberry Pi Team Up For Retro Console Multicart”
There are many ways of storing data in a computer’s memory, and not all of them allow the computer to write to it. For older equipment, this was often a physical limitation to the hardware itself. It’s easier and cheaper for some memory to be read-only, but if you go back really far you reach a time before even ROMs were widespread. One fascinating memory scheme is this example using a vacuum tube that stores the characters needed for a display.
[eric] over at TubeTime recently came across a Raytheon monoscope from days of yore and started figuring out how it works. The device is essentially a character display in an oscilloscope-like CRT package, but the way that it displays the characters is an interesting walk through history. The monoscope has two circuits, one which selects the character and the other determines the position on the screen. Each circuit is fed a delightfully analog sine wave, which allows the device to create essentially a scanning pattern on the screen for refreshing the display.
[eric] goes into a lot of detail on how this c.1967 device works, and it’s interesting to see how engineers were able to get working memory with their relatively limited toolset. One of the nice things about working in the analog world, though, is that it’s relatively easy to figure out how things work and start using them for all kinds of other purposes, like old analog UHF TV tuners.
We don’t know about you, but when our friends ask us if we want to help them fix something, they’re usually talking about their computer, phone, or car. So far it’s never been about helping them rebuild an old electron microscope. But that’s exactly the request [Benjamin Blundell] got when a friend from a local hackerspace asked if he could take a look at a vintage Cambridge Stereoscan 200 they had found abandoned in a shed. Clearly we’re hanging out with the wrong group of people.
As you might imagine, the microscope was in desperate need of some love after spending time in considerably less than ideal conditions. While some of the hackerspace members started tackling the hardware side of the machine, [Benjamin] was tasked with finding a way to recover the contents of the scope’s ROM. While he’s still working on verification, the dumps he’s made so far of the various ROMs living inside the Stereoscan 200 have been promising and he believes he’s on the right track.
The microscope uses a mix of Texas Instruments 25L32 and 2516 chips, which [Benjamin] had to carefully pry out after making sure to document everything so he knew what went where. A few of the chips weren’t keen on being pulled from their home of 30-odd years, so there were a few broken pins, but on the whole the operation was a success.
Each chip was placed in a breadboard and wired up to an Arduino Mega, as it has enough digital pins to connect without needing a shift register. With the wiring fairly straightforward, [Benjamin] just needed to write up some code to read the contents of the chip, which he has graciously provided anyone else who might be working on a similar project. At this point he hasn’t found anything identifiable in his ROM dumps to prove that they’ve been made successfully, all he really knows right now is that he has something. At least it’s a start.
More and more of these older electron microscopes are getting a second lease on life thanks to dedicated hackers in their home labs. Makes you wonder if there’s ever going to be a piece of hardware the hacker community won’t bend to their will.
Polyglots, in computing terms, are files have multiple valid meanings. We’ve seen some amazing examples of polyglot files in releases of The International Journal of PoC||GTFO. One example: a PDF that is also a ZIP, HTML file, and BPG image.
[Vi Grey] was inspired by PoC||GTFO’s release of a PDF/ZIP/NES ROM hybrid file for issue 0x14. Using a different method, [Vi] created a file which is both an NES ROM and ZIP, where the full contents of the ZIP are stored in the NES ROM.
When PoC||GTFO created their NES ROM polyglot, they stuck most the information outside the bounds of the NES ROM. While the file is valid, you’d lose the ZIP archive if it was burnt to a cartridge.
[Vi]’s polyglot is different. Rip it from a real NES cartridge and you get a ZIP file. Unzip it, and you get the source. Compile that source, and you get a valid ZIP file containing the source. Burn that to a cartridge and… hopefully you grok the recursion at this point.
The source and scripts to mangle the polyglot together are up on Github.