Casio PV-1000/Rendering: Difference between revisions
From Obscure Wiki
Jump to navigationJump to search
(off-by-one errors) |
(add diagram) |
||
Line 6: | Line 6: | ||
BUSREQ is asserted from pixels 20 through 267; the other 40 pixels it's deasserted. The first two pixels are during hsync. | BUSREQ is asserted from pixels 20 through 267; the other 40 pixels it's deasserted. The first two pixels are during hsync. | ||
[[File:Casio PV-1000 Rendering Timing.png|right|frame|A visualization of the timing below]] | |||
While the Z80 asserts BUSACK | While the Z80 asserts BUSACK |
Revision as of 23:41, 2 June 2023
There are 288 pixels on each scanline.
Note that pixel 0 is defined as the start of hsync.
During each of the 192 active scanlines, if enabled in the configuration register, the ASIC does the following:
BUSREQ is asserted from pixels 20 through 267; the other 40 pixels it's deasserted. The first two pixels are during hsync.
While the Z80 asserts BUSACK
- the ASIC continuously asserts /MREQ
- the ASIC runs the same 8 pixel 4 fetch pattern: TilemapEntry Bitplane Bitplane Bitplane
- unfortunately the RGB order of bitplanes is not known
- if BUSACK, the first tilemap fetch happens during pixels 28 and 29, and fetches the tile with coarse X of 00, such as B800, B820, &c
- as a result, the first fetches that matter are
- pixels 44-45: fetch B802, &c
- pixels 46-47: fetch red (probably) bitplane
- pixels 48-49: fetch green (probably) bitplane
- pixels 50-51: fetch blue (probably) bitplane
- pixels 52-53: fetch B803, &c
- pixels 54-61: draw the above three bitplanes, most significant bit on left
- The last fetches are:
- pixels 260-261: fetch B81D, &c
- pixels 268-269: fetch B81E, &c
- pixels 268- release /BUSREQ, and continue drawing 8 pixels from final valid fetch
If rendering is enabled too late, the ASIC reliably draws garbage for one to two slivers, depending on whether the tilemap fetch is valid