There are two ways you can judge an emulator, either by what it can do, or what it can’t do. Personally I’ve always favored the first option, it’s a more positive outlook, and it’s a good one to take with MAME, and especially MESS, or the combined UME project (and it’s part of the whole philosophy behind it, UME allows you to do more than MAME)
It’s with that introduction I’ll mention some of the progress in 0.148u2 coming from the MESS side of things. It goes without saying that the Jaguar driver is a bit rubbish, in terms of what it *can’t* do you could fill a list covering most of the system library but I’m going to focus on what it can do here, and 0.148u2, thanks to some work from Ville, expands what it can do into the realm of being able to run Tempest 2000, the psychedelic follow-up to Atari’s arcade classic. The game runs and is very playable on my Core2 system with full sound, I don’t think the graphics are perfect but it’s a huge improvement on before where it would simply crash the emulator due to unsafe blitter operations overwriting the game ROM in memory!
(Tempest 2000 benefited from recent improvements to the Jaguar emulation and is now mostly playable with sound)
Purists might say it lacks the crisp vector look of the original, although that’s obvious given that it isn’t running on vector hardware here, but it has a style of it’s own, and I feel could easily have been an arcade release. Jaguar will need a lot more significant work applied (probably a full rewrite) before it’s anywhere near a good driver, but nice to see it getting a bit of attention in the same way that u2 has given some attention to several older MAME drivers. The original Jaguar version of Rayman also benefited from the changes with the collisions now being fixed, although that still lacks sound and the save feature shows ‘ERROR’ in all slots, still it complements the progress made with the Saturn version of the same game in u1 nicely!
(Rayman was also improved, but still lacks sound)
Speaking of Saturn there have been continued improvements to the emulation of it in u2 from Kale, mostly targeting specific issues highlighted by specific games, but many of the improvements likely have a wider impact than the individual test cases observed. A knock on effect of this Saturn work has been improvements to the ST-V emulation in MAME, and as featured on Kale’s Blog, the game ‘Zenkoku Seifuku Bishoujo Grand Prix Find Love’ is now playable in MAME. If it wasn’t clear from the title it’s an adult game where you undress Japanese ‘gals’ by playing various mini-games, including a ‘find the differences’ one, ‘pairs’ and a jigsaw game. Typical 90s garbage really, but at least it works now, interesting only really because of the platform it runs on.
(Kale got Zenkoku Seifuku Bishoujo Grand Prix Find Love working thanks to a better understanding of ST-V / Saturn hardware)
Some observations were also made about the protected ST-V games during this development cycle, and Kale identified that the broken player / ball movements in Tecmo World Cup ’98 were indeed related to a protection check, although even with that fixed the game still hangs if the USA Goalkeeper gets the ball, it isn’t clear if that is further protection on the GKs special move, or just a bug in the Saturn / ST-V emulation. From some brief studying of the protection it looks like Sega actually used a complex encryption / compression system on some of the game data for these ST-V games, similar (possibly the same as) the one used on the Naomi cartridges. Further research suggests it might also be used on Model 3, both for the games with compressed graphics there, and even the ones doing a dumb ‘string check’. That would mean Sega were using an encryption scheme as complex as CPS2 to perform nothing more than a hardcoded check against a string in some cases if true, mind boggling!
(Kale improved Tecmo World Cup ’98, but it still has game breaking bugs and bad performance)
Either way, a lot more work, and possibly extensive data collection + analysis will be needed to either confirm or deny that theory. Decathlete remains an odd-one out and seems to have the compression more for functional purposes than protection, the way it talks to the device is different to the rest, and it explicitly uploads what look like Huffman tables for the compression. I plan on having another look at that one in the future. There were other ST-V fixes as well, the long standing ‘some games give 2 credits on startup’ bug appears to have been fixed as well, and while only a minor irritation it is a sign that the driver, and understanding of the hardware are starting to mature even a huge amount of work remains, especially in terms of performance and video accuracy.
The work on Gunpey is included in 0.148u2, although no progress was made on the compression, which remains problematic. My early optimism that I would have that one sorted in a week definitely didn’t pay off! It’s actually rather playable but still marked as not-working because a couple of the sheer number of broken graphics caused by the missing decompression.
(Gunpey, quite playable but understanding the compression scheme has become a sticking point)
You’re probably sick of seeing Cool Riders by now, but that is included as well, I’d had the driver on freeze for a while as not to break in any way prior to the 0.148u2 release, I might give some of the remaining issues another look now that u2 is out of the way, the main irritation is still the sound. *edit* Cool Riders will have problems with some Mac systems in 0.148u2 due to a compiler bug with the CLang compiler used, a workaround has been submitted by Phil B, thanks for the reports.
(Cool Riders is officially supported in 0.148u2)
On the MESS side etabeta has been giving some attention to expanded cartridges for a number of systems. The Genesis and SNES were beneficiaries of this, and also improved documentation of the cartridge content (rom name, chip locations, extra hardware etc.) thanks to notes / information from ‘ICEknight’, ‘Sunbeam’ on the MESS forums and other contributors from elsewhere. This kind of information is essential to the documentation value of MESS, and of course proper identification and emulation of any important extra chips found in the cartridges.
I mentioned expanded cartridges, and for the Genesis that more often than not means 3rd party ones, usually unlicensed (by Sega) Chinese titles and the like many of which had unusual / custom mapping for things like their battery backed save systems, or custom protections. A number of games previously requiring hacked dumps to run can now be used with the proper ones, including things like ‘Tiny Toon Adventures 3’ I am however still noticing some stability issues with the driver randomly crashing, especially on startup with certain games (Mulan for example) This may or may not be related to some overall stability issues I’ve noticed since the recent HLSL work went in, where games with dynamic resolution changes are bombing out on me at random. The genesis does do dynamic resolution changes…
(A selection of unlicensed Genesis titles where the extra hardware in the cartridges is now emulated)
Other systems saw work on obscure carts / pirate releases too, with the Gameboy not being excluded from that. Work was done on support for the custom hardware used by “Shi Qi Shi Dai – Jing Ling Wang Dan Sheng” a Chinese RPG, it still has issues with drivers other than gbpocket due to unhandled bios interactions (maybe it only works on specific machines anyway?) Improvements were made to the Rockman 8 support too, a pirate sequel to the famous series although I’m not convinced it REALLY works yet, most enemies seem to be missing until you die, and the glitches with the video timing are irritating.
(Some unlicensed Gameboy titles had their emulation improved by emulating cart specific hardware)
Another Gameboy-like handheld, the Megaduck had it’s software list hooked up, although both the Software List and driver have existed in their current form for a long time so I’m guessing the lack of a hookup (a one line addition) was more of an oversight than anything else. The emulation seems to have some minor timing glitches causing the occasional bad line, unsurprisingly similar to those seen with the regular Gameboy. *edit* Apparently this was actually a regression fix, and the Softlist had been hooked up in the past, but the hookup was lost at some point in recent refactoring
(The Megaduck was hooked up to the Software List, although both the driver and list have been there for a while!)
As part of etabeta’s work the SNES saw a large number of cleanups, and refactoring to make things work in a more ‘logical’ way. For cartridges with expanded hardware you no longer need to specify different base machines, instead the software lists specify what hardware was in the cartridge and dynamically add the extra required CPUs to the emulation etc. The downside to this is that the slot system seems to be causing some pretty significant performance issues, with a drop of 20% reported on some of the SNES titles for which performance was already worrying (the DSP based ones). Hopefully this is temporary, and some more intelligent coding somewhere can win it back. The SNES also had a number of pirate titles and the like, including an odd multi-game cart consisting of an original Tetris game alongside many ported NES titles. Not all the games run especially well in MESS, although many are glitch on (at least some models of) original hardware too. Like most multi-game pirates the cartridge contains extra bankswitching logic and etabeta needed to emulate this in order for it to run at all.
(A funky SNES bootleg cart containing NES games required custom bankswitch emulation in order to boot, although still has issues)
While that pirate cart is quite funky, there were also a number of multi-games containing regular SNES games. Unfortunately most dumps of these are bad, containing only the first bank, probably due to being dumped with cart copiers incapable of dealing with the bankswitching. A similar problem exists for many Genesis mulit-game pirate carts.
There were SNES games with additional protection as well, although many of these seem to have been of an even lower quality than the Genesis ones. Tekken 2 is one such example. A cracked version of the pirate game has been supported for a while, but 0.148u2 adds emulation of the original protected pirate cartridge too. The screenshots might look reasonable but the actual gameplay on offer makes Fit of Fighting in MAME look like Marvel vs. Capcom. Imagine if you will controls, animation and scrolling running at something like 5 frames per second, and a game where most of your attacks, if you do manage to pull any off, get blocked. It’s diabolical. As it turns out, emulating the protection on this also allowed for another game to run, the Street Fighter EX plus alpha pirate, that’s marginally better, but we’re talking very, very small margins here.
(Some more terrible SNES pirate games are also now working)
You’ll have noticed something of a recurring theme with the emulation of these pirate carts, and might be wondering why etabeta has spent his time looking at these rather than spending time improving the actual SNES and Genesis emulation. I think a lot of it comes down simply to levels of interest, it’s always enjoyable to be discovering, documenting and understanding something new then recording those findings in MAME / MESS as a record of how they work, and while the games are often terrible that’s not really the point. When I was working on HazeMD it was one of my goals, to understand the things nobody had put much effort into understanding before, so I’m glad to see that continued here, and it looks like people have even started performing hardware tests for some of the protected carts to document how they really work. I’ve always said the value of MAME / MESS is the knowledge contained within it, and obviously understanding these things increases that even when the games are of little worth.
Back to the MAME side, we decided to mark Stadium Hero 96, the game featured in the previous update here, as working. Kale played through the game, completing it, and reported that there only seem to be a few issues with the clipping windows in places, and no game breaking bugs, so the IMPERFECT GRAPHICS flag seems more appropriate than the non-working one at this point.
(The previously shown progress on Data East’s Stadium Hero 96 is included)
I don’t usually cover bootleg clones, but ‘RevisionX’ dumped an unknown board which turned out to be a new bootleg of Moon Cresta called Star Fighter (making it the 3rd game we have supported to carry that name..) It has some redrawn graphics, fast shooting, and more aggressive wave advancement compared to the original at least, I’m not sure how it compares to some of the other bootlegs. The colours might be wrong because no colour PROM was dumped, and we’re using the one from the original.
(Star Fighter is an interesting bootleg of Moon Cresta)
PoPo Bear, another game featured here in a previous update is also officially supported in 0.148u2.
(Snake meets Bomberman in PoPo Bear)
From a more technical side of things one of the most significant updates in 0.148u2 is the complete rewrite of the 6809/6309/KONAMI CPU cores by Nathan Woods. This was done as an attempt to make the cores cycle accurate and should lead to far better raster effects in systems like the CoCo in MESS with some other supporting improvements. This is a very big change, and has the potential to break a lot, in fact when it first went in there was widespread breakage of many drivers in MAME and MESS, but during the course of the u1->u2 cycle the majority of the obvious ones were caught and fixed. Just be warned, some bugs could still be lurking because it’s fresh code replacing tried and tested old code. Naturally if you see any new suspicious behavior introduced for games using a CPU from this family in 0.148u2 it should be reported on Mametesters
Kale also put some work into the Casio Loopy, allowing preliminary screens of that. The system is a difficult target primarily because there is no dump of the BIOS. The system uses an SH1 with internal ROM, and boots the games from that, with some code pointing back to the bios for various interrupts / system calls. The goal of trying to emulate some of the system like this is in part to gain an understanding how how things work, and potentially come up with a way to dump the content of the internal ROM if the hardware allows for reading of it from the game code. The speech bubbles shown in one of the games might actually be an ideal starting place for such work so while most of this looks like meaningless garbage right now it is actually potentially very important progress.
(Preliminary work on Casio Loopy might help find a way to get the BIOS dumped)
Back to the ‘technical’ changes, we’ve seen a LOT of modernizations in MAME and MESS during this update in additional to Firewave going over a lot of drivers and devices adding proper initialization of many member variables in an effort to keep the project both clean, deterministic and stable. Many of these were missed during older initialization passes because the older (non C++) device model would automatically 0 out memory when creating devices, but the new one does not, and was leaving many things in undetermined states, which generally isn’t a good thing because a lot of those are detectable by the emulated system and/or can cause stability issues. I do wonder if the Genesis stability issues I’ve been seeing while writing this article aren’t related to a similar problem if we can rule out the D3D code updates made for HLSL / multithreading by default. Tracking random issues like that can be a nightmare tho, especially when they stop happening altogether in your debug builds, so I’m glad to see preemptive steps being taken to prevent many potential problems from cropping up later, it certainly helps narrow things down when you have to start looking for potential issues manually.
From the oddity department LoganB submitted a software list for the Sega Dreamcast VMU quickload files. While these aren’t technically ‘roms’ as such (but memory dumps) they do provide an accessible way to make use of Sandro Ronco’s driver by validating that you’re using recognized software, software that would definitely work on the original unit. While the approach used is not very ‘pure’ it is convenient, and very useful for regression testing and the like. Here are some screenshots of the Powerstone VMU memory dump running. No new work has been done on the actual driver, but with the software list now being present and hooked up it’s the first time I’ve given it a run through so I thought it warranted putting some shots up, for a reference to how it runs right now (even if it’s still marked as NOT WORKING)
(The Sega VMU got a Software List, this was the controller Memory Card thing used on the Dreamcast)
Not all work involving MAME and MESS involves changing the actual projects directly either. The support network is vital as well, and while I feel we should keep a lot of this tied as close to the actual emulation distributions as possible (rather than relying on miscellaneous forum posts and wiki entries) it is good to see when people make an active effort to teach people how to use MESS, and show what can be done. It’s with that I’d like to mention a thread R.Belmont created on the MESS forums to help people understand MESS to the point of being able to install an actual operating system inside an emulated PC in MESS. While doing this isn’t very practical for performance reasons it is important people realise that both MESS and UME can make use of far more advanced features of the MAME framework than MAME alone, and show how some of them are used. Now none of this would be possible without the underlying improvements to the PC emulation which have been ongoing for some time now, but the two really go hand in hand and one of the motivating factors for the project(s) is curiosity, and that desire to do things just because they can be done. There is another amusing thread of screenshots of the MESS forums taken from within MESS again showing that you can squeeze a lot of entertainment out of the projects beyond the obvious ones.
Let’s look at some more of the clone additions in MESS too. You’ll see that there has been a steady flow of Megatouch clones for the older Megatouch units showing up for a while now (most of the newer ones are PC based I believe, although I don’t know if anybody has looked at them recently after all the work done on the PC drivers)
Pit Boss Megatouch II (9255-10-01 ROG, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROK, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROB, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROA, Standard version) [Brian Troha, The Dumping Union]
Super Megatouch IV (9255-41-01 ROE, Standard version) [Brian Troha, The Dumping Union]
Super Megatouch IV (9255-41-01 ROC, Standard version) [Brian Troha, The Dumping Union]
is the whatsnew listing for Megatouch clones this time around. A question was put forward on the Mameworld board asking what the difference was between the various Megatouch clones, and ‘anoid’ put the following information forward about Megatouch III
9255-20-01 - Standard Version - Includes all options and no restrictions
9255-20-02 - Minnesota Version - Excludes Casino Games
9255-20-03 - Louisiana Version - Excludes All Poker Games
9255-20-04 - Wisconsin Version - Game cannot end if player busts; 1000 points are added to end of each hand
9255-20-06 - California Version - Excludes Poker Double-Up feature and no free game in solitaire
9255-20-07 - New Jersey Version - Excludes sex trivia and includes 2-coin limit with lockout coil
9255-20-50 - Bi-lingual ENG/GER - Same as standard version, without word games
9255-20-54 - Bi-lingual ENG/SPA - Same as standard version, without work games
9255-20-56 - No Free Credits - Same as standard version, without word games and no free credits
9255-20-57 - International - Same as standard version, without word games
Most of that doesn’t really apply here, because all these are ‘Standard versions’ ie the most complete ones so it’s possible (likely?) the ROx codes are just revision numbers, and used to indicate bug fixes etc. The information provided is interesting however because of the restrictions present in some of the other versions. Things like ‘no word games’ are obvious, the word games are going to be heavily Americanized, and unsuitable for regions not using a US-English dictionary. The rest are more complex, clearly indicating that some regions consider the standard version of the games to fall foul of gambling laws, even if the majority of people would not consider these to be gambling games. Rules such as “Game cannot end if player busts; 1000 points are added to end of each hand” would appear to be tailored around very specifically worded legislation!
While on the subject of gambling, the Data East hardware ‘Dream Ball’ (as featured in a previous update) is also included.
(Dream Ball is supported)
A bunch of new clones were added to the Igrosoft Multifish driver by MetalliC too, including the final game released on that platform ‘Crazy Monkey 2’ but the graphic roms and palette have some unhandled address line swapping on that one, so while you can initialize it like any other it currently only plays ‘blind’
The new Head On set is also an interesting clone because it uses a different maze to any of the other sets. ANY dumped this one, and I added support for it, bypassing what seems like it might be a trivial protection check on startup. It’s since been revealed that there was a much older dump of the same set, also from Italy, and that it should run on the Sidam boardset for the game (which lacks a Colour PROM, so chances are it should also be black & white) I guess this must have been a relatively common version of the game in Italy?
(This odd Italian clone of Head On features a different maze to the usual version)
ShouTime also continued the run of tracking down important clones and thus we can say the World version of Starblade is supported now as well. Visually it looks identical to the Japan one, sans the warning at startup, so there isn’t really anything to show or write about for it other than this quick mention, but by having a World version confirmed and supported the documentation value of MAME is enhanced because it confirms the game was released outside of Japan, and that a specific version was made for that.
In MESS, R.Belmont along with some others continued to add support for the various Apple II expansion cards, the Street Electronics Echo Plus, Zip Technologies ZipDrive and Apple II Rev. C SCSI Cards. The first of those is apparently a speech board, with the others being more self-explanatory.
Numerous other fixes were made across both projects, a couple you’re unlikely to really even notice the difference from unless you’re intimately familiar with the games in question, but nevertheless important fixes. An example of this is the fix made to the Deniam Logic Pro 2 sound banking, apparently just one sample differs between the banks and the error / missing banking had gone unnoticed for years.
Wrapping things up, Kale put in an early driver for the Casio FP-200 and you can already enter basic programs (make sure to RESET the memory first tho by typing RESET)
(The Casio FP200 had a small screen built into the keyboard unit)
As you can see, a lot of the progress again comes from the MESS side of things, and that’s even with me having worked flat out on MAME stuff for the past 2 months but there really isn’t much else to write about in terms of visible progress that I haven’t covered. There are definitely a few more interesting bit and pieces in the pipeline from other devs, but quite when they’ll hit nobody knows (Phil’s progress on Turret Tower still hasn’t been submitted for example, and the possibility of being able to submit another driver I worked on jointly with him but we’ve had to keep private for the past 3 years is increasing, so I’m crossing my fingers over that)
Please stress a bit more that 20% of performance hit in SNES only happens for DSP games (which are around 20 games over several hundreds games for the console, around 50 counting clones).
Games with no additional chips work at the same speed as before if not slightly faster. E.g. on my macbook core 2 duo @ 2.66GHz, -str 50 -nothrottle gives consistent positive benchmarks (smw 190% -> 193%, zelda3 205% -> 211%, tophant 220% -> 223%) even if they could just be fluctuations due to idle activities
anyway no meaningful impact as your article seems to imply ;)
>You’re probably sick of seeing Cool Riders by >now
No, I’m not… it’s actually pretty exciting.
ah, I thought it was kinda implied I meant the DSP games when I said “some of the SNES titles for which performance was already worrying” because it was OK for the rest of them anyway.
I’ll make the comment more explicit when I resume updating the article (writing such an article requires me to actually run the things and explore the changes, so is rather time consuming)
I know, and I seriously appreciate the effort :)
I was the first one who mentioned a possible slow down, because the snesnew driver was indeed slightly slower than the old code for most games. but when I merged the to drivers starting to install the memory handlers at start, we got back the original performance (with possible minor 3-5% fluctuations depending on specific situations)… except for DSP which slowed down a lot
later this week I plan to dig further into the code to hopefully find where the issue can be…
For mame everything you write here is “I..” “Kale..”
Is you and Kale the only Mame programmers left or are the rest lazy wastes of space?
Please be patient, the article isn’t finished yet, I’m still in the middle of writing it right now.
Obviously I’m going to start by mentioning things I’m most familiar with, and having worked on many of these things with Kale they provide an easy start for the article before I flesh it out.
Amazing piece of article as usual Haze!
I know it is quite time-consuming, but please don’t stop writing these
Yeah, just trying to not miss anything major. There are some more GB games eta made work for example, but in every case there was already a hacked dump of it running, so good progress, but less exciting. Then there are systems I don’t know much about so need to do some research.
It serves a purpose another purpose too, it ensures what we claim to be new / working / have worked on over the course of the update cycle gets at least one run-out so even if it is time consuming it’s worth it for that aspect too. As you can probably gather from the article in general I am a little concerned about some stability issues at present.
Following up on the other comment, upon further review there really isn’t much more for MAME this time around
-deniam.c: Fixed OKI sound banking in Logic Pro 2 and removed
IMPERFECT_SOUND flag. [Lord Nightmare]
from whatsnew_0148u2.txt is a nice fix if you like that game, but I don’t think a single person ever even reported it as wrong ;-)
there are some semi-interesting clones, but I added at least one of those too, heh.
the rest is mostly important, but small and invisible work (no difference made to the end result) and a lot of the mame whatsnew is just work on shared parts that benefit Mess more than Mame. There are regression fixes too, but I don’t like to promote those too much because we should be trying our best not to break things in the first place ;-)
I had a feeling a lot of the more significant work in this MAME update would be what I’ve been worked on with Kale, but I did think there was more to write about outside of that, so sorry if I got any hopes up there about things I might have missed.
The devs have been very busy with MESS related work however, and most of the current Mamedevs are Messdevs so I still wouldn’t call them lazy!
There’s also stuff going on “under the surface” which will eventually result in some pretty splashy features. The currently MESS-centric Ethernet progress sounds much more exciting when you consider that many of the mid-90s Midway/Atari racing games have an Ethernet port for networking.
Similarly, the debugger switch for non-Mac SDL builds sounds like inside nerdball, but it boosts the productivity of developers using those builds (always important). But more to my point, it’s serving as a case study for supplementing much of MAME’s fussy and difficult on-screen user interface with a VICE-like second window where you can perform all the Tab menu tasks in GUI comfort.
I’m strongly considering submitting a version of SailorSat’s Sega Model 1 networking patch as well, I’m just not sure how people would react (well, I know users would be pretty happy, of course).
concerning the work on pirate mappers, another point is that after converting carts to use slot devices adding support for these pirate carts becomes really easy. It basically reduces to creating few lines of new codes, and hence it makes them an easy target when I have no time for longer development efforts.
with previous (non-slot) implementations, for instance, bankswitch variations had to be either taken care at loading time, or you had to install as a separate handler the code to deal with rom accesses (to cope with the specific IO expected by the cart). and then these handlers had to be only installed if the specific cart was loaded, without interfering with the others, so you had to (sometimes heavily) modify the cart loading code to handle these properly.
and with snes, things were made even more difficult by the fact that ROM mirroring was implemented by loading at start the data in all required locations, making any IO change very difficult without interfering with mirrors
with the slot code, after the initial burden to create the general handlers that *all* carts will use (based on the memory ranges that the real system exposes to the carts), then adding a new pirate mapper just requires to modify the specific handler required by the new cart type, and to add a corresponding subclass in the code. most of the support is just inherited by the general carts.
About Cool Riders, it crashes mame64 with a “Floating exception” error as soon as you press 1 player. I’m using SDLMAME on OSX.
Right, the same way that after the initial hookup it became almost trivial to emulate new ISA/NuBus/Apple II cards. (And PCI in the near future).
‘Floating exception’ sounds like an odd one, the timing (pressing start) even more so. I’ll certainly need a backtrace or more information to debug that one because in terms of the emulation nothing special happens at that point at all..
Haze, Cool Riders crashes at the end of intro sequence too where the road comes up even before adding coins or trying to start the game. Hope this helps:
Crashed Thread: 5
Exception Type: EXC_ARITHMETIC (SIGFPE)
Exception Codes: EXC_I386_DIV (divide by zero)
Thread 0:: Dispatch queue: com.apple.main-thread
0 mame64 0x000000010e5e5df1 copybitmap(bitmap_ind16&, bitmap_ind16&, int, int, int, int, rectangle const&) + 609
1 mame64 0x000000010d392890 coolridr_state::sysh1_fb_data_w(address_space&, unsigned int, unsigned int, unsigned int) + 584
2 ??? 0x00000001273d63b9 0 + 4953301945
Thread 1:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8fc55d16 kevent + 10
1 libdispatch.dylib 0x00007fff87559dea _dispatch_mgr_invoke + 883
2 libdispatch.dylib 0x00007fff875599ee _dispatch_mgr_thread + 54
Thread 2:
0 libsystem_kernel.dylib 0x00007fff8fc53686 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8fc52c42 mach_msg + 70
2 com.apple.audio.midi.CoreMIDI 0x0000000118f82970 XServerMachPort::ReceiveMessage(int&, void*, int&) + 96
3 com.apple.audio.midi.CoreMIDI 0x0000000118f9eb23 MIDIProcess::RunMIDIInThread() + 243
4 com.apple.audio.midi.CoreMIDI 0x0000000118f83c2c XThread::RunHelper(void*) + 10
5 com.apple.audio.midi.CoreMIDI 0x0000000118f8380f CAPThread::Entry(CAPThread*) + 175
6 libsystem_c.dylib 0x00007fff883077a2 _pthread_start + 327
7 libsystem_c.dylib 0x00007fff882f41e1 thread_start + 13
Thread 3:
0 libsystem_kernel.dylib 0x00007fff8fc55386 __semwait_signal + 10
1 libsystem_c.dylib 0x00007fff88391800 nanosleep + 163
2 SDL 0x000000011901aaa6 SDL_Delay + 92
3 SDL 0x000000011901ab1f 0x118fec000 + 191263
4 SDL 0x000000011900f31a 0x118fec000 + 144154
5 SDL 0x000000011901a967 0x118fec000 + 190823
6 libsystem_c.dylib 0x00007fff883077a2 _pthread_start + 327
7 libsystem_c.dylib 0x00007fff882f41e1 thread_start + 13
Thread 4:: com.apple.audio.IOThread.client
0 libsystem_kernel.dylib 0x00007fff8fc53686 mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8fc52c42 mach_msg + 70
2 com.apple.audio.CoreAudio 0x00007fff8fba6f98 HALB_MachPort::SendMessageWithReply(unsigned int, unsigned int, unsigned int, unsigned int, mach_msg_header_t*, bool, unsigned int) + 98
3 com.apple.audio.CoreAudio 0x00007fff8fba6f26 HALB_MachPort::SendSimpleMessageWithSimpleReply(unsigned int, unsigned int, int, int&, bool, unsigned int) + 42
4 com.apple.audio.CoreAudio 0x00007fff8fba56f9 HALC_ProxyIOContext::IOWorkLoop() + 1209
5 com.apple.audio.CoreAudio 0x00007fff8fba51a1 HALC_ProxyIOContext::IOThreadEntry(void*) + 83
6 com.apple.audio.CoreAudio 0x00007fff8fba5069 HALB_IOThread::Entry(void*) + 75
7 libsystem_c.dylib 0x00007fff883077a2 _pthread_start + 327
8 libsystem_c.dylib 0x00007fff882f41e1 thread_start + 13
Thread 5 Crashed:
0 mame64 0x000000010d393b33 coolridr_state::draw_object_threaded(void*, int) + 1791
1 mame64 0x000000010ead9c5d worker_thread_process(osd_work_queue*, work_thread_info*) + 125
2 mame64 0x000000010eada49b worker_thread_entry(void*) + 187
3 libsystem_c.dylib 0x00007fff883077a2 _pthread_start + 327
4 libsystem_c.dylib 0x00007fff882f41e1 thread_start + 13
Thread 6:
0 libsystem_kernel.dylib 0x00007fff8fc550fa __psynch_cvwait + 10
1 libsystem_c.dylib 0x00007fff8830bfe9 _pthread_cond_wait + 869
2 mame64 0x000000010ead98c6 osd_event_wait(osd_event*, unsigned long long) + 246
3 mame64 0x000000010eada46f worker_thread_entry(void*) + 143
4 libsystem_c.dylib 0x00007fff883077a2 _pthread_start + 327
5 libsystem_c.dylib 0x00007fff882f41e1 thread_start + 13
Thread 7:
0 libsystem_kernel.dylib 0x00007fff8fc556d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff88309f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff88309d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff882f41d1 start_wqthread + 13
Thread 8:
0 libsystem_kernel.dylib 0x00007fff8fc556d6 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff88309f4c _pthread_workq_return + 25
2 libsystem_c.dylib 0x00007fff88309d13 _pthread_wqthread + 412
3 libsystem_c.dylib 0x00007fff882f41d1 start_wqthread + 13
Thread 5 crashed with X86 Thread State (64-bit):
rax: 0x0000000008000000 rbx: 0x00007fd690206450 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x00007fd68e403580 rsi: 0x0000000000000000 rbp: 0x0000000126cffea0 rsp: 0x0000000126cffd10
r8: 0x0000000000000006 r9: 0x00000000fbdfcd12 r10: 0x0000000000000000 r11: 0x00000000fbdfcd12
r12: 0x00007fd68c010e00 r13: 0x00008a8868ee9506 r14: 0x0000000000000000 r15: 0x00007fd690206458
rip: 0x000000010d393b33 rfl: 0x0000000000010246 cr2: 0x00000001027c2868
Logical CPU: 4
It would suggest that it crashes on the indirect line sprites then, interesting.
there’s definitely no divide by zero happening in there on Windows, and looking at the code any divides being done with a variable value have explicit bail outs earlier for a div0 condition. (I have “if (!hZoomHere) { drawy++; continue; }”)
for the case of no vZoom I also bail early, likewise I have an early out on hZoom for regular cases too.
I wonder if the compiler is screwing it up.
I can’t rule out a bug, but I’d be interested to see if you can get a more complete backtrace (something like bt full on windows) because it shouldn’t be able to reach the suggested crash scenario.
You could try turning the threading off quickly (tab menu -> game configuration -> use threading) then quit the emulator and restart…
It dies in a YXLOOP_NO_ZOOM.
OPTIMIZE=0 it runs fine (slowly).
OPTIMIZE=1 it crashes but the variables are optimized out to the point where between that and the heavy use of macros it’s basically impossible to debug.
That’s odd
YXLOOP_NO_ZOOM is the most basic case, where there is no zooming applied at all, and thus no divisions at all..
you could change
if ((hZoom==0x40) && (vZoom==0x40))
to
if (0) to force it through the ZOOMED path instead…
Just curious do you guys use things like boundschecker or valgrind? It is amazing what those two tools will find. Between those two they always find bugs in code I considered ‘solid’.
@Haze: if you would end up seeing this,
http://mamedev.emulab.it/etabeta/fast/files/0000_455523850.png
where would you search for the problem? the same code I use in md_svp.c can be copied in megasvp.c (up to adding the megasvp *state) and it just works albeit slowly, so I’m a bit puzzled about where the problem is…
eta> it’s probably the DMA thing. SVP (and SegaCD) cause bus contention issues with the VDP dma, see
UINT16 vdp_get_word_from_68k_mem_default(running_machine &machine, UINT32 source, address_space & space68k)
{
….
if ( source <= 0x3fffff )
{
if (_svp_cpu != NULL)
{
source -= 2; // the SVP introduces some kind of DMA 'lag', which we have to compensate for, this is obvious even on gfx DMAd from ROM (the Speedometer)
}
I'd guess that's your issue? you're no longer doing that?
that’s probably the deal. I’m going to check in a few minutes…
I knew you were the right person to ask ;)
oh yeah!
http://mamedev.emulab.it/etabeta/fast/files/0001_705481601.png
now I have to optimize a bit the code, because it suffers of part of the DSP-syndrome (even if not that bad, apparently…)
me>
some of the linux guys make use of valgrind / similar tools, and they have been useful in tracking down some issues.
a lot of the work on fixing up cases where there were uninitialized variables are a result of such tools being used, although we still have some drivers where what should be deterministic behavior isn’t so and record/playback fail and even those aren’t throwing up anything.
with Cool Riders it’s really looking like the compiler optimizations are breaking something, RB mentions it seems to be consistently failing (with divide by zero) on what should be a subtract operation but of course because it doesn’t crash with optimizations off it’s messy. The bug only shows up on certain versions of OSX with that compiler, and I was quite careful to make the code safe, so it did surprise me.
I guess it’s possible something else is wrong, and it’s just showing up in a strange way.
I know SH2 DRC won’t run at all for me (any drivers) in a 64-bit Windows Symbols+Map+Debug build (but doesn’t give a decent trace upon crashing) so there is something a bit dodgy about the code there, and I know when developing the driver even normally I had MAME crash out with ‘an unable to find object (anonymous)’ on startup once or twice (before even giving the disclaimer screens) which was a bit weird. GDB isn’t catching anything tho.
Ok, the crash would appear to be a compiler screwup, yes.. Phil B managed to track it down (guess he was affected)
http://forums.bannister.org//ubbthreads.php?ubb=showflat&Number=87093&#Post87093
for the record, the megaduck softlist had been attached to the driver for years (e.g. it was working in 0.148).
it got lost during the slot-ification due to a copy and paste mistake at my end, that judge spot and fix
Ah .. I was wondering, it seemed like an odd thing to just not have hooked up. The checkin could have made it clearer that it was a regression fix ;-)
Earlier version is published every two weeks. Why now comes out once a month?
for the record, I got improved DSP speed in latest svn
0.148u1
“mess snes -cart smkartj -str 50 -nothrottle” = Average speed: 145.67% (49 seconds)
“mess snes -cart pilotwinu -str 50 -nothrottle” = Average speed: 166.57% (49 seconds)
0.148u2
“mess snes -cart smkartj -str 50 -nothrottle” = Average speed: 108.51% (49 seconds)
“mess snes -cart pilotwinu -str 50 -nothrottle” = Average speed: 110.41% (49 seconds)
rev. 22026
“mess snes -cart smkartj -str 50 -nothrottle” = Average speed: 139.69% (49 seconds)
“mess snes -cart pilotwinu -str 50 -nothrottle” = Average speed: 158.55% (49 seconds)
(fwiw, the slowdown was due to read handlers switching bytes at each access before reading them, which is too slow… it’s definitely better to switch them only once at start and then to access them directly in the address space)
The Echo Plus was a combination speech/AY-3-8910 sound card. The others are indeed self-explanatory :)
The analogous improvement done for Virtua Racing MD in rev. 22024 produced a jump from 99%-102% to 167%-175% in the slot-ified SVP
still not the 185%-190% of gensvp, but I think we can safely pass to the new code now, while I search a way to get back some other bits of speed in this too
the 1 month u cycle seems to be what the current team coordinator Micko has decided on.
there probably isn’t enough work being done to warrant an update every 2 weeks at the moment, see previous comment made here about most visible work in MAME being done by kale+me, and for my contributions that’s only because I’ve been working on MAME flat out for the past 2 months (practically all day every day) which isn’t sustainable. I’m already having to take a post u2 break to prevent any burnout so u3 will mostly depend on other people (I know Phil still has some cool stuff to submit like Turret Tower, so hopefully we’re good)
also people have direct access to the official svn now etc. anyway so if they REALLY want to check out the latest changes they can always grab that, the u releases just provide an official sync point.
KONG- Taito do Brasil – Original video- PROM COLOR original.
Hello, Haze
Sorry, I wonder if this emulator can run the game from KONG- Taito Brazil
Watch the video PCB functioning
https://www.youtube.com/watch?v=ArK18niMGag&feature=youtube_gdata_player
well a dump of the PROM would help…
ah I see, Smitdogg just forwarded me the dump
Etabeta, a couple of hopefully quick fixes that could really help.. as others have said, NES badly needs save state support for obvious reasons; and there are softlists like 3do_m2 that for some reason aren’t hooked up but have been around for a long time. Is there any way to at least look into these further before .149? I’m guessing they wouldn’t take too much time and might work well with your schedule of not having time for longer development efforts.
So is Taito Brazil *really* Taito Brazil or just a bootlegger with a clever name?
@Stojan
I would not count on it if I were you. Guru will not dump Wyvern F-0 even if he gets $3000 or $6000 in donations he won’t dump it. He does not even care about dumping roms for MAME anymore. He just cares about money and politics so he can use that to wipe his ass with to get his debt paid off. Better off look for another one. Guru got himself banned from mameworld and he deserved it for being a stupid dumbfuck.