• Compy FPGA – Palettes and line buffers
• Compy FPGA – VRAM and Cornet CPU
• Compy FPGAs and how I got here (this one)

I had a lot of problems in the way. A lot! Fortunately they are part of the past now and I finally started to walk instead of crawl. Following are some of those stones that I hit in the road.

Which FPGA to use for development

When I started I didn’t have a clue of what FPGA I would need, so I decided to start with something cheap with enough connections to not miss anything. If that board would fell short I would know better which one I would need, and in fact, that was what happened.

I think that I started with the right foot choosing an Altera FPGA, I just can develop everything on Linux and there is more than enough, I mean, a lot more than enough documentation for my needs. The development environment is simple and on the long run it starts to feel familiar. Some tools like the Signal Tap Analyzer ended to be critical, but more on that later.

My first FPGA was a development board with a Cyclone IV with 6KLE. I got it for around USD$70 at that time. It fell short mainly for two reasons: I started using 40% of its capacity as early I started going beyond the basics, and the amount of block ram available (32K+) forced me to depend on the SRAM for everything. In the middle I got the Arrow SoCKit which is a beast, it has 110KLE, 2GB of DDR3 RAM, even an ARM CPU and I got it for USD$60.

The SoCKit has two main problems: One is that the RAM is harder to use and you also need to interact with the ARM CPU. The other problem which was a blocker for me is that the price that I got for it was not real, it can be easily go beyond USD$300 and I think I shouldn’t design for a device that most people would find expensive and overpowered like I find it now.

Fortunately I was able to find a middle spot, which is a Cyclone IV with 55KLE. These are the parts that I like the most:

• The price for a development kit is around USD$80, almost the same price that I started with
• You can get it as a core board + a daughter board with sdcard, port, buttons etc. For the future it should be easy to create a custom board for Compy just adding the same core board provided for less than $60 (for the core board)
• It has plenty of block ram (256K+) which allowed me to use it for the video RAM as described earlier.

Timing is critical

The main problem that I had was with timings. I read a lot about it but even being aware of the existence of the problem I didn’t realize that I was just having that problem. For a software engineer like me, one has a way of thinking that is very different than a hardware engineer. One comes from a sequential world and the hardware world is mainly parallel, you need to turn your sequential approach and divide it in bits of small parallel tasks. If you don’t get small enough, your logic just can’t be executed in the required clock cycle.

Another problem is that you just cannot use several clocks and share data between them. That’s an area that is very well studied and explained but again, I didn’t realize how critical it was. I was getting builds that ran flawlessly, then then next time the same logic glitched and I didn’t know why.

I would never give enough thanks to Daniel Serpell that helped me to realize of these issues and how there were all around my design. He gave me invaluable pointers to get them fixed and finally move forwards.

Daniel also has his own 6502 based computer, and from time to time I go to read his verilog code to check how he solved the issues that I find often with my design. I also have looked at several MiST cores, they are harder to read but they also help to check how different systems resolved common issues.

Signal Tap Analyzer

One of the most difficult parts for me was to know what was happening with my design in the FPGA. I did several approaches, like using the amazing 8bitworkshop IDE to simulate some parts of my design, or using the video output to display some events, like using specially colored pixels to display when video RAM was being read. It was some sort of “printf” for hardware design.

I knew that in the past people used oscilloscopes to see what was going on, but for me it was out of my reach. I knew that a tool called Signal Tap would help, but for some reason I wasn’t able to display any signals after several tries. Finally I understood how to set it up and it just changed my whole workflow. Now I know that if I get a behaviour that I don’t understand, I can always use Signal Tap and see the all the signals in all their glory, even keeping all the symbolic names! Again, it was a fortune to select Altera for my FPGA implementation.

Back to the first post of this series: Compy FPGA – Palettes and line buffers

• Compy FPGA – Palettes and line buffers
• Compy FPGA – VRAM and Cornet CPU (this one)
• Compy FPGAs and how I got here

Video RAM

Simultaneous access to RAM from the CPU and the video chip has been always an issue. When using a single bus as most 8 bit computers did, the CPU cannot access the video memory while the video chip is accessing it. There are some notable cases that I’ve seen, for example in the ZX80 computer the CPU had the priority to access the bus, so if you pressed a key and the CPU handled it, the image got corrupted because the video chip couldn’t read the pixels from memory at the same time. On other cases, if a computer has high resolution modes that require to read a lot from the memory, the CPU is most of the time just blocked for access, halted, so you end up with a very slow system, regardless the CPU speed or frequency.

Computers like the MSX took a different approach: The video RAM is isolated from the CPU and only the video chip can access it. This method solves the CPU blocking but produces an additional problem because it is more complex to read and write from video RAM because you cannot access it as memory, you need to do several reads / writes to access each pixel through the video chip.

Compy will use a more modern approach, again thanks to the dual port RAM. The CPU and Chroni will be able to access the video RAM at the same time, each using one port and their own clock! So the CPU runs at full speed and sees the video RAM as normal memory.

