MAMEWorld >> News
View all threads Index   Threaded Mode Threaded  

Pages: 1

redk9258
Regular
Reged: 09/21/03
Posts: 3962
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)



belegdol
Reged: 04/18/04
Posts: 200
Send PM


Re: MAME 0.145u1 new [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: 3962
Loc: Troy, Illinois USA
Send PM


Re: MAME 0.145u1 new [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 new [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: 3962
Loc: Troy, Illinois USA
Send PM


Re: MAME 0.145u1 new [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 new [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.



belegdol
Reged: 04/18/04
Posts: 200
Send PM


Re: MAME 0.145u1 new [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





Cyberzinho Punk
Reged: 12/31/09
Posts: 182
Loc: São José dos Campos, SP, Brazil
Send PM


Re: MAME 0.145u1 new [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: 3962
Loc: Troy, Illinois USA
Send PM


MAME_0.145u1b_64-bit... new [Re: redk9258]
#276565 - 02/19/12 08:27 PM Attachment: MAME_0.145u1b_64-bit.7z 14583 KB (161 downloads)


See attached.



redk9258
Regular
Reged: 09/21/03
Posts: 3962
Loc: Troy, Illinois USA
Send PM


MAME_0.145u1b_32-bit... new [Re: redk9258]
#276566 - 02/19/12 08:36 PM Attachment: MAME_0.145u1b_32-bit.7z 13680 KB (106 downloads)


See attached...



KingTut
Reged: 08/26/11
Posts: 11
Send PM


Re: MAME_0.145u1b_32-bit... new [Re: redk9258]
#276568 - 02/19/12 08:58 PM


Thank you redk9258.



Naoki
Reged: 11/10/09
Posts: 1987
Loc: UK
Send PM


CHDMAN new [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



MASH
MASH
Reged: 09/26/03
Posts: 1624
Loc: Germany
Send PM


CHDs inside ZIPs is missing... new [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 Konami
Reged: 09/21/03
Posts: 9606
Loc: ECV-197 The Orville
Send PM


Re: MAME 0.145u1 new [Re: Cyberzinho Punk]
#276578 - 02/19/12 10:51 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: 3962
Loc: Troy, Illinois USA
Send PM


Re: CHDs inside ZIPs is missing... new [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: 1624
Loc: Germany
Send PM


Re: Test it! new [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!



StevieWunderful
Reged: 11/19/04
Posts: 115
Loc: NY
Send PM


Re: MAME 0.145u1 new [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: 1987
Loc: UK
Send PM


Re: Test it! new [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



CiroConsentino
Frontend freak!
Reged: 09/21/03
Posts: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME 0.145u1 new [Re: redk9258]
#276589 - 02/20/12 01:05 AM


thank you.
big changes in CHD support and FLAC format.



Emu Loader
Ciro Alfredo Consentino
home: http://emuloader.mameworld.info
EmuCon Home: http://emuloader.mameworld.info/emucon
MCM Plus: http://mcm.mameworld.info
e-mail: emuloader@gmail.com



Sune
Connected
Reged: 09/21/03
Posts: 5521
Loc: Lagoa Santa, Brasil
Send PM


chd update trouble new [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: 3962
Loc: Troy, Illinois USA
Send PM


Re: chd update trouble new [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.



Trebor
MAME Fan
Reged: 01/18/05
Posts: 469
Send PM


Thank You (nt) new [Re: redk9258]
#276603 - 02/20/12 05:14 AM


.



CiroConsentino
Frontend freak!
Reged: 09/21/03
Posts: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME_0.145u1b_64-bit... new [Re: redk9258]
#276632 - 02/20/12 12:31 PM


thank you.



Emu Loader
Ciro Alfredo Consentino
home: http://emuloader.mameworld.info
EmuCon Home: http://emuloader.mameworld.info/emucon
MCM Plus: http://mcm.mameworld.info
e-mail: emuloader@gmail.com



CiroConsentino
Frontend freak!
Reged: 09/21/03
Posts: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME 0.145u1 new [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.



Emu Loader
Ciro Alfredo Consentino
home: http://emuloader.mameworld.info
EmuCon Home: http://emuloader.mameworld.info/emucon
MCM Plus: http://mcm.mameworld.info
e-mail: emuloader@gmail.com



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: MAME 0.145u1 new [Re: CiroConsentino]
#276641 - 02/20/12 01:39 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.

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



xibic
Reged: 05/12/05
Posts: 237
Send PM


Re: chd update trouble new [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: 5521
Loc: Lagoa Santa, Brasil
Send PM


Re: chd update trouble new [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



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: chd update trouble new [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: 5521
Loc: Lagoa Santa, Brasil
Send PM


Re: chd update trouble new [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



krick
Get Fuzzy
Reged: 02/09/04
Posts: 4186
Send PM


Re: MAME 0.145u1 new [Re: CiroConsentino]
#276662 - 02/20/12 05:36 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.

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



TafoidAdministrator
I keep on testing.. testing.. testing... into the future!
Reged: 04/19/06
Posts: 2948
Loc: USA
Send PM


Re: MAME 0.145u1 new [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: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME 0.145u1 new [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: 5521
Loc: Lagoa Santa, Brasil
Send PM


Re: MAME 0.145u1 new [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



Pr3tty F1y
MAME Fan
Reged: 07/18/05
Posts: 336
Send PM


Are the CHD changes safe or is it recommended to wait? new [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.



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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.



Doosh
MAME Fan
Reged: 07/02/09
Posts: 17
Send PM


Re: MAME 0.145u1 new [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?



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: MAME 0.145u1 new [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



AaronGiles
Galaxiwarrior
Reged: 09/21/03
Posts: 1334
Send PM


Re: MAME 0.145u1 new [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




Anonymous
Unregistered
Send PM


Re: MAME 0.145u1 new [Re: AaronGiles]
#276713 - 02/20/12 10:48 PM


Thank you!



Dullaron
Diablo III - Dunard #1884
Reged: 07/22/05
Posts: 5732
Loc: Fort Worth, Tx
Send PM


Re: MAME_0.145u1b_64-bit... new [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: 3962
Loc: Troy, Illinois USA
Send PM


Re: MAME_0.145u1b_64-bit... new [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.



krick
Get Fuzzy
Reged: 02/09/04
Posts: 4186
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [Re: etabeta]
#276739 - 02/21/12 04:53 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



BIOS-D
MAME Fan
Reged: 08/07/06
Posts: 1586
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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.



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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 Konami
Reged: 09/21/03
Posts: 9606
Loc: ECV-197 The Orville
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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 Konami
Reged: 09/21/03
Posts: 9606
Loc: ECV-197 The Orville
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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.



Pr3tty F1y
MAME Fan
Reged: 07/18/05
Posts: 336
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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.




Llaffer
MAME Fan
Reged: 05/04/11
Posts: 171
Send PM


Re: MAME 0.145u1 new [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: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: Are the CHD changes safe or is it recommended to wait? new [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: 2549
Send PM


Re: MAME 0.145u1 new [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



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


current chdman state... new [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: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME 0.145u1 new [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 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)



etabeta
Reged: 08/25/04
Posts: 2035
Send PM


Re: MAME 0.145u1 new [Re: CiroConsentino]
#276919 - 02/22/12 07:31 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: 5549
Loc: Alien from Terra Prime... and Brazil
Send PM


Re: MAME 0.145u1 new [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 Konami
Reged: 09/21/03
Posts: 9606
Loc: ECV-197 The Orville
Send PM


Re: current chdman state... new [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.



SmitdoggAdministrator
Reged: 09/18/03
Posts: 16208
Send PM


Re: current chdman state... new [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: 2549
Send PM


Re: current chdman state... new [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.



SmitdoggAdministrator
Reged: 09/18/03
Posts: 16208
Send PM


Re: current chdman state... new [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: 1987
Loc: UK
Send PM


Re: current chdman state... new [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)



SmitdoggAdministrator
Reged: 09/18/03
Posts: 16208
Send PM


Re: current chdman state... new [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: 1987
Loc: UK
Send PM


Re: current chdman state... new [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



kevenz
Reged: 04/25/11
Posts: 197
Send PM


Re: MAME 0.145u1 new [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: 2549
Send PM


Re: MAME 0.145u1 new [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.


Pages: 1

MAMEWorld >> News
View all threads Index   Threaded Mode Threaded  

Extra information Permissions
Moderator:  John IV, Tafoid 
4 registered and 27 anonymous users are browsing this forum.
You cannot start new topics
You cannot reply to topics
HTML is enabled
UBBCode is enabled
Thread views: 7621