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.
Ei kommentteja:
Lähetä kommentti