Changes
/* Hardware Sprites */
Sixteen hardware sprites are to be provided by the ASIC.
Each consists of an array of 16x16 pixels of four bits per pixel. A sprite pixel is "transparent" when it has a value of zero, thus allowing 15 sprite colours. The sprite pixel data exists in memory mapped registers with the ASIC, from address 4000h. The lower four bits of each byte contain the data for a single pixel. The first 16 bytes contain the data for the upper scan line, starting at the top left hand corner of the sprite. 15 more similar scan lines of 16 pixels each follow, thus each 256 (0100h) byte block of register space contains one sprite. When the pixel data for a sprite is read or written, that sprite is removed from the display for the duration of the access. Thus sprite pixel data should only be accessed during retraced time, or while the raster is scanning somewhere else, otherwise there is a risk of disruption of the displayto avoid this.
The position on screen of the upper left corner of each sprite, and the X and Y magnification, are defined by five registers for each sprite:
All sprite characteristics are independent of the main screen mode, the unmagnified pixel size being as for screen mode 2 (640x200). Sprite colours are defined by 15 entries in the colour palette (see section 2.2 below). Thus sprites can be in different colours and resolutions from the rest of the screen. Sprites may overlay with each other or the border, and are prioritized so that the border has the highest priority, followed by sprites 0 to 15 in sequence, then the main screen data. Thus sprites always appear "in front of" the main screen and behind "the border".
When writing offsets +3,+4,+5 and +7 you can set the sprite magnification. +4 to +7 are mirrors.When reading +3 and +4 show you will read X position, +5 and +7 show will read Y position. They are mirrors of X,Y values. When the sprite pixel data is read or written, only the sprite whose pixels are being accessed is disabled (e.g. reading or writing in the range &4000-&40ff will only cause sprite 0 to be affected.). The pixels are not disrupted, the sprite will continue to be displayed after the read/write is done with no corruption to the image of the sprite. At the point the read/write is done, the sprite is disabled and what you will see behind is the pixels from a lower priority sprite or the background depending on what is behind. The read/write interrupts the display of the sprite at that moment. A write of 1us seems to only affect a width of 1 byte (i.e. 4 mode 1 pixels) rather than the full 1us time. Writing to the sprite X,Y or magnification doesn't cause the sprite to be disabled, but note writing a different X or Y coordinate will cause the sprite to be cut and appear at the new location when it's reached. If you update a sprite which is covered by a lower priority sprite or the border then you will not see the effect.
===Colour palette===
