Please, no mention in the whatsnew
adds and documents all known sets (3 years or old).
Warning: Some sets have the version hacked to show sets "newer" then 3 years old. But these have been verfied to be older sets. There is also a note in the driver about version changes being made to make the opperator look like they are running a version that meets the standard of law change in 2007
- fix some "const" weirdness I introduced
- fix VREF in CRFILTER_VREF and RCFILTER_VREF. VREF never got used since it was only a static parameter.
- Removed enable from CR_FILTER* and RC_FILTER*
- Updated drivers accordingly.
- Use EXPECTED/UNEXPECTED to help the compiler
Grouped known "Artic Multi-System" games together and added a little note about it.
Corrected some rom names for Artic MS games. IE: The only label chips as "1" through 'x' Also changed the name of the color proms to show bprom type and board location
New Game Added
-----------------------------
Phoenix Part 2 [Andy Welburn, Dumping Union]
New Clone Added
------------------------------
Battle of Atlantis (bootleg) [David Heywood, Dumping Union]
Comments: The imported settings from galaxian were not matching up and a new set of game specific coinage setting were needed to match behavior in-game.
prom comes from an archive of a bootleg game Phoenix Part 2 (on Artic Multi-System (Galaxian hardware)). Statement in the readme says "the colour prom that was on the pcb that the rom daughtercard was in, actually matches 'Omega' (a 'the end' hack)."
So it I added it to the rom def.
Sent: Wednesday, September 30, 2009 2:43 PM
To: Aaron Giles
Cc: Klaus Sommer
Subject: Re: Unknown dump (galaxian hardware)
I'll leave this one up to Aaron to decide if it's worth including
anyway. I've attached the diff for you. Note, the current emulation of
this pacmanbl set doesn't seem to work properly at the moment anyway
(since the galaxian rewrite), the sprites are offset and vanish at the
top of the screen.
David Haywood wrote:
> It's a pacman bootleg, the content is identical to the pacmanbl set in
> MAME, although the order of the data in the roms is different. I'm
> not sure it will be supported.
>
> Klaus Sommer wrote:
>> hi!
>>
>> attached are the dumps of an unknown board (looks like galaxian
>> hardware)...i think an bprom is missing, but i'm not sure which one
>> it is!
>>
> From: David Haywood [mailto:neohaze@nildram.co.uk]
> Sent: Saturday, October 03, 2009 9:52 AM
> Cc: Aaron Giles
> Subject: Re: Fw: [The Dumping Union] Unknown Board from SETA
>
> Actually the gfx decode better as 8bpp.
>
> David Haywood wrote:
> > I haven't had much luck in getting this to do anything useful yet.
> >
> > This does however get the rom loading / gfx decoding out of the way
> >
> > new not working
> > -----------------
> >
> > Seta Roulette? [Team Europe]
> >
> > If anybody know what this ACTUALLY is (it might be by Visco, but it's
> > on Seta hardware) I'd be interested in knowing. The graphics look
> > roulette-like, but I see no title screen in the roms, so assuming the
> > dump is good, it probably doesn't have one.
> >
> > Klaus Sommer wrote:
> >> hi!
> >>
> >> i'm not sure if your email is included in the "dumping union" so i
> >> forward you this email, which i wrote today!
> >> maybe you are interested in this roms!
> >>
> >> Klaus
> >>
full release so we don't have a giant spacing diff.
--
> -----Original Message-----
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Thursday, October 01, 2009 8:13 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] srcclean perf, stye improvements
>
> Hi mamedev,
>
> srcclean.exe has a minor performance bug with it tab removing
> algorithm, in that the cost of removing n tabs is O(n^2). The first
> patch fixes this by always tracking the current column. The second
> patch then implements a new clean idiom, that spaces before tabs that
> are "invisible" should be removed. This change finds ~14k invisible
> spaces in MAME, so I suspect there may be some hesitation to adopt it.
>
> ~aa
--
> From: David Haywood [mailto:neohaze@nildram.co.uk]
> Sent: Tuesday, September 29, 2009 6:55 AM
> To: Aaron Giles; Klaus Sommer, B.Sc
> Subject: Re: Astro Blaster (German) Romset
>
> I've added a note by that rom in 'version 1', it should be checked at
> least. With the u25 supplied the german set works.
>
> new clones
> ------------
>
> Astro Blaster (German) [Volker Hann & Team Europe]
>
> Sommer wrote:
> > hi!
> >
> > attached is the new dumped u25 rom....it's the same as in all other
> romsets!
> >
> > could it be that the u25 dump from "version 1" is bad...and if you
> replace it with an u25 from another dump that it will work?
> >
> > regards,
> > klaus
- DISCRETE_TASK_START now requires a parameter TASK_GROUP (>=0, <=9)
- Tasks are scheduled in the order of their task group
- Nodes are automatically buffered between task groups
- Discrete core determines nodes which need buffering to minimize overhead (information in DISCRETE_LOG)
- A discrete block list now must put each stepped node into a task if it uses tasks
- Drivers not using tasks will get one task allocated automatically
- Updated drivers accordingly
- Some more constification
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Wednesday, September 30, 2009 7:56 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] More static qualifiers
>
> Hi mamedev,
>
> This patch makes more of MAME static, primarily targeting functions
> exported by header files that are in fact unused outside their own
> file, and the chip emulators in machine/snes.c. It also degenericizes
> some exported names in archimds, bublbobl, and lucky74.
>
> ~aa
- preparation work so that a task node output buffer may be read by
more than one following task.
- target: implementation of task groups: tasks in a task group run parallel, task groups serial. The current main task may than just be task (in the last task group)
Sent: Thursday, October 01, 2009 5:25 AM
To: Aaron Giles
Subject: MD update
I'm trying to get the HazeMD code running again (by request, and so
that
I can look at fixing some of the bugs that have surfaced, including
ones
which affect MAME)
This shuffles a bunch of stuff around in order to help with that
process, I've also killed off some old megaplay code which wasn't
really
needed anymore, and used the newer code instead.
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Sunday, September 27, 2009 7:58 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] More _NAME macros
>
> Hi mamedev,
>
> MAME's idiom for function/data macros is to first implement
> <name>_NAME, then implement the other macros in terms of the _NAME
> macro. Then in principle only a single line needs editing to change
> the naming convention.
>
> This patchset implements this idiom more completely. The first patch
> adds some missing _NAME macros and fixes cases in source files that
> should be using the macros. The second patch then changes header
> files where the macros should have been used, but weren't. This
> required changing the idiom for removing a machine driver function
> pointer from MDRV_<FUNCTION>(NULL) to MDRV_<FUNCTION>(0), to avoid
> problems with NULL being macro expanded. This actually unifies the
> handling of all such cases, as we already had ipt_0 and driver_init_0.
> It also required reworking the devtempl.h implementation in a way that
> triggered a warning on MSVC about using empty macros, so vconv.c
> needed to be updated. The third patch then renames all the _NAME and
> _0 macros to verify that all the cases have been covered, so it isn't
> intended to be applied.
>
> ~aa
> Sent: Sunday, September 27, 2009 5:45 AM
> To: submit@mamedev.org
> Subject: Increase the number of PROFILER_USERx slots when profiling
>
> Hi,
>
> sometimes, when I profile a game in order to see what is the most time
> consuming part of its emulation, the 4 PROFILER_USERx are just not
> enough.
> The attached patch increases this number to 8 in order to give more
> flexibility.
>
> It also removes the now unused and obsolete PROFILER_END constant in
> order
> to be sure that 'profiler_mark_start' will never be called with it
>
> Hope this help.
> Best regards,
>
> CJ
Sent: Friday, September 25, 2009 12:15 PM
To: Aaron Giles
Subject: 360 pad crash
This 'fixes' the bug where MAME crashes and corrupts your config files
if you connect a pad at runtime. Previously there was an assert, now it
simply doesn't execute that block of code if devcode is null.
I don't know if this is the best fix (it would probably be quite nice if
it could detect pads being added removed at runtime and adapt to that)
but at least it stops it crashing and corrupting files.
> Sent: Wednesday, September 30, 2009 4:05 AM
> To: submit@mamedev.org
> Subject: Cheat
>
> I have added a simple system for auto-detect the ram region for make
> more fast the cheatinit. But I have a problem on some address
> translation, for example in seattle.c the ram region have a physical
> address of 0x00000000 - 0x007fffff and the logical address is
> 0x80000000 - 0x807fffff, I not have found a way for convert the
> physical
> address to the logical address. For now the only way for initialize the
> cheat on seattle.c is force the address to the right range ("ci ub,
> 0x80000000, 0x7fffff") but is not a good solution.
> I hope can help me to fix this problem.
>
> Regards
>
> Sandro Ronco
Fixed the logical/physical issue by having the cheat system always
work at the physical layer and output cheats that explicitly point
to the physical space.
by prepending with an 'l' or 'p'. Logical remains the default. Example:
ppb@1000 = physical program space byte at address $1000. ldw@2000 =
logical data space word at address $2000.
New games added or promoted from NOT_WORKING status
---------------------------------------------------
Othello (version 3.0) [Tomasz Slanina, Stefan Lindberg]
------------------------------------
48-in-1 MAME bootleg (ver 3.09) [Guru]
48-in-1 MAME bootleg (ver 3.02) [Guru]
I lost the decrypt for these in an inbox cleaning accident, but even with
that out of the way the protection is much heavier than 39in1's so they're
not really worth the effort.
Credit: MetalliC
MAMETesters bug ID 03403 "Can't init Roll Fruit game."
Hooked up inputs for Roll Fruit
Added hopper emulation, payout now works
Added information on how to initialize Roll Fruit
Added in missing rom to a few MultiFish sets
----------------
Street Fighter II - The World Warrior (Quicken Pt-I, bootleg) [D. Beneke, Guru, Smitdogg, The Dumping Union]
Street Fighter II' - Champion Edition (Accelerator!, bootleg) [D. Beneke, Guru, Smitdogg, The Dumping Union]
