Jaguar Coding Nightmare

At last!!! Today I've put together all three games that I've been developing for the last... I don't know and I don't want to remember, it was too much time.

I think that I've spent more than 70% of the time fixing bugs, some of them were my own mistakes, when you code all by yourself it's normal to make mistakes but some of them were caused by some kind of mismatch between the tools and the lack of OS, these were very hard to find.

I haven't used any library, it's 100% my own code, well... Christmas Craze and Classic Kong are a port from the SNES version, but I had to rewrite some parts to use the Jaguar hardware.

Here you have a couple of errors that took me a lot of time to spot and fix it.

Data alignment

The Jaguar it's very picky with this, if you try to access a 32bits value (must be aligned to 4 bytes boundary) with the GPU but the data it's aligned to a 2 bytes boundary you won't read the correct value. It's ok but when you code in C sometimes you can forget to align the data or the compiler can do some nasty things (see below -flto).

Object Processor

The same as above but this time the data must be aligned to a 16 bytes boundary (phrase) or sometimes to a 32 bytes boundary (dphrase) for scaled objects.

Also when the Object Processor reads the list, it'll modify the Bitmapped Objects, and if you make a mistake in the list you'll hang the Jaguar instead of having a wrong display, sometimes because it will read data outside the Object Processor List and can smash the code.

-flto

Link time optimization, with this flags the compiler delay optimization to the link phase, I don't know if it a bit buggy or if it should be used with other flags but when I was using this flag (I wanted the fastest code 😜) some data missed the alignment, this means you are in big problems with the GPU and the Object Processor.

-fno-zero-initialized-in-bss

When I was coding the games (any of them) and the menu, sometimes the code didn't work (about 1/20 of the times), I uploaded the code to the Skunkboard and nothing happens. I thought that I got some wrong init code, I've looked at the init code at the Jaguar SDK and even I disassembled a couple of games to have a look at the init code, but everything looked fine.

When I coded the menu to launch any of the three games I got the following issues with each game.

1. Christmas Craze, it worked.
2. Classic Kong, always hangs at the intro when you start to play (Kong climbing with Pauline).
3. BurgerTom, sometimes it played the menu music, sometimes you can see the menu with graphics glitches, sometimes it just hangs at the very beginning.

It was really weird because all games begin with the same code, upload the GPU code, init the sprite system, init the sound system. If I uploaded the code of any game to the skunkboard it worked but failed if the game was launched from the menu, weird because it was a simple copy game code to $4000 and jmp $4000, the error must be somewhere, not in the menu... 

After a couple of print debugging (I wish to have a proper debugger 😞), I realized that this part of the code executed in a different way when the game was uploaded to the skunkboard than it was copied from the menu, _text_strip wasn't NULL 😮.

...

static SPRITE_STRIP *_text_strip = NULL;

...

void init_text()

{

    if ( _text_strip == NULL )

        _text_strip = new_strip(256, 224, 0);

    clear_strip(_text_strip);

    ...

}

Looking at the map file generated by the linker, _text_strip was located at the bss segment. By default gcc compiler put all data initialized to zero into bss (-fzero-initialized-in-bss) because the OS will fill the bss section with zeros, BUT we don't have any OS on the Jaguar so _text_strip can have any value, actually, It will have some value from the menu code or data.

So after a lot of headaches I could finish all games, sometimes it was my own error, sometimes the tools didn't worked fine (-flto) and sometimes the lack of OS support makes that some features of the tools useless (-fzero-initialized-in-bss).

Let's hope that future projects will take me a lot of less time 😉.

ST-NICCC 33%

