When you want to write software for a system like the Commodore 64, the obvious and safe choice is to create an image that can be used with a tape or floppy drive emulator. Yet these come with the obvious disadvantage of loading time and manual steps, much like with the original hardware. Unfortunately, if you crave that instant-on experience that cartridges offer – courtesy of them being plugged directly into the system’s CPU bus – you better get an EE diploma to figure it all out. Or maybe not, as [Linus Åkesson] found out when he created a custom cartridge to boot his Commodordian project from.
For the core of the cartridge a bit of stripboard was sufficient to interface with the C64’s cartridge slot. Despite being single-sided, all the required signals were on one side of the slot. These include the EXROM line that informs the system that a cartridge is present, the ROML line that informs the cartridge when the system is trying to read from it, and of course the data bus. After this the interaction gets somewhat interesting, due to the use of the single-sided stripboard, as the address bus and other signals are on the non-connected side.
Working around this was the biggest challenge, but by creatively using the ROML and DotClk lines and by disabling the display output, the ATmega88 and 74HC541-based cartridge a working solution was created. There is still room for improvement here, naturally, but it would appear that if the goal is simply to autoload software on boot, this is definitely a workable solution. One could also splurge on double-sided stripboard, but that would strip away most of the fun of this solution.
Double side stripboards are more expensive and hard to find, but RS Uk has some models
https://uk.rs-online.com/web/p/stripboards/1004182?gb=b
This project goes into the category: find an non-existing problem and solve it
Hacker solves non-existing problem, parents dissapointed “We had such high hopes!”
Actually, I’m pretty sure the real hack is that an AVR wouldn’t be fast enough to read the address lines, access the appropriate data in flash, output it, etc. I won’t go into how difficult a task that is even for a GHz SBC.
By assuring the data is requested sequentially, the AVR can keep up.
Impressive hack and potentially useful in other realms.
At least he can add the Reset line. Also, he wouldn’t do the whole read-fetch-send process. Just comparing the address to the “intended” address, and in case step back.
Not sure I understand…
If he were running from the AVR as though it was a typical firmware ROM, address requests could be pretty much random, what with jumps and lookup tables and interrupt vectors. Reading the address would at the very least take two additional AVR (port read) instructions, slowing the fetches down considerably. Maybe he could’ve added a bus-wait for such things, otherwise the AVR just wouldn’t be fast enough to emulate a ROM… those two additional instructions would be too many.
So instead he wrote only a tiny deterministic step-by-step loader “program” to be run from the AVR ROM emulator that sequentially loads the rest of the program into RAM (where “random access” is in the name).
Your “non-existing problem” conclusion is actually not very accurate at all. In fact, I’d go so far as to suggest the solution, here, is very similar to a previous wide-spread standardized solution to a similar problem: How does one interface a microcontroller responsible for moving read/write heads on a hard disk platter to a typical address/data bus, and have it respond to requests fast-enough not to bog down the system with wait-states? Treat one memory location as a FIFO. And lockstep the accesses to that single “address” at the “memory”/device-side. It just happens to be, in this case, that the CPU is actually requesting different addresses, but they can be ignored by the “FIFO” since they’re known to be sequential.
I think it’s a pretty elegant solution to a number of such problems I’ve encountered.
Another example might be e.g. HD44780, which is a microcontroller of sorts… and has many internal memory locations to write to, but its accesses are limited to essentially only two physical memory addresses as far as the host CPU is concerned.
I think it’s not so much a problem here, because the C64 is more like a glorified microcontroller. It so slow that it was being outperformed by electric typrwriter machines of the day. So yeah. A modern AVR can probably keep track with it.
LOL, I dare you to try… Maybe the C64, specifically, but go just one MHz faster with the CPU and it’d be quite a challenge, even for an RPi. Ask me how I know…
I like it. Noticing a feature of the expansion port and exploiting it. Wish my C64 still worked. And it’d also be nice if I knew enough about electronics to design such an item.
Ingenious, as usual.