z80

112 Articles

The Dual-Core, ARM-Powered Commodore 64

July 2, 2016 by 28 Comments

There is no CPU that is better understood than the 6502 and its cousins the 6510, 6507, 6509, and whatever we’re calling the CPU in the NES. With this vast amount of documentation, just about anything can be done. Want a discrete and un-discreet 6502? Sure thing. It’s the NMOS version, though. Want an emulated version. Sure. With libraries porting the 6502 to every platform ever, there’s only one place left to go: putting a 6502 in a Commodore 64. Make it dual-core, too, so we can run CP/M.

This build is based on one of [telmomoya]’s earlier builds – a soft-core 6510 running on an ARM Cortex M3. The inspiration for this build came from a 6502 emulator running on an Arduino, which got [telmomoya] wondering what would happen if he attached some external RAM, CIA or a SID. Doing this on an Arduino is hard, but there are a few 5 Volt tolerant ARM chips out there, and with a few banks of SRAM, [tel] quickly had an emulated 6502 running EhBasic.

Running an emulated 6502 on an ARM chip is nothing new. What makes this build spectacular is the adaptation to the C64 motherboard. Since [telmomoya] was already breaking out the data and address lines to go to the SRAMs, it didn’t take much extra work to simply build an adapter for the DIP40 CPU socket on a C64. A few 74-series logic chips made the interface easy, and after a bit of soldering, [telmomoya] had a Commodore 64 powered by an ARM chip.

If you’re emulating one chip, you can emulate two, and with the Commodore 64, this leads to a few interesting possibilities. The C64 had a CP/M cartridge — a cartridge that contained a Z80 CPU, sharing the data and address bus with the 6510. This cartridge allowed the ‘toy computer’ C64 to run the ‘business’ CP/M operating system (and the Z80 made the Commodore 128 much cooler).  Since [telmomoya] was already emulating a CPU, emulating a second CPU wasn’t really that hard.

It’s a phenomenal build, and great if you’ve ever wanted to speed up VisiCalc.

Who Needs The MSP430 When You Have TI’s Other Microcontroller, The TI-84?

May 2, 2016 by 11 Comments

We’re sure there are more expensive LED controllers out there, but the TI-84 has got to be up there. Unless you have one on hand, then it’s free. And then you’ll doubtless need an SPI library for the famously moddable graphing calculator.

[Ivoah] is using his library, written in assembly for the Z80 processor inside the TI, to control a small strip of DotStar LEDs from Adafruit. The top board in the photograph is an ESP8266 board that just happened to be on the breadboard. The lower Arduino is being used as a 5V power supply, relegated to such duties in the face of such a superior computing device.

Many of us entertained ourselves through boring classes by exploring the features of TI BASIC, but this is certainly a step above. You can see his code here on his GitHub.

After his proof-of-concept, [Ivoah] also made a video of it working and began to program a graphical interface for controlling the LEDs. Video after the break.

Continue reading “Who Needs The MSP430 When You Have TI’s Other Microcontroller, The TI-84?” →

Breadboard Colecovision

March 7, 2016 by 13 Comments

The Colecovision was a state-of-the-art game console back in 1983. Based around the Z-80, it was almost a personal computer (and, with the Adam add-on, it could serve that function, complete with a daisy wheel printer for output). [Kernelcrash] set out to recreate the Colecovision on a breadboard and kept notes of the process.

His earlier project was building a Funvision (a rebranded VTech Creativision) on a breadboard, so he started with the parts he had from that project. He did make some design changes (for example, generating separate clocks instead of using the original design’s method for producing the different frequencies needed).

Continue reading “Breadboard Colecovision” →

Winning The Console Wars – An In-Depth Architectural Study

November 6, 2015 by 78 Comments

From time to time, we at Hackaday like to publish a few engineering war stories – the tales of bravery and intrigue in getting a product to market, getting a product cancelled, and why one technology won out over another. Today’s war story is from the most brutal and savage conflicts of our time, the console wars.

The thing most people don’t realize about the console wars is that it was never really about the consoles at all. While the war was divided along the Genesis / Mega Drive and the Super Nintendo fronts, the battles were between games. Mortal Kombat was a bloody battle, but in the end, Sega won that one. The 3D graphics campaign was hard, and the Starfox offensive would be compared to the Desert Fox’s success at the Kasserine Pass. In either case, only Sega’s 32X and the British 7th Armoured Division entering Tunis would bring hostilities to an end.

In any event, these pitched battles are consigned to be interpreted and reinterpreted by historians evermore. I can only offer my war story of the console wars, and that means a deconstruction of the hardware.

Continue reading “Winning The Console Wars – An In-Depth Architectural Study” →

The RUM 80 – A Home Brew Z80 Computer Built From Scratch

April 15, 2015 by 11 Comments

[M] recently tipped us off about hacker [Lumir Vanek] from the Czech Republic. Between 1985 and 1989, [Lumir] built his own home brew, Z80 based computer. The list of home computers available in the 1980’s is extensive. Those living in western Europe and the Americas could choose offerings from Acorn, Apple, Commodore, Atari, Radio Shack, and Sinclair Research to name just a few. Even the erstwhile Czechoslovakia had home computers available from Didaktik and Tesla.

