What's new

sammargh

Professional
Joined
Jul 24, 2017
Messages
568
Reaction score
413
Location
South Dakota
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(95a3cef8) 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,8)
// 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?
 
Sorry it's not going to be a short and simple answer but at least it contains useful information.
I personally use WinCUPL to create my .jed files.

Outputs of the PAL are different from one B board type to an other but it can quickly be figured out by probing /CE lines of graphic chips.

Inputs however are always arranged the same (bits naming is just for the demonstration sake):
- pin 1 = object type bit 2 (ot2)
- pin 2 = object type bit 1 (ot1)
- pin 3 = object type bit 0 (ot0)
- pin 4 = clock
- pin 5 = tile code bit 5 (tc5)
- pin 6 = tile code bit 4 (tc4)
- pin 7 = tile code bit 3 (tc3)
- pin 8 = tile code bit 2 (tc2)
- pin 9 = tile code bit 1 (tc1)
- pin 11 = tile code bit 0 (tc0)

Object type is as follow (in binary):
000 = sprites
001 = scroll 1
010 = scroll 2
011 = scroll 3
100 = star field

Example for 1941 using mapper YI24B, according to MAME:

MAME said:
/* type start end bank */
{ GFXTYPE_SPRITES, 0x0000, 0x1fff, 0 },
{ GFXTYPE_SCROLL3, 0x2000, 0x3fff, 0 },
{ GFXTYPE_SCROLL1, 0x4000, 0x47ff, 0 },
{ GFXTYPE_SCROLL2, 0x4800, 0x7fff, 0 },
{ 0 }
For SCROLL3 we have 0x2000 which is 0010 0000 0000 0000 in binary.
You must drop first 11 bits (can be done by dividing by 0x800) so you obtain (0) 0010 0 which are tile bits:
- tile bit 5 = 0 (tc5)
- tile bit 4 = 0 (tc4)
- tile bit 3 = 0 (tc3)
- tile bit 2 = 1 (tc2)
- tile bit 1 = 0 (tc1)
- tile bit 0 = 0 (tc0)

As SCROLL 3 corresponds to object type 011 (ot2 = 0, ot1 = 1, ot0 = 1) you obtain:
SCROLL3 = (!ot2 & ot1 & ot0) & (!tc5 & !tc4 & !tc3 & tc2)
tc1 and tc0 must be dropped as the region covers 0x2000 bytes (0x2000 to 0x27ff and 0x2800 to 0x2fff and 0x3000 to 0x37ff and 0x3800 to 0x3fff).
 
Last edited by a moderator:
I understand most of what you have said but I'm having trouble wrapping my head around the last part with regards to the bank size and tc1/tc0. How do you represent a bank that were say 0x1000 or 0x5000 with regards to SCROLL3? Do you specify tc1 & tc0 as a method of the size in bank?
 
In fact you need both information: address start and length.
Let's do it from SCROLL1:
- address start 0x4000 => 00 1000 (tc5 to tc0)
- type 001 (ot2 to ot0)
- length 0x800 => 00 0001
Here tc1 and tc0 are significant (you want to affect only the first 0x800 bytes to the region so tc1 and tc0 must be 0).
To make it simpler, any bit BEFORE the 1 in the length must be dropped. Here we have 00 0001 so nothing before the 1 so all bits must be kept.
So you obtain:
SCROLL1 = (!ot2 & !ot1 & ot0) & (!tc5 & !tc4 & tc3 & !tc2 & !tc1 & !tc0)
 
I think I'm understanding now.. Taking a random example don't even know if it really exists but it'd be like this?

address start 0x0000 => 00 0000
length 0x5000 => 0101 0000 0000 0000 => 00 1010
type 001

EXAMPLE = (!ot2 & !ot1 & ot0) & ((!tc5 & !tc4 & !tc3) # (!tc5 & !tc4 & !tc2 & !tc1))

Correct? From what I'm understanding you convert the length and you have to do an or between where the significant bits lay within the length?
 
Back
Top