* pokey: yet another performance enhancement
In case
* no counters are running at high speed without prescalers - and
* no prescalers have triggered - and
* there is no borrow counter expected to finish
there is no need to continue on step_one_clock.
Performance measuements:
Before:
./mame64 -bench 50 missile -> Average speed: 1322.75% (49 seconds)
./mame64 -bench 50 starwars -> Average speed: 548.97% (49 seconds)
./mame64 -bench 50 jedi -> Average speed: 375.08% (49 seconds)
After:
./mame64 -bench 50 missile -> Average speed: 1503.10% (49 seconds)
./mame64 -bench 50 starwars -> Average speed: 648.10% (49 seconds)
./mame64 -bench 50 jedi -> Average speed: 444.25% (49 seconds)
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* pokey: remove unused macros
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* This fixes a regression introduced by [1]
* Could not detect a performance change introduced by this
[1] 308c3c2d04
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* step_pot is called from step_one_clock only and just in case pokey is not in
reset state -> No need to check reset state again
* in case there were no bits in 'upd' latched to one, there is no need to call
synchronize(SYNC_POT, 0) because m_ALLPOT won't change.
Performance results with missile / starwars (no pots):
Before:
./mame64 -bench 50 missile -> Average speed: 1171.67% (49 seconds)
./mame64 -bench 50 starwars -> Average speed: 551.66% (49 seconds)
After:
./mame64 -bench 50 missile -> Average speed: 1321.16% (49 seconds)
./mame64 -bench 50 starwars -> Average speed: 551.10% (49 seconds)
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* pokey: rename pokey_device::m_output -> pokey_device::m_out_raw
There is a variable pokey_device::pokey_channel::m_output. Two variables with
same name in close context but complete different maning are not exactly
helpful to understand the code.
renaming pokey_device::pokey_channel::m_output was not an option because this
would damage stored machine states - right?
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* pokey: rework for performance enhancements
Profiling with valgrind pointed to the following hotspot:
pokey_device::step_one_clock / line 686-689:
| for (int ch = 0; ch < 4; ch++)
| {
| sum |= (((((m_channel[ch].m_output ^ m_channel[ch].m_filter_sample) || (m_channel[ch].m_AUDC & VOLUME_ONLY)) ? (m_channel[ch].m_AUDC & VOLUME_MASK) : 0 )) << (ch * 4));
| }
First solution was to move bit-shifting to first part of ?-part:
| sum |= (((m_channel[ch].m_output ^ m_channel[ch].m_filter_sample) || (m_channel[ch].m_AUDC & VOLUME_ONLY)) ? ((m_channel[ch].m_AUDC & VOLUME_MASK) << (ch * 4)) : 0);
because shifting 0 does not change value. Performance measurements showed
improvements but they were not satisfying exactly (change is part of this
patch).
So I thought more of what this piece of code is about:
* it is run at high frequency (@starwars: 1.5MHz * 4 pokey instances *
4 channels -> ~6MHz)
=> that is creating the high CPU cycle consumption
* frequency of output change is in a range of (double) audible frequencies (few
kHz).
=> there are long sequences creating identical output
* the sum value calculated depends on few channel input variables: m_output /
m_filter_sample / m_AUDC
This patch suggests a solution which keeps track of possible input variable
change and as long as they don't change there is no need to render output sum.
The following tests were performed:
* mame64 -bench 50 starwars: Average speed increases from ~430 to ~490 on my PC
* on screen profiling shows ~2% idle win
* starwars, missile-command and marble-madness do not show any audible
artefacts
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* pokey: rework prescaler handling
* CLK_1 does not have a prescaler so there is no need to increment and reset
m_clock_cnt[CLK_1]
* Unroll other prescalers: It gives performance win and reading is easier.
Function tests: on missile/starwars
Performance test: mame64 -nothrottle starwars
Before: Average speed: 409.36% (21 seconds)
After: Average speed: 447.37% (21 seconds)
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
* new NOT WORKING
---
Spider-Man (JAKKS Pacific TV Game) (older hardare) [Sean Riddle, external donators]
looks like this is SPG110 or similar, die markings to be confirmed, does things a little different to Pinball, so might just be a different mode, or slightly different die, we'll find out later.
* new NOT WORKING machines
---
I Can Play Piano [Sean Riddle, external donators]
new NOT WORKING software list entries
---
icanpian:pianfav Piano Favorites [Sean Riddle, external donators]
* specify unsupported (nw)
* (nw)
* add a known cartridges list to icanpian (nw)
* list some known carts here too (nw)
* (nw)
* visual inspection of die from Sean suggests it's the same (nw)
* (nw)
* add pinout information from Sean for the I Can Play Guitar and Piano carts
* new WORKING machines
---
Geigeki Go Go Shooting (Japan) [Peter Wilhelmsen, Sean Riddle, ShouTime, David Haywood]
new NOT WORKING machines
---
e-kara Mix (Japan) [Peter Wilhelmsen, Sean Riddle, ShouTime, David Haywood]
(e-kara mix is designed to connect to a PC, don't think it displays other than the startup warning message unless you do that, might also require specific carts)
* New NOT_WORKING clone
-----------------------------------------------------
My First LeapPad (World, V1.3) [Sean Riddle, ClawGrip]
Also renamed the existing set to "mfleappadus", as it's the US version, an made the new set the parent, even being older, as it's the World version.
* Add "mfleappadus" (nw)
* New NOT_WORKING clone
------------------------------------------------
LeapPad (Canada) [Sean Riddle, ClawGrip]
* Fix year (nw)
* Add "leappadca" (nw)
- Shift all CRU addresses by 1 in memory maps. This makes CRU addressing more consistent with both register values and external address lines. (CRUOUT is multiplexed with the lowest address line on the 8-bit bus versions.)
- Addressing for CRU read accesses is now the same as it has been for CRU write accesses: one address for each bit. This simplifies the CPU cores (which were already emulating bit access times), though it means some read handlers now have to do some additional work.
- CRU space is now little-endian, despite the big-endian memory organization, because less significant bits correspond to lower CRU addresses.
SDL/X11 number mouse/lighgun buttons 1,2,3, while windows and other parts of
MAME like offscreen_reload expect 0,2,1. Transpose buttons 2 and 3, and then
-1 the button number to align the numbering schemes.
This fixes lightgun support on Linux - tested with an Ultimarc AimTrak and
the following config:
lightgun 1
lightgun_device lightgun
lightgunprovider x11
lightgun_index1 "Ultimarc Ultimarc"
offscreen_reload 1
Note: MAME must be compiled with XInput support:
make -j10 NO_USE_XINPUT=0
Fixes bug #4695
Game sometimes accesses RAM via kuseg, which on R3041 is mapped at a 1GB offset. RAM is also accessed via kseg0/kseg1, meaning the hardware must ignore at least A30.
