- 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