There is one additional feature that is not yet implemented but it will be very easy to do. When you use direct access to video RAM in the addressing space (65KB), it’s easy to read/write using the CPU because is “just RAM” so you use the normal LD/ST instrctions, but as you go higher in resolution, colors and other features like sprites, you reduce the amount of addressable memory for code and data. For example in the ZX Spectrum you have 48KB of RAM, but around 6KB is used as video RAM, so you only have around 42KB for your code and data. In the Atari800 a high resolution mode could bring the available RAM from 48KB to only 30KB+ if you are using double buffer, so there is always a compromise between video quality and amount of RAM available for your code and data.

For Chroni to provide high resolution modes with more colors and sprites than these computers, you need a lot more memory. To not sacrifice address space for code and data, I defined that the 128KB of video RAM will be mapped on memory as 8KB blocks, so it wouldn’t take more space than the other computers still allowing to access it at full. The problem now is that the code to access that video RAM may need to handle page traversal, this is, changing the currently mapped 8KB page for another one when needed.

Quite at the beginning it was a though decision to make, because the alternative was to use the method used in the MSX but… why not both? Using the dual port RAM it is quite easy to provide both methods giving more options to the developers depending on what they need. If you need precise read/write operations, you can map the video RAM into the addressable space, if you need just large reads/writes spanning several pages or you want to use the full RAM to store the code and data, you just can unmap the video RAM and access it using the MSX method. The best of both worlds.

“Cornet” 6502 CPU

Adding more features to the FPGA implementation has not been easy at all. One of the problems is that some features require other features that cannot be isolated. For example when adding palettes I also needed a way to initialize that palette from somewhere, so I started to require more sequential code…. a CPU was needed.

Or well, some sort of CPU, even a laughable one.

There are rock solid implementations of several processors, but with my little experience I knew that adding such a big component would be very hard to troubleshoot if I didn’t understand the implementation first. So I decided to create a small 6502 like CPU with just a few instructions, only the ones that I need for now. In the future it will be easy to swap this CPU for a good one because I’ll know that the system works and it is not a fault of the big block of code being added.

Adding this naive CPU was a complete success. It not only allowed me to make some parts of the system work, but it also helped me realize of many of the improvements described in these posts, and I’m starting to feel that Compy in the FPGA is a bit more of a computer rather than only a video output.

Continue on: Compy FPGAs and how I got here

I started writing about all this as single post, but it grew a bit, so I splat it into three posts

• Compy FPGA – Palettes and line buffers (this one)
• Compy FPGA – VRAM and Cornet CPU
• Compy FPGAs and how I got here

I’ll start with some design changes and improvements to the design of Compy that were driven by the FPGA implementation, and I will end talking about the main issues that I had to fight against and how I was able pass beyond them.

The global palette and output modes

Chroni uses up to 256 colors from a 16 bit RGB palette (RGB565). At the beginning I thought about putting the palette anywhere in VRAM but then I realized that reading pixel data and color data from the same memory at the same time will leave too little time to add sprites later, you must know that there are limited cycles between outputting one pixel and the next, specially on the high resolution video modes. If you require more cycles than allowed between pixels, your screen will just glitch.

How older machines resolved this problem? Older computers had fixed palettes, so they don’t have load data from memory to know which RGB values they need for that pixel.  Computers like the Atari800, C64 and ZX Spectrum, they all have fixed and well known palettes. Then the IBM-PC had a different method, the RGB values are not stored in memory but in registers, so I went this route instead: You just write a palette index and then you write two values to store the RGB565 color for that index. Later Chroni will read these registers to know the RGB565 color to use for a certain 8-bit pixel value.

You will see that this approach opened the alternatives for other interesting features!

This is an example code setting the RGB565 color for palette index #9

BG_COLOR = $29AC 

LDA #0
STA $9004

LDA #<BG_COLOR
STA $9005

LDA #>BG_COLOR
STA $9005

Thanks to a suggestion from the ATLAS group in Telegram, I ended up using dual port RAM blocks for storing the palete. One of the advantages of this method is that you can read and write values using different clocks. I defined that the system (CPU, main memory, and others) will run at a fixed frequency (100Mhz based), but the output (VGA) will run at the frequency driven by the output resolution (25Mhz – 150Mhz). This separation allows Compy to use different output modes without affecting the computer speed. Note that older computers were strictly tied to the screen output, so PAL and NTSC computers ran at slightly different clock rates and they were all based on the pixel clock frequency which was around 3.58Mhz. With the amount of available video options these days, I think that it’s very restrictive to tie the computer speed to the output frequency of certain video mode.

Line buffers

Older computers also read one pixel at a time when rendering to the screen, but this restricts the number of operations that you can do for each pixel, also this is one of the reasons the computer speed is tied to the output frequency. As I separated the main system from the video output I needed a way to render the pixels not at the same time that they are going out to the screen, so I first render one line of video and then the output logic will just read this line buffer when needed, at the required output frequency.

This method has several advantages. It’s easier to:

