palette.c to preserve the alpha when transforming palette values.
These changes should be transparent to almost all drivers and rendering
(ha-ha), but there may be an occasional instance where a driver relied
on the alpha being 0 in the system palette. This also means that the
palette_set_color() function preserves any alpha value that is set.
Changed Firefox to RGB32 to allow for mid-screen palette changes. Because
of the above change, the hacky alpha manipulation that was previously
required is no longer necessary; the alpha is set directly in the palette
entry.
(Guru, can you check that ms5pcb you have, the roms in MAME are now marked as NO DUMP)
Updated Neo-Geo game pcb infos
2020bba: Marked MVS and AES version
sonicwi2: Added correct sized v2
kof95 / kof95a:
. Renamed kof95 to kof95h
. Renamed p1 to correct chip label
. Added note
. Renamed kof95a to kof95
. Renamed p1
samsho3 / samsho3a:
. Renamed samsho3a to samsho3
. Renamed samsho3 to samsho3h
. Renamed p1 to correct chip label
. Marked AES version
kof98 / kof98n:
. Renamed m1 in kof98 to correct chip label
. Renamed m1 in kof98n to correct chip label
(kof98n should be latest revision, cart had very high SN 1xx.xxx)
kof97: Marked MVS version
samsho5 / samsho5h:
. Correct text layer size
. Marked samsho5h AES version
neogeo:
. Updated system set to what is found on NEO-MVH MV1FS
. Added note
ms5pcb:
. Hooked up bios dip
. Renamed bios to correct chip label
. Renamed p1 / p2 to correct chip label, marked NO_DUMP
. Added note
compared to other emulator (i.e. kawak), mame does not perform very well in
terms of speed of emulation against Neo Geo games.
Looking at profiling data for these neo geo games, we can see :
---------------------------------------------------------
% cumulative self self total
time seconds seconds calls s/call s/call name
18.40 18.80 18.80 971070 0.00 0.00 video_update_neogeo
10.42 29.45 10.65 4416 0.00 0.00 texture_set_data
10.06 39.73 10.28 1144463 0.00 0.00
sprite_line_timer_callback
6.24 46.10 6.37 187970965 0.00 0.00 astring_cmpc
3.77 49.95 3.85 35732143 0.00 0.00 memory_region
---------------------------------------------------------
I was wondering why functions like 'astring_cmpc' and 'memory_region' where
in the top 5 of the most time consuming functions.
The answer is found in the function 'draw_sprites' from
'mame/video/neogeo.c' where 'memory_region' is called for each sprites for
each VIDEO_UPDATE.
I patched mame in order to keep track of this 'memory_region'. This is done
in VIDEO_START via a global variable (region_zoomy) just like in some other
drivers.
Sent: Thursday, September 25, 2008 3:15 AM
To: submit@mamedev.org
Subject: using macros in UI message
This patch changes the message, that appears when no roms have been
found, to use the macros instead of hard-coded strings
Sent: Wed 9/24/2008 2:00 PM
To: submit@mamedev.org
Subject: Speed up fillbitmap
Hi,
there are many places in mame which make use of "fill_bitmap" or the
equivalent "fillbitmap"
An optimisation is done when the depth of the bitmap is 16 or 32 bpp and
when the UINT16 or UINT32 corresponding to the color is composed of same
bytes (i.e 0xffff for example). This is usefull because most of the calls
are for color 0 (black).
In all other cases, the bitmap is filled one pixel at a time using a loop
with a code like :
================
for (y = fill.min_y; y <= fill.max_y; y++)
{
UINT16 *destrow = BITMAP_ADDR16(dest, y, 0);
for (x = fill.min_x; x <= fill.max_x; x++)
destrow[x] = (UINT16)color;
}
================
However, each rows of the final bitmap will be the same. So I modified this
simple assigned to work as follow :
1) fill the first row one pixel at a time
2) fill all the other rows by copying the first one.
This makes us use memcpy instead of a hard coded loop for most of the
filling process.
Sent: Tue 9/23/2008 1:16 PM
To: submit@mamedev.org
Subject: More naomi ...
Hi.
This patch shows the contents of the framebuffer if the 3d accelerator is
not used so that now the atomiswave logo and messages are shown (if you
wait enough).
Removes a maple bug (no more strange messages in cvs2gd).
Improves documentation of the communication registers with the dimm board.
And if DEBUG_VERTICES is defined as 1 the vertices sent to the tile
accelerator are collected and then drawn connected by a segment to give a
wireframe-like view of the scene.
Bye,
Samuele Zannoli
Sent: Tuesday, September 23, 2008 4:46 AM
To: Aaron Giles
Subject: 8080 bug
To fix this bug : http://mametesters.org/mantis/view.php?id=2322
a part of my code should be removed.
It seams that this feature I have added is only available on KP580BM80A (Russian clone of this processor).
So until I make a new patch (that support this clone processor) please apply this to fix MAME drivers.
Thanks,
Miodrag
Sent: Mon 9/22/2008 3:15 PM
To: submit@mamedev.org
Subject: Better Input clean in system1
I've re-made the job better than last time (i hope), clean up the inputs in system1, next time i'll fix all dips location.
Bye Sonikos.
Sent: Sunday, September 21, 2008 10:45 AM
To: submit@mamedev.org
Cc: atariace@hotmail.com
Subject: [patch] More static qualifiers
Hi mamedev,
Another static function update from yours truly, almost entirely
affecting code added in the last few months to MAME. The fixes are
the usual lot, changing enum definitions so they aren't declared,
decorating dead code/declarations with #if...#endif, and of course,
adding static where appropriate. In addition, I fixed a bunch of
UNUSED_FUNCTON symbols to be spelled correctly (I didn't introduce
this).
~aa
Sent: Thursday, September 18, 2008 6:01 AM
To: submit@mamedev.org
Subject: fix for MT 2252
1 line fix (silly mistake that I was sure I had fixed BEFORE sending the patch) :(
Regards,
Fabio
---
From: Fabio Priuli [mailto:doge.fabio@gmail.com]
Sent: Friday, September 19, 2008 1:15 AM
To: submit@mamedev.org
Subject: Fix for MT 2258
Regressed in 126u3 due to a wrong tag. Fixed.
Fabio
---
enclosed please find a patch which makes non-static two pointers to i/o handlers and includes them in megadriv.h. This makes possible for external drivers (in particular MESS genesis emulation) to define elsewhere their own input handlers and to feed them to the megadriv.c routines.
---
From: Fabio Priuli [mailto:doge.fabio@gmail.com]
Sent: Mon 9/22/2008 2:15 PM
To: submit@mamedev.org
Subject: fix for MT 2254
Hi,
enclosed please find a patch which fixes bug 2254. Tags were switched. Thanks to Haze for noticing the root of the problem.
Regards,
Fabio
fine and basic searching/playback/skipping is functional. Still a bit
glitchy.
Firefox improvements:
- removed need for deprecat.h
- memory map is complete from schematics
- gutted laserdisc hacks in favor of actual laserdisc implementation
- fixed all CPU and sound clocks
Removed old laserdsc.c implementation.
Added generic timer devices, which simply allocate a timer but don't
prime it. This is the preferred method for allocating timers, and may
eventually be the only mechanism for doing so in the future.
System 23:
* Added Rapid River readme
* Adjusted Gorgon h/w MIPS clock to 133 MHz based on readme
* Renamed GP500 to 500GP, which is it's correct name
Game Cristal:
* Use correct BIOS [f205v]
Uploaded to roms/current/g.
Includes mamedriv.c I missed with the System 23 checkin.
New games marked as GAME_NOT_WORKING
------------------------------------
GameCristal (version 2.613) [ANY, f205v]
* Fixed text layer to show (colors are wrong)
* Added very preliminary support for Gorgon h/w
* Added Rapid River and an alternate Time Crisis 2
New games marked as GAME_NOT_WORKING
------------------------------------
Rapid River (RD3 Ver. C) [Guru, R. Belmont]
Time Crisis 2 (TSS2 Ver. B) [Guru]
