sammargh
Professional
So boredom got the best of me tonight and I decided to try tackling converting a game from the older 90629B-3 to 91635B-2. I decided a good candidate would be King of Dragons because it already uses the same C board and was able to craft the program roms properly from what I understand:
ROM_REGION( CODE_SIZE, "maincpu", 0 ) /* 68000 code */
ROM_LOAD16_BYTE( "kdu_30b.11e", 0x00000, 0x20000, CRC(825817f9) SHA1(250f61effcbe59f8b70baaf26eb8aef419fed66b) ) - 23 even low
ROM_LOAD16_BYTE( "kdu_37b.11f", 0x00001, 0x20000, CRC(d2422dfb) SHA1(6e369a62012f3c480755b700d4d4f4c112c79483) ) - 23 odd low
ROM_LOAD16_BYTE( "kdu_31b.12e", 0x40000, 0x20000, CRC(9af36039) SHA1(f2645178a042689a387f916b4ecd7d1d859d758a) ) - 23 even high
ROM_LOAD16_BYTE( "kdu_38b.12f", 0x40001, 0x20000, CRC(be8405a1) SHA1(8d4f9a0489dc4b2971b20170713284151bc10eb7) ) - 23 odd high
ROM_LOAD16_BYTE( "kdu_28.9e", 0x80000, 0x20000, CRC(9367bcd9) SHA1(8243b4b9bb9756f3fa726717e19a166cb2f5b50a) ) - 22 even low
ROM_LOAD16_BYTE( "kdu_35.9f", 0x80001, 0x20000, CRC(4ca6a48a) SHA1(9d440ecd8d2d0e293fecf64ca3915252b94e7aef) ) - 22 odd low
ROM_LOAD16_BYTE( "kdu_29.10e", 0xc0000, 0x20000, CRC(0360fa72) SHA1(274769c8717a874397cf37369e3ef80a682d9ef2) ) - 22 even high
ROM_LOAD16_BYTE( "kdu_36a.10f", 0xc0001, 0x20000, CRC(95a3cef
SHA1(9b75c1ed0eafacc230197ffd9b81e0c8f4f2c464) ) - 22 odd high
Using a phoenixed set I combined them all and wrote all the chips and plugged everything in. It worked! Kinda. The game loads but because I'm using the PAL from Mame the graphics are a complete mess. I was curious how the PAL works in CPS-1. Looking at the source to Mame I see:
static const struct gfx_range mapper_KD29B_table[] =
{
// verified from PAL dump:
// bank 0 = pin 19 (ROMs 1,2,3,4)
// bank 1 = pin 14 (ROMs 10,11,12,13)
// pin 12 is never enabled
/* type start end bank */
{ GFXTYPE_SPRITES, 0x0000, 0x7fff, 0 },
{ GFXTYPE_SPRITES, 0x8000, 0x8fff, 1 },
{ GFXTYPE_SCROLL2, 0x9000, 0xbfff, 1 },
{ GFXTYPE_SCROLL1, 0xc000, 0xd7ff, 1 },
{ GFXTYPE_SCROLL3, 0xd800, 0xffff, 1 },
{ 0 }
};
and looking at SF2CE:
static const struct gfx_range mapper_S9263B_table[] =
{
// verified from PAL dump:
// FIXME there is some problem with this dump since pin 14 is never enabled
// instead of being the same as pin 15 as expected
// bank0 = pin 19 (ROMs 1,3) & pin 18 (ROMs 2,4)
// bank1 = pin 17 (ROMs 5,7) & pin 16 (ROMs 6,
// bank2 = pin 15 (ROMs 10,12) & pin 14 (ROMs 11,13)
// pins 12 and 13 are the same as 14 and 15
/* type start end bank */
{ GFXTYPE_SPRITES, 0x00000, 0x07fff, 0 },
{ GFXTYPE_SPRITES, 0x08000, 0x0ffff, 1 },
{ GFXTYPE_SPRITES, 0x10000, 0x11fff, 2 },
{ GFXTYPE_SCROLL3, 0x02000, 0x03fff, 2 },
{ GFXTYPE_SCROLL1, 0x04000, 0x04fff, 2 },
{ GFXTYPE_SCROLL2, 0x05000, 0x07fff, 2 },
{ 0 }
};
Which from what I understand I need to modify the PAL for King of Dragons to use bank0 = pin 19, pin 18 and bank1 = pin 17, pin 16 however the format for JED confuses me and the tool @neocps1 made to generate a PAL doesn't seem to exist anymore on the internet. Is there a document somewhere that explains the PAL format and how pins coincide to the logic for the GAL16V8?
ROM_REGION( CODE_SIZE, "maincpu", 0 ) /* 68000 code */
ROM_LOAD16_BYTE( "kdu_30b.11e", 0x00000, 0x20000, CRC(825817f9) SHA1(250f61effcbe59f8b70baaf26eb8aef419fed66b) ) - 23 even low
ROM_LOAD16_BYTE( "kdu_37b.11f", 0x00001, 0x20000, CRC(d2422dfb) SHA1(6e369a62012f3c480755b700d4d4f4c112c79483) ) - 23 odd low
ROM_LOAD16_BYTE( "kdu_31b.12e", 0x40000, 0x20000, CRC(9af36039) SHA1(f2645178a042689a387f916b4ecd7d1d859d758a) ) - 23 even high
ROM_LOAD16_BYTE( "kdu_38b.12f", 0x40001, 0x20000, CRC(be8405a1) SHA1(8d4f9a0489dc4b2971b20170713284151bc10eb7) ) - 23 odd high
ROM_LOAD16_BYTE( "kdu_28.9e", 0x80000, 0x20000, CRC(9367bcd9) SHA1(8243b4b9bb9756f3fa726717e19a166cb2f5b50a) ) - 22 even low
ROM_LOAD16_BYTE( "kdu_35.9f", 0x80001, 0x20000, CRC(4ca6a48a) SHA1(9d440ecd8d2d0e293fecf64ca3915252b94e7aef) ) - 22 odd low
ROM_LOAD16_BYTE( "kdu_29.10e", 0xc0000, 0x20000, CRC(0360fa72) SHA1(274769c8717a874397cf37369e3ef80a682d9ef2) ) - 22 even high
ROM_LOAD16_BYTE( "kdu_36a.10f", 0xc0001, 0x20000, CRC(95a3cef

Using a phoenixed set I combined them all and wrote all the chips and plugged everything in. It worked! Kinda. The game loads but because I'm using the PAL from Mame the graphics are a complete mess. I was curious how the PAL works in CPS-1. Looking at the source to Mame I see:
static const struct gfx_range mapper_KD29B_table[] =
{
// verified from PAL dump:
// bank 0 = pin 19 (ROMs 1,2,3,4)
// bank 1 = pin 14 (ROMs 10,11,12,13)
// pin 12 is never enabled
/* type start end bank */
{ GFXTYPE_SPRITES, 0x0000, 0x7fff, 0 },
{ GFXTYPE_SPRITES, 0x8000, 0x8fff, 1 },
{ GFXTYPE_SCROLL2, 0x9000, 0xbfff, 1 },
{ GFXTYPE_SCROLL1, 0xc000, 0xd7ff, 1 },
{ GFXTYPE_SCROLL3, 0xd800, 0xffff, 1 },
{ 0 }
};
and looking at SF2CE:
static const struct gfx_range mapper_S9263B_table[] =
{
// verified from PAL dump:
// FIXME there is some problem with this dump since pin 14 is never enabled
// instead of being the same as pin 15 as expected
// bank0 = pin 19 (ROMs 1,3) & pin 18 (ROMs 2,4)
// bank1 = pin 17 (ROMs 5,7) & pin 16 (ROMs 6,

// bank2 = pin 15 (ROMs 10,12) & pin 14 (ROMs 11,13)
// pins 12 and 13 are the same as 14 and 15
/* type start end bank */
{ GFXTYPE_SPRITES, 0x00000, 0x07fff, 0 },
{ GFXTYPE_SPRITES, 0x08000, 0x0ffff, 1 },
{ GFXTYPE_SPRITES, 0x10000, 0x11fff, 2 },
{ GFXTYPE_SCROLL3, 0x02000, 0x03fff, 2 },
{ GFXTYPE_SCROLL1, 0x04000, 0x04fff, 2 },
{ GFXTYPE_SCROLL2, 0x05000, 0x07fff, 2 },
{ 0 }
};
Which from what I understand I need to modify the PAL for King of Dragons to use bank0 = pin 19, pin 18 and bank1 = pin 17, pin 16 however the format for JED confuses me and the tool @neocps1 made to generate a PAL doesn't seem to exist anymore on the internet. Is there a document somewhere that explains the PAL format and how pins coincide to the logic for the GAL16V8?