I did want this next update to be about the rare Sega game Charles is current dumping the FD1094 key for, to complete a trilogy of ‘3D’ sprite based games, but as it turns out the ROMs aren’t fully dumped yet (although the key has been, fingers crossed it’s still good!)
Anyway, while the rest of that gets done I’ll spend a bit of time talking about something else, it’s a gambling game, so might not be of interest to everybody, but from a hardware perspective it’s quite interesting.
The game in question is Seta’s Jockey Club II. Jockey Club II seems to have been one of the more popular Seta titles, to the point where it came out on several different hardware revisions (we’ve got dumps from 2, but there is apparently at least a 3rd) It also ended up being bootlegged rather heavily.
Currently the only version of the game that works in the ‘Dark Horse’ bootleg (although the actual driver in MAME has been broken for a while now, but doing a quick fix on it was what got me to take another peek at this)
Now, the bootleg is quite crazy, as Luca observed when emulating it they’re parsing all the video ram and converting data from the format expected by Seta customs into plain tilemaps + basic sprites for use with their cheaper hardware. It’s a novel approach, and can only really work if you have CPU power to spare, and the game doesn’t make extensive use of the more advanced features of the chip, but in this case Seta were pretty much just using it for some basic virtual tilemaps and sprites anyway.
Seta had a lot of custom chips, especially video ones, the hallmark features were usually floating sprite ’tilemaps’ plus many levels of hierarchy, indirection, inherited attributed etc. The later ones also integrated sound hardware, and a tile/data blitter + RLE decoder. I’m pretty sure the CPS3 video chips are an evolution of the Seta chips because they share a lot in common with the later ones such as the SSV sprites and the ST-0026 (NiLe) used on Super Real Mahjong 6.
Now, for whatever reason Seta seemed to put some of their more interesting chips to the most mundane of uses, as already mentioned, the ST-0026, which features full RLE decoder and alpha blended sprites was only used on a single Mahjong game!
The Jockey Club II hardware revisions we know about are no exception to this, I guess they could afford to be lavish knowing that casinos and the like would pay good money for these things, but considering the hardware use it seems a bit of a waste.
So the two hardware revisions and their Seta Customs
‘PCB E79-001 rev 01a’ (newer hardware)
SETA ST-0032, SETA ST-0013, SETA ST-0017
‘E06-00409 + E06-00407’ (older hardware)
SETA ST-0020, SETA ST-0016, SETA ST-0013, SETA ST-0017
both revisions are driven by a 68020, and use the same basic code, so let’s discuss the customs.
SETA ST-0013, SETA ST-0017 are also common to both, the 0013 features on Super Real Mahjong 6, I’d guess it’s some kind of input multiplexer, the ST-0017 is unique to this PCB and I have no idea of it’s function, but it’s probably another support chip of some sort.
The real beef of the hardware is in the ST-0032 (newer) or ST-0020 and ST-0016 combo (older) with the ST-0032 and ST-0020 both being large heatsinked chips.
Starting with the older hardware, because we recognize both the chips. The ST-0020 is a sprite chip, it does large zooming sprites, works with 512kb of RAM for the sprite lists, 4MB of RAM for the actual graphics, has a blitter to copy data from ROM to the video RAM and is all driven by a ~100mhz crystal. We know it because it was found on the Gundam Final Shooting SSV board, to boost the capabilities of the basic SSV board (zooming support etc.) Luca had emulated it there previously, or at least emulated it to the degree the limited use of gdfs allows for, it’s possible it can do more.
ST-0016 we also know, it’s an all in 1 Z80 + video + sound chip used for some complete games (Neratte Chu being a personal favourite) as well as a support chip on other games to do basic text layers and such (Super Eagle Shot) We’ve also seen it employed simply to provide audio, ignoring the video capabilities completely (Super Real Mahjong 5) which seems like a waste, but also appears to be what it’s used for here because the ROM for it contains no graphics.
The newer hardware uses the ST-0032, which is an unknown quantity, but after some basic studying it seems to operate in a very similar way to the ST-0020, at least in terms of the video support, some data structures are in a different order, and there are no doubt some other differences. Given the lack of an ST-0016 on these boards, and dedicated sample ROM I’d hazard a guess it also has integrated sound support.
There are a couple of other differences with the bootleg too, the bootleg has dedicated sprite ROMs, the originals seem to contain the sprite data compressed in the program ROMs somehow, it seems the 68k is responsible for decompressing it rather than any of the blitter functions of the ST-0020 / ST-0032 because the board doesn’t actually appear to have any dedicated graphic roms (or at least nothing we can identify as such) so unless the blitter can be tied to program space or do ram->ram operations it doesn’t actually have anything to work with.
Anyway, that’s a lot of text, and to be honest, I don’t have much progress to show for it. What I’ve done is separate the ST-0020 emulation code from ssv.c, and converted it to be a nice modern C++ device in MAME, this allows for easier code reuse. The natural progression was to then hook it up into the Jockey Club II driver, and figure out how to get Jockey Club II (older hardware, with ST-0020) to display something, after that, and seeing how close the RAM content was I wanted to make the ST-0032 version show something too. What we have in the end are a bunch of error messages.
Jockey Club II (ST-0020 / ST-0016 hardware)
Jockey Club II (ST-0032 hardware)
Not thrilling, but better than the black screen the games have been showing for several years now, and it shows that the bits of the chip are hooked up in the right place, it’s good grounds for further progress. Interestingly, the games *require* a valid Eeprom (which may have to be faked in the case of the two original sets) because it contains the machine ID, which appears to be a serial number of sorts, which I don’t think the games can reprogram on their own (Naomi has similar) If you look at how the Dark Horse bootleg has been broken in MAME for a while now you’ll see the same message as the newer hardware set above.
Dark Horse (bootleg hardware) (with broken eeprom handling, MT report)
That message is simply complaining about the eeprom hookup / default eeprom, which is what had broken in the bootleg driver. It’s fixed now, but at least knowing that points us in the right direction as far as what at least one of the original sets is currently complaining about.
As you can see, all 3 screens are slightly different, which might indicate the bootleg is based off a copy running on different hardware revision to the originals we have, although like most gambling games it seems to have a large number of revisions anyway, the board even has a socket which appears to be for upgrading the program rom without having to replace the entire larger rom but instead just patching over the code section.
So overall not much progress, but some, and maybe enough to get the driver looked at a bit more :-)
Nice work!
Are there many other video chips that are used by different systems and could get the same “device” treatment as the ST-0020, thus avoiding code duplication / different implementations between drivers?
Any plans on updating the Taito L System to use the new device created for Last Bank / Fruit Dream in the near future?
Thanks.
Taito L is on my todo list..
Seta had a lot of chips, so code duplication is pretty low anyway, they all function in slightly different ways so often need their own implementations anyway.
ST-0020 was converted because we knew it was used in multiple places, the old TNZS 001a/002a chips likewise. ST-0016 video could be made a device, but the code is already shared anyway. Most of the other chips seem to only really be used on one system / game.
Thanks.
Do you know if there’s any plan to use the “new device” implementations appended by Mizapf to some old cores? The new versions seem to be used only by Mizapf’s drivers.
I have no idea what you’re talking about, so no ;-) Cores should be converted, eventually.. but the migration path is very difficult for some of the more complex ones.
Heh, was talking of such submits:
http://git.redump.net/mame/commit/?id=15292823272024e52ee13b0b5489931edb06cd03
http://git.redump.net/mame/commit/?id=ddbb553cf194b67f82051881787b3bf42ed0b011
where the drivers that use the legacy version haven’t been updated to the new one, AFAIK.
that’s pretty bad to be honest, it means there are now two versions of the device copy+pasted in there, it doesn’t even appear to be wrapped around the old one.
The major problem is that dozens to hundreds of drivers use those devices, so some kind of automation is necessary to update things. Lacking that, this at least allows drivers to continue to work while someone goes through and updates them (Osso, if you’re interested, we’d certainly accept such submissions – it’s a *terrific* low-risk beginner’s project).
Yeah I was just thinking from a bug fix perspective, there are now two copies of the same code, rather than two interfaces to the same code, meaning it would be easy for them to go their separate ways and end up with different compatibility.
but yes, as RB says, converting drivers to use a new device is rather easy, it usually consists of just a change to the memory map, a few lines in the state class for each driver so that it looks up the device on startup, and some updated lines in the MACHINE_CONFIG structure to tell it the system uses said device.
of course that assumes the new device is drop-in compatible, but as long as there are other examples it’s an easy enough task
the only thing i’d say is make sure you do a ‘make depend’ before working on such things, otherwise changes to .h files won’t get picked up and the relevant source files won’t get recompiled, which can lead to some very weird crashes ;-)
Sadly I’m not a programmer. The only thing I can do is update some obscure WIKI. Though I must admit it’s tempting to try and see if I can figure that out.
Now, if only etabeta weren’t lost in updating software list, it would be a perfect job for him.. :)
In fact, I’m mostly lost with real life :(
these days, I tend to have series of ~5 min short breaks to work on emulation, and these chunks of time do not really fit any serious programming work…
updating softlists is basically the only thing that can be done in these conditions (and I’m struggling to keep things up-to-date there as well)
I’m interested in this converting drivers project and you mentioned that “as long as there are other examples it’s an easy enough task”. Would there be said examples? (I ran a quick search of Zapf on the git and didn’t see any.) I’m not a professional programmer, but I have programmed (taken courses and made little personal programs), am pretty good at reading what code is doing and would like to help out MAME. Since it was qualified as “rather easy” I thought I would give it a shot (then again, maybe by just asking, it disqualifies me and my “skills”).
Osso is actually taking a look at this already, and converted a couple although there was some debate over the naming of the new device, and subsequent patches don’t appear to have been put in yet
It’s always worth trying to get and understanding of MAME anyway tho, and being able to understand what code is doing (especially if that extended to the various assembly languages) is quite a useful skill to have for MAME / emulation, because it’s all about understanding and logic.
Ok then, I’ll just wait for the patches to make it through and give a look at them then.
I heard that my changing of the suffix from n to _new hasn’t been approved. I plan to wait for the next u release and resend the patch without the suffix change.
If you want to do it, I have nothing against it. Just let me know, to avoid duplicating efforts.
unfortunately that’s Mamedev all over….
the ‘N’ suffix destroys documentation, because there’s already a part called ‘AN’ and it ends up looking like the drivers use it.
marking it properly is a lot clearer, you did that, which is good, but because it’s more than a trivial change, and came from external it ends up having to jump through hoops to get accepted, when in reality the original patch, using ‘N’ in an inappropriate way should have been rejected / reverted / asked to be corrected, but wasn’t because it was internal.
SN76489, SN76489A and SN76489AN are all real device names. Naming a new class implementation of the SN76489A as ‘SN76489AN’ is simply not appropriate because when you search+replace everything it makes it look like all the SN76489A chips were SN76489AN chips, then if later the SN76489AN gets changed back to SN76489A it’s going to destroy other documentation in comments for cases where the chips really were SN76489AN.
SN76489A_NEW or SN76489A_MODERN is a much clearer marking of the new implementation until the old one goes away, it leaves no room for confusion or error and doesn’t erode any documentation. It is risk-free as far as the potential for any search+replace errors goes.
The other alternative is that the old device be tagged _LEGACY (actually maybe tagging all legacy devices as _LEGACY would be a good idea, give some incentive to upgrade them)
Now I can’t discount you making an error with your change, but it Mamedev really have real coders left they’d assist you with that, show you what you did wrong, fix it, apply it, and give you a bit of guidance, but that never seems to happen anymore. This is especially important for new contributors who might not be 100% familiar with things. I think one of the reasons we’re not seeing as many new contributors sticking around lately is that the current team aren’t willing to take time out to go over things with people, show them the ropes, and explain how everything works.
I’ve said before, it puts people off, and it does. This should be obvious stuff without needing a page to explain it.
Unfortunately by sending more changes without correcting this poor naming scheme you’re only going to be introducing more problems for later due to the multiple different meanings of ‘SN76489AN’, the new one being entirely incorrect. That really needs to be fixed first….
As a first time submitter, I think having an official answer from the team would be very important. I’d really like to understand if/what I did wrong.
Still, since IANAP, it’so no big loss to MAME if I stop sending these little patches.
Haze is simply feeding the machine without asking questions and assuming a lot again. That is how misunderstandings happen. Osso, expect an email from me today regarding this. Thank you.
I’d agree I was blowing things up if it was an isolated case, but it isn’t, it’s by far the most common complaint about Mamedev, including from me personally, questions go unanswered, proper guidance isn’t given, petty changes are made to peoples code without explanation etc. so I will push the issue.
It is absolutely essential that people are kept in the loop and have things explained to them, the process needs to be as transparent as possible.
When I took over the submission process a few months ago, I’ve been working very hard to keep things as speedy, transparent and as fair to everyone as possible. So, I personally dropped the ball and did not get back to a submitter (Osso) about a submission and it has barely been a week and no new releases have been made. I didn’t even know he was asking about it until I was told by Haze about it after he posted his “unfortunately that’s Mamedev all over….” response. I just don’t care for the negativity to everything else I’ve tried to do for submissions and MAME – it equates to a literal slap in the face to everything I’ve done.
Auto-responder or not, the message each submitter gets is clear. If any submitter has a question about a submission or doesn’t see it applied for a time (I think it says one or two U releases), they only need to contact that address again. Otherwise, you can contact one of many Devs that frequent the forums , irc and otherwise. We aren’t hard to find and are willing to help anyone contribute to MAME.
Tafoid, that’s what I did. I wrote a PM to a dev and he told me about a suffix renaming issue. I didn’t really understand, since the suffix will need to be removed either way (n or _new) in the end.
Still, as I wrote above, I have no problem resubmitting the patch after the next u release, without the suffix change.
I’m happy to learn that you’re working on answering to external submissions. I do think it’s really important for Mamedev to give the impression of caring about external contributores, otherwise people might lose motivation. In my case, I’m just a typing monkey so no big deal. But losing a talented programmer because of lack of comunication would be terrible.