• Use any scaling method on the output
• It’s easier to define the final pixels, for example when overlaying sprites
• Reading the pixel is just reading one pixel value and then the palette entry.

Computers like the Atari800 had this kind a separation but at a pixel scale. The ANTIC chip was responsible of reading the memory and ended outputting just a bit encoded color index, then this bitstream was fed into the GTIA, which was responsible of turning this color code to the signal required by the television encoding (final pixel).

Of course, line buffers are also implemented as dual port RAM. On one port the pixels are calculated and defined, and on the other port the final pixel values are just read. Using double buffer, before each scan line has to be sent to the video output, one line buffer is populated while the other is being drawn.

Continue on: Compy FPGA – VRAM and Cornet CPU

The problem is that 4:3 displays are not available for most people on these times as 16:9 monitors are, so I started with this idea of handling the output display:

• Alternative 1: Compy -> VGA -> VGA Monitor 4:3
• Alternative 2: Compy -> VGA -> VGA Monitor 16:9
• Alternative 3: Compy -> VGA -> VGA to Composite converter -> CRT TV 4:3

To handle each connection alternative, having different output modes will allow us to have the 4:3 display on TV devices and VGA monitors, being them wide or not, CRT or LCD. But, there is a catch, because for standard compatibility you need to use standard VGA modes like 640×480, 800×600, 1280×720 or 1920×1080, so I found a way to create some display modes that will match each video requirement. There are the video output modes:

• Mode1 640×480 : Each pixel is duplicated on the screen, there are no borders. This mode is suitable for 4:3 flat panel and CRT VGA monitors, and TV devices that don’t require any kind of borders/overscan.
• Mode2 800×600 : Each pixel is duplicated (640×480) on the screen but there is a border around the display area (overscan). This mode is suitable for TV devices that may require overscan.
• Mode3 1280×720: Each pixel has triple the size on the screen (960×720). This mode is perfect to get the right aspect ratio 4:3 on modern 16:9 monitors.

It was not that simple: 80 characters mode

For some time I wanted to add an 80 columns mode, I was doing some testing using 4 pixels wide characters, but I never felt it right, so after watching some videos showing the Amiga with a real 8 pixel 80 columns mode I decided to give it a try and I loved it.

Now, this mode requires 640 individual pixels per line, and TV devices are not capable of that, you end with some color glitches around the single pixels, but as this mode is meant to be used to program or work directly on the machine and there is already a 40 columns mode for TV I thought it would be a good option for those with “high” resolution VGA monitors.

Initially it was an easy to implement mode, because it was just doubling the original 320 horizontal resolution, but a problem arose with the 1280×720 mode: If I wanted to use the screen at its full glory, the only option was to use 3 times the resolution, this is going from 320×240 to 960×720, but how do you get 80 columns with 960 pixels. You can’t.

What I finally did was to relax the design and allow to have a 120 columns mode (960/3) when using output Mode 3. This mode was something that Aldrin Martoq was proposing some weeks ago and I turned it down because of the TV resolution restrictions, but when using a wide VGA monitor is just perfect.

This is the only special mode, and programmers (me) will need to query the output mode to know if this high resolution text mode is 80 or 120 columns wide.

Following there are three shots showing each mode.

I think Compy should encourage people to experiment, write their own programs, port games from other systems and make better versions of them. To accomplish this, in the audio area one would like to have the simplest way to produce a sound and at the same time to have the flexibility to create interesting sounds and music. It’s hard to have both at the same time, that’s why I started with the POKEY, because it allows one to create a sound just writing two values containing the frequency, type of sound and volume. Just as simple as that. This is the simplest way to produce a sound.

Creating more complex sounds with FM Modulation

Now, what is the way to create more interesting sounds? Here comes FM or Frequency Modulation, a technique to alter a simple wave using other waves called operators or modulators. These operators usually come in configurations of 2 or 4 operators per channel. This technique is frequently combined with envelope modulation, a technique to use the same base wave to produce different kind of sounds, for example a piano like sound and a violin like sound can be built from a similar sine wave, where the only difference is how quickly the sound reaches its highest volume before decaying. This is known as Attack/Decay/Sustain/Release or ADSR envelope.

FM synthesizers were the rage in the ’80, just in the time where Compy is designed to be based on! There were popular ones like the Yamaha DX7 used in professional music, and the ones inside arcade machines and computers from the late ’80 and early ’90.

But we are skipping a beat here.

The Programmable Sound Generator: PSG

Before going full into FM audio there is a middle ground – and this is very important if I want Compy to make it easy to port games from popular computers like the ZX Spectrum, Amstrad and (maybe) the MSX machines.  There was another extremely popular sound chip that was used in these machines and even bigger ones like the Atari ST: It’s the famous PSG, also known as the SSG, the AY-3-8910, the YM2149, Ben Sobel…Leone, Benny the Groin, Elmer the Fudd, Tubby the Tuba and the fuckin’ doctor. That’s it, bada-bing, bada-boom, very good.

