Game Boy Cartridge Emulator Uses STM32

December 30, 2014 by Adam Fabio 20 Comments

Game Boys may be old tech, but they still provide challenges to modern hackers. [Dhole] has come up with a cartridge emulator which uses an STMicroelectronics STM32F4 discovery board to do all the work. Until now, most flash cartridges used programmable logic devices, either CPLDs or FPGAs to handle the high-speed logic requirements. [Alex] proved that a microcontroller could emulate a cartridge by using an Arduino to display the “Nintendo” Game Boy boot logo. The Arduino wasn’t fast enough to actually handle high-speed accesses required for game play.

[Dhole] kicked the speed up by moving to the ARM Cortex-M4 based 168 MHz STM32F4. The F4’s 70 GPIO pins can run via internal peripherals at up to 100MHz, which is plenty to handle the 1MHz clock speed of the Game Boy’s bus. Logic levels are an issue, as the STM32 uses 3.3V logic while the Game Boy is a 5V device. Thankfully the STM32’s inputs are 5V tolerant, so things worked just fine.

Simple Game Boy cartridges like Tetris were able to directly map a ROM device into the Game Boys memory space. More complex titles used Memory Block Controller (MBC) chips to map sections of ROM and perform other duties. There were several MBC chips used for various titles, but [Dhole] can emulate MBC1, which is compatible with the largest code base.

One of the coolest tricks [Dhole] implemented was displaying a custom boot logo. The Game Boy used the “Nintendo” logo as a method of copyright protection. If a cartridge didn’t have the logo, the Game Boy wouldn’t run. The logo is actually read twice – once to check the copyright info, and once to display it on the screen. By telling the emulator to change the data available at those addresses after the first read, any graphic can be displayed.

If you’re wondering what a cartridge emulator would be useful for (other than pirating games), you should check out [Jeff Frohwein’s] Gameboy Dev page! [Jeff] has been involved in Game Boy development since the early days. There are literally decades of demos and homebrew games out there for the Game Boy and various derivatives. .

Continue reading “Game Boy Cartridge Emulator Uses STM32” →

Z80, CP/M, And FAT File Formats

December 30, 2014 by Brian Benchoff 18 Comments

[Gary Kildall] and CP/M are the great ‘also ran’ of the computing world; CP/M could run on thousands of different 1980s computers, and [Gary] saw a few million in revenue each year thanks to CP/M’s popularity. Microsoft, DOS, and circumstances have relegated [Kildall] and CP/M to a rather long footnote in the history of microcomputers, but that doesn’t mean CP/M is completely dead yet. [Marcelo] wrote a Z80 emulator running CP/M inside an Arduino Due, and he did it in such a way that it’s actually convenient and useful to use.

Instead of using CP/M disk images, [Marcelo]’s emulator emulates CP/M disk drives on top of a regular FAT file system. Drives are mapped to folders in the FAT file system, so a folder named ‘A’ will show up as the A: disk in CP/M. Drives up to P: are supported, the maximum number of drives available under CP/M. The BIOS resides in the root directory of the SD card, and so far Microsoft Basic, Turbo Pascal, UCD Micromumps, and Wordstar work just fine.

The Arduino project was built upon one of [Marcelo]’s earlier projects that put the CP/M emulator on Windows. The version for the Due works exactly how you think it would, with a serial connection and terminal emulator providing the IO, and the huge amount of processing power and RAM available on the Due doing all the heavy lifting.

Robotically-Tuned Tube Radio

December 27, 2014 by Matt Freund 8 Comments

Dubbed the “Robot Radio” by [Brek], this clinking-&-clunking project merges three generations of hackers’ favorite technologies: robots, vacuum tubes, and microcontrollers. After the human inputs the desired radio frequency the machine chisels its way through the spectrum, trying its best to stay on target.

This build began its life as a junky old tube radio that [Brek] pulled out of a shed. The case was restored and then the hacking began. Inserted between the human and the radio, a PIC 16F628A keeps watch in both directions. On one side, the radio’s tank circuit is monitored to see what frequency the radio is currently playing. On the other, the human’s input sets a desired frequency. If the two do not match, the PIC tells a stepper motor to begin cranking a pair of gears until they do.

Another interesting feature is that as the tubes and other electronics warm up and change their values, the matching circuit will keep them in line. [Brek] shows this in the video by deliberately sabotaging the gears and seeing the robot adjust them back where they belong.

As an afterthought, the Robot Radio was supplemented with a module that adds 100khz to the signal so that the information from a nearby airport can be received.

[Brek] styled the whole machine up with some copper framing and other bits, similar to his spectacular atomic clock build we featured last month.

See the video of the radio tuning after the break.

Continue reading “Robotically-Tuned Tube Radio” →

NeXT Cubes And LCD Monitors

December 27, 2014 by Brian Benchoff 15 Comments

The NeXT slabs and cubes were interesting computers for their time, with new interesting applications that are commonplace today seen first in this block of black plastic. Web browsers, for example, were first seen on the NeXT.

Running one of these machines today isn’t exactly easy; there are odd video connectors but you can modify some of the parts and stick them in an LCD monitor. It’s a tradeoff between a big, classic, heavy but contemporary CRT and a modern, light, and efficient LCD, but it’s still a great way to get a cube or slab up and running if you don’t have the huge monitor handy.

