Quote:

As I (may) have thought up some nice solutions, the following features will most likely be implemented in the next release: Redirect boot code to a hotkey test to disable software boot Double cartridge entry without the need of a second Sound Cartridge Support for BASIC in ROM. Unfortunately, the work-around I provided earlier doesn't work. Though there is something weird with this type of support, even though it is supported Page 0 ROM's support. This will require RAM in page 0

Today a new version of ROMLOAD was released. From this list only the last one is implemented right now. Furthermore some system related settings can be forced: language setting and version setting. Also a list of all-combination patches have been added to the manual. Since there are a few versions for some games, I've added patches for each of them where necessary. The versions provided are based on the GoodMSX versions of the games.

Currently I'm looking into the double cartridge entry without the need of a second Sound Cartridge and support for BASIC in ROM. As always you can post new feature requests in this thread.

Awesome! Now all you SSC+ users get some 6164 dram chips and do the upgrade!

I really like the "Redirect boot code to a hotkey test to disable software boot" idea!

It's not very important for gamers, but it sure helps a lot coders to test the rom image

Is there anyway of upgrading a Konami Snatcher/SD Snatcher cartridge without breaking it (label and plastic case)?

Indeed. And on that note, implementation of the hotkey system is on its way.

Opening a Sound Cartridge without any 'outside damage' is difficult but not impossible. I don't know exactly how though.

This what I've done... First of all, I've bought a second SD-Snatcher to keep at least one completely undamaged, and here in the Netherlands it's easier to get a second SD-Snatcher than a second Snatcher. By reading these steps you'll understand why. Secondly, any steps done in this list are completely at your own risk. I will take no responsibility whatsoever for any damage that may have been caused by these steps:

• in the lower left and the lower right corner of the label there are two holes. You can find them by rubbing over the areas
• by pressing a screw driver in the lowest part of these holes through the label you come accross two of the 'locks'. You can either gently bend it just enough to be able to open it on these positions or simply remove these 'locks' as the other 4 will be sufficient to keep the casing closed firmly
• slightly higher of the middle you'll recognise two 'locks' on both the left and the right. Using the screw driver you can bend the outer casing a bit to release it
• now you can gently open the casing like a book. Any resistance can be overcome to gently press the last 2 'locks' open by pushing the casing to where the label crosses from the upper half to the lower half

After all this you'll see the PCB which is shown on this page. Instructions on adding the RAM chips can be found there as well.

Quote:

I really like the "Redirect boot code to a hotkey test to disable software boot" idea! It's not very important for gamers, but it sure helps a lot coders to test the rom image

Option implemented.

hhmm... isnt is possible to remove the 2x 64KB and add 4x128KB or even more on a SCC+ thingy?

Quote:

hhmm... isnt is possible to remove the 2x 64KB and add 4x128KB or even more on a SCC+ thingy?

There is very few information available on the SCC-I chip which contains the sound processing unit, mapper, read/write control and other necessary logic to even be sure if that is possible.

Wouldn't just counting the address lines be enough to know?

If you know which pins on the SCC-I the address lines are...

Well, they connect to the RAM, so that can't be hard to trace

Even then it's 128K that is addressed and address lines aren't always in the same region as the already connected lines, let alone in the correct order. So it's still hard to find which pins are address lines (apart from the ones already connected), which of the unconnected lines are possibly address lines and even then which line is which bit within the address...

Seems somebody just needs to try

I don't know how far Sean Young got with his investigation around the pin assignments. IIRC he lost the docs he kept regarding that... :/