The PSG is a three channel sound chip that can create pure square wave tones or noise with ADSR. It’s simple like the POKEY and it has a distinctive sound but most importantly, it was widely used. Think that the first version of Castlevania called Vampire Killer in MSX had its well known spectacular music coming from a PSG. A lot of games from Konami and other companies like Compile made an impressive use of this simple sound chip, so in some way the PSG must be included in Compy.

Hold on and you will see that this interruption will make sense at the end.

Yamaha FM audio alternatives

Coming back to FM audio there are a lot of alternatives to choose from. In this case it would be very tempting to choose the most powerful FM sound chip around, but this would not be realistic for a computer from 1988, it would give it an anachronistic sound. Also the programming interface must be simple enough to allow the 6502 or the z80 to handle it, the only permission that I would give is to use a higher frequency clock just to allow the computer play a song while running a game, if not, the CPU would only be able to play a song and nothing more.

Yamaha has several FM chips, and after studying all of them, I considered only these ones: OPL, OPLL, OPL2, OPL3, OPL4, OPM, MSX-AUDIO, OPN, OPNA and OPN2

From that set of sound chips and considering the characteristics of this computer I discarded OPL3, OPL4, OPN2 and OPM for being just too advanced, they are more appropriate for the next CLC-92 computer.  Basically the OPL3 is an stereo OPL2 with twice the channels and more wave forms, it was used in the popular Sound Blaster 16 (I told you it was too advanced for 1988). On the other hand the OPL4 is an OPL3 with wavetable synthesis from.. 1993. Totally out of the Compy timeframe. The OPN2 was used in the Sega Genesis, a 16 bit console, and finally the OPM is a special case…

The OPM (YM2151) is a sound chip from 1983, but it is quite powerful! It is like an OPL3 but with less channels. It was used in the Sega System 16 arcade board (Out Run) and the X68000 computer which is a computer from the 32-bit generation, just too way into our future. Even when the OPM is from 1983, it would cost a fortune to have that one in a home computer in 1988.  Now, I know that the Commander X16 by The 8-bit guy will use the OPM but they had their own criteria to choose it.

This shortens our list to: OPL, OPLL, OPL2, MSX-AUDIO, OPN and OPNA

The chosen one

The OPL is quite interesting, this is the foundation of all PC FM audio cards that started with the Adlib and continued with the Sound Blaster. The OPL has 2 operators per channel and nothing more. It was used in some early arcade machines like Bubble Booble and the C64 sound expander. It is a great option for Compy.

The OPLL is a cost reduced version of the OPL. Basically it is an OPL with 15 predefined sounds, meanwhile the OPL is fully programable. Now it may seem quite limited but it was successfully used in the MSX-MUSIC expansion and the Sega Master System console. There are some interesting tunes made with it. It’s a good option for Compy, but OPL is better.

The OPL2 is an improved OPL with more waveforms and additional algorithms. This sound chip was what made the Adlib the standard FM audio for PCs, and it is included in some way or another on every PC computer up to today. It’s quite versatile and using good programming you can make a masterpiece with it, the music made by Vibrants and games like Tyrian are the best examples of what can be achieved. Unfortunately this sound chip also has the characteristic sound of bad programmed music, and it is quite hard to not think of a PC game with horrible music when listening to it. It doesn’t add something new to what we already have been listening for years so that makes it quite boring. I discarded it for all that.

The MSX-AUDIO is basically an OPL with PCM sound. This is: samples!  You can combine your FM Music with real sounds like short voices or drums, which is what it is most used for. The PCM part is not like what we have today but it is ADPCM, a sort of compressed PCM that can use less memory with a little reduction on quality. This option is more interesting than the OPL one.

The OPN (YM2203) is a quite different beast from 1983. While the OPL is a 2 operator chip, the OPN has 4 operators like the OPL3 only with 3 channels instead of the 9 that the OPL has. So it has better sound than the OPL only that it has less channels, but hold my beer… it has 3 additional channels from a PSG!! I told you that this would come back! This is the perfect combination to have 6 channels with FM and PSG in the same chip. This sound chip was used in the NEC PC and some Sega boards like Hang On and Space Harrier. This is the perfect candidate for Compy but oh wait.. oh wait.. oh god lord please wait…

There is one more chip, the OPNA (YM2608). This is backwards compatible with the OPN but with big improvements. First, it has 6 FM channels that are compatible with the OPN, it also has the 3 PSG channels and grab to your seat because – por la cresta que es bueno este chip – it has 7 ADPCM channels. In its original design 6 ADPCM channels are connected to a ROM with predefined drum sounds and 1 ADPCM channel is user programmable. Using this chip you can have incredible good FM music combined with PSG and ADPCM. Quite a beast!!

The OPNA was used in the NEC PC computers and the japanese musicians made it shine with their music. It totally adds a new dimension to what we are used to listen from computers without moving away from 1988. When you hear it, you hear the ’80.

