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.


A visualization of the timing below

While the Z80 asserts BUSACK

  1. the ASIC continuously asserts /MREQ
  2. the ASIC runs the same 8 pixel 4 fetch pattern: TilemapEntry Bitplane Bitplane Bitplane
    unfortunately the RGB order of bitplanes is not known
  3. 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
  4. 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
  5. 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