redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
MAME 0.145u1
#276551 - 02/19/12 06:23 PM
|
|
|
http://mamedev.org
0.145u1 -------
MAMETesters Bugs Fixed ---------------------- - 04668: [Interface] megatech, stvbios: Crash After Cartridge Selected in File Manager Menu (Softlist) (Miodrag Milanovic) - 04689: [Documentation] ep_pkni: The correct description is "Phoenix Knights (The) (Global) (EPOCH)". - 04688: [Documentation] sc2rock: The correct description is "How Big's Your Rock? (Global) (Scorpion 2/3)". - 04687: [Documentation] ep_milhr: The correct description is "Who Wants To Be A Millionhare? (Global) (EPOCH)". - 04683: [Documentation] hb_mrmon: The correct description is "Mr. Money (Qps)". - 04682: [Documentation] hb_ydd: The correct description is "Yabba- Dabba-Dough (Qps)". - 04680: [Documentation] sc4qmodo and clones: Missing an apostrophe. The correct description is "Quazzi Mo' Dough (Qps) (Scorpion 4) (set 1)". - 04690: [Documentation] ep_beavr and clone: The correct description is "Casino Beaver Las Vegas! (Global) (EPOCH, set 1)". - 04685: [DIP/Input] yosakdon, yosakdona: Unable to control players (Tafoid) - 04675: [DIP/Input] steeltal and clones: Control Issues and Resets (Phil Bennett) - 04672: [Sound] radrad: [possible] Broken shot sound (DAC) (hap) - 04673: [Color/Palette] springer: Rabbit has wrong colors. (M.A.S.H.) - 04666: [Sound] spacelnc: Missing one DAC sound. (hap) - 02580: [Crash/Freeze] dirtfoxj: Game freezes immediately after the race start countdown. (Phil Bennett) - 04655: [Graphics] All sets in stv.c: Graphic corruption (hap)
Source Changes -------------- Minor improvements to the Cool Riders text layer. [Andrew Gardner]
m68k: 68040 MMU improvements [O. Galibert]
i386: Fixes for DOS4GW 1.97 [Carl]
i386: Trap flag support [Carl]
New modern object-oriented bus-signals-available SCSI implementation [O. Galibert]
IDE controller now support two slots, currently used devices are made as slot devices [Miodrag Milanovic]
Namco System 21/2 changes: [Phil Bennett] * Writing a C148 IRQ priority register now clears the prior interrupt state (required by dirtfoxj and winrun) * Changed 'Winning Run Suzuka Grand Prix (Japan)' setname to winrungp * Promoted winrungp and winrun91 to working.
tsamurai.c: Fixed clocks and audio pitch. [Takahiro Nogi]
Added polynew.h multithreaded-render support to N64 RDP emulation. Speedup ratios of 1.6x to 2.8x observed. [Ryan Holtz]
Redone 30test layout, resembling the cabinet more [hap]
Add LZMA codec and .7z container support [David Haywood, R. Belmont]
updated sdl os-core to compile against stock SDL-2.0 [couriersud] * The SDL team has moved from 1.3 to 2.0. At the same time, changes were made to allow SDL1.2 and SDL2.0 to coexist. All SDL2.0 include files are now in /usr/include/SDL2. * Added sdlinc.h to avoid having tons of #ifdef .. #include in the code. * Scalemode is no longer a per-window setting * Fixed a bug in YUV rendering. * Use SDL_GetClipboard (SDL2.0) * Updated README_SDL20.txt Currently, SDL 2.0 is only supported on *nix. Volunteers welcome.
Various N64 stability fixes. [Ryan Holtz]
Steel Talons: Fixed controls and removed the MSP speedup hack which was causing the game to reset at certain points. [Phil Bennett]
NMK16 priority fixes [Raiden II Project Team]
N64: Partially fix PIF access, several more games recognize cart SRAM, cart FlashROM, cart EEPROM, and controller paks [Ryan Holtz]
68040: Fix for fsave opcode [O. Galibert]
Added support for (track)balls to osd/sdl. [Couriersud]
Fixed testkeys to work with SDL2.0. Keymaps can now contain SDL1.3 and SDL2.0 mappings. Updated km-de.txt as an example. [Couriersud]
Major CHD/chdman update: [Aaron Giles] The CHD version number has been increased from 4 to 5. This means any diff CHDs will no longer work. If you absolutely need to keep the data for any existing ones you have, find both the diff CHD and the original CHD for the game in question and upgrade using these commands:
rename diff\game.dif diff\game-old.dif chdman copy -i diff\game-old.dif -ip roms\game.chd -o diff\game.dif -op roms\game.chd -c none
Specifics regarding this change:
Defined a new CHD version 5. New features/behaviors of this version: * support for up to 4 codecs; each block can use 1 of the 4 * new LZMA codec, which tends to do better than zlib overall * new FLAC codec, primarily used for CDs (but can be applied anywhere) * upgraded AVHuff codec now uses FLAC for encoding audio * new Huffman codec, used to catch more nearly-uncompressable blocks * compressed CHDs now use a compressed map for significant savings * CHDs now are aware of a "unit" size; each hunk holds 1 or more units (in general units map to sectors for hard disks/CDs) * diff'ing against a parent now diffs at the unit level, greatly improving compression
Rewrote and modernized chd.c. CHD versions prior to 3 are unsupported, and version 3/4 CHDs are only supported for reading. Creating a new CHD now leaves the file open. Added methods to read and write at the unit and byte level, removing the need to handle this manually. Added metadata access methods that pass astrings and dynamic_buffers to simplify the interfaces. A companion class chd_compressor now implements full multithreaded compression, analyzing and compressing multiple hunks independently in parallel. Split the codec implementations out into a separate file chdcodec.*
Updated harddisk.c and cdrom.c to rely on the caching/byte-level read/ write capabilities of the chd_file class. cdrom.c (and chdman) now also pad CDs to 4-frame boundaries instead of hunk boundaries, ensuring that the same SHA1 hashes are produced regardless of the hunk size.
Rewrote chdman.exe entirely, switching from positional parameters to proper options. Use "chdman help" to get a list of commands, and "chdman help " to get help for any particular command. Many redundant commands were removed now that additional flexibility is available. Some basic mappings:
Old: chdman -createblankhd New: chdman createhd -o -chs ,,
Old: chdman -createuncomphd .... New: chdman createhd -i -o -c none ....
Old: chdman -verifyfix New: chdman verify -i -f
Old: chdman -merge New: chdman copy -i -ip -o
Old: chdman -diff New: chdman copy -i -o -op
Old: chdman -update New: chdman copy -i -o
Added new core file coretmpl.h to hold core template classes. For now just one class, dynamic_array<> is defined, which acts like an array of a given object but which can be appended to and/or resized. Also defines dynamic_buffer as dynamic_array for holding an arbitrary buffer of bytes. Expect to see these used a lot.
Added new core helper hashing.c/.h which defines classes for each of the common hashing methods and creator classes to wrap the computation of these hashes. A future work item is to reimplement the core emulator hashing code using these.
Split bit buffer helpers out into C++ classes and into their own public header in bitstream.h.
Updated huffman.c/.h to C++, and changed the interface to make it more flexible to use in nonstandard ways. Also added huffman compression of the static tree for slightly better compression rates.
Created flac.c/.h as simplified C++ wrappers around the FLAC interface. A future work item is to convert the samples sound device to a modern device and leverage this for reading FLAC files.
Renamed avcomp.* to avhuff.*, updated to C++, and added support for FLAC as the audio encoding mechanism. The old huffman audio is still supported for decode only.
Added a variant of core_fload that loads to a dynamic_buffer.
Tweaked winwork.c a bit to not limit the maximum number of processors unless the work queue was created with the WORK_QUEUE_FLAG_HIGH_FREQ option. Further adjustments here are likely going to be necessary.
Fixed bug in aviio.c which caused errors when reading some AVI files.
Fixed an issue with text being missing in some Aleck 64 games. [Ryan Holtz]
Reduced memory usage in the N64 driver. [Ryan Holtz] Hook up 64DD RTC and interrupts in the N64 code. [Ryan Holtz, kammedo]
Added warm reset support to N64 hardware [Ryan Holtz]
Fix -romident to work with .7z archives [David Haywood]
Added new CHD codec: CD-FLAC which knows how to shuffle CD data to more optimally use FLAC. Updated flac wrapper to implement a tell callback so FLAC can tell us how much we've decoded. Updated chdman to use CD-FLAC codec in preference over the existing codecs for CDs by default. [David Haywood]
Fail initializing the CD-FLAC codec if the hunk size is not CD-compatible. [Aaron Giles]
Centralize detection of existing output files. Add detection (require --force) for extracted files as well. Move checks outside of try/catch so that the files are not subsequently deleted. [Aaron Giles]
Move all-0 detection to the write path. Use hunk_info on the compression path to detect whether the write went through. [Aaron Giles]
Changed sample pack names for alphamc07 -> equites and aristmk4 -> 3bagflvt to match up sample to an actual setname. [Tafoid]
dma8237: fix uninitialized variable [Hans Ostermeyer]
mc146818: remove previous Apollo hack, fix 32768 Hz. updates [Hans Ostermeyer]
m68k: fix FSGLMUL/FSGLDIV plus some minor MMU improvements [Hans Ostermeyer]
m68k: slightly less stubby CINV [Hans Ostermeyer]
namcos23: documentation update [Guru]
vamphalf.c: Added correct speed up to Diet Family [Dave Haywood]
Assorted N64 SP/DP/CPU comms accuracy fixes. [Ryan Holtz]
Rewrote SAMPLES as a modern device. Updated all callers. FLAC reading is now done using the FLAC wrapper. There is now a samples_iterator class to centralize the logic for handling the sample list walking. [Aaron Giles]
Redid the cheesy half-baked votrax device since it relied on some old samples-based handling. Until we have a real implementation, it would be good to route the various clients through the current one to at least wire it up properly, even if it just plays samples in the end. Will look into that shortly. [Aaron Giles]
Added windows implementation of pseudo tty access functions over pipes [Carl]
Fixed N64 RDP to not try to render a triangle with no spans. [Ryan Holtz]
Sega Model 2 update: [Brian Troha] * Dumped and hooked up Dynamite Baseball * Dynamite Baseball 97 renamed as dynabb97 * Properly renamed 4 MASK ROMs in dynabb97 to match pcb manual * Minor cleanups and fixes
New games added or promoted from NOT_WORKING status --------------------------------------------------- Winning Run [gamerfan, Smitdogg, The Dumping Union] Oozumou - The Grand Sumo (DECO Cassette) [Charles MacDonald, Dr. Spankenstein, Kevin Eshbach, T. Huff, SteveS, E. Page-Hanify, Hikari, ArcadeDude, F. Bukor, N. Francfort, jmurjr, arcade-history.com, ThumB, Hurray Banana, Paratech, Xiaou2, Cornishdavey, A. Costin, M. Ponweiser, Tormod, Rambo, Smitdogg, The Dumping Union] Diet Family [Dr. Spankenstein, Paratech, joe35car, tormod, M. Hoenig, Mosquito2001, M. Ponweiser, M. Viste, Phil Bennett, N. Francfort, A. Costin, J. Finney, gamerfan, Smitdogg, The Dumping Union] Kung-Fu Roushi [hap] Winning Run Suzuka Grand Prix [Phil Bennett] Winning Run 91 [Phil Bennett]
New clones added ---------------- Space Invaders Part II (Brazil) [Marcello Mancini] Print Club 2 Earth Limited Kobe (Print Club Custom) (J 970808 V1.000) [f205v, ranger_lennier, dopefishjustin, Yohji, Smitdogg, The Dumping Union] Eyes (bootleg set) [f205v, Antro] JoJo's Bizarre Adventure (990927) [Layne, Smitdogg, The Dumping Union] Wyvern Wings (alt) [RetroRepair] Dynamite Baseball [Layne, Yohji, hap, Smitdogg, The Dumping Union]
New games marked as GAME_NOT_WORKING ------------------------------------ Soul Surfer (Rev A) [f205v. The Dumping Union] Initial D Arcade Stage Ver. 3 (Export) [f205v, The Dumping Union]
Edited by redk9258 (02/19/12 08:04 PM)
|
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276553 - 02/19/12 06:43 PM
|
|
|
Looks like the update is not ready yet:
Quote:
patching file makefile Hunk #1 FAILED at 639. Hunk #2 succeeded at 731 (offset 1 line). 1 out of 2 hunks FAILED -- saving rejects to file makefile.rej --snip-- patching file src/lib/lib.mak Hunk #7 FAILED at 307. 1 out of 7 hunks FAILED -- saving rejects to file src/lib/lib.mak.rej
This is on linux after fixing the line endings with:
Code:
find . -type f -not -name *.png -exec sed -i 's/\r//' {} \;
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: belegdol]
#276554 - 02/19/12 07:06 PM
|
|
|
The diff file on mamedev.org is OK now. Thanks Kale.
Edited by redk9258 (02/19/12 08:11 PM)
|
|
|
Kale |
Il Sindaco
|
|
|
Reged: 09/26/03
|
Posts: 155
|
Loc: Naples, Italy
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276556 - 02/19/12 07:30 PM
|
|
|
> Use these files instead of the malformed patched ones... > > > makefile > > lib.mak
I love how many times I get free testing from users that believes to be smart by taking a release that wasn't announced in the first place ...
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: Kale]
#276558 - 02/19/12 07:38 PM
|
|
|
Sorry, I thought since it was on mamedev.org is was fair game. Again my apologies.
|
|
|
Kale |
Il Sindaco
|
|
|
Reged: 09/26/03
|
Posts: 155
|
Loc: Naples, Italy
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276559 - 02/19/12 07:44 PM
|
|
|
> Sorry, I thought since it was on mamedev.org is was fair game. Again my apologies.
I'm not complaining about the free testing part per se (that is a good thing and I thank you for that). I'm complaining that things like these should go in private, not in public, that's all.
|
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276562 - 02/19/12 08:13 PM
|
|
|
It seems that laserdisc-related tools do not build (tested on linux with make all):
Quote:
src/tools/ldresample.c: In function 'chd_error open_chd(chd_file&, const char*, movie_info&)': src/tools/ldresample.c:157:74: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c:163:11: error: 'chd' was not declared in this scope src/tools/ldresample.c:166:78: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c:181:23: error: base operand of '->' has non-pointer type 'chd_file' src/tools/ldresample.c: In function 'chd_error create_chd(chd_compressor&, const char*, chd_file&, const movie_info&)': src/tools/ldresample.c:204:26: error: 'class chd_compressor' has no member named 'create' src/tools/ldresample.c:207:79: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c:212:16: error: 'class chd_compressor' has no member named 'clone_all_metadata' src/tools/ldresample.c:215:74: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c:220:16: error: 'class chd_compressor' has no member named 'compress_begin' src/tools/ldresample.c:223:79: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c: In function 'int read_chd(chd_file*, UINT32, movie_info*, UINT32)': src/tools/ldresample.c:237:2: error: 'av_codec_decompress_config' was not declared in this scope src/tools/ldresample.c:237:29: error: expected ';' before 'avconfig' src/tools/ldresample.c:241:2: error: 'avconfig' was not declared in this scope src/tools/ldresample.c:241:29: error: no match for 'operator*' in '*info->_movie_info::bitmap' src/tools/ldresample.c:241:49: error: base operand of '->' has non-pointer type 'bitmap_yuy16' src/tools/ldresample.c:248:25: error: 'AV_CODEC_DECOMPRESS_CONFIG' was not declared in this scope src/tools/ldresample.c:248:62: error: 'chd_codec_config' was not declared in this scope src/tools/ldresample.c:251:39: error: 'chd_read' was not declared in this scope src/tools/ldresample.c: In function 'int write_chd(chd_file*, UINT32, movie_info*)': src/tools/ldresample.c:265:2: error: 'av_codec_compress_config' was not declared in this scope src/tools/ldresample.c:265:27: error: expected ';' before 'avconfig' src/tools/ldresample.c:269:2: error: 'avconfig' was not declared in this scope src/tools/ldresample.c:269:29: error: no match for 'operator*' in '*info->_movie_info::bitmap' src/tools/ldresample.c:269:49: error: base operand of '->' has non-pointer type 'bitmap_yuy16' src/tools/ldresample.c:276:25: error: 'AV_CODEC_COMPRESS_CONFIG' was not declared in this scope src/tools/ldresample.c:276:60: error: 'chd_codec_config' was not declared in this scope src/tools/ldresample.c:279:49: error: 'chd_compress_hunk' was not declared in this scope src/tools/ldresample.c: In function 'void create_close_chd(chd_file*)': src/tools/ldresample.c:295:35: error: 'chd_compress_finish' was not declared in this scope src/tools/ldresample.c:297:76: error: 'chd_error_string' was not declared in this scope src/tools/ldresample.c:299:16: error: 'chd_close' was not declared in this scope src/tools/ldresample.c: In function 'void close_chd(chd_file*, movie_info*)': src/tools/ldresample.c:310:24: error: 'chd_free_buffers' was not declared in this scope src/tools/ldresample.c:311:16: error: 'chd_close' was not declared in this scope src/tools/ldresample.c: In function 'int main(int, char**)': src/tools/ldresample.c:536:60: error: cannot convert 'chd_file' to 'chd_file*' for argument '1' to 'int find_edge_near_field(chd_file*, UINT32, movie_info*, int, INT32*)' src/tools/ldresample.c:548:55: error: invalid initialization of reference of type 'chd_compressor&' from expression of type 'chd_file*' src/tools/ldresample.c:200:18: error: in passing argument 1 of 'chd_error create_chd(chd_compressor&, const char*, chd_file&, const movie_info&)' src/tools/ldresample.c:597:50: error: cannot convert 'chd_file' to 'chd_file*' for argument '1' to 'int read_chd(chd_file*, UINT32, movie_info*, UINT32)' src/tools/ldresample.c:619:56: error: cannot convert 'chd_file' to 'chd_file*' for argument '1' to 'int read_chd(chd_file*, UINT32, movie_info*, UINT32)' src/tools/ldresample.c:630:26: error: cannot convert 'chd_file' to 'chd_file*' for argument '1' to 'void close_chd(chd_file*, movie_info*)' src/tools/ldverify.c: In function 'void* open_chd(const char*, movie_info*)': src/tools/ldverify.c:212:30: error: 'CHD_OPEN_READ' was not declared in this scope src/tools/ldverify.c:212:57: error: 'chd_open' was not declared in this scope src/tools/ldverify.c:215:74: error: 'chd_error_string' was not declared in this scope src/tools/ldverify.c:220:103: error: 'chd_get_metadata' was not declared in this scope src/tools/ldverify.c:223:78: error: 'chd_error_string' was not declared in this scope src/tools/ldverify.c:224:16: error: 'chd_close' was not declared in this scope src/tools/ldverify.c:232:16: error: 'chd_close' was not declared in this scope src/tools/ldverify.c:238:38: error: 'chd_get_header' was not declared in this scope src/tools/ldverify.c: In function 'int read_chd(void*, int, bitmap_yuy16&, INT16*, INT16*, int*)': src/tools/ldverify.c:263:2: error: 'av_codec_decompress_config' was not declared in this scope src/tools/ldverify.c:263:29: error: expected ';' before 'avconfig' src/tools/ldverify.c:275:3: error: 'avconfig' was not declared in this scope src/tools/ldverify.c:284:38: error: 'AV_CODEC_DECOMPRESS_CONFIG' was not declared in this scope src/tools/ldverify.c:284:75: error: 'chd_codec_config' was not declared in this scope src/tools/ldverify.c:287:82: error: 'chd_read' was not declared in this scope src/tools/ldverify.c: In function 'void close_chd(void*)': src/tools/ldverify.c:304:28: error: 'chd_close' was not declared in this scope make: *** [obj/sdl/tools/ldresample.o] Error 1 make: *** Waiting for unfinished jobs.... make: *** [obj/sdl/tools/ldverify.o] Error 1
|
|
|
|
Re: MAME 0.145u1
[Re: belegdol]
#276563 - 02/19/12 08:16 PM
|
|
|
Same error here.... =S
|
Sorry, my English is bad!!!
Slackware Linux 14.2 beta 2/Fluxbox 1.3.7
Linux user #438128
MAME for Slackware
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
|
|
|
Re: MAME_0.145u1b_32-bit...
[Re: redk9258]
#276568 - 02/19/12 08:58 PM
|
|
|
|
Naoki |
|
|
|
Reged: 11/10/09
|
Posts: 1998
|
Loc: United Kingdom
|
|
Send PM
|
|
|
CHDMAN
[Re: redk9258]
#276572 - 02/19/12 10:20 PM
|
|
|
Since I see the options have been changed drasticly, will CHDMAN create folders if they don't exist? I really wished sometimes it would. Otherwise, nice to see some more options, even if I will have to relearn settings and that I already hate change XP
|
----
On a quest for Digital 573 and Dancing Stage EuroMix 2
By gods I've found it!
|
|
MASH |
MASH
|
|
|
Reged: 09/26/03
|
Posts: 1775
|
Loc: Germany
|
|
Send PM
|
|
|
CHDs inside ZIPs is missing...
[Re: Naoki]
#276576 - 02/19/12 10:41 PM
|
|
|
MAME can't find the CHD in the romset ZIP.
MAME 0.130: Allow CHDs to be directly in the rom directory without a subdirectory [Olivier Galibert].
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
|
> Same error here.... =S
Correct. Kale releases on Sundays when he has the time, which isn't always when the code is in a good state
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: CHDs inside ZIPs is missing...
[Re: MASH]
#276581 - 02/19/12 11:22 PM
|
|
|
> MAME can't find the CHD in the romset ZIP. > > > > > MAME 0.130: Allow CHDs to be directly in the rom directory without a subdirectory > [Olivier Galibert].
In the ROM directory doesn't mean in the zip file!
|
|
|
MASH |
MASH
|
|
|
Reged: 09/26/03
|
Posts: 1775
|
Loc: Germany
|
|
Send PM
|
|
|
Re: Test it!
[Re: redk9258]
#276583 - 02/19/12 11:32 PM
|
|
|
> > MAME can't find the CHD in the romset ZIP. > > > > > > > > > > MAME 0.130: Allow CHDs to be directly in the rom directory without a subdirectory > > [Olivier Galibert]. > > In the ROM directory doesn't mean in the zip file!
Check it with MAME 0.145. Use the konam80s CHD (826eaa01.chd) put it into the zip and start MAME!
|
|
|
|
Re: MAME 0.145u1
[Re: Kale]
#276585 - 02/19/12 11:51 PM
|
|
|
Whats the big deal?
If something doesnt work, people dont really blame you or whomever. They bring it to peoples attention, to get fixed... not to try to make people feel bad.
You should not take it personally. Nobody else does.
Furthermore, theres neither no way to make everyone Hide their posts on such a subject.. nor would you really want that. Its quick feedback, its free, and its good.
Its also far easier than joining a bug finding team, which many just wont put that kind of effort into doing.
If you put the project underground... than that means keeping beta releases from the public.. which then causes slower progress, less positive growth feedback, and other problems, such as shunning its many non-dev supporters.
|
|
|
Naoki |
|
|
|
Reged: 11/10/09
|
Posts: 1998
|
Loc: United Kingdom
|
|
Send PM
|
|
|
Re: Test it!
[Re: MASH]
#276587 - 02/20/12 12:32 AM
|
|
|
> > > MAME can't find the CHD in the romset ZIP. > > > > > > > > > > > > > > > MAME 0.130: Allow CHDs to be directly in the rom directory without a subdirectory > > > [Olivier Galibert]. > > > > In the ROM directory doesn't mean in the zip file! > > Check it with MAME 0.145. Use the konam80s CHD (826eaa01.chd) put it into the zip > and start MAME!
It means you don't need the chd to be placed within it's own folder and can be at the root of you rom path
Edited by Naoki (02/20/12 12:37 AM)
|
----
On a quest for Digital 573 and Dancing Stage EuroMix 2
By gods I've found it!
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276589 - 02/20/12 01:05 AM
|
|
|
|
Sune |
Connected
|
|
|
Reged: 09/21/03
|
Posts: 5648
|
Loc: Lagoa Santa, Brasil
|
|
Send PM
|
|
|
chd update trouble
[Re: redk9258]
#276596 - 02/20/12 04:05 AM
|
|
|
> Old: chdman -update New: chdman copy -i -o
I'm trying to update my hydro thunder chd: chdman copy -i hydro_old.chd -o hydro.chd
It's not working for me. First time it hung on 29%, I left it for almost an hour. I quit and tried again and now it's hanging at 37%.
/EDIT
OK it worked the third time.. strange.
S
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: chd update trouble
[Re: Sune]
#276600 - 02/20/12 04:46 AM
|
|
|
> I'm trying to update my hydro thunder chd: > chdman copy -i hydro_old.chd -o hydro.chd > > It's not working for me. First time it hung on 29%, I left it for almost an hour. I > quit and tried again and now it's hanging at 37%. > > /EDIT > > OK it worked the third time.. strange. > > S
I'm not sure what you got going on but it's contagious! My PC froze solid while viewing your post. That don't happen very often. I think this may be the second or third time in over two years.
|
|
|
|
Thank You (nt)
[Re: redk9258]
#276603 - 02/20/12 05:14 AM
|
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME_0.145u1b_64-bit...
[Re: redk9258]
#276632 - 02/20/12 12:31 PM
|
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276639 - 02/20/12 01:35 PM
|
|
|
thanks. do I really need to update my current CHD files ? I'm asking because I just tried vaportrx without updating the CHD file and it still works.
also, I used chdman to update the file and it got bigger... I thought this new header version would make CHD files smaller.
|
Ciro Alfredo Consentino
home: http://emuloader.mameworld.info
e-mail: [email protected]
|
|
|
|
> thanks. > do I really need to update my current CHD files ? I'm asking because I just tried > vaportrx without updating the CHD file and it still works. > > also, I used chdman to update the file and it got bigger... I thought this new header > version would make CHD files smaller.
no. updating chds to v5 will only save some space (how much depends on the CHD, and Laserdisk will save less than others), but v4 CHDs will remain fully compatible for long time
the only exception is for MESS CHD containing hard disk images for PC or Mac drivers: those CHDs needs to be writeable for the emulated OS to write on them, and therefore they need to be updated because v4 compatibility is read only.
summarizing: read-only CHDs (*all* MAME ones and the MESS ones containing CD dumps) do not need to be updated unless you want to see how much space you can save; writeable CHDs (MESS one for emulated HDs) need to be updated to keep working
|
|
|
|
Re: chd update trouble
[Re: Sune]
#276642 - 02/20/12 02:00 PM
|
|
|
> > Old: chdman -update New: chdman copy -i -o > > I'm trying to update my hydro thunder chd: > chdman copy -i hydro_old.chd -o hydro.chd > I will rather say: chdman copy -i hydro.chd -o hydro_new.chd
remove hydro.chd and rename hydro_new to hydro.chd
|
Sorry for my poor english^^
エツ
|
|
Sune |
Connected
|
|
|
Reged: 09/21/03
|
Posts: 5648
|
Loc: Lagoa Santa, Brasil
|
|
Send PM
|
|
|
Re: chd update trouble
[Re: xibic]
#276645 - 02/20/12 02:43 PM
|
|
|
> > > Old: chdman -update New: chdman copy -i -o > > > > I'm trying to update my hydro thunder chd: > > chdman copy -i hydro_old.chd -o hydro.chd > > > I will rather say: > chdman copy -i hydro.chd -o hydro_new.chd > > remove hydro.chd and rename hydro_new to hydro.chd
Why? The filename shouldn't make any difference. It should work just as well if renamed to yourmom.chd or whatever. I renamed it first instead of using -f which turned out to be a good idea since it didn't work. If I hadn't renamed the chd I would probably have lost it.
S
|
|
|
|
Re: chd update trouble
[Re: Sune]
#276647 - 02/20/12 02:53 PM
|
|
|
> > > > Old: chdman -update New: chdman copy -i -o > > > > > > I'm trying to update my hydro thunder chd: > > > chdman copy -i hydro_old.chd -o hydro.chd > > > > > I will rather say: > > chdman copy -i hydro.chd -o hydro_new.chd > > > > remove hydro.chd and rename hydro_new to hydro.chd > > Why? The filename shouldn't make any difference. It should work just as well if > renamed to yourmom.chd or whatever. > I renamed it first instead of using -f which turned out to be a good idea since it > didn't work. If I hadn't renamed the chd I would probably have lost it. > > S
I think he was just saying that most probably you were starting from hydro.chd as input and converting it to a hydro_new.chd as output I doubt he was claiming filenames do any difference: if you first changed name to your chd from hydro to hydro_old and then you used your command line, of course you got the same result of his command line
the only thing to avoid is
chdman copy -i hydro.chd -o hydro.chd
which would overwrite your original file when starting the process and you'd lose it if anything goes wrong
|
|
|
Sune |
Connected
|
|
|
Reged: 09/21/03
|
Posts: 5648
|
Loc: Lagoa Santa, Brasil
|
|
Send PM
|
|
|
Re: chd update trouble
[Re: etabeta]
#276650 - 02/20/12 03:31 PM
|
|
|
> I think he was just saying that most probably you were starting from hydro.chd as > input and converting it to a hydro_new.chd as output > I doubt he was claiming filenames do any difference: if you first changed name to > your chd from hydro to hydro_old and then you used your command line, of course you > got the same result of his command line
That's what I did. > the only thing to avoid is > > chdman copy -i hydro.chd -o hydro.chd > > which would overwrite your original file when starting the process and you'd lose it > if anything goes wrong
Yep, which is why I renamed it to hydro_old first!
S
|
|
|
|
|
> do I really need to update my current CHD files ?
I don't know why anyone would update all their samples or CHD files for a "u" version. From my understanding, "u" releases are like development snapshots between major releases. It's entirely possible that this new 7-zip and FLAC stuff may change before MAME 0.146 is released.
Though, I guess someone has to be the guinea pig to try this stuff out and find bugs before the next release, so carry on.
> also, I used chdman to update the file and it got bigger... I thought this new header > version would make CHD files smaller.
My understanding is that there is a tiny amount of overhead to store the information about what compression algorithm to use for each block, however that should be negated by the higher compression ratios of the new algorithms. I guess it's possible, but not likely, that the best compression algorithm for each block ends up being "zip" (like in the v4 CHD) and the overhead makes the file larger.
Someone should convert ALL the CHDs and post a list of before/after sizes.
|
GroovyMAME support forum on BYOAC
|
|
Tafoid |
I keep on testing.. testing.. testing... into the future!
|
|
|
Reged: 04/19/06
|
Posts: 3135
|
Loc: USA
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: krick]
#276667 - 02/20/12 05:43 PM
|
|
|
> > do I really need to update my current CHD files ? > > I don't know why anyone would update all their samples or CHD files for a "u" > version. From my understanding, "u" releases are like development snapshots between > major releases. It's entirely possible that this new 7-zip and FLAC stuff may change > before MAME 0.146 is released.
This is, of course, a very good point. There is no harm in using v4 at all. v5 CHD's share the same SHA1 hashes as v5, just use alternate compression (which is selectable by user). Just know, once you convert, those CHD's cannot be used on anything earlier that 0.145u1 and it is not a trivial effort to convert it back to v4. I'm avoiding it (for those compatibility reasons) because I need to be able to test older version for bug testing. Others may not care, but know what you are getting into. There is no RUSH unless a version change becomes mandatory, which this is not.
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: etabeta]
#276671 - 02/20/12 06:01 PM
|
|
|
thank you all for the tips. I will not convert my CHD files, for now. But I need to convert some of them to support header v5 in my frontend.
|
|
|
Sune |
Connected
|
|
|
Reged: 09/21/03
|
Posts: 5648
|
Loc: Lagoa Santa, Brasil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: krick]
#276676 - 02/20/12 06:08 PM
|
|
|
> Someone should convert ALL the CHDs and post a list of before/after sizes.
Converting the Hydro Thunder CHD to v5 shaves off about 20MB.
S
|
|
|
|
Are the CHD changes safe or is it recommended to wait?
[Re: redk9258]
#276687 - 02/20/12 07:51 PM
|
|
|
Anyone in the know have any recommendation. From looking at the MESS SVN, there are still fixes coming in.
The conversion time and required disk space are not the issue. I simply don't want to destroy any necessary data.
Any help would be appreciated.
|
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: Pr3tty F1y]
#276688 - 02/20/12 07:59 PM
|
|
|
> Anyone in the know have any recommendation. From looking at the MESS SVN, there are > still fixes coming in. > > The conversion time and required disk space are not the issue. I simply don't want to > destroy any necessary data. > > Any help would be appreciated.
Unless you do something silly like using the same filename for input and output (which would overwrite your file), there is no way to destroy necessary data. the worst it can happen is that chdman crashes or hangs and no v5 CHD is created, so that you remain with your v4 CHD only. if the conversion/copy ends successfully and you want to be over-paranoid, just run "chdman verify -i your_new.chd" to see if the new chd is fine
Remember anyway that if you update the CHD they won't work on older MAME versions
For the record, all the fixes you saw in MESS svn were to fix creation of new blank CHDs for use as HDs in computer emulation. Possibly, there will be more fixes to avoid current random hangs, but as stated above the 0.145u1 code already produces perfectly stable CHDs when the process completes fine.
|
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276697 - 02/20/12 09:20 PM
|
|
|
Can someone please post detailed instructions on how to update/convert an entire current CHD directory which is version 4 to another CHD directory which is version 5 and also how to verify that the conversion has worked - ie:
g:\CHD_V4
to
g:\CHD_V5
Other questions:
1) What is the main purpose of updating CHD's to V5? Is it because files are compressed more in V5 than in V4. If so, how much space is saved between an entire CHD collection (Mame 0.45) once converted to V5 when compared to version 4?
|
|
|
|
Re: MAME 0.145u1
[Re: Doosh]
#276698 - 02/20/12 09:24 PM
|
|
|
re-read the whatsnew for the update syntax and browse the rest of the topic for the other answers
|
|
|
|
Re: MAME 0.145u1
[Re: Doosh]
#276699 - 02/20/12 09:29 PM
|
|
|
> Can someone please post detailed instructions on how to update/convert an entire > current CHD directory which is version 4 to another CHD directory which is version 5 > and also how to verify that the conversion has worked - ie: > > g:\CHD_V4 > > to > > g:\CHD_V5
Code:
for %i in (g:\CHD_V4\*.chd) do chdman copy -i %i -o g:\CHD_V5\%~nxi
|
|
|
|
Re: MAME 0.145u1
[Re: AaronGiles]
#276713 - 02/20/12 10:48 PM
|
|
|
|
Dullaron |
Diablo III - Dunard #1884
|
|
|
Reged: 07/22/05
|
Posts: 6125
|
Loc: Fort Worth, Tx
|
|
Send PM
|
|
|
Re: MAME_0.145u1b_64-bit...
[Re: redk9258]
#276733 - 02/21/12 03:50 AM
|
|
|
> See attached.
Thanks. I never could get it to build.
Edit: Look like someone else had the same issue that I have.
|
|
|
redk9258 |
Regular
|
|
|
Reged: 09/21/03
|
Posts: 3968
|
Loc: Troy, Illinois USA
|
|
Send PM
|
|
|
Re: MAME_0.145u1b_64-bit...
[Re: Dullaron]
#276736 - 02/21/12 04:06 AM
|
|
|
> Thanks. I never could get it to build. > > Edit: Look like someone else had the same issue that I have.
There is something wrong with ldverify, which you can probably get by without for now. I just used the -i option with make to ignore the errors. All of the rest of the stuff compiled fine.
|
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: etabeta]
#276739 - 02/21/12 04:53 AM
|
|
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: krick]
#276744 - 02/21/12 05:25 AM
|
|
|
> >...but as stated above the 0.145u1 code already produces > > perfectly stable CHDs when the process completes fine. > > > Or not... http://mametesters.org/view.php?id=4699
My choice would be to wait for an official release before converting all. Not because u1 may be untrusted, but because apparently and according to certain blog, the release was rushed and there's a possibility compression ratio may improve. Plus some bug fixes during the reimplementation code are still needed. This is a chance for testing as many as you can though.
|
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: krick]
#276771 - 02/21/12 12:00 PM
|
|
|
apparently there are two different issues involved: on one hand, CHD-CDs created with very old chdman got metadata updated in this passage and this changes the resulting sha1. this is sort of correct, in the sense that these old CDs miss pregap/postgap data and should be anyway marked as bad_dumps until they can be redumped. in other words, it is the old sha1 which was wrong in a sense (but the new one might be wrong too, if the disks need gaps data, so in both cases they should be considered as bad dumps)
otoh, the issue with laserdisks (and apparently gdroms too) is something different still under investigation
so yeah, there is something not very stable at the moment in the code, but I'm not sure about how bad the situation is
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: etabeta]
#276815 - 02/21/12 09:57 PM
|
|
|
GD-ROMs are a subset of the CD-ROM issue; some of them also were old-format CHTR metadata and the upgrade on the metadata changes the SHA1 (but not the "Data SHA1", indicating no changes or damage to the actual data). GD-ROMs created with 2009 or later versions of chdman (such as initdv3e which I just added in u1) will update to v5 with no SHA1 changes at all.
So the source needs to be updated to the new SHA1s where applicable for these GD-ROMs, but no further action needs to be taken. (As opposed to CD-ROMs where the source should be updated *and* those sets should be marked BAD_DUMP).
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: BIOS-D]
#276823 - 02/21/12 11:03 PM
|
|
|
> My choice would be to wait for an official release before converting all. Not because > u1 may be untrusted, but because apparently and according to certain blog, the > release was rushed
I wish. The truth is that Kale releases on random Sundays when he has free time. Devs get about a 12 hour advance warning, and for devs in the US a large chunk of that time is when we're normally asleep due to how the time zones line up. It wasn't a rush, it was just a snapshot of SVN at an inopportune time. Since the "old" CHDs all continue to work flawlessly (and in fact you'll have less hassle with u1 if you *don't* update your CHDs) there's no reason to panic.
|
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: R. Belmont]
#276830 - 02/21/12 11:56 PM
|
|
|
> > My choice would be to wait for an official release before converting all. Not > because > > u1 may be untrusted, but because apparently and according to certain blog, the > > release was rushed > > I wish. The truth is that Kale releases on random Sundays when he has free time. Devs > get about a 12 hour advance warning, and for devs in the US a large chunk of that > time is when we're normally asleep due to how the time zones line up. It wasn't a > rush, it was just a snapshot of SVN at an inopportune time. Since the "old" CHDs all > continue to work flawlessly (and in fact you'll have less hassle with u1 if you > *don't* update your CHDs) there's no reason to panic.
Thanks much for that info. to you.
|
|
|
|
Re: MAME 0.145u1
[Re: AaronGiles]
#276833 - 02/22/12 12:32 AM
|
|
|
> > Can someone please post detailed instructions on how to update/convert an entire > > current CHD directory which is version 4 to another CHD directory which is version > 5 > > and also how to verify that the conversion has worked - ie: > > > > g:\CHD_V4 > > > > to > > > > g:\CHD_V5 > > > for %i in (g:\CHD_V4\*.chd) do chdman copy -i %i -o g:\CHD_V5\%~nxi
I turned that into a .bat file and added some tweaks to it so it runs in low priority, so I can run other programs on my system without it lagging the entire system out.
Here is the content of chd.bat: for %%i in (g:\CHD_v4\*.chd) do %comspec% /c start /low /wait chdman copy -i %%i -o g:\CHD_v5\%%~nxi
This will kick off a new cmd.exe process for each call to chdman.exe that will close when completed, then a new window will open.
/wait added to it will prevent it from trying to execute 438 simultaneous instances of chdman. It will still run one at a time.
If you don't want new windows to pop in and out, and instead want it all to run in the window window, you can add a /b in the list of arguments before chdman, but then you lose the ability to CTRL-C terminate.
In case anyone was wondering how long this process takes and what disk space is saved, I started the process last night to see for myself. Here are my findings:
Size of CHD_v4 directory: 240,243,510,229 bytes Size of CHD_v5 directory: 230,936,465,918 bytes (a 3.87% reduction in size)
Process started: 21:18 Monday Process ended: 16:11 Tuesday Duration: 18 hours, 53 minutes
Of course, your mileage may vary depending on your system's specs vs. mine.
I've done all the work in separate directories from my MAME library, so I wouldn't mess anything up. So I don't know how CLRMamePro will handle the v5 CHD files yet. I'll probably will run a similar process again when .146 is released and then merge them into my library at that time.
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: Are the CHD changes safe or is it recommended to wait?
[Re: Pr3tty F1y]
#276842 - 02/22/12 01:18 AM
|
|
|
I tested a bunch of games that use CHD files and all of them worked with 0.145u1 (no update needed).
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: Llaffer]
#276848 - 02/22/12 02:23 AM
|
|
|
> So I don't know how CLRMamePro will handle the v5 CHD files yet.
clrmamepro 4.03a handles CHDs just fine. See that whatsnew on Roman's site for information and instructions.
His forums are here. http://www.emulab.it/forum/index.php
|
|
|
|
current chdman state...
[Re: R. Belmont]
#276885 - 02/22/12 10:57 AM
|
|
|
I think this post I made half an hour ago
http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=276883
covers the current situation, but please let me know of any inaccuracy so that I can fix it.
I really hope that the memory issues reported by Jurgen after a valgrind run are the reason of all the current problems (including chdman getting miscompiled by Apple GCC with default OPTIMIZE value ), so that we can fix all of them at once
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#276899 - 02/22/12 04:20 PM
|
|
|
CHD type info on games with CHD broken in this update ? games like "Taito G-NET" use vPCMIA II Cards, not HDDs until v0.145 they were listed as "card" in the disk region (-listxml output).
now, with v0.145u1 their region are all listed as "drive_0" and there is a new entry set "< slot", but instead of being listed as "card" they have a "hdd" tag for ALL games.
is this right or it will change in the future ? What are these new "< slot" entries for ?
Support for CHD types filters in my frontend is completely broken now I might just have to drop CHD type filters completely and list them only has "games with CHD"
Code:
< game name="flipmaze" sourcefile="taitogn.c" romof="taitogn" > < disk name="flipmaze" region="drive_0" /> < slot name="drive_0" > < slotoption name="hdd" /> slot > < slot name="drive_1" > < slotoption name="hdd" /> < /slot > < /game >
old entries (until v0.145)
Code:
< game name="flipmaze" sourcefile="taitogn.c" romof="taitogn" > < disk name="flipmaze" region="card" /> < /game >
thank you for any info on this.
Edited by CiroConsentino (02/22/12 04:22 PM)
|
|
|
|
|
Short answer: in Emu Loader you can simply ignore the <slots> because they have negligible effect on MAME
More complete answer: The slot options come from MESS slot device code and they're used to support configurable slots in computer emulation where e.g. you can have 8 ISA ports to connect the combination you want of Floppy drives, Hard Disks drives, Serial mice, Graphics cards, Sound cards and so on (and yeah, current MESS basically allows you to test any combo you wants in PC and Mac drivers) or you can plug a IEEE48 serial cart into a Vic20 and connect several disk drives to the system through it (and yeah, current MESS allows you to do this and much more both in Vic20 and C64 drivers)
In the case of MAME, slots cannot be configured by users and only a default configuration is offered (which should match the configuration of the hardware inside the cabinet) Hence, expect to see more of these when emulation of PC-based arcade systems become more accurate, but don't expect the users to be able to play with them as they can do in MESS
Focusing on your specific example, taitogn.c games, the change is related to the presence of an "IDE Controller" in the original cabinet and in the changes of its emulation performed by Micko between 0.145 and 0.145u1. Now the IDE controller is handled through slot devices and its emulation is hardcoded to have an HDD connected to each of its slots (this is in progress, the final configuration will reflect the real content of the cabinet, i.e. only a pcmcia card connected), hence the xml output.
Killer Instinct is another example you can find in xml.
Feel free to ask, if you need any additional info.
|
|
|
CiroConsentino |
Frontend freak!
|
|
|
Reged: 09/21/03
|
Posts: 6211
|
Loc: Alien from Terra Prime... and Brazil
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: etabeta]
#276925 - 02/22/12 08:49 PM
|
|
|
thanks for the help. sadly, I will have remove sub-categories for CHD filter.
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9716
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: current chdman state...
[Re: etabeta]
#276933 - 02/22/12 09:41 PM
|
|
|
> I really hope that the memory issues reported by Jurgen after a valgrind run are the > reason of all the current problems (including chdman getting miscompiled by Apple GCC > with default OPTIMIZE value ), so that we can fix all of them at once
Nothing Juergen reported is anything like fatal. He and everyone seems to assume that the Linux maintainer wouldn't already have tried Valgrind and submitted a patch called, say, "fix trivial uninitialized variable in chd.c" and that sort of thing.
|
|
|
|
Re: current chdman state...
[Re: R. Belmont]
#276940 - 02/22/12 10:11 PM
|
|
|
fwiw I dumped a Gauntlet hard drive last night with v4 (it turned out to be the 1.6 version in mame so nothing new) but when I tried to convert it to the v5 with the new chdman it got about 1/10th of the way through and then crashed my whole computer and it reset itself. Won't be trying it again until u2.
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: current chdman state...
[Re: Smitdogg]
#276944 - 02/22/12 10:35 PM
|
|
|
chdman uses 100% of your CPU, so you probably have a hardware fault somewhere or some instability issues.
I already converted a complete set with no hangs or any issues hardware wise on my end.
Hopefully you have dumped it with 145 version of chdman as well.
|
|
|
|
Re: current chdman state...
[Re: B2K24]
#276945 - 02/22/12 10:37 PM
|
|
|
It's my dumping computer with XP 32bit on it. It's old so there could be some fault, I guess. I loaded the v4 dumped hd in mame and it's 1.6 so no I'm not planning on dumping it with v5 and I'm not even sure what the command is to do so.
|
|
|
Naoki |
|
|
|
Reged: 11/10/09
|
Posts: 1998
|
Loc: United Kingdom
|
|
Send PM
|
|
|
Re: current chdman state...
[Re: Smitdogg]
#276952 - 02/23/12 12:43 AM
|
|
|
> It's my dumping computer with XP 32bit on it. It's old so there could be some fault, > I guess. I loaded the v4 dumped hd in mame and it's 1.6 so no I'm not planning on > dumping it with v5 and I'm not even sure what the command is to do so.
In V5 it's "CHDMAN createhd -i \\.\PhysicalDriveX -o X:\%path%\%game%.chd" for me.
Edited by Naoki (02/23/12 12:44 AM)
|
|
|
|
Re: current chdman state...
[Re: Naoki]
#276953 - 02/23/12 12:45 AM
|
|
|
Thanks I'll try that next time I dump a hd and after u2 is out.
|
|
|
Naoki |
|
|
|
Reged: 11/10/09
|
Posts: 1998
|
Loc: United Kingdom
|
|
Send PM
|
|
|
Re: current chdman state...
[Re: Smitdogg]
#276960 - 02/23/12 02:10 AM
|
|
|
I found I have to run that using an administrative prompt in Windows 7 otherwise it can raw read/write to the disk. But considering you're using XP, nothing to worry about
|
|
|
|
Re: MAME 0.145u1
[Re: redk9258]
#277596 - 02/28/12 05:23 AM
|
|
|
I updated my chd using chdman copy -i 1.chd -o 2.chd and it worked fine..... except mame 145u1 now says my chd have bad SHA1.
damn.... this is such a pain in the....!
|
|
|
B2K24 |
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
Reged: 10/25/10
|
Posts: 2663
|
|
|
Send PM
|
|
|
Re: MAME 0.145u1
[Re: kevenz]
#277600 - 02/28/12 06:29 AM
|
|
|
> I updated my chd using chdman copy -i 1.chd -o 2.chd and it worked fine..... except > mame 145u1 now says my chd have bad SHA1. > > damn.... this is such a pain in the....!
There are issues that still need to be worked out and investigated by the Devs. If you look at mametesters plus various other threads and such, it has already been confirmed by the Devs themselves.
Hopefully, you have not deleted all your V4 stuff.
|
|
|