This is a small update, I've realized that I've some bugs in my libraries when I tried to compile it. :(

The software render version (1) it's the same code than the first version but now I'm using gcc compiler instead of vbcc.

For now, only options 1 & 2 are implemented.

Music updated with the original tune.

I've realized that if you draw a CLUT sprite without writing the CLUT (using uninitialized colors) you will get some ugly vertical lines.

Download: st-niccc 33% (skunkboard only)
Download: st-niccc (first version)

My dream Jaguar

After some time developing for the Jaguar here are some ideas that I wish that Atari implemented into the Jaguar.

First of all, all the things about bitness it’s complete bullshit. You don’t have a better device if you have some 64bits processor, just have a look at Intellivision (Mattel 1979), it has a 16bits CPU so the games look just like a Sega Megadrive(Genesis) or a SNES, isn’t it?.

With today's technology you could build an 8bits console running at 1GHz, and a GPU with thousands of cores, each one will draw a single pixel. Everything using 8bits ALU, and it will blow away any other 8, 16, or 32bits console.

In the end the most important thing it’s the memory bandwidth, not the bits. Note, for 3D games also you need computational power because you’re going to do a lot of multiplications.

68000

It’s too slow to make something interesting also the lack of cache makes it starve for free cycles of the bus.

Ideally, it should be on his own bus with something like 256KB of RAM, and maybe only can access the other custom chips but not the main RAM. A better option could be a 68020 or a 68030.

GPU/DSP

I would change the instruction set encoding to allow a few more opcodes, all single operand instructions can use the same opcode, and then use the reg1 field to specify the actual instruction. Also, it’s a must to allow bigger jumps. And of course, include a cache (the real one) to run the code from the main RAM without the current headache.

Some new opcodes that I find useful.

- split: Takes a 32 bits register and write the high word into a second register and the low word into the current one. With and without sign extension.

- join: The inverse of the split opcode, of course.

- pack/unpack with RGB pixels

- load/store with pre-decrement and post-increment

- loadp/storep should work with registers pairs, instead of using a different register for the high word.

- 32bits bus on the DSP, well actually it has a 32bit bus but it’s not fully connected, maybe to make the MMU more simple?.

- Include a real sound chip.

Object Processor

Having to rebuild the Object Processor list on each frame it’s a waste of time, anyway I think that there are more important things to fix.

- Bigger CLUT, 256 color palette it’s not enough. At least 1024 colors, this is 4 8bits sprites with different palettes.

- Object to change CLUT

- It could be interesting to include an 8bit direct RGB mode in the color depth.

- More transparency modes and they must also work in RGB.

- Include three-color multipliers, one for each color channel, to make easy fade effects.

- Pixel precise collision detection. 

- Remove all link address in all object except at branch object.

- The Image Width field must be a signed value to allow vertical mirrored sprites.

- GPU interrupt Object must have y coordinate and height field, and work without bugs…

- Rearrange the bitmap object and scaled bitmap object to have the same size. If you remove the link address both objects fit into 16bytes.

- Improve the write ratio, it must write at 4 pixels per cycle.

- Cache, it will be flushed on each VBL interrupt.

Blitter

I don’t know why they thought that the bitter was fast enough, if you try to make any interesting effect like scaling, rotation or texture map you must work in pixel mode and it kills the performance. The blitter must be as fast as the Object Processor, it’s sad but you can’t make a game like After Burner (1987) into the Jaguar without a lot of headaches.

- Allow pixel expansion, this allows to use 1, 2, 4, or 8 bits texture and write the destination in a 16bits bitmap.

- Optimize single color/Gouraud horizontal lines. If you are going to draw a horizontal line, always write the pixels in phrases.

- RGB lighting

- Command queue, why do you have to wait for the blitter to be idle before you set any register? This is a waste of time.

- Reorganize the registers, why the integer and fractional coordinates are in different registers? What they were thinking?

- Cache, of course

RAM

Dual-port RAM could be nice but it’s expensive maybe 4MB should be better.

As an extra, I think that it would be great to include a second GPU to drive the blitter, something like a RPU (Rasterizer Process Unit) but it only runs code from his internal RAM. You’ll write a polygon list (or sprite with scaling/rotation info) and this RPU will read it and send the corresponding blitter command while you are processing the next frame with the CPU/GPU.

And of cause some more Mhz, a bus at 13Mhz it’s a bit slow.

Disassembling Supercross 3D

I've been playing a bit with my disassembler, mostly fixing bug... And I've been using Supercross 3D for testing. Looking at the source code I can understand why it runs so slow. Ok the Jaguar it's very slow at texture mapping but the code could be better.

For now I've seen the following things.

• The code it's about 117KB, 120,016 bytes to be precise and it's stored at the end of the cartridge.
• The game it's locked to a minimum of 4 vbls per frame for PAL systems and 5 vbls for NTSC ones, this means that it will run at maximum speed of 12,5fps and 12fps respectively.
• There are one block of DSP code, I suppose that it's the sound engine.
• There are eleven blocks of code for the GPU (maybe one or two more, I haven't finished the disassembly)
• One of the GPU blocks it's used just to set the Object Processor List Pointer, this one never it's loaded into the GPU internal RAM, it runs from ROM.
• There are about 20KB (21, 184bytes) of dead code or unused data, they are spread around the code and most of them end with a $4E75 (rts opcode) but they are never referenced or called.
• Short branches are almost never used.
• It waits for the bitter to be idle in several places, but IMO if you are using the 68000 you don't need to wait because it has lower priority (68000 < blitter), so if the blitter it's busy the 68000 will be stoped. The only advantage of not having a cache.
• There are some link/unlink opcodes, also some routines push values into the stack, jump somewhere, load the values from the stack to the registers and jump again to do the actual work. I think that some parts are written in C and others in assembler, and this kind of routines are used to jump from C to ASM.
• There are some parts of the game that depends if the system it's PAL or NTSC, but it reads the hardware register each time that it needs to instead of using a flag.
• The game runs in 8bits mode with colors in CrY format (not 100% sure).

And now some codes snippets. All of them are actual code (it's full of them).

move.w (a0),d0

addq.w #1,d0

move.w d0,a3

move.w a3,-(sp)

jsr l01e3e0e

At least it uses quick add, I think that this is used to increment the lap count and print it.

move.w #0,l01b72d8
move.w #0,l01b72da
move.w #0,l01b72dc
move.w #0,l01b72de
move.w #0,l01b72e0
...

What about using a data register and post-increment addressing?

move.l a1,-(sp)
move.l #l01ece80,d3
move.l d3,a1
jsr (a1)

Because jsr l01ece80 it's too easy.


By the way, I've found two bugs in my assembler when I was looking at the disassembled code to write this post.

Squeezing Part II

Let's start with the sound effects.

The game uses 23 sounds effects, let's have a look at them with Audacity.

• sample1.wav: 8,000 Hz 9,250 bytes 8 bits
• sample2.wav: 11,025 Hz 10,803 bytes 8 bits
• sample3.wav: 11,025 Hz 9,257 bytes 8 bits
• sample4.wav: 11,025 Hz 2,192 bytes 8 bits
• sample5.wav: 22,050 Hz 31,364 bytes 16bits
• sample6.wav: 11,025 Hz 7,834 bytes 8 bits
• sample7.wav: 11,025 Hz 6,807 bytes 8 bits
• sample8.wav: 11,025 Hz 4,442 bytes 8 bits
• sample9.wav: 11,025 Hz 7,436 bytes 8 bits
• sample10.wav: 11,025 Hz 4,535 bytes 8 bits
• sample11.wav: 11,025 Hz 6,834 bytes 8 bits
• sample12.wav: 22,050 Hz 14,040 bytes 8 bits
• sample13.wav: 11,025 Hz 6,925 bytes 8 bits
• sample14.wav: 11,025 Hz 17,407 bytes 8 bits
• sample15.wav: 11,025 Hz 1,922 bytes 8 bits
• sample16.wav: 11,025 Hz 5,409 bytes 8 bits
• sample17.wav: 11,025 Hz 3,288 bytes 8 bits
• sample18.wav: 8,000 Hz 14,460 bytes 8 bits
• sample19.wav: 22,050 Hz 20,748 bytes 8 bits
• sample20.wav: 11,025 Hz 20,876 bytes 8 bits
• sample21.wav: 11,025 Hz 15,898 bytes 8 bits
• sample22.wav: 22,050 Hz 14,444 bytes 8 bits
• sample23.wav: 11,050 Hz 16,110 bytes 16 bits

That's 252,269 bytes for the sounds effects.

As you can see, each sample has different resolution and frequency, this is quite common with home-brew games. I'll convert all of them to a 8bits 8,000Hz, signed sample. Maybe I can use a higher frequency if I've some free space to improve the sound quality. 

After conversion and packing the data I've 87,730 bytes, that's 34,7% of the original space or 65,3% space saved. If I need some extra space I'll use ADPCM encoding to reduce each sample to a 50% before compression.

Classic Kong Demo GPU version

I've recoded the sprite engine (part of it) into the GPU, I hope that it'll fix all the slowdowns.

Now it's time to fix that ugly clouds.

Download Classic Kong Demo GPU version

PD: Yes I've used the same image. XD

Classic Kong Demo

Demo version of the first level

I still have some issues to fix, also I need some feedback from NTSC users.

Download Classic Kong Demo