What's new
By:
Filters

ViewPoint graphics error (solved)

P

pierpa86

Student
Joined
May 5, 2022
Messages
43
Reaction score
34
Location
Italia
Hello to all guys ^^

I'm trying to do a conversion of ViewPoint from a copy of Super Side Kik 2 (poor soccer game, no one love it)
All working fine, program will start so i can see P1 is good, sound also is good but someting wrong here with C roms.

View: https://youtu.be/TvlqWHcUW7M


I know the original game is on CHA42G and this roms is arranged in this way i think.
  • C1 = First 1MiB of C1 + First 1MiB of C3
  • C2 = First 1MiB of C2 + First 1MiB of C4
  • C3 = Second 1MiB of C1 + Second 1MiB of C3
  • C4 = Second 1MiB of C2 + Second 1MiB of C4
So if this is the logic i dont have to re-arrange data, but what i wrong ?
This is my last jumper configuration but i already try with J7 - J8, and CRC is correct.

IMG-1048.jpg
 
This is a weird one. if you look at the MAME driver for viewpoint the first half of the C-ROMs is located at 0x000000 and the second half is located at 0x400000 So there's a big gap in there.

you'll want to use 27c322s and set the jumpers accordingly
you'll need to split the C-ROMs
C1_322 = C1_first half + 800mbit empty + C1_second half + 800mbit empty
C2_322 = C2_first half + 800mbit empty + C2_second half + 800mbit empty

or just to fill space:
C1_322 = C1_first half + C1_first half + C1_second half + C1_second half
C2_322 = C2_first half + C2_first half + C2_second half + C2_second half
 
twistedsymphony said:
This is a weird one. if you look at the MAME driver for viewpoint the first half of the C-ROMs is located at 0x000000 and the second half is located at 0x400000 So there's a big gap in there.

you'll want to use 27c322s and set the jumpers accordingly
you'll need to split the C-ROMs
C1_322 = C1_first half + 800mbit empty + C1_second half + 800mbit empty
C2_322 = C2_first half + 800mbit empty + C2_second half + 800mbit empty

or just to fill space:
C1_322 = C1_first half + C1_first half + C1_second half + C1_second half
C2_322 = C2_first half + C2_first half + C2_second half + C2_second half
Click to expand...
As always you are a super user :D yes this trick is working i made the first rom settings.
Thanks.
 
twistedsymphony said:
This is a weird one. if you look at the MAME driver for viewpoint the first half of the C-ROMs is located at 0x000000 and the second half is located at 0x400000 So there's a big gap in there.

you'll want to use 27c322s and set the jumpers accordingly
you'll need to split the C-ROMs
C1_322 = C1_first half + 800mbit empty + C1_second half + 800mbit empty
C2_322 = C2_first half + 800mbit empty + C2_second half + 800mbit empty

or just to fill space:
C1_322 = C1_first half + C1_first half + C1_second half + C1_second half
C2_322 = C2_first half + C2_first half + C2_second half + C2_second half
Click to expand...
Hello guys, im trying to understand better this number.
This is the xml from mame driver

<rom loadflag="load16_byte" name="051-c1.c1" offset="0x000000" size="0x100000" crc="d624c132" sha1="49c7e9f020cba45d7083b45252bcc03397f8c286" /> <!-- CXK381600 -->
<rom size="0x100000" offset="0x400000" loadflag="continue" />

What i understand:
051-c1.c1 = 0x100000 = 1048576 Bytes (1MB) -> continue flag with second half 0x100000 that have 4194304 Bytes (4MB) offset.
why c1 second half start at 2097152 byte (0x200000 ?) ?

i miss something please help to underastand 8|
 
pierpa86 said:
why c1 second half start at 2097152 byte (0x200000 ?) ?
Click to expand...
because that's where the developer decided to put it.

there's a good chance they were targeting a different CHA board where this arrangement made more sense
 
sorry for my english i mean, from mame db we have offset="0x400000" but reading this:
C1_322 = C1_first half + 800mbit empty + C1_second half + 800mbit empty
i undeastand that c1 second half start from 0x200000 what i wrong ?
 
it's 32bits spread across two ROMs so half of the size is on the other ROM.
 