As you may have guessed, the OPNA is the selected sound chip for advanced audio in the CLC-88 Compy. There are emulators written for it and there are FPGA cores as well. The music made for the OPN (YM2206) will also be playable using this chip. Most importantly there are FM trackers that can be used to create new music or port existing ones… I only need to port the players to the 6502 and Z80 but that’s another story.

Now, I must admit that 7 ADPCM channels can be an overkill and probably I will use only one ADPCM channel. Also the design must consider probably 256K of additional RAM that will be directly connected to this chip without using the system bus. The programs must upload the ADPCM data to this exclusive memory and send commands to the chip to replay this data.  The other part, 6FM + 3PSG is just perfect.

Now, just listen to these videos to have a sense of what this baby can do.

(I know what you may been thinking… the OPNA seems more advanced than the OPM which I discarded, well the OPM is already used in the CX16 and it doesn’t have a PSG, so let’s bring something new to the table)

Today there are many people that is doing “remakes over original hardware”, they take an existing game from a specific computer and they patch the game to create a better version on that same computer. They are also porting games from similar architectures, for example they take an ZX Spectrum game and create an improved port for a more advanced computer like the MSX2. In the past, the game companies ported ZX games to the MSX but as budget was scarce they just made the minimum effort and they didn’t use the improved hardware. Today the only limit is the will to do it.

Compy provides improved graphics and sound but the design should allow a game to be ported with minimal changes. Chroni – the video processor – has Atari 800, Amstrad and ZX Spectrum like video modes and as of today, it provides dual POKEY audio with PSG (AY-3810) is planned. I don’t think there would be ports from C64 or MSX machines, they already have great hardware and older games still have room to push the limit on those computers.

A port should be easy to make at the base level, this being having a version that is just identical to the original. From there on many improvements could be made, starting with using a better color palette and as much as redoing all the graphics, using hardware sprites and improving the music and sound.

Multi clocks for the CPUs

Making such improvements may push the Z80 and 6502 to their limits, some games were designed to use all available cycles and making small changes like adding more sound channels may consume those scarce spare cycles. So to give greater flexibility these processors will run at a variable clock rate, they will start running at their original clock rate and the games will have the ability to switch the processor to a higher clock rate just writing to a specific port.

This will not only allow a game to do more stuff, it will also make CPU intensive games run faster. This has been already been done and there are excellent results in games like Rescue in Fractalus using accelerator cards.

In their original computers these processors were clocked around the TV NTSC and PAL standards, because they worked in sync with the video processor and pixel generation. Common frequencies for the 6502 and Z80 were 1.79 and 3.58Mhz respectively. Note that even when the 6502 was clocked at half the speed of the Z80, the internal design made the 6502 ran very well at that speed.

I still have to test it and see if this can be done but I would like to have a master clock at the speed required for video generation, and divide that clock to provide lower clock rates for each processor. Let’s say the video processor runs at 28.64Mhz, then using clock dividers I can provide 14.32Mhz, 7.16Mhz, 3,58Mhz and 1.79Mhz (CLK/2, CLK/4, CLK/8, CLK/16).  The 6502 would use CLK/16 and the Z80 would use CLK/8 at boot, but writing to a specific port they can switch to a faster CLK/4 and CLK/2. That would give enough power to make new games or make greatly improved ports, but as I said, I still have to test if this would work or not in FPGA given the original designs of these processors and other timing considerations like DRAM access and shared memory between the CPU and Chroni.

For this to work Chroni will receive the CLK signal and it will provide a derived signal for each processor. At all times Chroni will have the control over the clock – hence the name – and this will give it the power to halt the CPU and/or switch it to a different clock line as requested.

Boot process

To boot the system and select the active processor, this will be the boot sequence:

1. The system starts with the Z80 ROM mapped at the bottom of the memory map
2. The Z80 boot code checks if certain function key is pressed
3. If pressed, the 6502 ROM is mapped to the top of the memory map
4. The Z80 code writes to a port on Chroni to switch the CPU
5. Chroni halts the clock for the Z80
6. Chroni gives the clock to the 6502 and proceed with a reset procedure
7. The 6502 ROM code disables the Z80 ROM
8. The 6502 continues booting the system

At this moment there are no plans to switch back to the Z80 once the control to the 6502 has been given, that would make the design too complex even though it may open the doors to advanced programming tricks, but this is still too much beyond in the future.

What I did was to take the Raster Music Tracker player and port it to Compy adding a full user interface to select songs and play them. Porting RMT was quite easy, I changed the audio port addresses and modified the code a bit to handle mono and stereo songs using the same code (it was hardcoded). The rest of the application is another story, but it was a great exercise to test how easy/hard is to program this computer and I made a lot of changes here and there to add some library functions for common tasks like scrolling, handling strings and more.

Audio on Compy

Very early in the design I wanted to have at least two audio options, a simple one and a more advanced one so anyone can use what they are more confortable with, or both! For example a game could use the advanced audio for music and the simple audio for special effects. Now, with the right tools even the most simple audio can give great results as you can hear in the RMT player above.

