One of the characters driving the kart MUST be a penguim! 
One of the characters driving the kart MUST be a penguim!
Absolutely! That was my first though too!
But as of now I haven't been able to portray a penguin on a kart from behind... YET!
Wha i think that maybe not a racing, but a 3d tank battle multiplayer game could be done with this engine?
it should be possible, definitely, a 3D version of tanks... actually I did one as my engineering thesis 
But I have not calculated yet where you need to display a sprite given its 3d location and the viewport orientation, so enemies can not be yet displayed. This should be the next step!
The code is quite ugly
I only update the color table, and I set the pattern in a way that each write to the VDP writes exactly 2 superpixels (of 4x1 each), so no colorspill. It is done in a way that if I write 0xAB, the first 4x1 pixels get the color 0xA, and the second 4x1 pixels get the color 0xB.
The map is 64x64 pixels, it is stored in a somewhat weird way: 1st byte contains two times the 1st pixel, the 2nd byte contains once the 1st pixel and once the 2nd pixel (immediately left from the 1st), the 3rd byte contains twice the 2nd pixel, etc... So if pixels starting from the left corner are colored 0, 1, 2, 3, ... the map is stored as:
0x00, 0x01, 0x11, 0x12, 0x22, 0x23, etc....
This means that the map takes 8kbytes (64x64x2), but we store 4 copies of the map, one for each 90º rotation.
As a result, the map occupies 4 segments, of the 256 available in ASCII8 mapper.
The tables are basically a set of offsets (16 bits), and are precalculated in two areas. the 4x1 offset is 32 lines x 32 characters, and takes 2kbytes. the offsets for the 4x2 part is also 32 lines x 32 characters, so another 2kbyes. Full lookup tables for a specific view is 4 kbytes.
Each big map pixel is divided in 16 possible subpixels (4 horizontal subdivisions, and 4 vertical subdivisions), and we encode 16 angles (from -45º to +39.375º). We need one lookup table for each combination: 256 combinations, 1024 kbyes (128 segments).
The precalculated a lookup tables only cover for 90º, this is the reason we need to encode the map rotated 4 times.
When rendering, we use the mapper to map the map to 0x8000 and another copy to 0xA000, so beyond the horizon we see a repetition of the original map. We map the current quadrant of the map.
Then, the lookup table corresponding to the current subpixel and angle is mapped inside the 0x6000 segment.
At the start of the copying rutine, HL points to the current map coordinate that contains twice the pixel value. SP points to the beginning of the lookup table, and we start to run the code that combines the current map coordinate (on HL) with the lookup that calculates the perspective.
That's the very rough explanation. There a few oddities more, but they are not really relevant to the engine.
