Electronics, coding and hacking. And ADD.

« Patching the live Amiga ROM Happy New Year, my resolution, and then some. »

Work in progress: APECAT


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.


to Work in progress: APECAT

Feed for this Entry


  • Hello,
    Ah, I had this idea in my head for a long time now. I never thought of using a microcontroller directly to fill the host memory. Can't wait to see your next steps on this project.

  • Interesting new version of the C64 card ! (btw, I'd love to aquire one... if avail)

    Do you use halt pin of the 68K, and gain the memory access via the DMA (in AGA) bus controls ?
    Otherwise, you're not alone to deal with the bus, even if the CPU is halted...
    That might explain conflits in the data put in the choosen addresses if several chips are electrifying the bus :-)


    #1174 | Comment by John ][ on Aug 17, 2019 11:44pm
  • John ][: Yes, /HALT is pulled low while my board is active.

    But still, I suspect there's *something* going on on the bus despite that. Not sure what or why yet, I'll have to pick up the A500's schematics to make sure.

    I've kept this project on the shelf for a while now, maybe it's time to pick it up again and give it another go.

  • Had another look at the code and made a breakthrough.. updates will follow!

  • Yes. It's working. Stay tuned!

About You

Email address is not published.

All messages must be validated by the admin.

Spam messages or messages containing URLs linking to spam, will never be published.

Add to the Discussion

Add to Google