I actually meant it was to be released last week
but there are bugs which I hope to correct in the next week or so. It all depends on free time, as usual...
The MSX1 version will follow very quickly as its display is not too different from the Spectrum. As mentioned, this first version will operate at the lower 32x24 colour resolution with the advantage being this will be a bit faster and it will be 100% source compatible with the Spectrum. In time there will be a second version for the MSX1 and Timex machines (which share the exact same 256x192 pixel 32x192 colour resolution display mode) so that it will be possible to choose between a faster low colour resolution mode and a slower high colour resolution mode. I don't think the lower colour resolution mode is too much of a compromise because the MSX still has those 32 hardware sprites that can be added to spruce up the colour if desired.
splib2 has a 32x192 colour mode already. What it does is use 3 bytes to define each 8 pixels of the sprite (graph, mask, colour) and has a "rotation threshold" parameter that determines how much the sprite needs to be rotated in the x direction before the colours are also rotated. The single colour byte for the 8x8 pixel tile is renamed a "pallette byte" that is used as an index into the pallette table where the eight colour bytes used for the tile can be looked up.
What I would like to do (and haven't thought out completely yet) is to continue with the pallette byte idea (a single byte used to look up eight colours) but also have some bytes reserved to mean a solid colour used for the entire 8x8 pixel tile. I hope this will speed things up. For the sprites I would like to move back to the two-byte definition (mask and graph only) and use pallette bytes for their colours as well. The reason is the next lib has functions to colour the sprite by copying colour bytes into each sprite's 8x8 pixel structs. The colours for these functions can be chosen depending on how much the sprite has been rotated in the x direction, hopefully assisting with the colour clash problem. If I had to copy 8 colour bytes per 8x8 pixel struct, it would slow things too much.
Another thing I am looking at is the possibility of having sprites display on odd pixel rows while being transparent in even pixel rows and have background tiles display on even pixel rows while being black on odd pixel rows. This way sprites and background never clash, but I am not sure how good this would look.
As you can tell, the ideas are still much in the air about how to handle the 32x192 colour mode. If you have suggestions, now is a good time to make them
About the CPC: I don't mean to exclude it from discussion here. The main problem is that I am not sure yet what to do with the CPC version. On the one hand I would like to have a version where games written for the Spectrum and MSX1 can also run on the CPC with minimal fuss (and vice versa), but then the CPC is able to do more colour-wise and I think this should be taken into consideration. I haven't decided on a mode yet, but I suspect there should be multiple versions for different modes. Do you have any preferences for the first attempt?
And thanks for the offers of help, I may take advantage of it in the coming week or two.
Now I wish this year was 1986 and not 2006. We could be rich right now 
allí es los insectos (insects? good grief.. bugs) fuera de los cuales espero llevaré un par de fines de semana la clase.
you write english ¡please!.
Great News!!! We can't wait, we want see it n-o-w ! 
