Sunday, August 31, 2014

One year with no (posted) news

Yes, I'm alive and kicking :)

Sorry I may have appeared MIA... I just had nothing interesting to post; it's been a year since I virtually don't have anything going on involving my lovely DS or the little GBA.

Anyway a few months ago I recovered my younger brother's SEGA Master System II and also his SEGA Game Gear, both of which were forgotten long ago... fortunately, they both are still almost perfectly working.
In case you've never heard of them, they're basically the same hardware, even if the latter is a portable system featuring a color LCD display, more colors and stereo audio. What we're talking about here are 3.5 MHz Zilog Z80 powered 8 bit systems, not exactly something you can compare to GBA 16.5 MHz and DS 66 MHz 32 bit ARM processors horsepower.

Still it's already proving to be very intriguing to write code for these consoles.

First, you have to deal with the processor. The Z80 is an 8 bit CPU, as I said, so actually it can handle only rather small numbers. It even has no instruction to perform multiplication, not to mention division. Shifting a register requires twice the time it takes to make an addition, and you can shift bits left or right by one position only. The fastest operations, such as the addition, require 4 clock cycles (here's the complete instruction set). Many basic operations are available on selected registers only.

The memory. The system features 8 KB of RAM, built into the console. However, the code runs from ROM: there is a chip inside each and every cartridge, so there are also no loading times. ROM size can be up to 1 MB, but everything bigger than 48 KB requires bank switching to access the upper part.

There's virtually no other option but to code in assembler. WLA DX is currently the assembler of choice.

Then there's the hardware responsible for the graphic, the Video Display Processor (VDP), which has very limited capability, again I mean compared to the DS/GBA. Basically here you've got a single background made up of a grid of 32x24 tiles, each with 16 colors either from the first or the second palette, which is the one that is also used by the sprites. The hardware also isn't capable of displaying more than 64 different colors, and I don't mean at the same moment. Finally, up to 64 16-colors sprites (each 8x8 or 8x16 pixels dimensions) are available, but only up to 8 will be drawn on the same scanline. Sprites unfortunately cannot be flipped neither horizontally nor vertically. The VDP still has the quite powerful feature of supporting hardware scrolling of the background in both X and Y directions.

The background tiles, the map, the sprites graphics and the Sprite Attribute Table (SAT) all share the same VRAM space, which is only 16 KB total. The most troublesome issue here is that you can write to VRAM in specific moments only (when video is disabled or during VBlank). If you write to VRAM at the wrong moment, your data will simply be discarded, so it's very easy to end up with corrupted graphics.

Finally, Japanese version of the SEGA Master System apart, the system generates music and sound effects from its PSG chip (the Texas Instruments SN76489 Programmable Sound Generator), which has 4 mono audio channels. Each of the first three channels can output a true square wave (50% duty cycle) of a given frequency, while the fourth channel can output noise only. Volume of each channel can be set to one of 16 attenuation levels on a logarithmic scale.

There are some ready-to-use tools and libraries to compose and replay modules using the PSG chip, but none of these libraries is currently supporting both music and sound effects. So I decided to try implementing a solution to be able to have sound effects over background music, even with the very limited number of available channels.

The result is PSGlib. It plays VGM tunes written for the SN76489 (the tunes need to be converted to a specific format), and it supports sound effects on the third square wave channel and/or on the noise channel, avoiding any collision with the music that would be probably trying to use the same channels. More details about the library may follow in a separate post, eventually.

And... that's pretty much everything so far.


  1. Nice. Hope to hear more about it ... Has it got any support for SAT updates during HSYNC to support more "virtual sprites" as for the C64 ?

    1. In theory you could update the SAT in any moment, but writing to VRAM when screen is on (and not in VBlank phase) requires a precise timing or the data will simply be discarded.
      During a single scanline you can push no more than 8 bytes to VRAM and that makes "virtual sprites" pretty hard to achieve... though not impossible per se.