Electronics, coding and hacking. And ADD.

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.

Happy New Year, my resolution, and then some.


Okay, so 2018 wasn't quite the year for this blog. If I'm not mistaken, I managed to squeeze out one - yes one - post last year. My new year's resolution is a minimum of one post per month in 2019. Feel free to call me out if I fail to deliver.

The reason I'm posting this is not just to point out how lazy I've been, but I want to emphasize someone who's not on the lazy side. But before I begin, let me stress that I'm not doing this for money or referrals, this is just me sharing my experience and excitement over a PCB manufacturer called AllPCB.

Long story short: This Saturday I decided to get some new PCB's produced, so that I have something to work on for my January entry (no, this one doesn't count). I quickly looked around for some cheap manufacturers, and AllPCB popped up with an offer: $5 for 10 boards, $19 shipping with DHL. I couldn't resist the temptation, and placed an order. Keep in mind, we're still on Saturday. Today is Tuesday - three days later - and guess what? The package has arrived!

Sure, DHL was fast (and they usually are) but looking over the order history at AllPCB, I can see that they manufactured and shipped the boards the same day as I placed the order. This is excellent service and you bet your ass I will place my next order with them as well.

I'll bring a couple of boards + parts with me to work tomorrow, so I can populate them under better conditions than in my freezing cold shed. And, if everything goes right, I'll start testing it tomorrow night.

Let's hope this project works and makes a cool post within the next few days.

Bomb by Insane


1, 2, 3.. testing.. is this thing still on? Ok, good.

You may or may not have noticed, but I've been a little dormant lately. To be honest, inspiration has been slim to none, the willpower to get out in the shed and do things has been literally absent. The remaining energy to get going is just around the bend, so hang in there.

While we're waiting, let me take you through the latest demo we released for OCS Amiga. This is "Bomb" by Insane:

Pou√ęt link

This demo was made pretty much from scratch in a couple of days, to support the Datastorm party. Good for us, only two demos were submitted to the OCS demo compo, so we nailed the 2nd place.

Since nobody asked, let's walk through the demo and discuss how things were done.

The spinning "INSANE" logo was originally planned as a decrunch part, but during the development of the demo a few things changed. The next part is being decrunched and initialized while the current part is running, but since I had made this part already, I included it anyways. The rotation matrix is all precalculated, so it's basically a line drawing routine you're watching.
The stretcher is a simple liquid effect. I originally wanted the image to flip upside-down, like a coin flip, but didn't have the time to code that, so I ended up with this. I guess it turned out allright, even though a coin-flip would look much better. Oh well, maybe next time.

Fun fact: It didn't quite stick the landing before the screen flash. Notice how it's a little "off."

The twister turned out to be quite the eyecandy. I coded a standard twister routine on a 4 bitplane image, and applied RGB plasma on top of it. The plasma colour scheme is a blend of two gradients: one smooth and one hard/aggressive. The end result is a pretty crazy color scheme which I think looks pretty cool.

Fun fact 1: The background fades to a set of colours predefined in a table. However, I forgot to set more than the two first colours, so what you're seeing are the RGB representations of the assembly opcodes following the table.

Fun fact 2: The effect was too slow to run every 2nd rasterline. Every 3rd line got too ugly, so it alternates between 2 and 3 lines down the screen.

Before the next part I needed a 8-10 second filler part. We decided to do one in the form of a fullscreen logo. To prevent it from being too static, we added the falling bombs in the background.
Now, the zoomer part is the one I'm the most proud of in this demo, but I think the twister part took the edge of it, somehow. This is a 31x31 pixel, (almost) fullscreen, full-color zoom routine that runs 50fps, invented and executed by yours truly. To be honest it's a combination of animation and color cycling, all working in prefect glory to bring the illusion of a growing image.
The end part is dead simple. A 5 bitplane image and an up-scroller in the 6th. The writer runs while the text is scrolled upwards, giving it a "tilted" appearance, if you look carefully.

Hope this was interesting to atleast one of my two readers (hi mom!) and I'll try to pick up some hardware projects again in the near future.

Dumping the Coolbaby console flash


You may remember that in my last post I said I was interested in the NOR flashrom inside the Coolbaby NES game console. Well, I've been obsessing with it lately, so let me review the progress from the past two weeks.

My original idea was to read the IC in situ, I soldered up a ton of breakout pins and was able to dump the contents while the system was running.

Unfortunately, the CPU made it difficult to read the flash rom while the system was powered off. Probably some pull-downs or whatever that caused problems for me, so I removed everything and started from scratch. I even tested the console one last time to make sure everyting was working before I started ripping it apart.

I bought a TSOP56-to-dip adapter, and decided it was time to desolder the flash rom to dump it. I tried to protect most of the board with kapton tape and aluminium foil, and fired up the hot air station.

It went surprisingly well, and a few minutes later the chip was cleaned up and secured in the ZIF TSOP56 adapter.

I decided to use a STM32F4 Discovery board for reading the data. It has lots of nice I/O pins, it's fast, it has native USB and much more.

So, here it is all wired up - not pretty but it works. My apologies if you have OCD and like colour coded wires, I just used what was at hand.

The next step was to write a UART-over-USB for the ARM processor. Then, interface the pins to the flash rom and try to implement the protocol for reading the contents. Once that's in place, I wrote a client on the PC side that receives the data and saves it as a binary file.

Yada yada yada, long story short: success! I present to you a sample from the file. Here you can see part of the adventures games lists:

Next up is figuring out how the games are arranged and how the menus work.

Stay tuned.

Cool NES, baby!


About a week ago I stumbled across a NES clones on Aliexpress called "Coolbaby". It's basically a miniature NES clone, not unlike the NES Classic, with 600 built-in games. It was so small and cute I just had to buy one. Let's take a quick look at it, and have a peek inside.

The console is shipped with two controllers, a MicroUSB power supply and an AV video cable. An HDMI version exists, but unfortunately I didn't see that listing before buying this. With a price tag of just $20 I can afford to upgrade to the HDMI version later. Oh, and before you ask, the cartridge door does not open. It's simply a groove for decoration purposes.

It's in fact so small and cute I admit that is the main reason I bought it. It's kind of hard to show on a two-dimensional screen, but here it is with an iPhone 4 for comparison:

The image quality is good, but the colors appear to be a little off. Looks over-saturated with a hint of pink. With a little luck an onboard resistor DAC may be configured wrong, but I'll look into that.

Opening the console is pretty straight-forward. Remove the rubber feet and unscrew four phillips screws and you're in. Prior to opening it I had no idea what to expect, so I was pleasantly surprised when I saw this clean, neat, single-sided PCB inside:

And yes, it really is single-sided. Here is the bottom side of the board.

The PCB consists of two components. A S29GL512N11TFI02 512mbit flash ROM, and what's probably a NOAC (NES On A Chip) or a variant of it, packaged as chip-on-board and drowned in epoxy resin.

U2 is the IC that interest me the most. I suspect it can be dumped and/or reprogrammed, and I intend to do so. There are tons of test points to hook on to, and with a little luck I may be able to replace the entire IC with something I can reprogram via USB.

Well, that's it for now. I'll probably experiment with the hardware as soon as time allows it.

The console is definitely worth the money, and if you're looking for a quick retro fix, go buy one - just make sure you get the HDMI edition.

Add to Google