Super Majik Spiral Crew's Guide to using their Code (0.00) ============================================================================== Character Loader - ------------------ The character loader routines written by the SMSC so far have a few features included with them to make handling the characters a bit easier. First there are two types of characters defined by the character loader, the first is the regular 16 color characters, but there is a special "mono" mode for characters the only need to use the first and last colors in the palette. This mono mode is intended for text characters as they will usually only need two colors, but I suppose it could be used for any two color characters provided that they can use the first and last color entries. Also provided as a feature of the character loader is the ability to easily load a series of characters by only calling the subroutine once. Also along with the series loading, is also the ability to specify right in the character data the video memory location the characters are to be loaded to. This allows the programmer to change only some characters between levels or locations and not have to worry about writing over character that are still needed. I'll first describe the format of the mono characters as they are the easiest to set up. As I hope you know, the SMS characters are 8x8 pixels. Because every row uses exactly the same format I'll only go through setting up one row. The format is much the same as most of the older computers from the late 70s and early 80s used for their 2 color characters, only because the SMS is actually 16 color you'll have to remember the "off" pixels are really palette entry 0 and the "on" pixels are palette entry F (15). Basicly each pixel in the row gets a different value ranging from 1 to 128, if you want to turn a pixel on you just add the value for that column to the total for that row. Here are two examples: 1| | | | | | | | Values 2|6|3|1| | | | | 8|4|2|6|8|4|2|1| -|-|-|-|-|-|-|-| Exam 1 1|0|1|0|1|0|1|0| = 128+32+8+2=170 | | | | | | | | Exam 2 0|1|0|1|0|1|0|1| = 64+16+4+1=85 0 = off, 1 = on If you will also notice that the binary value 10101010 does equal the decimal value 170, and 01010101 is 85, you will see how simple this method is. The color mode characters use the full 16 color palette entries. It is really unknown if this information that follows is correct, but it will be assumed to be accurate until proven otherwise. It is known that every row has to have 4 bytes so that the math will work out correctly, but how these bytes describe what color each pixel will be is unsure. Note: If this method is wrong, then the mono data is also incorrect, and the entire character loader routine has to be rewritten. This method is assumed because the document I received on the SMS said that the characters are made up of 4 bit planes. Assuming that the mono data is using 1 bit plane, the color characters will have 4 bytes to define each row, giving 4 bits to each pixel, allowing for 16 colors and fulfilling the math requirements also. The layout would look something like this: 1| | | | | | | | Values 2|6|3|1| | | | | 8|4|2|6|8|4|2|1| -|-|-|-|-|-|-|-| Plane 1 1|1|1|1|0|0|0|0| = 240 = F0 | | | | | | | | Plane 2 1|1|1|1|0|0|0|0| = 240 = F0 | | | | | | | | Plane 3 1|1|0|0|1|1|0|0| = 204 = CC | | | | | | | | Plane 4 1|0|1|0|1|0|1|0| = 170 = AA Color F E D C 3 2 1 0 So the 4 bytes you would use are F0, F0, CC, AA. That is assuming that the method is correct. If it doesn't work, I have one other simple guess as to how the character would be layed out, which would make the colors actually easier to use, but would totally iliminate the mono mode, in my other guess the bytes would be FE, DC, 32, 10. If you can see those numbers are taken dirrectly from the colors used. The reason I don't think that this is the method is while it may seem human logical, it isn't machine logical at all, as there is no most or least signaficant byte. If neither of these ideas work right away, it may also be do to the fact the the bytes are in the reverse order, or in the second case because of it being so unlogical the entire half byte order be need to be reversed. In the next few days after writing this, I will be attempting to display a mono character on the screen, if it works I know that the format is correct, but do to how the mono characters are loaded the byte order listed here may be backwards for the color characters, but this can be easily fixed. If I get total garbage, I'll know I have to start over from the begining. The actual layout of the character data should look like this: Byte 0 Number of characters to load in this series. (Number of characters-1) 1 character = 0, 256 characters = 255. Byte 1 Low byte of the video address where the characters should start. (See video RAM memory map for proper locations for characters). Byte 2 High byte of the video address. Byte 3 Color or Mono (00 = Color, FF = mono) Byte 4 First actual byte of the character data. ... The rest of the character data, 8 bytes per mono character, 32 bytes per color character. You can not mix mono and color characters in one series. Palette Loader - ---------------- Fortunatly I know my information about the palette is correct, so this won't need a total rewrite anytime soon. There is only one extra byte in the header of the palette data, it just allows you to easily keep track of character and sprite palettes. Or if you are doing something simple just use one set of palette colors to be loaded into both palettes with only 1 call to the subroutine. The SMS has a 16 color palette, where each of the 16 colors is picked from a system palette of 64 colors. There are two different palettes on the SMS, one for the characters printed on the screen, and one for the actually movable sprites. This allows for at max 32 different colors to be on screen at one time. Each palette entry takes 1 byte. The bit format of the byte is very simple: 7|6|5|4|3|2|1|0 -|-|-|-|-|-|-|- x|x|B|B|G|G|R|R x = Unused B = 2 bits for Blue G = 2 bits for Green R = 2 bits for Red The RGB values range from 0 to 3. Here is where I am unsure about the palette. A lot of settings on the SMS are active low logic, where 0 = On and 1 = Off. So did they do it again here? Well if the did, 0 is 100% of that color and 3 is none of that color in the mix. If they didn't, then is it just backward from that. When I get my character to display on screen I will also find out which way the colors are used. The palette data layout goes like this: Byte 0 Palette Type (00 = Character Palette, FF = Sprite Palette, Anything else = Both Palettes) ... The 16 bytes for the 16 colors to be loaded for the selected palette(s).