For the simple audio option I chose the POKEY chip. This is a 4 channel chip that was used in the Atari800 and it is very very simple to program, just write a note in one register and the effect + volume in another register and you have sound.

On these days it is common that people modify their Atari computers to use two chips for stereo sound. I wanted something similar but I find that this can be a bit restrictive. Using two POKEY chips you have 4 channels at the left and 4 channels at the right, if you want to produce a sound on both sides you have to use 2 channels. I modified the POKEY emulator to add a new register where you can specify where every channel will sound, so you can use one channel for both left and right at the same time.

Now, the emulator code that I used had a bug when more than one chip was used and I spent a lot of hours tracking it down.  But as master Bob Ross says, this was a happy accident, because this forced me to understand how the POKEY works and that takes us to the next step.

A better POKEY

The POKEY produces sounds using a simple square wave with an amplitude from 0 to 15. This square wave can be distorted using a polycounter, which is basically a sequence of 1s and 0s that indicates if the square wave is cut off or not. Periodic sequences of 1s and 0s produce motor like sounds and more random sequences produce steam like sounds.

Now, this is a very simple device and still produces amazing sounds, but why not take it one step further! I will be modifying the code to add ADSR and more waveforms, so this chip will be able to produce sounds like the PSG (AY-8910) and the SID chip at some extent. Ironically, adding these kind of features is easier to do in FPGA rather than software, but software will come first.

By default the POKEY will behave like the original chip, but you will have additional registers to use the extra features.

Advanced audio

For advanced audio I still evaluating different options. I would like to have FM synthesis and a simple PCM processor. One could just throw an OPL4 chip with multi-channel hardware mixed PCM audio but that would be overkill for this computer, and it would not be realistic for a computer made in 1988. Not to mention that the 6502 / Z80 would struggle handling something like that.

Fortunately, there are some configurations from that era where I can get some inspiration. The MSX had audio expansions with FM and PCM, and even the C64 had an FM one.

Let’s see what are the options available.

Options for FM Audio

Yamaha is the king in this area, and they have at least three lines of FM synthesizers that I would call the low end, consumer and arcade lines.

Most people know the consumer line where we can find the OPL2, OPL3 and OPL4 synths, because they were used in the Adlib and Soundblaster PC sound cards. From this line I would only consider the OPL2, the other two are more appropriate for the CLC-92 Compu.

In the arcade line there are several interesting chips, including the one used in the Sega Genesis. Again, these are more appropriate for Compu and not Compy except for the OPM (YM2151).

In the low end there are more alternatives for a computer from 1988. In this range I would consider the Y8950, the OPL and OPLL (YM3256 and YM2413).

So, in summary the options are: OPL, OPL2, OPLL, OPM and Y8950.

Follow the links for sound examples of each one.

Options for PCM Audio

For PCM audio there are two limiting factors. First, it cannot be handled by the CPU, it is just not fast enough to produce sound and do other interesting stuff at the same time.  Second, the amount of memory limits the length and the quality of the sound.

I see two options here, one is to just create a dedicated processor and the other is to use a chip like the Y8950 that already has this part using a kind of compressed PCM (ADPCM).

The PCM would be designed for short mid-quality sounds, like explosions or drum sounds. The CPU would write the start address and length and the PCM chip would just play that. How many channels and stereo options are not decided yet. Another decision that must be taken is to add exclusive memory for PCM or not.

The MSX has good examples of this simple PCM feature and probably I would take more ideas from there.

Choosing a color palette is a big commitment.

Later on, VGA broke that commitment offering a “true color” palette, where you can choose between an universe of 16M colors, but VGA is far beyond the limits of what we would want for an 8 bit computer like Compy, also the memory and CPU speed would make it impossible to use that amount of colors.

The approach used by Chroni has the best of both worlds,  instead of using a fixed palette to start with, let’s choose a 256 color palette from a bigger colorspace (RGB565) and provide methods to use as little as memory as possible.

RGB565 Global Palette

How many colors can be displayed depends on the Digital to Analog Converter (DAC) used in the computer, older computers have limited colors because just a few bits were used per RGB channel, but today computers can use many more bits per RGB channel thus giving more color options.  For example, using 4 bits per RGB channel gives 64 colors (4³) 8 colors, and using 5 bits per channels gives 125 colors (5³).

Chroni is designed to be used through emulation or FPGA devices.  Using emulation we have “true color” (16M), but using FPGA the available devices are restricted to the real DAC converting bits to analog colors.  Of course, we can build our own resistor ladder DAC but if we look at the off the shelf options available, most VGA connectors use RGB 565, which is 5 bits for Red, 6 bits for Green and 5 bits for Blue thus giving 2¹⁶  = 64K colors, which is more than enough for an 8 bit computer.

In Chroni you define a base palette of 256 colors, but each color is an RGB565 entry, so you pick a subset of a 64K colorspace for your game or program. Using this method you can match any of the existing 8-bit computer palettes and also you can use a palette that didn’t exist on any of those computers.