The NeXT cube doesn’t have a single wire going between the computer and the monitor; that would be far too simple. Instead, a NeXT Sound Box sits between the two, providing the user a place to plug the monitor, keyboard, mouse, and audio connectors into. [Brian] took the board from this Sound Box and put it inside an old NEC LCD monitor he had sitting around. 12V and 5V rails were wired in, the video lines were wired in, and [Brian] created a new NeXT monitor.

There are two versions of the NeXT Sound Box – one for ADB peripherals (Apple IIgs and beige Macs), and another for non-ADB peripherals. [Brian] also put together a tutorial for using non-ADB peripherals with the much more common ADB Sound Board.

Learning I2C With The Bus Pirate

December 27, 2014 by Adam Fabio 8 Comments

When an air quality display project needed a display, [Inderpreet] looked into small character-based LCDs. [Inderpreet’s] chosen LCD used an I2C interface, which was new to him. Rather than shy away, [Inderpreet] grabbed his Bus Pirate and dove in!

I2C or Inter-Integrated Circuit serial interfaces are often mentioned here on Hackaday. They generally are easy to use, but as with all things, there are little gotchas which can make the road a bit more bumpy the first time you travel it. One of those things is voltage interfacing – I2C uses bidirectional open drain lines, so interfacing 3.3 V and 5V circuits requires a voltage level shifter circuit designed to handle that requirement. Thankfully in [Inderpreet’s] case, both his TI launchpad target devboard and the LCD used 3.3 volt logic levels.

Before using the TI though, [Inderpreet] wanted to test with the Bus Pirate first. This would allow him to verify the hardware, and to make sure he was correctly using the I2C bus. The Bus Pirate can operate at 3.3V or 5V logic levels, and has on-board programming specific to the I2C bus. Controlling the Bus Pirate is as easy as hooking up a serial terminal program and plugging in a USB cable.

The I2C bus protocol is relatively simple, but can still be confusing to a new user. Each transaction needs an address, read/write bit, and a start command sent in the proper sequence before the data bytes can begin flowing. There are also acknowledge bits which prove that the data bytes are actually being received by the LCD. The Bus Pirate made all this easy, allowing [Inderpreet] to quickly display “Hello” on his LCD module.

The I2C bus is just the tip of the iceberg for the Bus Pirate. If you’re interested in learning more, check it out over at The Hackaday Store!

[via Dangerous Prototypes]

Weird Clocks And A Two Chip Apple I

December 26, 2014 by Brian Benchoff 18 Comments

The Apple I, [Woz]’s original, had about sixty chips on a single board. Most of these chips were logic glue or hilariously ancient DRAMs. The real work was done by the 6502, the 6821 PIA, and the Signetics video chip. It’s a simple computer, really, and following the now popular tradition of two-chip computers, [Dave] built a replica of the Apple I using a 6502 and an ATMega.

The ATMega in this project takes care of everything – the 4k of RAM, the few bytes of ROM, the IO, and even the clock. With the 6502 you can have a little bit of fun with the clock; because the 6502 reads data off the bus a few nanoseconds off the falling edge of the clock and writes on the rising edge, [Dave] played around with the duty cycle of the clock to give the ATMega a bit more time to do its thing. With a 50% duty cycle, the 16Mhz ‘Mega has about eight cycles to decode an address and read or write some data. By making the low part of a clock cycle longer, he has about 45 cycles on the ‘Mega to do all the work. All of this was inspired by a fantastic tutorial on the 6502 clock.

Right now [Dave] has some hex values displaying on a small LCD, while the real I/O is handled by a serial connection to a computer. It’s retro enough, and a future update will include a faux cassette interface, possibly using an SD card for storage.

Dual Porting A C64 Flash Cart

December 26, 2014 by Brian Benchoff 4 Comments

The old cartridges for the Commodore 64 use EEPROMs to store their data, and the newer Flash carts use either a Flash chip or an SD card to put a whole bunch of games in a small plastic brick. [Stian] and [Runar] thought that wasn’t good enough – they wanted to program cartridges in real time, the ability to reboot the C64 without ever touching it, and a device for coding and testing. What they came up with is the latest advance in Commodore cartridge technology.

The device presents 8k of memory to the C64, but it doesn’t do this with Flash or an EEPROM. Instead, [Stian] and [Runar] are using a dual-port static RAM, specifically one from the IDT7005 series. This chip has two data busses, two address busses, and /CE, /OE, and R/W lines for either side of the chip, allowing other digital circuits to be connected to one small section of the C64’s memory.

Also in the cart is an ATmega16 running V-USB to handle the PC communications. It takes about 1 to 1.5 seconds to transfer an entire 8k over to the cartridge, but this chip can read and write the RAM along with the C64 simultaneously.

If you want a box that will give you the ability to put ever game in existence on a single cartridge, this isn’t the one. However, if you want to write some C64 games and do some live debugging, this is the one for you. The Eagle files are available, and there’s a video demo below.

Continue reading “Dual Porting A C64 Flash Cart” →