No - I've only managed to extract the first 8x8 set so far. TBH I've been struggling to figure out how to calculate the start addresses for the other sets from the gfx_range mapper_S9263B_table, or perhaps I am looking in the wrong place? Do all of the sets start at address zero, but only have a valid range in the address space?
I've tried to confirm that all the 8x8 tiles are duplicated twice with a quick search of gfx memory in a hex editor. I expected every 4-byte aligned 4-byte sequence from the region near address zero to be seen elsewhere. This seems true for most, but not all sequences.
I don't understand where the 32 bit offset comes from. From my understanding memory is built up by adding two bytes from ROM 1, then two from 2, then 3 then 4 then back to 1 and round again - each cycle will be 8 bytes. Each 8x8 element is 8x8x4 bits = 32 bytes and is contiguous in memory (albeit in short 1D bitplanes). I think this means that the data for each 8x8 element must be split between the 4 ROMs. This would mean that to draw 8x8 pixels data is required from all 4 roms. I must have misunderstood something.
EDIT: I think I've figured this out. In the 8x8 layouts the y spacing is 4*16 bits = 8 bytes, whereas each row is only 4 bytes. So the each pair of tiles in the pair of 8x8 sets are interleaved together row by row. Each row each tile from the first set uses 2 bytes from the ROM 1 and 2 bytes from ROM 2. Each row each tile from the second set uses 2 bytes from ROM 3 and 2 bytes from ROM4. This also explains why layout.charincrement is 2x the tile size in bytes.
Yep, you've got it. I think it works that way because the hardware fetches data from all four ROMs in parallel, over a 64-bit data bus (each ROM is 16 bits wide). The ROM chips available in 1988 weren't very fast, so rendering 3 scrolling layers plus sprites at an 8MHz dot clock required a fair bit of parallelism.
I might get this for backgrounds in which the tiles are drawn on a regular grid, but if an 8x8 sprite can be drawn at any pixel position then do you mean odd and even positions within a 2D array of tiles that make up an object?
There are no 8x8 sprites on CPS1. There are four layers: a tilemap (scrollable character grid) of 8x8 tiles, a tilemap of 16x16 tiles, a tilemap of 32x32 tiles, and sprites that are made out of 16x16 cels. It will help you understand the MAME source if you know that "scroll 1" is the 8x8 tilemap, "scroll 2" is the 16x16 one, and "scroll 3" is the 32x32.
Okay, if you look at the mapper table you'll see that there are three "banks", each corresponding to one set of four ROMs. Bank 0 is the ROMs numbered 1, 2, 3 and 4; bank 1 is the ROMs numbered 5, 6, 7 and 8, and bank 2 is the ROMs numbered 10, 11, 12 and 13. Banks 0 and 1 are entirely used by sprites, while bank 2 contains the last few thousand sprites, then the 32x32 tiles (SCROLL3), then the 8x8 tiles (SCROLL1), then the 16x16 tiles (SCROLL2).
You can see in gfxrom_bank_mapper() that if the requested code is a sprite or a SCROLL2 tile it gets multiplied by 2 (left shifted by 1, same thing), if it is a SCROLL3 tile it gets multiplied by 8, and if it is a SCROLL1 tile it is left alone. So the "unit" that the ranges in the mapper table are measured in is one duplicated 8x8 tile (which is half a 16x16 tile, or one eighth of a 32x32 tile). Meaning 16 bytes in one ROM, or 64 bytes in the whole interleaved set.
So, to answer your original question: the 32x32 tiles are at 0x20000-0x3FFFF in ROMs 10, 11, 12 and 13 (that's the address in each individual ROM--multiply by 4 if you're working with them interleaved). The 8x8 tiles are at 0x40000-0x4FFFF in those same ROMs, and the 16x16 tiles are at 0x50000-0x7FFFF. The first 0x20000 bytes of ROMs 10, 11, 12, 13, and the entirety of the other eight ROMs, contain sprites (which are in exactly the same format as 16x16 tiles).
If you press F4 and look at the graphics in MAME, you'll see the entire region (all 12 ROMs) decoded in all three formats, meaning you have to page through lots and lots of garbage before you get to valid 8x8 or 32x32 tiles. That's because MAME uses the same GFXDECODE info for all CPS1 games, regardless of which mapper they use. Most 1980s sprite-and-tile arcade systems weren't as flexible as CPS1 with its single ROM bus and per-game mappers; in most systems each layer had an entirely separate bus to its own dedicated ROMs, and the MAME F4 graphics viewer was designed with that as the assumption.
ETA: I think the "8x8" graphics you think you've extracted may actually be the quarters of the 16x16 sprites. The 8x8 and 16x16 formats have the same row stride, so if you decode one of them as the other you'll still get recognizable graphics (whereas the 32x32 will look like complete garbage)