Casio PV-1000/Rendering: Difference between revisions
From Obscure Wiki
Jump to navigationJump to search
mNo edit summary |
(another braino) |
||
(2 intermediate revisions by the same user not shown) | |||
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 | ||
Line 11: | Line 14: | ||
# the ASIC runs the same 8 pixel 4 fetch pattern: TilemapEntry Bitplane Bitplane Bitplane | # the ASIC runs the same 8 pixel 4 fetch pattern: TilemapEntry Bitplane Bitplane Bitplane | ||
#: unfortunately the RGB order of bitplanes is not known | #: unfortunately the RGB order of bitplanes is not known | ||
# if BUSACK, the first tilemap fetch happens during pixels | # 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 | # as a result, the first fetches that matter are | ||
#* pixels | #* pixels 44-45: fetch B802, &c | ||
#* pixels | #* pixels 46-47: fetch red (probably) bitplane | ||
#* pixels | #* pixels 48-49: fetch green (probably) bitplane | ||
#* pixels | #* pixels 50-51: fetch blue (probably) bitplane | ||
#* pixels | #* pixels 52-53: fetch B803, &c | ||
#* pixels 52-59: draw the above three bitplanes, most significant bit on left | #* pixels 52-59: draw the above three bitplanes, most significant bit on left | ||
# The last fetches are: | # The last fetches are: | ||
#* pixels 260-261: fetch B81D, &c | #* pixels 260-261: fetch B81D, &c | ||
#* pixels 268-269: fetch B81E, &c | #* pixels 268-269: fetch B81E, &c | ||
#* pixels | #* 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 | If rendering is enabled too late, the ASIC reliably draws garbage for one to two slivers, depending on whether the tilemap fetch is valid |
Latest revision as of 19:34, 3 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 52-59: 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