Maybe i need a long explanation because i still not understand how to interpret this value on eeprom.
Check here, we have more wird allocation;

Code: 
<dataarea name="sprites" size="0x1c00000">
                <rom loadflag="load16_byte" name="059-c1.c1" offset="0x000000" size="0x200000" crc="763ba611" sha1="d3262e0332c894ee149c5963f882cc5e5562ee57" />    <!-- TC5316200 -->
                <rom loadflag="load16_byte" name="059-c2.c2" offset="0x000001" size="0x200000" crc="e05e8ca6" sha1="986a9b16ff92bc101ab567d2d01348e093abea9a" />    <!-- TC5316200 -->
                <!-- 400000-7fffff empty -->
                <rom loadflag="load16_byte" name="216-c3.c3" offset="0x800000" size="0x400000" crc="665c9f16" sha1="7ec781a49a462f395b450460b29493f55134eac2" />    <!-- mask rom TC5332205 -->
                <rom loadflag="load16_byte" name="216-c4.c4" offset="0x800001" size="0x400000" crc="7f5d03db" sha1="365ed266c121f4df0bb76898955a8ae0e668a216" />    <!-- mask rom TC5332205 -->
                <rom loadflag="load16_byte" name="059-c5.c5" offset="0x1000000" size="0x200000" crc="59013f9e" sha1="5bf48fcc450da72a8c4685f6e3887e67eae49988" />   <!-- TC5316200 -->
                <rom loadflag="load16_byte" name="059-c6.c6" offset="0x1000001" size="0x200000" crc="1c8d5def" sha1="475d89a5c4922a9f6bd756d23c2624d57b6e9d62" />   <!-- TC5316200 -->
                <!-- 1400000-17fffff empty -->
                <rom loadflag="load16_byte" name="059-c7.c7" offset="0x1800000" size="0x200000" crc="c88f7035" sha1="c29a428b741f4fe7b71a3bc23c87925b6bc1ca8f" />   <!-- TC538200 -->
                <rom loadflag="load16_byte" name="059-c8.c8" offset="0x1800001" size="0x200000" crc="484ce3ba" sha1="4f21ed20ce6e2b67e2b079404599310c94f591ff" />   <!-- TC538200 -->
            </dataarea>
 
pierpa86 said:
<rom loadflag="load16_byte" name="059-c1.c1" offset="0x000000" size="0x200000" crc="763ba611" sha1="d3262e0332c894ee149c5963f882cc5e5562ee57" /> <!-- TC5316200 --> <rom loadflag="load16_byte" name="059-c2.c2" offset="0x000001" size="0x200000" crc="e05e8ca6" sha1="986a9b16ff92bc101ab567d2d01348e093abea9a" /> <!-- TC5316200 -->
Click to expand...
the data for graphics is 32 bit, but the ROMs are only 16 bit, this means that each odd numbered C-ROM (like C1) is always paired with an even numbered C-ROM (like C2) to make the complete 32-bit data record. Even if you had only 1 very small sprite stored here you would always need 2 ROMs to make 32-bits

you can tell this from the data by the "offset". the offset defines the starting position within the memory region for the ROM. if you see xxxxxx1 instead of xxxxxx0 it means that the xxxxxx1 data is interleaved with the xxxxxx0 data to. if you had 8-bit ROMs instead they would end in 0, 1, 2, and 3 because it would take 4 separate 8-bit ROMs to make 32-bits (you see this on some old 32-bit Sega boards).

While the "offset" tells you the start point, the "size" can't be used to determine the end point without accounting for the other ROMs. so C1 might have a size of 0x200000 but C1+C2 together make a size of 0x400000.
So C1 in your example spans from 0x000000 through 0x400000 but only has data for every other byte hence why it's "size" is only 0x200000

Different CHA boards can map ROMs into the space differently. C1 doesn't necessarily start at 0x0000000, only if the CHA board is designed that way.

again in your example it seems as though the CHA board was designed expecting every ROM to be 0x400000 in size, and the developer decided to spread the data around multiple ROMs that allowed some of the ROMs to be smaller, but this also causes gaps in the ROM mapping of areas where no data is placed.
 
Last edited:
You must log in or register to reply here.
Back
Top