The computer is not committed to a specific palette, but your program is, so you can define the style of how you want your game to look like. Take a look on this site about how a color palette can define the aesthetics of a movie.

Now, Chroni avoid to have fixed addresses and use pointers instead, this method helps avoid the CPU having to copy blocks of memory. Just change the palette pointer to another place in VRAM and Chroni will use that.

VPALETTE = $9004
lda #<vram_pallette_addr
sta VPALETTE
lda #>vram_palette_addr
sta VPALETTE+1

Sub Palettes

Once you define your 256 color palette, which colors will be used in 4 color mode? or 16 color mode? To better understand this part, let me explain how older computers worked.

The Atari 8 bit computer had a fixed 256 color palette, to select a color you write to a specific register with the index of the desired color in that 256 color palette.  If you write 3 to the color register you were referring to the palette[3] entry, if you write 29, it was the palette[29] entry and  so on.  For a 4 color mode you had 4 registers for the visible area and 1 register for the border color, thus 5 registers were needed to define all colors.

In Chroni there are no fixed registers for colors except for the border color, the display colors are defined by a memory area where these color indexes are stored. Again, this is not a fixed area and it can be placed anywhere, you only need to set a pointer to this area. This area is called a subpalette, so depending on the video mode you will have 4 color subpalettes, 16 color subpalettes and so on.

A subpalette base address is set through a display list instruction, so it is part of your screen definition and you can change it for every scanline.  More info about display lists will be added in this series of Chroni articles, for now think that for each line on the screen you can define a video mode and a subpalette to be used.

SUBPAL_BASE = $A806
VCOLOR0     = $9010 ; this is the border color

lda #0
sta VCOLOR0 ; border has palette[0] color

; now write a subpalette base address
; in the default display list

mwa my_subpalette_vram_addr SUBPAL_BASE

Color Attributes

Now, you can use an entire subpalette for your whole screen but that would restrict you to use up to X color in the whole screen. Of course, you can modify the subpalette or palette for each line but wouldn’t be awesome to have more than one subpalette for each line?

Chroni uses a similar method found in the Spectrum, C64 and NES to define colors through “attributes”.  In Chroni there is display data and attribute data: Display data defines the pixels, characters or tiles to be displayed, while attributes define which subpalette or colors will be used in that display.

For example, bitmap and tiled modes have attributes defining which subpalette will be used. So if you have a 4 color mode you will be using 4 color subpalettes. Look at the following code:

subpalettes:
.byte 0x34, 0x43, 0x85, 0x23
.byte 0x82, 0x01, 0x0F, 0xFF
.byte 0x22, 0x21, 0x44, 0x23
.byte 0x74, 0x29, 0x99, 0xA0
.byte 0x33, 0x32, 0x44, 0x42

The code shows 5 subpalettes, so using attributes you can select any of those subpalettes for each display block (depending on the mode). If you use 0 as the attribute for a display entry, that will use first subpalette (0x34…), if you use 3 it will use the third subpalette (0x22…) and so on.

Using this method you can change the colors used for any part of the screen just changing one byte (attribute), or you can point Chroni to use a different set of subpalettes just updating the subpalette base address in your display list as shown in the previous section.

Text modes use attributes in a similar way that the spectrum used the attributes. For each attribute byte a foreground and background color is defined, so you can use up to 16 colors for each foreground and backgound. Which colors? These are defined in a 16 color subpalette.

In the following shots you can see one same program using different global palettes.  The border color is changed through VCOLOR0, and the foreground and background colors of each char is defined by the attributes. Which colors to take from the 256 colors are defined in the subpalette.  Floating objects are sprites using their own subpalettes

This is a simple example to write to the first byte at VRAM

VPAGE = $9009

lda #0
sta VPAGE ; Map VRAM Page 0 at $A000
lda #$FF
sta $A000 ; Write $FF at VRAM $0000

This will set VPAGE to write into the next 16KB of VRAM

lda #1
sta VPAGE ; Map VRAM Page 1 at $A000
lda #$CC
sta $A000 ; Write $CC at VRAM $4000

VRAM addresses in Chroni

These examples use the VRAM addresses from the CPU point of view, but inside Chroni the whole VRAM is accesible via a 16 bit address. To access the whole 128KB VRAM addresses Chroni multiplies this 16 bit address by two (one bit shift left). So if you need to access VRAM $1254 from Chroni, you need to specify $92A as the address ($1254/2 = $92A).

As you may guess, all Chroni addresses are 16 bit aligned, so you can’t access address $1255 directly. For example if you use the Chroni address $92A, it will be VRAM address $1254, and the next Chroni address $92B will point to VRAM address $1256

VRAM to RAM – RAM to VRAM conversions

You will need to convert addresses from VRAM to RAM and viceversa to setup sprites, palettes, display lists, and more. The current BIOS included with the emulator contains code to do these conversions, you can call those routines or alternatively there is a stdlib.asm file with short routines to call that BIOS code.  These routines use predefined system variables to convert from VRAM to RAM and viceversa as follows:

