Sprite Sneak Peak

 

KAPE GPU

KAPE GPU is currently the most designed area of the KAPE 8bit homebrew computer/console project. The graphics are currently run on two AVR microcontrollers. There is a FIFO chip between the AVR chips - this works as a framebuffer and needs at least 24Kx8 of memory. The current design outputs 16 colors in RGBI, so 4 bits per pixel, and the screen resolution is 256x192. There is a small bug in the output circuitry, which is worked around by outputting one black byte after every line, so in effect the screen is actually 258x192, though only 256 pixels per line are actually used for graphics.

The two UNOs shown in picture aren't really involved in the GPU operation. The top one is more closely related, as it is the Serial communications line through which I can send data to the Command FIFO and thus to the KAPE GPU itself (the ATmega1284P), which enables me to send commands and data and use the GPU kind of like it is intended to be used in the full computer. The bottom UNO is just a programmer for the GPU, so I can change the firmware of the GPU. The GPU outputs PAL RGB SCART image just fine without those, but the top UNO is needed to send data after a reset (mostly the tileset graphics as well as commands to make the GPU show them on screen properly)

There is an ATtiny84 chip that provides PAL timing and handles the framebuffer memory output to screen. The ATtiny84 doesn't actually read the memory itself at all, it only provides the FIFO memory a clock signal to clock pixels out at the right time. Then the byte is piped through a Quad 2-input multiplexer (a 74HC157N) that selects which nibble is shown at what time. This selection signal is actually straight up the same clock signal that is fed to the FIFO chip, so on high the multiplexer shows the other nibble and on low the other, so I get two pixels out with one FIFO clock cycle. I'm using a dot clock of 8 MHz so giving the FIFO a 4 MHz clock signal provides an 8 MHz per pixel clock, as we are packing two pixels in one byte. The bits are interpreted how a CGA monitor interprets RGBI, I have resistors setup so that the output conforms or at least gets close to the 0.7V peak needed for output. More on this on a later post.

Unfortunately I couldn't find a 32K FIFO in through-hole components - well, there is an IDT7207 and IDT7208, but there are hard to source and DIP versions have been obsoleted - but I did find a much bigger FIFO with a 393,216 x 8 configuration, so it's more than enough for holding a framebuffer. The AL422B is actually really easy to source so there's that. Unfortunately it's an SMD component, but with an SOIC-to-DIP adapter it's easy enough to use on a breadboard. On a custom PCB it wouldn't be a problem at all though, even though SOICs can be a bit harder to solder than through-hole components for beginners - at least it was for me. 

So the FIFO sits between the ATtiny84 (KAPE GPU Pixel Timer) and the GPU proper, which is an ATmega1284P. It has 16k of SRAM (the highest I found in the AVR line), and comes in a DIP-40 package. It's a bit pricey when bought individually from Chinese sites (I paid for one about 7€), but should be actively in production and a bit cheaper when buying from sites like Digikey.com. The ATmega1284P works in the system as a GPU, and the 16k RAM enables me to use a tile-set of 16x16 8x8 tiles in RGBI - that takes 8k of memory, but enables me to just push the pixels out. This current method has about ~45 fps, (frame time is about 22 ms). I need sprite drawing and command handling as well, so we might need to push the MCU more to get where I need. Perhaps overclock the chip to 32 MHz? Currently it runs at 18 MHz (as I didn't have a 16 MHz passive crystal oscillator available when building it.

The current design idea is to communicate with this GPU from the CPU side by commands, and I'm using another FIFO in between as a command/data buffer. As it's quite hard to get outside timings to work with an AVR chip properly, the FIFO chip acts as the real IO device the CPU side will see. I have added a 74HC595N as an extended IO for an Arduino UNO that communicates with the FIFO and works as though it was the CPU side sending commands, and this gives me the ability to actually debug and make sure the design actually works. The FIFO is an IDT7203 and at least they are easy and cheap to source from China, but it's an obsolete part (at least in DIP package) so we might need to redesign this whole thing at some point. Also one of the reasons I want the expansion bus and modular GPU and other cards.

Current firmware supports both a 32x24 text mode as well as a 32x24 tiled graphics mode.

What's this project all about?

Hey there! 

So what's all this KAPE homebrew stuff all about? Well, a couple
of months ago I needed something to direct my attention to. So I started reading and watching videos on YouTube about 8bit computers. I decided I want to design and make my own 8bit computer as well, and that's what KAPE is all about.

As everything needs a name to be able to talk about them, I decided to call this project KAPE. KAPE is short for 8bit game machine, but in Finnish (Kasibittinen Pelikone). The current design goals are as follows:

1. 6502 as the main CPU
2. At least 64k RAM (Maybe more with some paging techniques?)
3. A minimalist base ROM of 2K that lives in the top 2K of the memory map
1. This ROM is just a bootloader, and will load from a swappable Serial ROM to memory and runs that
4. Expansion Bus w/ edge connectors that tap directly into the CPU Address and Data Buses in addition with a few control signals
5. Peripherals with a VIA chip (6522) and serial communications with either an ACIA (6551) or some other, perhaps more modern UART chip
6. Address decoding with either common glue logic chips or a single ATF22V10C GAL chip.

One of the main goals for the board design and material choices is to have as a little an amount of components as possible, and use mostly through-hole components. These chips need to be able to sourced easily either a few at a time from places like AliExpress or Ebay, but it would be nice if they would still be in production and could also be sourced from big chip resellers like Digikey or Mouser. 

I will be prototyping this whole thing in breadboards (thanks Ben Eater for the videos about breadboard computers! Helped me a lot on this). Eventually the end product will be a computer-in-a-keyboard-case kind of deal (a la C64, Amiga 500, etc.) with a 60% keyboard with some additions - mainly arrow keys and ESC, possibly some others. All in a custom PCB inside a custom case, what could be better than that! I've been working on this for months now, and I expect the end result to be done and ready in a year or two.

The main board part is still yet to be designed in any meaningful way, except I've been thinking about things like these for the most part. Currently the most interesting progress I've made is with the GPU. As I'm going to design a 2D platformer with exploration and fighting elements a la metroidvania that the computer will be running - in addition to other software - I will need tile-based graphics rendering with sprite support. The design goals for the KAPE GPU are as follows:

1. Resolution of 256x192
2. Output a PAL RGB signal
3. At least 16 colors
4. At least 1 background tile layer
5. Sprite support for multiple 8x8 sprites on anywhere on screen (with variable hotspot)
6. At least 25 fps refresh

I haven't decided on whether I would use any scroll registers or not. I was also debating a long time on whether to just get a V9958 graphics chip used in MSX systems as that would somewhat fit my requirements, but in the end I opted to go for modern microcontrollers and use AVR chips for graphics generation. The idea is to use the graphics card in the expansion bus, so in case decided to change my mind later, I can just yank the GPU out and design a new one. One possibility would be to just use a STM32F411 MCU for graphics generation, as it would definitely be fast enough and has a lot of RAM as well as supports DMA operation from memory to pinouts, AND it has breadboardable breakout board readily and cheaply available, but currently I'm just having too much fun creating the GPU on AVRs.

Early prototype output, straight output from an Arduino UNO through some resistors and a composite output (a monochrome output with 104x192 or 13x24 text output)