|
MAME 0.191
#370528 - 10/25/17 06:08 AM
|
|
|
MAME 0.191
It’s the end of October, and time for the hotly anticipated MAME 0.191 release. This release includes an experimental Hitachi SH3 recompiler from frequent contributor David “Haze” Haywood that shows promising performance improvements for Cave CV-1000 emulation, and holds the tantalising possibility of bringing similar gains to systems based on the SH4 in the future (including Sega NAOMI). Bug fixes to the Saturn/ST-V emulation will enhance your enjoyment of numerous Sega titles from the ’90s. There have also been some optimisations and improvements to MIPS3 and Voodoo emulation, as used in a number of 3D arcade systems.
For fans of systems more often experienced at home, David Haywood also rewrote most of the Gamate emulation, taking it from mostly broken to (hopefully) best-in-class. We’ve also got some important bug fixes for the Tatung Einstein, the NEC PC-Engine console, and the M6809 CPU used by the Tandy CoCo family (among other things). Three more Tiger handhelds have been added for this release, namely Batman, Judge Dredd, and Swamp Thing. The hard limit of four emulated screens has been lifted, allowing you to plug in more video cards, more serial terminals, or just emulate systems that just have lots of screens.
We’ve got some big updates to the software lists this month, with plenty of Apple II cassettes, RM Nimbus software, and over seventy new PlayStation dumps. BBC Torch floppies and Gamate cartridges are now considered working, and Kiki Inland for Gamate has been added. A number of titles that don’t require a PC/AT have been moved from the IBM 5170 list to the IBM 5150 list. There are also some nice additions to the IBM PC and Fujitsu FM Towns software.
Of course, there are lots more bug fixes and newly dumped versions of emulated games. You can get the source/Windows binaries from the download page and start emulating.
MAMETesters Bugs Fixed
- 00759: [Misc.] (mystwarr.cpp) mtlchamp and clones: Problem with NVRAM in the RAM/ROM check after changing settings in service mode. (MetalliC)
- 04910: [Crash/Freeze] (pce.cpp) pce, tg16 [dslaylh, dslayedj]: No inputs and Black Screen. (Angelo Salese)
- 04950: [Crash/Freeze] (pce.cpp) pce [draculax]: Game freezes at start of Stage 5. (Angelo Salese)
- 05192: [Graphics] (pce.cpp) tg16 [airzonk]: Graphics freeze when traversing too far up the screen. (Angelo Salese)
- 05994: [Crash/Freeze] (pce.cpp) pce [imagef2]: Freezes before displaying title screen. (Angelo Salese)
- 06154: [DIP/Input] Games with a rotary positional joystick: Some positions are skipped. (Angelo Salese)
- 06387: [Graphics] (pce.cpp) pce [finalsol, finalsols]: Messed up/disappearing tiles. (Angelo Salese)
- 06487: [Documentation] tonton, ppj, big10: Documentation found on Success website. (D Go Go Fan)
- 06622: [Graphics] (pce.cpp) pce [beball]: Garbage appears when collecting the dual arrow item. (Angelo Salese)
- 06637: [Interface] Internal UI does not save entire configuration. (AJR)
- 06656: [Interface] Configuring Machine level “Video Option” causes CRASH. (Nathan Woods)
- 06689: [Crash/Freeze] (amstrad.cpp) cpc6128: Loading a disk freezes the emulator. (Patrick Mackinlay)
- 06690: [Color/Palette] (bottom9.cpp) bottom9n: Sprites have incorrect colors. (Angelo Salese)
- 06691: [Graphics] tokio and clones: Tokio – graphic glitches on the right side of the screen. (Lord Nightmare)
- 06696: [Graphics] (pce.cpp) tg16 [turrican]: Not showing Title Screen. (Angelo Salese)
- 06697: [Crash/Freeze] (stv.cpp) grdforce: Hangs after insert coin. (Angelo Salese)
- 06701: [Gameplay] (pce.cpp) pce [shingen, shingen1]: Extended/Unexpected periods of Black Screen. (Angelo Salese)
- 06708: [Media Support] (tandy2k.cpp) tandy2k: Does not boot from disk (regression). (Carl)
- 06711: [Interface] UI: If you exit with the Exit option, the last used game is not saved. (Vas Crabb)
- 06713: [Misc.] (dbz.cpp) dbz, dbza, dbz2: Correct names for these three games. (Fortuna)
- 06719: [Core] (coco12.cpp) coco12, coco3, other 6809?: SBCB instruction returns the wrong result. (hap)
- 06720: [Interface] Prescale option allows invalid values. (Tafoid)
- 06723: [DIP/Input] (einstein.cpp) einstein [hustler, starq]: Keyboard is not responding! (Dirk Best)
- 06724: [Gameplay] (vegas.cpp) gauntleg, gauntdl: Various Effects Cause More Damage than they should (64-bit Only). (Ted Green)
- 06727: [Documentation] (ibmpc.cpp) Parent/Clone Issues for IBM5170 softlist. (Justin Kerk)
- 06728: [Timing] (einstein.cpp) einstein: In Xtal Basic the PRINT TI$ always gives "000000" ?. (Dirk Best)
New working machines
- Batman (Tiger handheld) [hap, Sean Riddle]
- Judge Dredd (Tiger handheld) [hap, Sean Riddle]
- Mephisto Mondial II [yoyo_chessboard, Sandro Ronco]
- Swamp Thing (Tiger handheld) [hap, Sean Riddle]
New working clones
- Alien3: The Gun (Japan) [ShouTime]
- Athena (bootleg) [Porchy, The Dumping Union]
- Biomechanical Toy (Ver. 1.0.1878) [Jorge Silva]
- Cabal (UK, Joystick) [hammy, The Dumping Union]
- Cobra Command (M.A.C.H. 3 hardware, set 2) [f205v]
- Cyberball (rev 1) [Brian Troha, The Dumping Union]
- Fidelity Elite Avant Garde (model 6117-7, set 2) [CB-Emu]
- G-LOC R360 (Japan) [ordyne, The Dumping Union]
- Kaypro 16 [rfka01]
- Knights of the Round (bootleg, World 911127) [hammy, The Dumping Union]
- Rod-Land (World, set 2) [frsj8112]
- Super Hang-On (Hang-On conversion, Beta bootleg) [Cmonkey]
- Target Hits (ver 1.1, Checksum 86E1) [Peter Wilhelmsen, Morten Shearman Kirkegaard, Clawgrip, Brian Troha, David Haywood]
- Tecmo World Cup ’94 (set 3) [caius, Angelo Salese, The Dumping Union]
- TH Strikes Back (Non North America, Version 1.0, Checksum 020EB356) [caius, The Dumping Union]
- unknown ‘Space Invaders’ gambling game (set 2) [Roberto Fresca, Arzeno Fabrice]
- World Series: The Season (rev 0) [f205v, The Dumping Union]
Machines promoted to working
- Big Casino [Ivan Vangelista]
- Votrax Personal Speech System [Robbbert]
- Votrax Type ’N Talk [Robbbert]
Clones promoted to working
- Terco 4426 CNC Programming station [Edström]
- Torch CF240 [Nigel Barnes]
New machines marked as NOT_WORKING
- Baby Boom Challenge [f205v]
- Casino Strip I (Poker version, for Pioneer LD, set 1) [Dragon’s Lair Project]
- Casino Strip II (Poker version, for Sony LD) [Dragon’s Lair Project]
- Casino Strip III (Poker version, for Sony LD) [Dragon’s Lair Project]
- Casino Strip IX (Poker version, for Sony LD) [Dragon’s Lair Project]
- Casino Strip Private Eyes / All Start (Poker version, for Sony LD) [Dragon’s Lair Project]
- Casino Strip V (Poker version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip V (Shooting Game version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip VI (Poker version, for Sony LD) [ANY, Smitdogg, The Dumping Union]
- Casino Strip VI (Shooting Game version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip VIII (Poker version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip VIII (Shooting Game version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip Vivid 1 (Poker version, for Sony LD) [Dragon’s Lair Project]
- Casino Strip X (Poker version, for Sony LD) [ANY, Smitdogg, The Dumping Union]
- Casino Strip XI (Poker version, for Sony LD, set 1) [Dragon’s Lair Project]
- Casino Strip XI (Shooting Game version, for Pioneer LD) [Dragon’s Lair Project]
- Casino Strip XII (Poker version, for Sony LD) [ANY, Smitdogg, The Dumping Union]
- Dobou-Chan (ver. JAA) [R. Belmont, Rod_Wod]
- E-Touch Mahjong Series #2: Joshiryou de NE! [ShouTime, Team Japump, The Dumping Union]
- E-Touch Mahjong Series #6: Scandal Blue - Midara na Daishou [ShouTime, Team Japump, The Dumping Union]
- E-Touch Mahjong Series #7: Trap Zone - Yokubou no Kaisoku Densha [ShouTime, Team Japump, The Dumping Union]
- Elektronika MS 6102.02 [shattered]
- Gokidetor [Surgeville, Sean Sutton, Smitdogg, The Dumping Union]
- Mikrocomputer fuer Ausbildung [rfka01, Robbbert]
- Note Chance [Roberto Fresca, Ryan Holtz, Smitdogg, The Dumping Union]
- Ocha-Ken Hot Medal [Darksoft]
- Ton Puu Mahjong [ShouTime, The Dumping Union]
New clones marked as NOT_WORKING
- 301/Bullseye (Traditional Scoring) [barakandl]
- A.G. Soccer Ball (R07u) [PinMAME]
- Casino Strip XI (Poker version, for Sony LD, set 2) [Dragon’s Lair Project]
- Cheetah (Blue cabinet version - Stern Pinball) [Cooke/LondonPinball]
- Eight Ball (rev. 17) [Quench]
- Epson CM6000 [Colin McDougall]
- Flash Point (Japan, bootleg set 2) [Arzeno Fabrice, David Haywood]
- Horizon (North Star Computers, 2MHz) [AJR]
- Knights of Valour 3 (V100, China) [XingXing]
- Knights of Valour 3 (V104, China) [XingXing]
- Mikrocomputer fuer Ausbildung MAT85 [rfka01, Robbbert]
- Omni 4 Logic Analyzer [rfka01]
- Poker Ladies (Censored bootleg, set 2) [hammy, The Dumping Union]
- SD Gundam Sangokushi Rainbow Tairiku Senki (Korea) [Rod_Wod, The Dumping Union]
- Time Warp (L-3) [PinMAME]
- Trident (Later version - Stern Pinball) [Quench]
- Virtua Athletics / Virtua Athlete (prototype) [antron, MetalliC, rtw]
New working software list additions
- apple2_cass: Alignment Test Tone / Renumber, Alignment Test Tone / Sampler, Apple Bowl, Applesoft IIa, Applesoft ][ Floating Point BASIC / Floating Point BASIC Demo, Apple Trek, Apple-2 Trek, Apple-Vision / Biorhythms, Basic Finance I/ Penny Arcade, Brian’s Theme / Phone List, Brick out / Color Demonstration Programs, Breakout / Color Graphics, Breakout / Color Demos, Checkbook, Color Sketch / Supermath, Datamover / Telepong, High Resolution Graphics, Hangman / Color Math, Hopalong Cassidy / Lemonade Stand, Leases / Loans, Savings / Finance [Dagarman]
- bbc_flop_torch: Hard Disc Utilities v4.1, Torch System Disc v1.7 [Nigel Barnes]
- fmtowns_cd: Ginga Eiyuu Densetsu III SP, Gulf War Soukouden, New 3D Golf Simulation: Harukanaru Augusta, TownsPAINT V1.1L20, Video Koubou V1.3L10 [r09]
- fmtowns_flop: Sweet Angel [r09]
- gamate: Kiki Inland [Morten Shearman Kirkegaard, Peter Wilhelmsen]
- ibm5150:
The Adventures of Captain Comic, Back to the Future Part II, Dragons of Flame, Gryzor, Loom (French), Kings of the Beach (3.5"), Leisure Suit Larry 3 (French), Le Manoir de Mortevielle (3.5"), Operation Wolf (3.5"), Out Run, Super Ski, Zombi [breiztiger]
Drakkhen, Kaypro 16 Autoload, Kaypro 16 Master Disks, Leisure Suit Larry 3, Loom (German), Manhunter - New York, Manhunter 2 - San Francisco, Police Quest II - The Vengeance, Silpheed, Space Quest II - Vohaul’s Revenge [Justin Kerk]
MS-DOS (Version 3.30B) (V1.2) (Schneider) (German) [rfka01]
- ibm5170:
Amazon - Guardians of Eden, Arcade Pool, Zool 2 [ArcadeShadow]
Crash Course [breiztiger]
Sneakers Computer Press Kit [Justin Kerk]
- lynx: MegaPak 1 [anonymous]
- msx1_cart: Roc’n Rope [Anonymous]
- nimbus: BBC BASIC V1.00a, IBM Mode Software For Nimbus PC V2.61, IBM Mode Software for Nimbus PC Rel.3, Microsoft Windows 2.03 for Nimbus PC System, Microsoft Windows 3 Standalone PC 186, Microsoft Windows ISV Toolkit Release 1.02, Microsoft Windows Release 1.02 Stand Alone, Microsoft Windows Release 1.03 Stand Alone, Microsoft Windows V2.1 Presentation Manager for Nimbus PC186, Nimbus Winchester Format Tools, Parallel Printer Driver Parallel Board For I/O Board Version V1.0G, RM BASIC V1.0F, RM LOGO V1.0D, RM Nimbus General Utility Disk, RM Nimbus PC Upgrade Disk DOS 3.1 Rel 3.10.A, RM Nimbus Sketchpad Driver V1.0B, Release Disk SetPC V2.90 IBM Mode, Steed Ver 1.4A, WordStar Rel. 3.30, XferCPM V1.0A [Nigel Barnes]
- pv2000: Exciting Jockey, Real Number Basic [SSJ, Team Europe, Dustin Hubbard]
- smondial2: Mephisto College Module [yoyo_chessboard]
Software list items promoted to working
- bbc_flop_torch: Adventure B01 - 550 points, Torch BBC BASIC (Z80) v2.30, Comanex, dBASE-II, Hard Disc Utilities v4.4, Kermit-80 v4.05, Perfect Software Suite, Standard Utilities v2.0, Turbo Pascal v3.0A, UniComm, WordStar [Nigel Barnes]
New NOT_WORKING software list additions
- apple2_cass: Apple Stock Quote Reporter, Tape Measure / Alignment Test Tone [Dagarman]
- bbc_flop_torch: Basic Pack v2.0, Prog Dev Pack v2.0, Text Pack v2.0, Unix Upgrade Pack release 1.0 to 2.0 [Nigel Barnes]
- hx20_rom: SkiWriter [Nigel Barnes]
- rx78: Challenge Golf [SSJ, Team Europe, Dustin Hubbard]
Translations added or modified
- Chinese (Simplified) [YuiFAN]
- Chinese (Traditional) [YuiFAN]
- German [Raf Tacker]
- Greek [BraiNKilleRGR]
- Japanese [Katsuhiko Kagami]
- Portuguese [Pedro Simoes]
- Russian [Nikita Zimin, MetalliC]
Source Changes
coco3: Made banked cartridges actually work. [AJR]
z8: Fixed disassembly of LDE Irr, r. [AJR]
am9513: Implemented time-of-day mode. [AJR]
Actually make sure OSD options are included when saving through UI. [AJR]
Draw a nominal distinction between PC060HA and TC0140SYT. [AJR]
Explicitly allow floating point values for state registration. [AJR]
ccs2810: Major refinements. [AJR]
Implemented power-on jump in a hardware-accurate manner, including full configuration options.
Hooked up INS8250 device for RS-232 serial communication (requires ROM wait states simulation for baud rate to be recognized).
Made serial port address configurable as well (although monitor expects it to be at the default setting).
S-100 bus refinements: [AJR]
Made slots subdevices, eliminating the need to hardcode the bus tag.
Clock the bus and its slots.
Use correct XTAL for nshrz and added 2MHz variant.
legionna.cpp: Fixed Denjin Makai background pen colors. [Angelo Salese]
rx78.cpp: Added border area. [Angelo Salese]
ygv608.cpp updates: [Angelo Salese]
Fixed page select boundaries for tilemap drawing (fixes Namco Classics Vol. 2 garbage GFX in attract mode).
Reset pattern name table states on mode changes (fixes Mappy Arrange corrupt tiles).
Enabled sprite wraparound when both sx and sy pass clipping boundaries (fixes disappearing char on NCV2 game select screen).
Fixed CRTC vblank period (fixes NCV2: Dig Dug Original regression). [Angelo Salese]
huc6270: Invert h/vsync logic for interrupts – fixes several PC Engine hangs. [Angelo Salese]
saturn.cpp updates: [Angelo Salese]
Rewrote SMPC as a device, merging ST-V and Saturn implementations.
Moved SCU-related functions insto a device. [Angelo Salese]
smpc: Simulate SETTIME bit behaviour if invalid NVRAM data is found for Sega Saturn. [Angelo Salese]
All Sega Saturn ROM sets now calls the BIOS setup if NVRAM is uninitialized, setting up proper defaults.
stv.cpp: Patch Sport Fishing 2 BIOS to actually return a country code, and added bare bones MPEG CD commands. [Angelo Salese]
Game now loops into attract mode with mostly missing graphics (MPEG video logic not yet added).
stvvdp2.cpp: Added ROZ mode 3. [Angelo Salese]
Fixes split screen in Sasissu, backgrounds in Elandore, and Guy stage in Final Fight Revenge.
jalmah.cpp: Improved fake palette DMA behaviour – avoids corrupt colors for girls. [Angelo Salese]
stvvdp1.cpp: CEF bit gets reset when the framebuffers get swapped (fixes Twinkle Star Sprites Arcade Mode hang). [Angelo Salese]
dec0.cpp: Updated inputs in all games in the driver. [Angelo Salese]
Added input labels for most games in the driver, and removed unused buttons.
Updated positional rotary for Heavy Barrel/Midnight Resistance to use remap table.
Made Boulder Dash use 4-way stick as per manual.
dec0.cpp: Hooked up priority video port to Midnight Resistance bootlegs. [Angelo Salese]
taito_b.cpp: Fixed pixel layer offset and enable for Hit the Ice. [Angelo Salese]
taito_z.cpp: Saner interleave CPU timings for Double Axle, attempted to fix road layer getting stuck on continue. [Angelo Salese]
wheelfir.cpp: Converted to RAMDAC device. [Angelo Salese]
Made some small fixes to general info panel on the system selection menu. [BraiNKilleRGR]
Added lua translation to makefile and regenerated translations. [Carl]
plugins/cheat: Added input sequence cheats. [Carl]
abc800 updates: [Curt Coder]
Corrected Turbo Kontroller name to UNI DISK and identified CPU type.
Added skeleton for Databoard 4112-23 floppy disk controller.
Fixed Luxor 55-10828 “slow” floppy controller board logic.
Updated androidp year to 1987 based on in-game date showed after end credits. [David Haywood]
Documented that the ‘oldsplus’ set identifies as “Oriental Legend 2” when the protection device supplies Korea as the region. [David Haywood]
Gamate overhaul, fixes many games: [David Haywood]
Sound is 100% AY8910 compatible according to kevtris and Peter Wilhelmsen – use the AY8910 core.
Rewrote the video implementation from scratch using kevtris’ document and Peter Wilhelmsen’s notes this fixes many games.
Added some mirroring to memory map.
Converted cartridges to slot devices that handle protection themselves.
Rewrote protection emulation from scratch based on notes from kevtris and Peter Wilhelmsen.
Merged Hitachi SuperH CPU cores and implemented a preliminary SH3/SH4 recompiler. [David Haywood]
Recompiler is currently enabled for Cave CV-1000 but disabled for Sega NAOMI.
Recompiler can more than double the benchmark speed of CV-1000 games.
supbtime.cpp: Cleaned up and merged with tumblep. [Dirk Best]
Removed duplicate code, used screen raw parameters and XTAL values, added DIP switch locations to all games.
z80sio/z80scc: Return CPU-specific default vector when no interrupt found to acknowledge. [Edström]
t4426 cart: Added MC14411 BRG, 6850 ACIA as a second RS232 port and fixed banking; promoted to working. [Edström]
proteus3: Added MC14411 bit rate generator device and replaced the timer based clocks for the ACIAs. [Edström]
imgtool: Added support for HP85 tape. [F.Ulivi]
mc146818: Fixed main interrupt flag. [Jean-François DEL NERO]
Fixed crash loading 80-track .mfm dumps of 40-track floppy disks on 40-track drives. [Justin Kerk]
Hacked around MT06691 by suppressing partial updates in Tokio video – timing is likely wrong. [Lord Nightmare]
mc68901: Fixed TCDCR register – bits 6-4 are used for timer C bits 2-0 are used for timer D. [Nicolas PLANEL]
abc310: Added 80286 2nd processor. [Nigel Barnes]
tube_z80: Check NMI state when paging in ROM. [Nigel Barnes]
acorn_dsk: Improved identifying SSD/DSD by comparing image size with sector counts. [Nigel Barnes]
Also fixed DDCPM format to handle correct image of Double Density CP/M.
bbc: Added Torch Z80 Communicator as Tube slot device. [Nigel Barnes]
acorn_dsk: Removed CPN format, now handled with SSD/DSD. [Nigel Barnes]
hx20: Added optional ROM slot and software list. [Nigel Barnes]
z80scc: Fixed interrupt mask generation. [Patrick Mackinlay]
Added new bt459 device (Brooktree RAMDAC used in InterPro graphics boards). [Patrick Mackinlay]
ms6102: Decrypted chargen. [Robbbert]
ts803: Fixed and used z80sti; cleanup and notes. [Robbbert]
mc8030: Added random ROMs, to be sorted. [Robbbert]
p8000: Added WDC ROMs. [Robbbert]
ax80: Added roms, notes, and flesh. [Robbbert]
Note Chance: Added skeleton driver with front panel layout, sound, and extensive notes. [Roberto Fresca]
vme_hcpu30: Added Besta HCPU30 VME board skeleton device. [shattered]
Generate tiled layouts for systems with three or more screens (fixes crash with four or more emulated screens). [Vas Crabb]
Eliminated vestigial palette that was breaking generic terminal when it isn’t first screen. [Vas Crabb]
Improved PORT_CHAR (natural keyboard/paste/key post mapping) for US Apple IIe/IIc (thanks to Golden Child for report). [Vas Crabb]
Exposed condition for DIP switches, configuration entries, and adjusters in -listxml output. [Vas Crabb]
dynax.cpp: Fixed credits lost after exiting the game in tenkai. [Wei Mingzhi]
psx.xml: Synchronized with redump.org, adding 76 new dumps and replacing two bad dumps. [aeternal606]
gaelco.cpp: Corrected various clock speeds and added PCB layout for Biomechanical Toy. [Brian Troha]
naomi.cpp: Decapped and identified Atomiswave ‘ROMEO’ ASIC. [brizzo]
segasp.cpp: Dumped Network firmware ver 1.25. [Darksoft]
segas16b.cpp: Made some corrections to Aurail documentation. [ekorz]
gauntlet.cpp: Reinstated correct size for ‘gfx1’ ROM, which was chopped off a long time ago. [f205v]
Added PAL dumps for supbtime. [Luiskiko/jammarcade.net]
Dumped touchgo SRAM from two more boards, and used that dump to verify/correct the SRAM image. [Peter Wilhelmsen, Morten Shearman Kirkegaard, David Haywood]
Fixed zexall build target. [RandomArts]
EuroPC: Added first and last known BIOS versions. [rfka01]
taitoair.cpp: Dumped ainferno’s Controller PCB ROM. [ShouTime, The Dumping Union]
qix.cpp: Added some documentation to the qixb set. [ShouTime]
Corrected years for Final Furlong 2, Crisis Zone, Big 10, Waku Waku Doubutsu Land TonTon, Pyon Pyon Jump, and Sui Sui Pyon Pyon. [sjy96525]
pv2000.xml: Desoldered and redumped ROMs for rakugaki and excitem2. [SSJ, Team Europe, Dustin Hubbard]
Added newer version of Mephisto Academy (German) as BIOS option. [yoyo_chessboard]
Added support for multiple PORT_CHAR() bindings, and adopted in the CoCo driver. [Nathan Woods]
Created a more flexible date/time structure for use within imgtool intended to replace most usage of time_t. [Nathan Woods]
|
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370538 - 10/25/17 02:01 PM
|
|
|
just a quick note
'Target Hits' should have been included in the "Machines promoted to working" list, the game was entirely non-functional in 0.190 (and marked as such)
(it is mentioned in the new clones list, because yes, a new working clone was also added, but should have been in the other list too because the parent set was also promoted to working)
|
|
|
|
Re: MAME 0.191
[Re: Haze]
#370539 - 10/25/17 02:06 PM
|
|
|
> just a quick note
>
> 'Target Hits' should have been included in the "Machines promoted to working" list,
> the game was entirely non-functional in 0.190 (and marked as such)
If it was really non-functional in 0.190 it should have actually been marked MACHINE_NOT_WORKING, but it wasn't. It was just marked MACHINE_UNEMULATED_PROTECTION. The lists of promoted systems are just systems that have had the MACHINE_NOT_WORKING flag lifted in the release cycle. If we try to define it any other way it'll lead to endless arguments about whether things are worthy of listing or not.
Besides, we've been promoting the Gaelco progress for months. If someone hasn't noticed already, one release isn't going to make them suddenly wake up.
|
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370540 - 10/25/17 02:48 PM
|
|
|
> > just a quick note
> >
> > 'Target Hits' should have been included in the "Machines promoted to working" list,
> > the game was entirely non-functional in 0.190 (and marked as such)
>
> If it was really non-functional in 0.190 it should have actually been marked
> MACHINE_NOT_WORKING, but it wasn't. It was just marked MACHINE_UNEMULATED_PROTECTION.
> The lists of promoted systems are just systems that have had the MACHINE_NOT_WORKING
> flag lifted in the release cycle. If we try to define it any other way it'll lead to
> endless arguments about whether things are worthy of listing or not.
>
It was definitely 100% unplayable, there were no targets to shoot at and the game would hang as soon as you attempted to start it or if you let it play the demo. The dallas does all the calculations and maths for the targets appearing and movement of the targets.
I guess somebody felt UNEMULATED PROTECTION was a 'more accurate' way of saying MACHINE NOT WORKING or something since both give red screens.
The fact it wasn't marked as NOT WORKING in previous releases is definitely the mistake here, it's very much something that has been promoted to working in 0.191.
The unemulated protection flag seems ambiguous anyway, if the protection simulation on a game isn't trusted well enough to be sure the gameplay is correct, then the driver should be marked as NOT WORKING anyway. If it is instead intended to be used for all cases where protection is simulated, not emulated, even if that simulation is 100% (eg silly cases like Semicom 0x200 byte code transfer) then it shouldn't be a red screen (and needs adding to a LOT more drivers)
I've even seen cases where it seems to have been used to tag things like hardware collision detections being wrong, which isn't protection at all IMHO while in the case we've seen here it was simply (inappropriately) used as a substitute for a proper NOT WORKING flag.
Given all that, I'd say the most important thing to apply in cases like this however is common sense.
|
|
|
| Asure |
|
MAME Fan
|
|
|
|
|
|
Reged: 11/29/04
|
|
Posts: 40
|
|
Loc: Nederland
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370541 - 10/25/17 03:52 PM
|
|
|
The Hitachi recompiler runs CV1000 buttery smooth now.
In fact it's so smooth, i get killed all the time as the thing runs better than my real boards, omitting the slowdown(s) normally caused by blitter limits and ram speeds 
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8603
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370548 - 10/25/17 06:50 PM
|
|
|
Some good updates with this version:
Casino Strip series finally being supported even though it will be some time before laser disc part is emulated.
>There are also some nice additions to the IBM PC
Yep. Some quality IBM PC software list additions this time around.
-
>New NOT_WORKING software list additions
>rx78: Challenge Golf [SSJ, Team Europe, Dustin Hubbard]
-
Good to see Bandai system emulation getting cartridge addition in order to improve emulation of the system.
>The hard limit of four emulated screens has been lifted, allowing you to plug in more
>video cards, more serial terminals, or just emulate systems that just have lots of
>screens.
This update will be handy for emulated systems that have many multiple video outputs especially any of the arcade hardware that use the satellite boards like the multiple screens horse racing games.
|
|
|
|
Re: MAME 0.191
[Re: Haze]
#370550 - 10/25/17 07:43 PM
|
|
|
> Given all that, I'd say the most important thing to apply in cases like this however
> is common sense.
Common sense in this case would be to learn the rules by which the whatsnew creation script operates, and work within them. Not to expect an already-time-strapped individual to go by hand through potentially hundreds of commits to appease one external contributor who refuses to march in step with the rest of us, Mr. Snowflake.
Edit: And really, "Someone should have marked it as non-working"? I agree, someone should have marked it non-working. Perhaps the person who submitted the pull request?
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370551 - 10/25/17 08:20 PM
|
|
|
> > Given all that, I'd say the most important thing to apply in cases like this
> however
> > is common sense.
>
> Common sense in this case would be to learn the rules by which the whatsnew creation
> script operates, and work within them. Not to expect an already-time-strapped
> individual to go by hand through potentially hundreds of commits to appease one
> external contributor who refuses to march in step with the rest of us, Mr. Snowflake.
>
> Edit: And really, "Someone should have marked it as non-working"? I agree, someone
> should have marked it non-working. Perhaps the person who submitted the pull request?
I specified that it was promoted to working with the submission
it appeared under the initial list of things that were promoted from not working in the generated whatsnew.
vas deleted it from that list under the technicality that it was never marked as non-working, only 'unemulated' protection.
so please, do one.
|
|
|
|
why?
[Re: Haze]
#370552 - 10/25/17 08:59 PM
|
|
|
With all due respect to the devs, why do you guys air out your dirty laundry on the mame boards? This argument is irrelevant to the vast majority of people out here. The three of you should get a private room, beat the hell out of each other, then go grab a drink and laugh it off (trying to make it light here). Seriously, just let it go. The project needs all of you as each of you make invaluable contributions. I understand that I am replying to developers so the tone of this reply will probably be taken out of context, but it really is made to try to lighten up the mood between the devs.
|
|
|
|
Re: why?
[Re: Jason]
#370553 - 10/25/17 09:14 PM
|
|
|
> With all due respect to the devs, why do you guys air out your dirty laundry on the
> mame boards? This argument is irrelevant to the vast majority of people out here. The
> three of you should get a private room, beat the hell out of each other, then go grab
> a drink and laugh it off (trying to make it light here). Seriously, just let it go.
> The project needs all of you as each of you make invaluable contributions. I
> understand that I am replying to developers so the tone of this reply will probably
> be taken out of context, but it really is made to try to lighten up the mood between
> the devs.
Well Moogly's potshot was completely out of order.
This type of thing is entirely why I've distanced myself from the team.
Instead of valuing the contribution, or actually contributing to the discussion of how the unemulated protection flag is used / abused and how that could be improved, this type of thing happens.
So I'm not just going to sit and ignore it because this type of thing seems to happen over and over again. A lot of hard work was put into things like this, but some people just can't help themselves.
My initial post was just to help make sure people were properly informed that Target Hits is now a working game in 0.191 when it wasn't in 0.190 despite not being mentioned to due to an oversight (albeit an intentional one with some rather odd logic behind it since I couldn't really retroactively mark the game as NOT WORKING to actually promote it)
|
|
|
|
Re: MAME 0.191
[Re: Asure]
#370556 - 10/26/17 12:57 AM
|
|
|
> The Hitachi recompiler runs CV1000 buttery smooth now.
> In fact it's so smooth, i get killed all the time as the thing runs better than my
> real boards, omitting the slowdown(s) normally caused by blitter limits and ram
> speeds
Notwithstanding the awesome job Haze and team did with the DRC, I'm sure you realize delivering us from slowdown brings MAME further away from accurate CV1000 emulation. I'm sure there were reasons to go the route they did, but I'm curious whether this was a necessary step to introduce the slowdown, so common with the games on this platform, at some point in the future. I'm guessing it won't happen anytime soon, but it's nice to dream.
|
|
|
|
Re: MAME 0.191
[Re: Shoegazr]
#370557 - 10/26/17 01:10 AM
|
|
|
> > The Hitachi recompiler runs CV1000 buttery smooth now.
> > In fact it's so smooth, i get killed all the time as the thing runs better than my
> > real boards, omitting the slowdown(s) normally caused by blitter limits and ram
> > speeds
>
> Notwithstanding the awesome job Haze and team did with the DRC, I'm sure you realize
> delivering us from slowdown brings MAME further away from accurate CV1000 emulation.
That's totally inaccurate and misleading. Mame slowing down because a PC can't run it has nothing in relation to how the games are supposed to run / on a PCB because of blitter limits. They are both "slowdown" but they are totally different, happening at different times of the game, not related at all. By this logic if Haze made it run shittier that would be "more accurate because it slows down more". That's just completely wrong.
|
|
|
|
Re: MAME 0.191
[Re: Haze]
#370561 - 10/26/17 02:16 AM
|
|
|
Game is definitely playable now, and included in my video compilation.
As always, great work guys ! you keep rocking !
|
|
|
|
Re: MAME 0.191
[Re: Smitdogg]
#370563 - 10/26/17 06:41 AM
|
|
|
> > > The Hitachi recompiler runs CV1000 buttery smooth now.
> > > In fact it's so smooth, i get killed all the time as the thing runs better than
> my
> > > real boards, omitting the slowdown(s) normally caused by blitter limits and ram
> > > speeds
> >
> > Notwithstanding the awesome job Haze and team did with the DRC, I'm sure you
> realize
> > delivering us from slowdown brings MAME further away from accurate CV1000
> emulation.
>
> That's totally inaccurate and misleading. Mame slowing down because a PC can't run it
> has nothing in relation to how the games are supposed to run / on a PCB because of
> blitter limits. They are both "slowdown" but they are totally different, happening at
> different times of the game, not related at all. By this logic if Haze made it run
> shittier that would be "more accurate because it slows down more". That's just
> completely wrong.
I suppose you're right, but I was responding to the previous comment that "the thing [now] runs better than my real boards, omitting the slowdown(s) normally caused by blitter limits...". I haven't tested the CV1000 drivers much, certainly not anytime recently, so I had to take the comment at face value - so if the new driver "omits slowdown" that was in the previous iteration of the driver, then yeah, it would be less accurate at least in that regard. Based on what you're saying though, I guess it doesn't do that. That's a good thing.
|
|
|
|
Re: MAME 0.191
[Re: Shoegazr]
#370564 - 10/26/17 06:46 AM
|
|
|
My comment could just as well have gone to stating the inaccuracy of the "better" comment.
|
|
|
|
Re: MAME 0.191
[Re: Shoegazr]
#370565 - 10/26/17 08:04 AM
|
|
|
> > The Hitachi recompiler runs CV1000 buttery smooth now.
> > In fact it's so smooth, i get killed all the time as the thing runs better than my
> > real boards, omitting the slowdown(s) normally caused by blitter limits and ram
> > speeds
>
> Notwithstanding the awesome job Haze and team did with the DRC, I'm sure you realize
> delivering us from slowdown brings MAME further away from accurate CV1000 emulation.
> I'm sure there were reasons to go the route they did, but I'm curious whether this
> was a necessary step to introduce the slowdown, so common with the games on this
> platform, at some point in the future. I'm guessing it won't happen anytime soon, but
> it's nice to dream.
The recompiler buys us some extra CPU cycles to work with.
Accurately emulating the blitter speed will require more calculations during rendering, which costs CPU cycles.
The recompiler potentially gives us breathing space to improve the accuracy without making the whole driver run badly.
I say potentially because the blitter and CPU run on different threads, and while the recompiler gets rid of the SH3 bottleneck in some places (especially noticeable on Pink Sweets and MM Pork when it's decompressing stuff ingame) it doesn't change the weight of the blitter thread which can still be heavy in places (although not as heavy as the SH3 was before this as the blitter was already extensively optimized)
A better way to thread the blitter to make use of the cycles freed up on the main core might also be needed however, currently it just makes use of a 2nd core because it's important that all blits are processed in order. It might be possible to split the blitting of each object by scanline, assuming blits aren't relying on reading data written by the same blit.
If the games however slowdown because the original SH3 CPU is not fast enough rather than the blitter, then yes, the recompiler could cause problems as the recompiler isn't really going to allow us to emulate 100% accurate memory access timings for the CPU, doing so would be incredibly slow and require a much more accurate interpretor that likely no PC will be able to run. To the best of my knowledge the limits come from the blitter, not the SH3 tho.
However, as I've said before, I've really little interest in trying to accurately model the blitter timings until all the games are dumped so I know exactly what I'm working with, so that could be a good 10 years yet. It doesn't really bother me at this stage. I'm not going to stop anybody else from doing it, but I'm not in a rush and would prefer to have all possible evidence to work with before I commit to something like that.
For now just enjoy the performance improvements, MAME needed somebody to look into building an SH3/4 recompiler and if you're lucky somebody else will build on what's been done here and make the recompiler work properly for Naomi-AW-SP-DC / Hikaru / Gaelco / Aristocrat Mk6 etc. too, at which point things get a lot more interesting. This is more about trying to help unlock some of MAME's potential, the Cave stuff was just a nice simple test bed.
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8603
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
another MAME FAQ entry material?
[Re: Haze]
#370573 - 10/26/17 04:01 PM
|
|
|
With some minor editing of the post, this is probably worthy of being an FAQ entry material on MAMEdev site sometime later since there will be future users wondering how this [recompiler feature] works. There probably is something there already, but this post also provides some useful examples.
-
The recompiler buys us some extra CPU cycles to work with.
Accurately emulating the blitter speed will require more calculations during rendering, which costs CPU cycles.
The recompiler potentially gives us breathing space to improve the accuracy without making the whole driver run badly.
I say potentially because the blitter and CPU run on different threads, and while the recompiler gets rid of the SH3 bottleneck in some places (especially noticeable on Pink Sweets and MM Pork when it's decompressing stuff ingame) it doesn't change the weight of the blitter thread which can still be heavy in places (although not as heavy as the SH3 was before this as the blitter was already extensively optimized)
A better way to thread the blitter to make use of the cycles freed up on the main core might also be needed however, currently it just makes use of a 2nd core because it's important that all blits are processed in order. It might be possible to split the blitting of each object by scanline, assuming blits aren't relying on reading data written by the same blit.
If the games however slowdown because the original SH3 CPU is not fast enough rather than the blitter, then yes, the recompiler could cause problems as the recompiler isn't really going to allow us to emulate 100% accurate memory access timings for the CPU, doing so would be incredibly slow and require a much more accurate interpretor that likely no PC will be able to run. To the best of my knowledge the limits come from the blitter, not the SH3 tho.
However, as I've said before, I've really little interest in trying to accurately model the blitter timings until all the games are dumped so I know exactly what I'm working with, so that could be a good 10 years yet. It doesn't really bother me at this stage. I'm not going to stop anybody else from doing it, but I'm not in a rush and would prefer to have all possible evidence to work with before I commit to something like that.
For now just enjoy the performance improvements, MAME needed somebody to look into building an SH3/4 recompiler and if you're lucky somebody else will build on what's been done here and make the recompiler work properly for Naomi-AW-SP-DC / Hikaru / Gaelco / Aristocrat Mk6 etc. too, at which point things get a lot more interesting. This is more about trying to help unlock some of MAME's potential, the Cave stuff was just a nice simple test bed.
-
|
|
|
|
Re: why?
[Re: Haze]
#370579 - 10/26/17 05:51 PM
|
|
|
> Instead of valuing the contribution, or actually contributing to the discussion of
> how the unemulated protection flag is used / abused and how that could be improved,
> this type of thing happens.
Oh, please get off your cross. To be crystal clear, everyone on the team values the hell out of your contributions, myself included. Somehow you manage to come up with a copious amount of time to work on drivers long-term that only a handful of other people seem to manage to stump up, and you do a great job of getting external people to contribute.
Now, what I take issue with is this:
Vas gave you a reasonable answer as to why it was omitted: The whatsnew is generated in a largely automatic way, building the list of newly-working games based on the removal of the MNW flag.
A reasonable response to that would be to say, either in your head or in the thread, "Oh, so it was an oversight due to the way the script works. It shouldn't be an issue in the future then, right?"
Instead, your response was "I guess somebody felt UNEMULATED_PROTECTION was a 'more accurate' way of saying..." (emphasis mine). That reeks of deflection. Who cares originally set it as MUP instead of MNW?
And to then use that as an excuse to jump up on your soapbox about something wholly unrelated to Target Hits or 0.191, the perceived "proper" or "improper" use of MACHINE_UNEMULATED_PROTECTION, I mean, really? You have a fantastic point that it's not used with any consistency in the codebase, why not make a thread or send an e-mail or raise it in its own dedicated topic, rather than using it as a cudgel in some unrelated debate?
The "use common sense" comment, it looked like you were implying that the current way of compiling the list of newly-working games is broken and that "common sense" should be used instead, when that would require manually trawling through tens or hundreds of commits each month, and given that Vas single-handedly puts the releases together, he's pretty time-strapped. It's only after re-reading it multiple times that I'm just now realizing that you might have been talking about using common sense regarding the MUP flag, in which case, yeah, I agree. MUP shouldn't be used for video hardware faults or missing collision detection.
The whole impression that I got off of your response to Vas was that of one looking to give out to someone, anyone. A man who feels personally slighted for not being given a "proper" amount of attention, when in reality it was a simple oversight that could have happened to anyone at any time over just about any driver. It comes off like you're seeking to blame someone or something for what you perceive as something bad happening, when the simple reality is that sometimes, these things happen.
I certainly should have phrased my response to you a lot better, and for that I apologize.
Having said that, it's pretty messed up that so many people, including this Jason fellow, are apparently willing to overlook any attitude coming from you, yet when I or anyone else reacts to the negative attitude being shown, suddenly it's time to clutch at pearls and play up the victim role. It's cry-bullying, it's bias, and it's tiresome.
|
|
|
|
Re: MAME 0.191
[Re: Haze]
#370591 - 10/27/17 01:24 AM
|
|
|
> If the games however slowdown because the original SH3 CPU is not fast enough rather
> than the blitter, then yes, the recompiler could cause problems as the recompiler
> isn't really going to allow us to emulate 100% accurate memory access timings for the
> CPU, doing so would be incredibly slow and require a much more accurate interpretor
> that likely no PC will be able to run. To the best of my knowledge the limits come
> from the blitter, not the SH3 tho.
Thanks for the informative post, Haze. This clears up quite a bit, for me and hopefully others. Let's hope the limits lie in the blitter rather than the SH3, I suppose someday we'll know. I'm not sure what else needs to be dumped but if it takes 10 years, so be it.
Also curious whether any of this work might impact SH2 emulation as well - it would be interesting to see Saturn/32X speed improvements too if that's possible.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Shoegazr]
#370640 - 10/29/17 03:45 AM
|
|
|
> Also curious whether any of this work might impact SH2 emulation as well - it would
> be interesting to see Saturn/32X speed improvements too if that's possible.
Nope. SH1/2 are about as fast as they can possibly go right now; they actually seem a few ticks slower on my benchmarks now, but modern CPUs are kind of unpredictable about what they really really want.
|
|
|
|
Re: MAME 0.191
[Re: R. Belmont]
#370646 - 10/29/17 05:10 PM
|
|
|
> > Also curious whether any of this work might impact SH2 emulation as well - it would
> > be interesting to see Saturn/32X speed improvements too if that's possible.
>
> Nope. SH1/2 are about as fast as they can possibly go right now; they actually seem a
> few ticks slower on my benchmarks now, but modern CPUs are kind of unpredictable
> about what they really really want.
Can the following drivers be made to run faster? Konami GX, Aleck 64, F-32, DGPIX, Eolith, Ghosteo, Vegaeo?
|
|
|
|
Re: MAME 0.191
[Re: R. Belmont]
#370647 - 10/29/17 05:16 PM
|
|
|
> > Also curious whether any of this work might impact SH2 emulation as well - it would
> > be interesting to see Saturn/32X speed improvements too if that's possible.
>
> Nope. SH1/2 are about as fast as they can possibly go right now; they actually seem a
> few ticks slower on my benchmarks now, but modern CPUs are kind of unpredictable
> about what they really really want.
Ah, well at least they've been fully optimized. They aren't bad on this Haswell here, I was curious mostly for other procs.
|
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370655 - 10/30/17 01:12 PM
|
|
|
any info on whether or not the "hack" used in another mame build for making primal rage 2 playable will be included in regular mame as well?
|
|
|
|
Re: MAME 0.191
[Re: Solstar]
#370656 - 10/30/17 01:42 PM
|
|
|
> any info on whether or not the "hack" used in another mame build for making primal
> rage 2 playable will be included in regular mame as well?
We've been through this plenty of times. The hack breaks all other games running on the same hardware. It can't possibly be right, and it's definitely more wrong than what MAME does already, since it breaks more games. MAMEdev knew this years ago.
|
|
|
| Dullaron |
|
Diablo III - Dunard #1884
|
|
|
|
|
Reged: 07/22/05
|
|
Posts: 6125
|
|
Loc: Fort Worth, Tx
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370659 - 10/30/17 03:03 PM
|
|
|
> > any info on whether or not the "hack" used in another mame build for making primal
> > rage 2 playable will be included in regular mame as well?
>
> We've been through this plenty of times. The hack breaks all other games running on
> the same hardware. It can't possibly be right, and it's definitely more wrong than
> what MAME does already, since it breaks more games. MAMEdev knew this years ago.
I rather have a clean non hack build than the hack build.
|
W11 Home 64-bit + Nobara OS / AMD Radeon RX 5700 XT / AMD Ryzen 7 3700X 8-Core 3.59 GHz / RAM 64 GB
|
|
| CiroConsentino |
|
Frontend freak!
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 6211
|
|
Loc: Alien from Terra Prime... and Brazil
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Solstar]
#370667 - 10/30/17 10:56 PM
|
|
|
|
|
|
|
> Can the following drivers be made to run faster? Konami GX
Yes, with a whole ton of effort. Ideally, it might be possible to offload the functionality of the various Konami graphics ICs onto compute shaders to leverage the GPU. But again, that would be a whole ton of effort.
Also, these days it's unlikely that the video emulation on Konami GX is the bottleneck, I seem to recall it has to do with the audio DSP needing incredibly tight sync. I don't even know how you could get around that to make it faster.
In general, I'd say that's starting our list off at a difficulty level of 10/10. This gives a good metric by which to rate the difficulty of your subsequent questions.
> Aleck 64,
That one's N64-based. At the moment, the DRC system is turned off for N64-related drivers because of some extremely rare and tough-to-debug game lockups that can happen literally minutes into the emulated game's time (so, upwards of half an hour or more in real life), but only with the DRC. It's difficult to debug in particular because the DRC doesn't have exactly the same timing as the interpreter core: whereas the interpreter core checks for interrupts after every instruction, the DRC checks for interrupts in between blocks of recompiled instructions.
Having said that, I should try to find the time to just quickly hack the interrupt-check UML into the start of mips3_dedvice::generate_opcode and see if any of these issues go away. If the DRC is fixed, that will gain a decent amount of speed back. Probably not enough to make the games run full speed on a machine that can't run some of the other drivers you mention full speed, but still a good speed increase.
On top of this, profiling with Intel VTune indicates that the main bottleneck of the N64 is not the emulation of the CPU, but the emulation of the GPU, called RDP. The amount of time spent in function calls related to the RDP dwarfs the amount of time spent elsewhere in MAME's codebase when emulating N64 games, so that would be a great place to optimize. However, the simple fact of the matter is the current implementation is slow, and no amount of optimizing what's there is going to make it that much faster.
There are, however, plenty of ways to skin this proverbial cat.
First, I'm tempted to simply ditch my current RDP code in MAME and port angrylion's C implementation back over. The two implementations have diverged wildly over the past few years, and I don't trust a number of the optimizations I've added to be bug-free, so I'd rather go back to a clean slate. I know he's spent some time doing optimization as well, so who knows, it might end up being faster. But there's a good chance it would be slower since it would involve ditching the current implementation's use of polynew.h, which lets MAME use multiple threads to speed up the emulation of GPUs like the RDP.
Another thing I'm considering is potentially doing my own reverse-engineering and seeing if I can make it any faster by making it a bit closer to how the silicon itself works. The cons include that it would effectively have worst-case performance at all times, since all "modules" would need to be advanced, whether in-use or not. It would also be a gargantuan pain in the ass. The pros include that it would give a fixed performance target, be cycle-accurate, (ideally) pass Nintendo's hardware tests, and potentially not be that much slower: 2-cycle mode would actually take two cycles, for instance, not forced through the emulation at once. This would probably be a difficulty level of about 7.5/10.
Then there's the whole subject of accelerating it on the GPU using compute shaders - and some graphics plugins for other N64 emulators have done this - but then we get into the realm of requiring a Herculean amount of effort, and knowledge that simply doesn't exist on the MAME team, myself included. Difficulty, 10/10, as with Konami GX.
> F-32, DGPIX,
> Eolith, Vegaeo?
These all use the E132XS "Hyperstone" derived CPU core. It's a pretty advanced CPU, but it's been years since the core was written, and it could use some love. Someone should throw a performance profiler at it and see what shakes loose, there could be some low-hanging fruit. If that were to be the case, the difficulty would probably me maybe 3.5/10.
A more difficult, but still doable, option would be to write a DRC frontend for it. It's fast enough to be worth it, though it of course would be a bit tough, as writing a DRC frontend tends to be. This one would probably be a 6/10.
> Ghosteo
This has a fairly fast ARM9 CPU, and profiling indicates that there isn't much to be done to make the ARM core faster in MAME. This one will require writing a DRC frontend for ARM architecture. On the bright side, I've had that exact project on my backburner for a while, and I've slowly been chipping away at it. Maybe 5/10 in difficulty, given what's left to do.
So yes, all of them can potentially be made faster. Will they be made faster? Who knows. But they can be. 
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370691 - 10/31/17 10:56 PM
|
|
|
Thank you for telling me good news. I was most concerned about the Hyperstone and Arm 9 games running faster, and it looks like they can fairly easily.
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370692 - 10/31/17 11:12 PM
|
|
|
Given the vast amount of hardware of all sorts using ARM parts, a DRC frontend for the ARM core seems like it would benefit a lot of different drivers
|
|
|
|
|
> Thank you for telling me good news. I was most concerned about the Hyperstone and Arm
> 9 games running faster, and it looks like they can fairly easily.
Yeah, I thought so a few hours ago, too. Then I spent a few hours picking at what I thought was low-hanging fruit for optimization in the Hyperstone core, and wound up making the damn thing about 15% slower in the process.
I'm going to defer to R. Belmont here in that nobody really knows anymore what the hell will make a particular compiler or CPU happy.
|
|
|
|
|
|
|
|
|
> Thank you for telling me good news. I was most concerned about the Hyperstone and Arm
> 9 games running faster, and it looks like they can fairly easily.
I just pushed an optimization to the Hyperstone core. On my machine, elfin consistently ran a -bench 60 at 260-262% before my change, and 291-293% afterward. What sort of speeds do you get before/after, if you're able to compile your own build?
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370712 - 11/01/17 10:58 PM
|
|
|
> > Thank you for telling me good news. I was most concerned about the Hyperstone and
> Arm
> > 9 games running faster, and it looks like they can fairly easily.
>
> I just pushed an optimization to the Hyperstone core. On my machine, elfin
> consistently ran a -bench 60 at 260-262% before my change, and 291-293% afterward.
> What sort of speeds do you get before/after, if you're able to compile your own
> build?
I can't build my own MAME, but I just measured the speed of Elfin on an old build. The speed changes frequently; mostly it stays between 65%-85% during gameplay, sometimes dropping to as low as 25% for a second. Hopefully your speedup will make it run at 96% or higher on my computer.
|
|
|
| Asure |
|
MAME Fan
|
|
|
|
|
|
Reged: 11/29/04
|
|
Posts: 40
|
|
Loc: Nederland
|
|
|
|
Send PM
|
|
|
Re: MAME 0.191
[Re: Smitdogg]
#370713 - 11/01/17 11:34 PM
|
|
|
I totally dropped the ball by using a wrong perspective on the 'better than' comment. I work a lot with embedded hardware and from a hardware perspective it runs at higher speeds and does not suffer from (albeit) intended slowdown.
I didn't mean to claim the emulation was now running cycle-accurate as on a real board
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370715 - 11/02/17 12:13 AM
|
|
|
> > Thank you for telling me good news. I was most concerned about the Hyperstone and
> Arm
> > 9 games running faster, and it looks like they can fairly easily.
>
> I just pushed an optimization to the Hyperstone core. On my machine, elfin
> consistently ran a -bench 60 at 260-262% before my change, and 291-293% afterward.
> What sort of speeds do you get before/after, if you're able to compile your own
> build?
I just tested the other drivers on an old build. Crazy War runs at 89%-100%; I thought it ran much slower because the sound stutters. Mosaic runs at 39%-70%, Puzzle King runs at 46%-52%, and Happy Tour runs at 22%-24% during gameplay.
|
|
|
|
|
> I just tested the other drivers on an old build. Crazy War runs at 89%-100%; I
> thought it ran much slower because the sound stutters. Mosaic runs at 39%-70%, Puzzle
> King runs at 46%-52%, and Happy Tour runs at 22%-24% during gameplay.
Good lord, what sort of computer do you have when my almost 3 year old laptop can pull around 200-250% on the same driver? A Commodore 64?
I don't mean to be insulting here, just realistic. If the games are that slow on your computer, there's little chance that any optimizations I do to the interpreter core are suddenly going to push these games into the realm of full speed. 
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370728 - 11/02/17 02:16 PM
|
|
|
|
|
|
Re: MAME 0.191
[Re: Osso1]
#370786 - 11/04/17 09:55 PM
|
|
|
> I'd like to benchmark on my PC but I don't see your commit, unless I'm missing
> something. Last update to the Hyperstone CPU seems from July:
> https://git.redump.net/mame/log/src/devices/cpu/e132xs
Yeah, I forgot to push. I've pushed that plus some other optimizations. Overall, elfin ran at around 200% unthrottled before my changes, and now runs at around 330% unthrottled, according to -bench 60. I'm pretty happy with that.
|
|
|
|
Re: MAME 0.191
[Re: MooglyGuy]
#370799 - 11/05/17 08:51 AM
|
|
|
Nice job! I tried elfin, mosaicf2 and vamphalf and all had a nice speed up.
|
.
|
|
|
Re: MAME 0.191
[Re: Vas Crabb]
#370808 - 11/05/17 10:44 PM
|
|
|
I like how new releases are presented like this, a couple of paragraphs informing us whats been improved etc... it's clean and concise. Thanks
P.S. Also never try and hide or make the info the smallest print either please, when it involves games being removed by the request of the manufacturer.
By the way current games should never need to be removed correct ? Wasn't it a while ago you guys sent out letters basically asking for permission from the manufacturers to include their games in mame ?
Edited by MKFAN (11/06/17 11:20 PM)
|
|
|
|
Re: MAME 0.191
[Re: MKFAN]
#370843 - 11/07/17 12:07 AM
|
|
|
> I like how new releases are presented like this, a couple of paragraphs informing us
> whats been improved etc... it's clean and concise. Thanks
I totally agree. It's extremely helpful and informative. Thanks Vas and team for these little things that make each MAME release even more a pleasure.
|
|
|
|
Index 
Threaded 
MAME 0.191
Reply
[Re: 