VRAM_TO_RAM -> lib_vram_to_ram -> RAM_TO_VRAM + VRAM_PAGE

RAM_TO_VRAM + VRAM_PAGE -> lib_ram_to_vram -> VRAM_TO_RAM

VRAM_TO_RAM is a 16 bit Chroni address

RAM_TO_VRAM is a 16 bit CPU address and VRAM_PAGE is the page value to write on VPAGE

The following example will read the DISPLAY_START Chroni Address and will write the value $41 to it (letter A). The DISPLAY_START is a 16 bit VRAM address and lib_vram_to_ram will convert it to a CPU address.

mwa DISPLAY_START VRAM_TO_RAM
jsr lib_vram_to_ram             ; result in RAM_TO_VRAM

ldy #0
lda #$41
sta (RAM_TO_VRAM), y

Now let’s say that we have a charset written in CPU address $A800 but using VRAM Page 2, we can convert that address to a 16-bit Chroni address using lib_ram_to_vram:

mwa $A800 RAM_TO_VRAM    ; Page 1, $A800 is the CPU address
mva $#1 VRAM_PAGE

jsr lib_ram_to_vram      ; result in VRAM_TO_RAM. Chroni address

mwa VRAM_TO_RAM VCHARSET ; VCHARSET is a Chroni register

Of course you can use the BIOS functions or your own code to perform these conversions. Following is the code being used to perform these conversions

stdlib.asm short routines to call the BIOS

lib_vram_to_ram:
   ldx #OS_VRAM_TO_RAM
   jsr OS_CALL
   lda VRAM_PAGE
   sta VPAGE
   rts

lib_ram_to_vram:
   ldx #OS_RAM_TO_VRAM
   jmp OS_CALL

graphics.asm These are the BIOS routines that perform the conversion, use them only as a reference to implement your own code if needed.

; vram = (page << 8 << 6 + (addr-VRAM)) / 2 => page << 8 << 5 + (addr-VRAM)/2
; in : RAM_TO_VRAM with CPU address
; VRAM_PAGE 16K Page in VRAM
;
; out: VRAM_TO_RAM with Chroni address (in words)

ram2vram:
   sbw RAM_TO_VRAM #VRAM
   lda RAM_TO_VRAM+1
   lsr
   sta VRAM_TO_RAM+1
   lda RAM_TO_VRAM
   ror
   sta VRAM_TO_RAM

   lda VRAM_PAGE
   asl
   asl
   asl
   asl
   asl
   ora VRAM_TO_RAM+1
   sta VRAM_TO_RAM+1
   rts

; page = (vram & 0xE000) >> 5 >> 8
; addr = (vram & 0x1FFF) * 2 + VRAM 
; in: VRAM_TO_RAM with Chroni address (in words)
; out: RAM_TO_VRAM with CPU address
; VRAM_PAGE with 16K Page in VRAM

vram2ram:
  lda VRAM_TO_RAM+1
  and #$E0
  lsr
  lsr
  lsr
  lsr
  lsr
  sta VRAM_PAGE

  lda VRAM_TO_RAM+1
  and #$1F
  sta VRAM_TO_RAM+1

  lda VRAM_TO_RAM
  asl
  sta VRAM_TO_RAM
  rol VRAM_TO_RAM+1

  adw VRAM_TO_RAM #VRAM RAM_TO_VRAM
  rts

Following there will be a series of post detailing the features included in Chroni, and this time they are not only ideas, most of these features are already implemented in the Compy Emulator. I also included several assembly programs included as an example of use.

Let’s start with the list of features:

• 128K of Video RAM
• 320×240 maximum resolution at 16 colors
• 64K color palette
• 3 Character modes: Normal, Wide and Double (1×1, 1×2, 2×2)
• 7 Bitmap modes: 160 or 320 pixels wide, from 2 to 16 colors
• 3 Tiled modes: 16×16 pixels, 160 or 320 pixels wide, from 4 to 16 colors
• 32 sprites. 16×16 pixels, 15 colors + 1 transparent color
• Horizontal and Vertical scrolling (not implemented yet)
• Antic like Display lists
• Vertical Blank Interrupts
• Display List interrupts

Design principles

A proper design for a Video Processor that will be driven by an 8 bit CPU must consider its limitations, mainly speed and the amount of addressable memory: The CPU just can’t read or write a lot of data per frame and the addressable memory is only 64KB.

Chroni is designed to reduce the need for screen memory access by the CPU, so copy operations are avoided by providing pointer operations instead. For example, sprites can be updated just pointing the data address to any location in VRAM. Using this method you can modify a sprite with just a 2 byte write operation. The same with palettes, tiled graphics and so on.

VRAM is mapped into a 16K window on main memory, and it can be mapped out because only Chroni needs to access that memory at all times and not the CPU. Using this method all the VRAM is accessible via a simple memory write/read instruction, there is no need to use more complex methods like registers on the video processor.

This is just a quick overview of Chroni, keep reading these post series for full details.