[Lumir]’s built was based around the Z80 processor and is built using regular, double-sided, prototyping board. It featured the 8-bit Z80 processor CPU, 8kB EPROM with monitor and BASIC, two Z80 CTC timers, an 8255 parallel interface for keyboard and external connector, 64kB DRAM, and Video output in black & white, 40×25 characters, connected to a TV. The enclosure is completely made from copper clad laminate. [Lumir] documented the schematics, but there is no board layout – since the whole thing was discrete wired. He even built the membrane keyboard – describing it as “layers of cuprextit, gum, paper with painted keys and transparent film”. When he ran out of space on the main board, he built an expansion board. This had an 8251 serial interface for cassette deck, one 8-bit D/A converter, and an 8255 parallel port connected to the “one pin” BT100 printer.

On the software side, he wrote his own monitor program, which allowed simple interactions, such as displaying and modifying registers, memory, I/O ports and to run programs. He wrote this from scratch referring to the Z80 instruction set for help. Later he added a CP/M emulator. Since the Z80 had dual registers, one was used for user interaction, while the other was reserved to allow background printing. Eventually, he even managed to port BASIC to his system.

Check out [Martin Malý]’s awesome article Home Computers behind the Iron Curtain and the follow up article on Peripherals behind the  Iron Curtain, where you can read more about the “one pin” BT100 printer.

Continue reading “The RUM 80 – A Home Brew Z80 Computer Built From Scratch” →

ZX81 Emulated On An Mbed

December 22, 2014 by 7 Comments

This is a wonderful example of the phenomenon of “feature creep”. [Gert] was working on getting a VGA output running on an mbed platform without using (hardly) any discrete components. Using only a few resistors, the mbed was connected to a VGA display running at 640×480. But what could he do with something with VGA out? He decided to emulate an entire Sinclair ZX81 computer, of course.

With more than 1.5 million units sold, the Sinclair ZX81 was a fairly popular computer in the early ’80s. It was [Gert]’s first computer, so it was a natural choice for him to try to emulate. Another reason for the choice was that his mbed-VGA device could only output monochrome color, which was another characteristic of the ZX81.

[Gert] started by modifying a very lean Z80 emulator to make the compiled code run as efficiently as possible on the mbed. Then he went about getting a picture to display on the screen, then he interfaced an SD card and a keyboard to his new machine. To be true to the original, he built everything into an original ZX81 case.

This isn’t the first time we’ve seen a ZX81, but it is one of the better implementations of an emulated version of this system we’ve seen.

Thanks to [Jeroen] for the tip!

Reverse Engineering Capcom’s Crypto CPU

December 12, 2014 by 26 Comments

There are a few old Capcom arcade titles – Pang, Cadillacs and Dinosaurs, and Block Block – that are unlike anything else ever seen in the world of coin-ops. They’re old, yes, but what makes these titles exceptional is the CPU they run on. The brains in the hardware of these games is a Kabuki, a Z80 CPU that had a few extra security features. why would Capcom produce such a thing? To combat bootleggers that would copy and reproduce arcade games without royalties going to the original publisher. It’s an interesting part of arcade history, but also a problem for curators: this security has killed a number of arcade machines, leading [Eduardo] to reverse engineering and document the Kabuki in full detail.

While the normal Z80 CPU had a pin specifically dedicated to refreshing DRAM, the Kabuki repurposed this pin for the security functions on the chip. With this pin low, the Kabuki was a standard Z80. When the pin was pulled high, it served as a power supply input for the security features. The security – just a few bits saved in memory – was battery backed, and once this battery was disconnected, the chip would fail, killing the game.

Plugging Kabuki into an old Amstrad CPC 6128 without the security pin pulled high allowed [Eduardo] to test all the Z80 instructions, and with that no surprises were found; the Kabuki is fully compatible with every other Z80 on the planet. Determining how Kabuki works with that special security pin pulled high is a more difficult task, but the Mame team has it nailed down.

The security system inside Kabuki works through a series of bitswaps, circular shifts, XORs, each translation different if the byte is an opcode or data. The process of encoding and decoding the security in Kabuki is well understood, but [Eduardo] had a few unanswered questions. What happens after Kabuki lost power and the memory contents – especially the bitswap, address, and XOR keys – vanished? How was the Kabuki programmed in the factory? Is it possible to reprogram these security keys, allowing one Kabuki to play games it wasn’t manufactured for?

[Eduardo] figured being able to encrypt new, valid code was the first step to running code encrypted with different keys. To test this theory, he wrote a simple ‘Hello World’ for the Capcom hardware that worked perfectly under Mame. While the demo worked perfectly under Mame, it didn’t work when burned onto a EPROM and put into real Capcom hardware.

That’s where this story ends, at least for the time being. The new, encrypted code is valid, Mame runs the encrypted code, but until [Eduardo] or someone else can figure out any additional configuration settings inside the Kabuki, this project is dead in the track. [Eduardo] will be back some time next week tearing the Kabuki apart again, trying to unravel the mysteries of what makes this processor work.