Sega ST-V Cart Conversion

[jcmorrisii]

Greetings everyone! Many years ago I had some Sega ST-V conversion carts (that I have long since sold off), and it got me thinking about how this could be done. I documented them with high res photos back in 2015, but like a dumbass, I had them hosted on photobucket and now they are gone. You can see the thread --> HERE and the thumbnails are still present. Other than that thread and a few "how to spot a boot" type of posts, I haven't been able to find any information on the subject. I noticed there is quite an extensive thread on PGM conversions outlining the known processes and was hoping to do the same for STV carts.

This is pretty straight forward, but NOT a quick easy conversion, some carts have 8 chips to flash and solder in place, each with 44 pins. This involves using a donor cart that matches the desired games PCB (SEGA 837-11124 is a common one that I'm using in this example). Removal of the factory Mask ROMS (located IC1-12), then replacing with a series of Macronix MX29L3211MC-10G chips flashed with the bins from the desired title. These can be programmed on the common GQ4x with the help of the ADP-019 Adapter for PSOP44. These chips are very finicky to write with the GQ4x, and very rarely verify 100%. I do not recommend programming these on the GQ4x!!!!!!

-MX29L3211MC-10G Datasheet is ---> HERE

These chips are 3.3V, unlike the 5v that the STV supplies. It looks like most conversions use a series of diodes and a resistor to bring the 5v down to 3.3v. While this may work, I prefer to use a dedicated regulator circuit. Pin 1 (WE) and pin 23 (VCC) are lifted, and the new 3.3v line tied to those pins.

I have also noticed differences in a bank of 0R resistors (located R1-R10) on different carts. Specifically, the 0R resistor at R5 is sometimes located on R6. These are used in conjunction with the EEPROM to the left of them, but is not necessary to change if no EEPROM is used on the game you are converting to.

Here is a test cart I wired up based on my findings;


-------Steps-------

-Remove Securty Screws using custom Gamebit head
-Resistor( jumper) at location R5 moved to R6
-Install voltage regulator on PC1 (5v left pad, Ground right pad)
-Original mask roms removed
-New game Flash chips soldered into their respective slot
-Pin 1 and 23 lifted and tied to 3.3V supplied with a regulator
-Clean up flux and place PCB back into case.

 

[twistedsymphony]

I have a handful of STV Games and I recently cracked them open just to see what these looked like. I have 4 carts and to my surprise all 4 had unique PCBs. two of them used a flash ROM in addition to the Mask ROMs and one of them had a Protection chip. some carts I've seen have a socketed ROM in lieu of a flash chip. So there's a lot of variation here.

I think for starters you'll probably want to use an unprotected cart as your donor (maybe the protected carts can have their protection disabled?) and any protected game you'll probably want to use a cracked copy (such as those used in the multi kits).

In general though your first stop should be the MAME driver: https://github.com/mamedev/mame/blob/master/src/mame/sega/stv.cpp

at first glance it seems all games use the same basic memory map which is good it means there's no logic to contend with.

looking at some ROM definitions

ROM_START( colmns97 )
	STV_BIOS

	ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
	ROM_LOAD16_BYTE( "fpr19553.13",    0x000001, 0x100000, CRC(d4fb6a5e) SHA1(bd3cfb4f451b6c9612e42af5ddcbffa14f057329) )
	ROM_RELOAD_PLAIN ( 0x0200000, 0x0100000 )
	ROM_RELOAD_PLAIN ( 0x0300000, 0x0100000 )
	ROM_LOAD16_WORD_SWAP( "mpr19554.2",     0x400000, 0x400000, CRC(5a3ebcac) SHA1(46e3d1cf515a7ff8a8f97e5050b29dbbeb5060c0) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr19555.3",     0x800000, 0x400000, CRC(74f6e6b8) SHA1(8080860550eb770e04447e344fb337748a249761) ) // good
ROM_END

ROM_START( cotton2 )
	STV_BIOS

	ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
	ROM_LOAD16_WORD_SWAP( "mpr20122.7",    0x0200000, 0x0200000, CRC(d616f78a) SHA1(8039dcdfdafb8327a19a1da46a67c0b3f7eee53a) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20117.2",    0x0400000, 0x0400000, CRC(893656ea) SHA1(11e3160083ba018fbd588f07061a4e55c1efbebb) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20118.3",    0x0800000, 0x0400000, CRC(1b6a1d4c) SHA1(6b234d6b2d24df7f6d400a56698c0af2f78ce0e7) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20119.4",    0x0c00000, 0x0400000, CRC(5a76e72b) SHA1(0a058627ddf78a0bcdaba328a58712419f24e33b) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20120.5",    0x1000000, 0x0400000, CRC(7113dd7b) SHA1(f86add67c4e1349a9b9ebcd0145a30b1667df811) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20121.6",    0x1400000, 0x0400000, CRC(8c8fd521) SHA1(c715681330b5ed37a8506ac58ee2143baa721206) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20116.1",    0x1800000, 0x0400000, CRC(d30b0175) SHA1(2da5c3c02d68b8324948a8cdc93946d97fccdd8f) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20123.8",    0x1c00000, 0x0400000, CRC(35f1b89f) SHA1(1d6007c380f817def734fc3030d4fe56df4a15be) ) // good
ROM_END

ROM_START( astrass )
	STV_BIOS

	ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
	ROM_LOAD16_BYTE( "epr20825.13",                0x0000001, 0x0100000, CRC(94a9ad8f) SHA1(861311c14cfa9f560752aa5b023c147a539cf135) )
	ROM_RELOAD_PLAIN ( 0x0200000, 0x0100000 )
	ROM_RELOAD_PLAIN ( 0x0300000, 0x0100000 )
	ROM_LOAD16_WORD_SWAP( "mpr20827.2",     0x0400000, 0x0400000, CRC(65cabbb3) SHA1(5e7cb090101dc42207a4084465e419f4311b6baf) ) // good (was .12)
	ROM_LOAD16_WORD_SWAP( "mpr20828.3",     0x0800000, 0x0400000, CRC(3934d44a) SHA1(969406b8bfac43b30f4d732702ca8cffeeefffb9) ) // good (was .13)
	ROM_LOAD16_WORD_SWAP( "mpr20829.4",     0x0c00000, 0x0400000, CRC(814308c3) SHA1(45c3f551690224c95acd156ae8f8397667927a04) ) // good (was .14)
	ROM_LOAD16_WORD_SWAP( "mpr20830.5",     0x1000000, 0x0400000, CRC(ff97fd19) SHA1(f37bcdce5f3f522527a44d59f1b8184ef290f829) ) // good (was .15)
	ROM_LOAD16_WORD_SWAP( "mpr20831.6",     0x1400000, 0x0400000, CRC(4408e6fb) SHA1(d4228cad8a1128e9426dac9ac62e9513a7a0117b) ) // good (was .16)
	ROM_LOAD16_WORD_SWAP( "mpr20826.1",     0x1800000, 0x0400000, CRC(bdc4b941) SHA1(c5e8b1b186324c2ccab617915f7bdbfe6897ca9f) ) // good (was .17)
	ROM_LOAD16_WORD_SWAP( "mpr20832.8",     0x1c00000, 0x0400000, CRC(af1b0985) SHA1(d7a0e4e0a8b0556915f924bdde8c3d14e5b3423e) ) // good (was .18s)
	ROM_LOAD16_WORD_SWAP( "mpr20833.9",     0x2000000, 0x0400000, CRC(cb6af231) SHA1(4a2e5d7c2fd6179c19cdefa84a03f9a34fbb9e70) ) // good (was .19s)

	// 610-0374-90   1998     317-5040-COM   ST-V      (yes, the 317-5040-COM chip was reused for 3 different games and on both Naomi and ST-V!)
	ROM_PARAMETER( ":315_5881:key", "052e2901" )
ROM_END

So I don't know what any of these carts look like but if we look at Columns 97 we see fpr19553.13 is the first thing loaded, this is 800Mbit so it's either a 27c080 or a flash ROM. then we have some gap space followed by a series of 32Mbit ROMs which would be your Mask ROMs.

If we look at cotton2 we'll see that there is no leading flash or socketed ROM it just the MASK ROMs. Then we can look at astrass and see that in addition to the leading ROM and the Mask ROMs there's also security key indicating that it's a protected game. There's also a note here that the same chip is used on multiple games, so maybe a conversion is possible with protection in place among those games?

--------------
Next thing to do would be to test a conversion virtually in MAME by simply renaming all of the ROM files for a target game, to that of your donor cart's game and then see if MAME will run it. If so then there's a good chance that the conversion will work in the real world.

We'll also probably want to document which games use which carts so we know what are suitable donors and what are not.

 

[nem]

There's a MVS Scans like repository for STV here:

http://titan.clubsega.se/Games

 

[twistedsymphony]

Looking more closely at this these carts really do seem like the predecessor to the NAOMI carts. very similar architecture.
I've started a spreadsheet here: https://docs.google.com/spreadsheets/d/1TB64uQakJYcTlsaRF19Pvo1RpEQ_7qLCrutkF4us0-Q/edit?usp=sharing

resistors can likely be worked out with a multimeter, I'd suspect they determine ROM size as I'm seeing differences in size of the leading byte ROM and some games seems to use 16M Mask ROMs instead of 32M Mask ROMs. Looking at the pictures in nem's link against the ROM configuration can lend clues here too.

the good news is it seems that most of the SHMUP titles are quite small and have no protection and no leading byte ROM. shenryu for instance is just 3 Mask ROMs... that's it!
Assuming there's enough clearance for a 27c322 it's entirely possible that a conversion cart like what fluffy did for PGM is possible for use with smaller games. Also possible to simply make one made for 3.3V SOP44 chips with an integrated voltage converter.

 

[twistedsymphony]

For reference, Im using a Shanghai Triple Threat cart, and trying to convert to Cotton 2.

I tried what you suggested with renaming the files and trying to get it to run in MAME but it will not load. Ill be honest Im not terribly familiar with MAME its been over a decade since I used it much. Are you using a terminal command or something to see the information bout romsize etc that you posted in the thread?

ok a few tips for this in MAME,
first you must specify the ROM to be loaded from the command line, selecting from the menu will fail because the CRCs don't match (they're all going to be completely wrong because it's a completely different game)

second you don't have to zip the files, you can simply place them in a folder with the folder named the same as you would the zip file, AND this can reside in the original ROMs folder along side the original zip, MAME will search the folder first.
so in your rom folder you likely have shanhigw.zip, you can leave that as is and then create a folder called shanhigw inside the rom folder. Then you can take your cotton roms renamed to match shangigw and place them inside the shanhigw folder. Then run "mame.exe -window shanhigw" from the command line. I like to also include the -debug flag but it's not necessary

So based on what I had done so far, what do you think may be the problem? Tried to mimic a genuine cotton 2 cart but obviously something is off. Maybe some offset when flashing the bins or something else?

any offset necessary would be visible in the MAME driver, lets look

ROM_START( shanhigw )
	STV_BIOS

	ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
	ROM_LOAD16_WORD_SWAP( "mpr18341.7",    0x0200000, 0x0200000, CRC(cc5e8646) SHA1(a733616c118140ff3887d30d595533f9a1beae06) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr18340.2",    0x0400000, 0x0200000, CRC(8db23212) SHA1(85d604a5c6ab97188716dbcd77d365af12a238fe) ) // good
ROM_END

ROM_START( cotton2 )
	STV_BIOS

	ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
	ROM_LOAD16_WORD_SWAP( "mpr20122.7",    0x0200000, 0x0200000, CRC(d616f78a) SHA1(8039dcdfdafb8327a19a1da46a67c0b3f7eee53a) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20117.2",    0x0400000, 0x0400000, CRC(893656ea) SHA1(11e3160083ba018fbd588f07061a4e55c1efbebb) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20118.3",    0x0800000, 0x0400000, CRC(1b6a1d4c) SHA1(6b234d6b2d24df7f6d400a56698c0af2f78ce0e7) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20119.4",    0x0c00000, 0x0400000, CRC(5a76e72b) SHA1(0a058627ddf78a0bcdaba328a58712419f24e33b) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20120.5",    0x1000000, 0x0400000, CRC(7113dd7b) SHA1(f86add67c4e1349a9b9ebcd0145a30b1667df811) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20121.6",    0x1400000, 0x0400000, CRC(8c8fd521) SHA1(c715681330b5ed37a8506ac58ee2143baa721206) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20116.1",    0x1800000, 0x0400000, CRC(d30b0175) SHA1(2da5c3c02d68b8324948a8cdc93946d97fccdd8f) ) // good
	ROM_LOAD16_WORD_SWAP( "mpr20123.8",    0x1c00000, 0x0400000, CRC(35f1b89f) SHA1(1d6007c380f817def734fc3030d4fe56df4a15be) ) // good
ROM_END

Ok first and foremost shanhigw uses was less ROM space than cotton 2, I don't know how you manage to rename the cotton2 ROM file to match shanghigw when you're trying to rename 8 file to match 2. If you want to perform a virtual conversion you must select a donor with the same or MORE rom space available, otherwise you would have to modify the mame source code and recompile. this is discussed in other threads and I wont get into it here, I'd simply recommend finding a better virtual donor. Also Notice that both of the shanhigw roms are 0x200000 in size which is 16Mbit, on cotton2 rom mpr20122.7 is 16Mbit in size but all of the rest are 0x400000 which is 32Mbit in size. again for a virtual donor you'll want to find something mapped similarly. we can also see that both games START with ROM 7 which is an offset of 0x200000, so there is no difference in offset between those two games.

a better virtual donor would might hanagumi as it has 12 ROMs, though it's ROM 7 is smaller than cotton2's so that might not work well. a good first test to understand the process I'd recommend trying a different virtual conversion altogether. EDIT: myfairld looks like a great virtual donor for cotton2, rsgun, and a number of other shmups

Maybe legs need to be tied to one of the pads? not sure.

given that the MX29L3211 is not a direct replacement for the Mask ROMs that sega used you'll need to determine how the pinout matches and how it differs and then appropriately tie the pins that differ. this generally means lifting the 3.3V pins for you power source but you'll want to pay attention to the write pins, enable pins, and byte mode pin to make sure that the cart PCB is treating it appropriately or if not lift it and tie it appropriately.

All the "resistors" that I have metered all appear to be 0Ohm or just a simple jumper. I moved r5 to r6 (donor cart Shanghai had it on R5).

yes 0hom resistors are often used for jumpers, MVS carts do this also. I wouldn't recommend moving any of them until you understand what they do, you'll need to take a multimeter and trace each side of each jumper and document where it goes, once you do that we can work out what it's for and the appropriate position for it to be in.
My guess is that these are used to determine whether 16M or 32M ROMs are used on the cart... but again this is just a guess and we wont know until you dive deeper

 

[jcmorrisii]

given that the MX29L3211 is not a direct replacement for the Mask ROMs that sega used you'll need to determine how the pinout matches and how it differs and then appropriately tie the pins that differ. this generally means lifting the 3.3V pins for you power source but you'll want to pay attention to the write pins, enable pins, and byte mode pin to make sure that the cart PCB is treating it appropriately or if not lift it and tie it appropriately.

I haven't been able to find a datasheet for the flash roms that SEGA used, but did link the datasheet for the MX29L3211 in the OP.

Ok first and foremost shanhigw uses was less ROM space than cotton 2, I don't know how you manage to rename the cotton2 ROM file to match shanghigw when you're trying to rename 8 file to match 2.

I was just renaming the individual files and rezipping. I was renaming the C2 files in the same way: mpr18340.2, mpr18341.3, mpr18342.4 etc. Like I said, havent touched MAME in many years so I thought it was something I was doing wrong.

ok a few tips for this in MAME,
first you must specify the ROM to be loaded from the command line, selecting from the menu will fail because the CRCs don't match (they're all going to be completely wrong because it's a completely different game)

second you don't have to zip the files, you can simply place them in a folder with the folder named the same as you would the zip file, AND this can reside in the original ROMs folder along side the original zip, MAME will search the folder first.
so in your rom folder you likely have shanhigw.zip, you can leave that as is and then create a folder called shanhigw inside the rom folder. Then you can take your cotton roms renamed to match shangigw and place them inside the shanhigw folder. Then run "mame.exe -window shanhigw" from the command line. I like to also include the -debug flag but it's not necessary


any offset necessary would be visible in the MAME driver, lets look

ROM_START( shanhigw )
    STV_BIOS

    ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
    ROM_LOAD16_WORD_SWAP( "mpr18341.7",    0x0200000, 0x0200000, CRC(cc5e8646) SHA1(a733616c118140ff3887d30d595533f9a1beae06) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr18340.2",    0x0400000, 0x0200000, CRC(8db23212) SHA1(85d604a5c6ab97188716dbcd77d365af12a238fe) ) // good
ROM_END

ROM_START( cotton2 )
    STV_BIOS

    ROM_REGION32_BE( 0x3000000, "cart", ROMREGION_ERASE00 ) /* SH2 code */
    ROM_LOAD16_WORD_SWAP( "mpr20122.7",    0x0200000, 0x0200000, CRC(d616f78a) SHA1(8039dcdfdafb8327a19a1da46a67c0b3f7eee53a) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20117.2",    0x0400000, 0x0400000, CRC(893656ea) SHA1(11e3160083ba018fbd588f07061a4e55c1efbebb) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20118.3",    0x0800000, 0x0400000, CRC(1b6a1d4c) SHA1(6b234d6b2d24df7f6d400a56698c0af2f78ce0e7) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20119.4",    0x0c00000, 0x0400000, CRC(5a76e72b) SHA1(0a058627ddf78a0bcdaba328a58712419f24e33b) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20120.5",    0x1000000, 0x0400000, CRC(7113dd7b) SHA1(f86add67c4e1349a9b9ebcd0145a30b1667df811) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20121.6",    0x1400000, 0x0400000, CRC(8c8fd521) SHA1(c715681330b5ed37a8506ac58ee2143baa721206) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20116.1",    0x1800000, 0x0400000, CRC(d30b0175) SHA1(2da5c3c02d68b8324948a8cdc93946d97fccdd8f) ) // good
    ROM_LOAD16_WORD_SWAP( "mpr20123.8",    0x1c00000, 0x0400000, CRC(35f1b89f) SHA1(1d6007c380f817def734fc3030d4fe56df4a15be) ) // good
ROM_END

If you want to perform a virtual conversion you must select a donor with the same or MORE rom space available, otherwise you would have to modify the mame source code and recompile.....Also Notice that both of the shanhigw roms are 0x200000 in size which is 16Mbit, on cotton2 rom mpr20122.7 is 16Mbit in size but all of the rest are 0x400000 which is 32Mbit in size. again for a virtual donor you'll want to find something mapped similarly. we can also see that both games START with ROM 7 which is an offset of 0x200000, so there is no difference in offset between those two games.

a better virtual donor would might hanagumi as it has 12 ROMs, though it's ROM 7 is smaller than cotton2's so that might not work well. a good first test to understand the process I'd recommend trying a different virtual conversion altogether. EDIT: myfairld looks like a great virtual donor for cotton2, rsgun, and a number of other shmups

Thank you, this helps and explains a lot. Ill try this out this afternoon when I have more time after work and report back here.

 

[twistedsymphony]

I haven't been able to find a datasheet for the flash roms that SEGA used

you probably wont find one but you don't really need it particularly because you have some conversion cart references already. in all of your cart pics pin 1 and pin 23 are lifted and tied to 3.3V. based in the datasheet pin 1 is setting the chip into read mode instead of write mode, and pin 23 is Vcc powering the chip. I think we can safely assume that the remaining pins all map out the same.

I was renaming the C2 files in the same way: mpr18340.2, mpr18341.3, mpr18342.4 etc. Like I said, havent touched MAME in many years so I thought it was something I was doing wrong.

I see, unfortunately that wont work. the mame driver doesn't understand naming conventions it goes by whatever is explicitly called out in the ROM definition, so if there's no file specified then mame wont know to look for it.

 

[jcmorrisii]

ok a few tips for this in MAME,
first you must specify the ROM to be loaded from the command line, selecting from the menu will fail because the CRCs don't match (they're all going to be completely wrong because it's a completely different game)

second you don't have to zip the files, you can simply place them in a folder with the folder named the same as you would the zip file, AND this can reside in the original ROMs folder along side the original zip, MAME will search the folder first.
so in your rom folder you likely have shanhigw.zip, you can leave that as is and then create a folder called shanhigw inside the rom folder. Then you can take your cotton roms renamed to match shangigw and place them inside the shanhigw folder. Then run "mame.exe -window shanhigw" from the command line. I like to also include the -debug flag but it's not necessary

I had a few minutes to give this a go, had to move the original zip outside the ROM folder because mame was running it and not files in folder. Im just getting CRC errors in the command prompt, wrong Checksum. This is what I did:

-Create folder with same file name as target "Virtual donor"
-unzip cotton 2 files into said folder
-renamed files to the same as those expected by myfairld
-run "mame.exe -window myfairld"

Now mame can find files, but is giving me a CRC checksum error on them. Also says it looked for a .NV file for myfairld and couldnt find it. I see in the myfairld.zip there is a .nv file in addition to the flash roms.

-I added the .NV file from the myfairld.zip into the "virtual donor" folder

Progress! Mame still shows me checksun errors, but loads the game to the system check screen on the STV, where it fails. This is the message in the STV main menu: Operation of this cartridge is unavailable with "System Assignments" Error on Catridge.

Hmmmmm .

 

[twistedsymphony]

1. create a folder called myfairld
2. unzip cotton2 into this folder
3. rename each of the cotton 2 files to match the myfairld files
so:
mpr20122.7 should be renamed to mpr21000.7
mpr20995.2 should be renamed to mpr20117.2
and so on following the names found in the mame driver for myfairld https://github.com/mamedev/mame/blob/master/src/mame/sega/stv.cpp#L2381

all files must exist and be the correct size, however if you leave your original myfairld.zip in the rom folder then it will grab any missing files from there if it doesn't find them in the folder you created.

finally
4. run "mame.exe -window myfairld"

you were missing step 3

 

[jcmorrisii]

1. create a folder called myfairld
2. unzip cotton2 into this folder
3. rename each of the cotton 2 files to match the myfairld files
so:
mpr20122.7 should be renamed to mpr21000.7
mpr20995.2 should be renamed to mpr20117.2
and so on following the names found in the mame driver for myfairld https://github.com/mamedev/mame/blob/master/src/mame/sega/stv.cpp#L2381

all files must exist and be the correct size, however if you leave your original myfairld.zip in the rom folder then it will grab any missing files from there if it doesn't find them in the folder you created.

finally
4. run "mame.exe -window myfairld"

you were missing step 3

All of the information in the previous post was based on having done that (renaming files to match donor). Edited post for clarity.

I also noticed there is a note in the code about myfairld being 1 player only, perhaps the message Im getting is some conflict due to that?

EDIT: I was right about it being due to the player configuration. I found that by going into the System assignments on the STV menu and changing the cabinet type to 1p to 2p solved the error, and now Cotton 2 will load!

After confirming that, where do you think we should go from there?

 

[twistedsymphony]

burn the ROMs install them on the cart and see how it goes.

working out the jumpers on 837-11124 they do this:

comp	left	right
R1	5V	IC13-A17
R2	IC13-A17	Mask ROMs-A17
R3	5V	IC13-A18
R4	IC13-A18	Mask ROMs-A18
R5	5V	IC13-A19
R6	IC13-A19	Mask ROMs-A19
R7	IC19-Pin12	IC13-A16
R8	IC13-A16	Mask ROMs-A16
R9	IC19-Pin12	IC13-OE
R10	IC13-OE	Mask ROMs-A16

mostly it's just tying IC13 to the Mask Roms and defining the size of the IC13 ROM

 

[jcmorrisii]

working out the jumpers on 837-11124 they do this:

comp	left	right
R1	5V	IC13-A17
R2	IC13-A17	Mask ROMs-A17
R3	5V	IC13-A18
R4	IC13-A18	Mask ROMs-A18
R5	5V	IC13-A19
R6	IC13-A19	Mask ROMs-A19
R7	IC19-Pin12	IC13-A16
R8	IC13-A16	Mask ROMs-A16
R9	IC19-Pin12	IC13-OE
R10	IC13-OE	Mask ROMs-A16

mostly it's just tying IC13 to the Mask Roms and defining the size of the IC13 ROM

Good stuff, very interesting, so unless there is an EPROM used, the location of the jumpers is irrelevant?

burn the ROMs install them on the cart and see how it goes.

I actually did this before making the OP, there are photos located near the bottom. FWIW, when burning, these are my settings in GQ4X:

File Mode: Binary
Read Mode: Normal
Fill Mode: Normal
File Offset: 000000

I just get the standard "cartridge error". Im guessing the error is in the writing process on my end perhaps?

 

[twistedsymphony]

those settings are fine. Are you verifying after burning?, with chips like these that essentially have to be soldered in place I usually verify multiple times to be 100% sure the data is correct.

what did you use for ROM7? since that is 16M instead of 32M

 

[jcmorrisii]

Are you verifying after burning?, with chips like these that essentially have to be soldered in place I usually verify multiple times to be 100% sure

Yes I did verify every chip multiple times, but there were a few that failed once before passing. I also suspect that some of the chips I got had issues from the beginning, some would flash and verify perfectly and others took multiple attempts. I just confirmed this to some extent by burning various roms to some spare “problem” chips and they won’t verify. Also, See below, maybe other contributing factors why

what did you use for ROM7? since that is 16M instead of 32M

I used the same MX29L3211MC, so that’s incorrect I guess?

 

[twistedsymphony]

that's a 32M chip. since it's normally looking for a 16M chip there I'd typically recommend doubling the ROM data to fill the whole space because if the cart is holding the high address line in the wrong direction it could be reading it as blank. Alternatively you could find a 16M EPROM to install there instead of the MX29L3211

 

[jcmorrisii]

that's a 32M chip. since it's normally looking for a 16M chip there I'd typically recommend doubling the ROM data to fill the whole space because if the cart is holding the high address line in the wrong direction it could be reading it as blank. Alternatively you could find a 16M EPROM to install there instead of the MX29L3211

Ill try pulling that chip , doubling the ROM data , and resoldering in place.

 

[jcmorrisii]

Well....Im dead in the water for now, the rest of the MX chips I had must have issues, none of them will pass verify no matter what is flashed to them. Guess I have to order more. I asked the seller if he had noticed issues with any in the past and got the typical "My stock is perfect from the factory everything has worked 100% i have sold 1 billion units thus far, your the first etc."

 

[twistedsymphony]

I had that same issue with a GQ4x4 on that same model of EPROM, there was something about the adapter I was using that made it incompatible.

 

[jcmorrisii]

I had that same issue with a GQ4x4 on that same model of EPROM, there was something about the adapter I was using that made it incompatible.

So what was the solution? Was the device being written correctly, just not verifying? I read other people accounts saying that they never could get certain files to verify but they worked fine. I hate to solder something on that didn’t verify because it’s time consuming and every time I feel like I’m making the pads more stressed .

Maybe I should order them flashed from ICnow….never used them before but I know others have for a long time.

 

[twistedsymphony]

So what was the solution? Was the device being written correctly, just not verifying?

reading was fine it wasn't wirting properly, so the verification process was correct and was indeed failing.

For me the temporary solution was to use buyicnow.com to write the chips for me, and I eventually bought a better programmer, as that was the straw that made me ditch the GX4x4 for good.