SpritesMind.Net

Christuserloeser wrote:Wow, 214 different games using GEMS ... No wonder people thought YM2612 sounds bad

Bad? O_o.

r57shell wrote:

Christuserloeser wrote:Wow, 214 different games using GEMS ... No wonder people thought YM2612 sounds bad

Bad? O_o.

You should read the interview with Jesper Kyd.

Which one?

r57shell wrote:Which one?

About MD sound quality.

Where?
https://www.google.com/search?q=Jesper+ ... +interview
How can I recognize that I read what you meant?

Do you mean that YM2612 sounds bad at all? Or just under GEMS driver?

Few years ago I've read one of interview with Jesper Kyd. He talk about music quality on MD. He told that everyone want digital drums with terrible low quality. And he offered pure synt instruments with "CD quality", which he used in own tunes. Indeed, music from Jesper Kyd on MD are peerless.

r57shell wrote:Do you mean that YM2612 sounds bad at all? Or just under GEMS driver?

Not all, but some music using the GEMS driver sounds bad. There are some exceptions (like Dune 2, Earthworm Jim, Vectorman) but a lot of it sounds rather flat in comparison to other sound drivers.

I think, it is just bad music/composition itself.

TmEE co.(TM), is there a chance you have the schematic for the parallel port to EXT adapter available somewhere? I'd like to breadboard one myself. I'm also curious what the memory map for the ROM/RAM carts is (and what the 4 dipswitches do).

I'm trying to throw together a working GEMS setup...

BTW, have any versions of gems other than 2.0, 2.5 and 2.8 been archived? As far as I know, these were the versions:
GEMS 2.0 - 1991-11-25 - [Dumped, both PC side and Genesis side]
GEMS 2.1 - 1991-12-16 - [Undumped, except readme]
GEMS 2.2 - 1992-03-05 - [Undumped, except surviving readme in GEMS 2.5 docs, and date in GEMS.A]
GEMS 2.5 - 1992-05-21 - [Dumped, both PC side and Genesis side]
GEMS 2.8 - 1994-04-26 - [Dumped, both PC side and Genesis side]

The copy of GEMS 2.0 that is floating around has a modified patch.bnk file in FMLIB in it which someone modified on 19920514, the original file should have a date more like 19911125. I'm asking some devs if they may have an unmodified copy of it...

GEMS 1.x is implied to exist by the readme with GEMS 2.0, but it was much more primitive. Unclear if any copies survived.

LN

Schematics are here :
http://www.tmeeco.eu/SMD/SegaLoaderBoard.JPG
http://www.tmeeco.eu/SMD/Sega%20Loader% ... (GEMS).pdf

Thanks so much!
Did you ever end up doing high-res scans of the front and back ROM/RAM carts? I'm trying to figure out the memory map of the carts, and I can't read the 74xx chip labels on the pictures at http://www.tmeeco.eu/FileDen/GEMSstuff.jpg
I know from the GEMS 2.8 program that at 0x19f8 it writes 0x10 to 0xa130e0, and i assume that somehow changes something with the big pile of logic on the cart (possibly disables write-protect on the SRAM?), and I'd love to be able to figure it out.

Those two(?) PLDs on the carts, the 315-5400 chip and the 20-pin lattice semi (GAL?) chip next to it could be the core of whatever is going on, which may require those chips to be dumped. I'm not sure.

My guess (and these are all guesses) is the two populated 27c1000 EPROMS at C04(?) and C05(?) map as the odd(C04?) and even(C05?) bytes respectively to 0x000000-0x03fffff; the two empty eprom sockets presumably map as odd and even bytes of 0x040000-0x07ffff.
I don't know what there is mapped to 0x080000-0x0bffff or 0x0c0000-0x0fffff, it may be a mirror of 0x000000-0x07ffff.
I don't know what there is mapped to 0x100000-0x1fffff, it may be a mirror of 0x000000-0x07ffff.
I assume the sram is mapped where sram usually maps on a genesis/megadrive cart, at 0x200000, but since it is so large it probably extends all the way to 0x21ffff rather than the usual max of 0x20ffff. I have no idea how the sram would mirror. I'm reasonably sure the SRAM is in one large chunk due to the changelogs in the GEMS 2.5 readme about a bug in GEMS 2.2 where the sequence data in the first 64k would smash the sample data at the beginning of the second 64k, implying they occupy a continuous region.

LN

I have dumped the GALs and the labelled chip and unfortunately the GALs seem to be protected, fusemap reads as all ones, with ID bits giving a pattern. But the labelled chip does look like a good dump. In addition I stripped most parts off the cart and took some photos that should be good enough for tracing out things (don't have a scanner that works...).

http://www.tmeeco.eu/SMD/171-5862A%20front.jpg
http://www.tmeeco.eu/SMD/171-5862A%20back.jpg

http://www.tmeeco.eu/SMD/171-5862A%20IC13.JED
http://www.tmeeco.eu/SMD/171-5862A%20IC19.JED
http://www.tmeeco.eu/SMD/171-5862A%20IC20.JED

WOW! Thank you so much for doing this!
The pcb calls the two gals "PAL16L8" even if they used lattice gal parts... if you can figure out which pins are inputs and outputs (which can vary based on the fusemap) it should be possible to brute force a truth table out of those parts, even if they are protected, by dumping them like a ROM, then re-generate a CUPL file based on that. PAL16L8 parts cannot* have registered latches, so they should hold a plain combinatorial map.

* It is possible through some abuse of the PAL array logic on a L or H pal to produce a 'fake' latch, but it is a gross hack. I think the PAL on the sound blaster 2 card which controls the addressing of the SAA1099 chips, and it does a hack like this, using an open collector output and open bus to form a fake latch?

LN

For now I'm really busy with other things but eventually I could wire up the chips to a counter and record the outputs and give the dump of that, assuming it will be necessary. I don't think the chips do anything more than address decode stuff and their function should be easy to guess.
I also tried to dump the GALs as PAL16L8 but that gave a full ones fusemap.

I'm pretty new to PAL/GAL stuff and only because I am in the process of decoding functions of one Gravis UltraSound card to uncover its secrets lol. It seems none of the tools I found can deal with GAL20V8A and making my own needs some thought to automate the process enough to produce something useful to look at. All the parts are in complex mode (no FFs luckily) but outputs feed back into the matrix very often and that complicates matters...

Lord Nightmare, checkout this thread also viewtopic.php?f=14&t=1898
plenty of useful info about GEMS.
All you need to do to work with GEMS ROM is:
1) just very big RAM at correct location,
2) ROM from dev kit (that is in srecord format) at offset 0
3) gems lpt device on EXT port. you can change EXT port to joypad port with small modification of ROM.
Location of RAM is also in that topic. It's how we setup SRAM range in ROM header, it's just workaround, because normal emulator doesn't support RAM except SRAM.