blog.jmp.no

Since I foolishly announced a minimum of one post per month, I'll do my best to keep my promise. This is why I'm lifting the curtains on my latest project: the APECAT.

APECAT is short for Amiga Processor Expansion Card for Application Transfer, and yes, I totally made that acronym up. Apekatt in Norwegian, translated word-by-word, means ape and cat. But for some reason it means monkey, and monkeys are fun. That's basically as deep as it goes.

This is work in progress as I'm still battling with a few minor bugs, but feel confident it will work eventually. I'll dig into the problems I'm experiencing further down this article.

The APECAT is a small, minimalist board you sandwich between the Amiga's 68000 CPU and motherboard. Its purpose is to allow the user to send data from an external host, for example a PC or a Raspberry Pi, and have it uploaded directly into the Amiga's memory. It is in many ways similar to the C64FC, only for the Amiga 500.

The goal is to be able to run software on an original Amiga, without using a floppy drive or hard drive at all. In fact, the Amiga I'm testing this on is just the motherboard. It doesn't even have a keyboard or a mouse attached.

How will it run anything without any software in the first place?

I have designed a hack for booting custom code from RAM, without the use of a floppy or hard drive. In short, it involves using the APECAT to stackbomb and interrupt the system ROM, followed by setting a reset-resident routine. This process takes less than a second. My custom code is then executed, which monitors the memory looking for flags set externally by the APECAT board. The basic principle has been tested and is confirmed working in the WinUAE Amiga emulator, but technical challenges has prevented me from running this on read hardware yet.

So what's not working?

The challenge is writing the data to RAM. I know this sounds like a deal breaker, but I strongly believe it's a minor issue and a consequence of not getting something right. I can freeze the CPU, point to a certain address in memory and write a value to it, but the value written is.. wrong. It seems almost random. I suspect this is due to one (or more) of these reasons:

• The timing is wrong. My code is either too fast or too slow.
• The order of write events are wrong. I'm doing things right, but not in the right order.
• I've missed something, like toggling a line or gate. What have I overlooked?
• The microcontroller I'm using is doing stuff I'm not aware of. Is the ICSP or something else disturbing things?
• I'm lost in my own code. The code is quite complex and confusing at the moment.
• I'm on a wild goose chase and this is whole project is impossible

Have you ever done something similar? Have you experienced similar write bugs on the 68000, or another system? Any ideas what I might have left out, based on what you've read so far? Leave a comment, I'd love to hear from you if you have. Let's discuss this in detail and figure out what's wrong.

I'm pretty close, though. As you can see from the image below, I'm bombarding the custom chipset at address $dff102, which is the horizontal scroll register. The addressing works, but the values written does not line up with what's expected. This obviously also works for other addresses, such as the background color, foreground color, bitplane pointers, etc. but this is the most convenient register to play with for visual confirmation.

This is the state of the current board, as it almost works. Bodge wires to /BGACK and /AS was added, as they were left out in the design process. The damage on the board you see is the VCC trace from the CPU that has been cut, as it was redundant and caused problems.

Wait, don't too carried away!

This is no miracle device, it is nothing revolutionary. It cannot be used to real-time debug the Amiga. It cannot read anything from the CPU. It can upload shit to RAM, and at the time being, that's all it'll ever do.

That doesn't make it any less exciting though, so stay tuned for updates. This will work soon, I know it.