Casio PV-1000/Rendering: Difference between revisions

From Obscure Wiki
Jump to navigationJump to search
(Created page with "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 Bitpl...")
 
mNo edit summary
Line 10: Line 10:
# the ASIC continuously asserts /MREQ
# the ASIC continuously asserts /MREQ
# 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 26 and 27, and fetches the tile with coarse X of 00, such as B800, B820, &c
# if BUSACK, the first tilemap fetch happens during pixels 26 and 27, 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

Revision as of 02:41, 25 May 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

  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 26 and 27, 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 42-43: fetch B802, &c
    • pixels 44-45: fetch red (probably) bitplane
    • pixels 46-47: fetch green (probably) bitplane
    • pixels 48-49: fetch blue (probably) bitplane
    • pixels 50-51: fetch B803, &c
    • pixels 52-59: 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 270- release /BUSREQ, and continue drawing 6 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