Changes
/* Palette */
LD BC,&FF64
LD A,14
OUT (C),CA
LD BC,&FF63
LD A,0
LD BC,&FF64
LD A,14
OUT (C),CA
LD BC,&FF63
LD A,3
LD BC,&FF64
LD A,14
OUT (C),CA
LD BC,&FF63
LD A,3
LD BC,&FF64
LD A,14
OUT (C),CA
LD BC,&FF63
LD A,2
So you need to know when each mask register is used and you need to understand the logical->physical VRAM mapping.
===== Write Mask in P1 mode =====
* Document states "In P1 mode, writing is prohibited on the side not specified as the transfer destination. (Layer "A":R#46, Layer "B":R#47)". I haven't discovered what this actually means yet.
===== Write Mask in bitmap and standby modes =====
* Registers specific to each command can be initialized in any order. "op" register (R52) should be written last so that it uses the correct register settings.
* CE will be set to 1 in status when operation has started. CE will be set to 0 in status when operation has completed. CE will be set to 1 in interrupt when operation has completed.
==== Command Recommendations ====
==== CMMC ====
* Data written by CPU is byte by byte and it is 1 bit per pixel. Each byte therefore represents 8 pixels. If the value of a bit is 0 then background colour register is used for pixel, if bit is 1 then foreground colour register is used for pixel. Data is used bit 7 first, 6 is next, all the way down to bit 0.
* Font is defined left to right, top to bottom, line by line. It doesn't follow the same form as Kanji ROM.
* If NX is not a multiple of 8, then unused bits are used on the next line. i.e. the command uses all 8 bits until they are exhausted at which point another byte is fetched and so on.
* Pixels appear to be are written according to physical vram. e.g. in 8bpp mode, x=0, bit has value 1, then foreground Foreground low byte is written, x = 1 and bit has value for physical VRAM0. Background low bytes is for physical VRAM 1, then foreground . Foreground high byte is written for physical VRAM1, and so onbackground high byte is for physical VRAM 1. Therefore to fill * To draw a font in the same colour ensure the same colour is repeated through for all pixels in FCand BC (i.e. for 8 bit mode set FC upper and lower byte to the same, and set BC upper and lower byte to the same.)
* For LOP, SC comes from background colour or foreground colour depending on the value of the bit.
* This command will operate without Kanji ROM.
* It is not clear where the pixel data is coming from when no Kanji ROM is connected. It is not forced to ff or 0. It almost looks like it also doesn't come from vram. What is reading it often seen is that the first 2 bytes are different from VRAM using the Kanji ROM addressrest, then the remainder of the bytes are the same and look to be based on BC low byte bit value.
==== POINT ====
==== BMLL ====
* If source and destination ranges overlap then there can be some unexpected data written. You should avoid overlapped areas or keep them at least 2 bytes apart. Result of overlapping areas can differ between runs. Investigation is going on to determine how this data can be stablisedpredicted or forced.
* When DIX=0, then both source and destination vram addresses are incremented. When DIX=1, then both source and destination vram addresses are decremented.
* I can't currently see what DIY does in respect of BMLL. It seems it has no effect. This may be an error in the documentation.
==== SRCH ====
* To know if a match has been found always look at the status bit. BD will be 1 for a match and 0 for no match. The border x coordinate is always set to something even if there is no match.
* When searching sx and sy are masked before use. If the width is 256, then sx is masked with 255 before use.
==== LMMC ====
* A new byte is fetched only when the pixels for that byte have been usedexhausted. For an odd number Therefore for 2bpp is NX is not a multiple of pixels in 4 and for 2bpp NX is not a mode such as 2bpp or 4bpp, this means multiple of 2 then the remaining pixels from a the byte will be used on the end of the line and the remainder of the pixels are used for the next line.
==== LMMV ====
