L0 ROM: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
m (Hashes) |
||
| Line 3: | Line 3: | ||
[[File:Ngscaling.png|right|thumb]] | [[File:Ngscaling.png|right|thumb]] | ||
The L0 ROM is a 64KiB (sometimes 128KiB with A16 tied to ground) ROM chip found in every NeoGeo systems, which contains byte values used by {{Chipname|LSPC}} to shrink [[sprites]] '''vertically'''. | |||
The dump is | The dump is called 000-lo.lo in [[system ROM]] sets. | ||
= | =Hash= | ||
The data | * CRC32: 5a86cff2 | ||
* SHA-1: 5992277debadeb64d1c1c64b0a92d9293eaf7e4a | |||
=Data format= | |||
The data is made of 256 tables of 256 bytes, each table corresponding to a vertical shrinking value for sprites. | |||
For the first 256 lines (first half of a full sprite), the index in the table is the horizontal line number of the sprite currently being drawn (scanline - Y position). | For the first 256 lines (first half of a full sprite), the index in the table is the horizontal line number of the sprite currently being drawn (scanline - Y position). | ||
Each byte is used as 2 nibbles: | Each byte is used as 2 nibbles: | ||
*The upper nibble is the tile number index to read in the tilemap | *The upper nibble is the tile number index to read in the tilemap in [[VRAM]] SCB1 (0 to 15). | ||
*The lower nibble is the line number of that tile to fetch in the [[C ROM]]s. | *The lower nibble is the line number of that tile to fetch in the [[C ROM]]s. | ||
| Line 20: | Line 25: | ||
Each byte is used as 2 nibbles: | Each byte is used as 2 nibbles: | ||
*The upper nibble is the tile number index XOR $1F to read in the tilemap | *The upper nibble is the tile number index XOR $1F to read in the tilemap in VRAM SCB1 (0 to 15). | ||
*The lower nibble is the line number XOR $F of that tile to fetch in the C ROMs. | *The lower nibble is the line number XOR $F of that tile to fetch in the C ROMs. | ||
Revision as of 09:36, 3 October 2016
The L0 ROM is a 64KiB (sometimes 128KiB with A16 tied to ground) ROM chip found in every NeoGeo systems, which contains byte values used by LSPC to shrink sprites vertically.
The dump is called 000-lo.lo in system ROM sets.
Hash
- CRC32: 5a86cff2
- SHA-1: 5992277debadeb64d1c1c64b0a92d9293eaf7e4a
Data format
The data is made of 256 tables of 256 bytes, each table corresponding to a vertical shrinking value for sprites.
For the first 256 lines (first half of a full sprite), the index in the table is the horizontal line number of the sprite currently being drawn (scanline - Y position).
Each byte is used as 2 nibbles:
- The upper nibble is the tile number index to read in the tilemap in VRAM SCB1 (0 to 15).
- The lower nibble is the line number of that tile to fetch in the C ROMs.
For the last 256 lines (second half of a full sprite), the index in the table is 255-((scanline - Y position) & 255). The table is read backwards.
Each byte is used as 2 nibbles:
- The upper nibble is the tile number index XOR $1F to read in the tilemap in VRAM SCB1 (0 to 15).
- The lower nibble is the line number XOR $F of that tile to fetch in the C ROMs.
Example of GPU processing
(Maybe place this part in the GPU page ?)
Sprite with Y zoom value = $1B and tile height = 2 (32 pixels).
- Line 0 of sprite. GPU asks LO data at address $1B00. Data is $00: Tilemap index 0, line 0 of tile.
- Line 1 of sprite. GPU asks LO data at address $1B01. Data is $08: Tilemap index 0, line 8 of tile.
- Line 2 of sprite. GPU asks LO data at address $1B02. Data is $10: Tilemap index 1, line 0 of tile.
...
- Line 26 of sprite. GPU asks LO data at address $1B1A. Data is $E8: Tilemap index is $E, line 8 of tile.
- Line 27 of sprite. GPU asks LO data at address $1B1B. Data is $F8: Tilemap index is $F, line 8 of tile.
- Line 28 of sprite. GPU asks LO data at address $1B1C. Data is $FF: Tilemap index is $F, line $F of tile.
- Line 29 of sprite. GPU asks LO data at address $1B1D. Data is $FF: Tilemap index is $F, line $F of tile.
...
Datasheet
Official TC531001 datasheet: [[1]]