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”
The Commodore 64 is the worlds bestselling computer, and we’re pretty sure most programmers and engineers above a certain age owe at least some of their career to this brown/beige keyboard that’s also a computer. These engineers are all grown up now, and it’s about time for a few remakes. [Jeri Ellisworth] owes her success to her version, there are innumerable pieces of the C64 circuit floating around for various microcontrollers, and now [Mathias] has emulated everything (except the SID, that’s still black magic) in a single ARM microcontroller.
On the project page, [Mathais] goes over the capabilities of his board. It uses the STM32F4, overclocked to 235 MHz. There’s a display controller for a 7″ 800×480 TFT, and 4GB of memory for a library of C64 games. Without the display, the entire project is just a bit bigger than a business card. With the display, it’s effectively a C64 tablet, keyboard not included.
This is a direct emulation of the C64, down to individual opcodes in the 6510 CPU of the original. Everything in the original system is emulated, from the VIC, CIAs and VIAs, serial ports, and even the CPU of the 1541 disk drive. The only thing not emulated is the SID chip. That cherished chip sits on a ZIF socket for the amazement of onlookers.
You can check out some images of the build here, or the video demo below.
Continue reading “A Complete C64 System, Emulated on an STM32”
[sweetlilmre] is just beginning his adventures in retrocomputing, and after realizing there were places besides eBay to buy old computers, quickly snagged a few of the Amigas he lusted after in his youth. One of the machines that didn’t make it into his collection until recently was a Commodore 64 with Datasette and 1541 drive. With no tapes and a 1541 disk drive that required significant restoration, he looked at other devices to load programs onto his C64.
These devices, clever cartridge implementations of SD cards and Flash memory, cost more than anyone should spend on a C64. Realizing there’s still a cassette port on the C64, [sweetlilmre] created Tapuino, the $20 Commodore tape emulator
The hardware used to load games through the Datasette connector included an Arduino Nano, a microSD breakout board, a 16×2 LCD, some resistors, buttons, and a little bit of wire. The firmware part of the build – available here on the Git – reads the .TAP files off the SD card and loads them into the C64.
[sweetlilmre] posted a very complete build post of the entire device constructed on a piece of protoboard, Pop that thing in a 3D printed case, and he can have the entire C64 library in his pocket.
Let’s face it, we all have keyboard peculiarities. Don’t try to deny it, everyone who types a lot has an opinion of the keyboard they stroke so frequently. We know [Brian Benchoff] swears by his model M, and we’re guessing he was the one that bumped into [Evan] and convinced him to write about his conversion of a Commodore 64 keyboard for use as a USB device.
This is not [Evan’s] first rodeo. We recently saw him fixing up the worn off letters of his own model M. But this time around there’s some clever microcontroller work at play. Apparently mapping 122 keys using an Atmel AVR 32u4 chip (built in USB connectivity) is quite a task. Luckily someone’s already worked out all kinds of good things and is sharing the love with the Soarer’s Keyboard Controller Firmware. Of course it handles scanning, but also includes debounce, muxing, and the trick to scan more keys than the uC has pins for. We still don’t fully understand that bit of it. But [Evan] did post the config file he’s using so perhaps after we get elbow-deep in the code we’ll have a better understanding.
If you give this a try, we want to hear about it. Anyone have any modern keyboards they’re in love with? Leave a comment below.
Black and white NTSC is simple – it can, and was, done with vacuum tubes for a long, long time. Color is just weird, though. It runs at 29.976 frames per second, uses different phases of the carrier for different colors, and generally takes a while to wrap your head around. [Sagar] is doing a series on the intricacies of NTSC, and the latest post deals with color and progressive scanning versus interlacing, or as it is better known, how classic game consoles and home computers generate video.
The test bed for [Sagar]’s video experimentations is a circuit containing an ATMega16, a 4-bit shift register, and a 14.31818 MHz clock. This clock is much faster than the 3.579545 MHz clock in an NTSC carrier frequency – exactly four times as fast – allowing the shift register to output four different phases of the carrier frequency a 0°, 90°. 180°, and 270°. Playing with some of the pins on the ATMega in the circuit results in a palette being generated on any old TV.
NTSC requires interlaced scanning, or sending an entire screen of even lines, then an entire screen of odd lines, at around 60 fields per second. The Nintendos and Segas of yesteryear didn’t bother with this, instead opting to send half the vertical resolution at double the frame rate. This is known as a progressive scan. [Sagar] found that this resulted in some image artifacts when displayed on a modern LCD, and moving back to an interlaced mode fixed the problem. All the code and files are up on the gits. If you’re feeling adventurous, this is exactly how projects like the Uzebox have created homebrew game consoles using little more than the ATMega found in [Sagar]’s build.
While [Rob] was digging around in his garage one day, he ran across an old Commodore 64 cartridge. With no ROM to be found online, he started wondering what was stored in this ancient device. Taking a peek at the bits stored in this cartridge would require dumping the entire thing to a modern computer, and armed with an Arduino, he created a simple cart dumper, capable of reading standard 8k cartridges without issue.
The expansion port for the C64 has a lot of pins corresponding to the control logic inside these old computers, but the only ones [Rob] were really interested in were the eight data lines and the sixteen address lines. With a little bit of code, [Rob] got an Arduino Mega to step through all the address pins and read the corresponding data at that location in memory. This data is then sent over USB to a C app that dumps everything in HEX and text.
While the ROM for just about every C64 game can be found online, [Rob] was unlucky enough to find one that wasn’t. It doesn’t really matter, though, as we don’t know if [Rob] has the 1541 disk drive that makes this cart useful. Still, it’s a good reminder of how useful an Arduino can be when used as an electronic swiss army knife.
Almost a year ago, [miker00lz] started a thread on the Arduino forums telling everyone about a 6502 emulator and BASIC interpreter he wrote for an Arduino Uno. The chip inside the Uno isn’t a powerhouse by any means, and with only 2KB of RAM it’s far less capable than just about any computer from the 70s. Arduino works on a lot of different chips, though, and after a few months, [Jan] turned an Arduino Due into a Commodore 64 emulator.
[Jan]’s code isn’t limited to the DUE, and can be used with any chip with enough memory. If you’re feeling fancy, you can connect a TFT display for all the vintage goodness of PETSCII graphics, all while running a faster BASIC than the very stripped down EHBASIC.
Because the emulator is using software to talk to the outside world, it should be possible to use this project to interface with the cooler chips found in Commodore machines – SIDs for one, but also the cartridge port for some vintage Ethernet goodness. It’s not even limited to Commodore machines, either: the POKEY chips found in Atari 8-bit micros are seriously underutilized in the chiptune and demoscene, and having modern hardware to play with these chips couldn’t hurt in the slightest.
Continue reading “C64 Emulator For The Arduino Due”