EMULAB Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

The new forum is online, hope you enjoy it!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - oxyandy

Pages: 1 [2] 3 4 5 6 7 ... 14
21
clrmame Discussion / Re: DAT (depreciated) -> XML
« on: 22 January 2015, 17:22 »
f205v change --> genericxml -to- cm should work

Cassiel - not that I know of, I rarely ever use datutil - it's old and antiquated.. It chokes on utf-8
I wrote that mini batch as I replied, I don't do batch - so when needed I use CMP for single dat converts.
crc32 + sha1 is ample, I don't see the need for md5 as well, is over kill really.

If I needed to batch convert dats I would write something modern with full utf-8 support.

22
clrmame Discussion / Re: DAT (depreciated) -> XML
« on: 16 January 2015, 15:26 »
Yep, as Roman says  ::)
Code: [Select]
if not exist done md done
for %%a in ("*.dat") do (
datutil -f genericxml "%%a"
move datutil.dat "Done\%%~na.xml"
)
pause

23
clrmame Discussion / Re: Status
« on: 04 December 2014, 05:08 »
I saw your post yesterday, then it's edit..
Is there anything you want tested / feedback with ?
Let us know.

24
clrmame Discussion / Re: Status
« on: 29 November 2014, 20:01 »
Quote
with all ok you mean no slowdown?
Correct, no slowdown

25
clrmame Discussion / Rest well
« on: 29 November 2014, 17:10 »
Roman I have done a bit further testing...
I took the new Beta III binaries you posted,
dropped them into a fresh official 4.015 download, over writing the existing files..
Configured everything from scratch.
All seems to be working great  ;D
Nothing to report
Rest well

NOTE:
Others testing Roman's latest beta should do the same (as above) dropping into an existing pre-configured CMP folder is not advised.
I'm sure feedback is welcomed, how's does it work for you ?

Oddi, yes the DAT we were looking at, has some missing <merge tags> which could prevent duplicate chds being created.
Not cmp related, hopefully a future MAME release has those omissions corrected.


26
clrmame Discussion / Re: Status
« on: 28 November 2014, 22:26 »
Hi Roman,
Good & Bad.
The Good:
Problem with chds (few I tested - not whole set) is fixed.

The Bad:
Memory & CPU usage has increased dramatically.
Switching between [Scanner to Rebuilder] 50% CPU & taking over 2 minutes ?
After clicking CMP [Scanner to Rebuilder] whole CMP vanishes from view for 2 minutes (only taskbar icon visible)
(via right hand lower corner button in Rebuilder window) - I had 0.156 MAME dat loaded
[Rebuilder to Scanner] not so bad, but not like it used to be.
Anyone else seeing this ?


EDIT: DAT I had loaded, http://speedy.sh/u7zMF/M.A.M.E.-v0.156-Nov-26-2014-r242067.xml.7z
trying new folder setup now.

EDIT2: New CMP Folder setup seems to have fixed it.
Tired too, back to bed..zzzzz


27
clrmame Discussion / Re: Status
« on: 28 November 2014, 12:41 »
 ;D
That all... sounds great !
I feel confident you know the exact problem we are facing, which should help you get to the root cause quickly..

Thanks Roman...

28
clrmame Discussion / Re: Status
« on: 28 November 2014, 11:24 »
Quote
a renamed chd file by hash compare as it does for roms....I mean area51.chd -> blabla.chd.

Quote
- double check if MAME supports loading of renamed chds

Better idea ? Disable the renamed CHDs.. Leave their damn names as they are ?
CMP Stable, had no problem with merging a CHD set, it's handling of chds needed no further development, did it ?

Yeah, as for 1. I have no idea why CMP now suddenly is:
  • ignoring the merge tags for chds
  • creating the clone folder & dupe chds..
But if I (we) whine enough, you might just look into why  :P

29
clrmame Discussion / Re: Status
« on: 28 November 2014, 10:03 »
What did "I" do ? haha you make me laugh, try again what did CMP do ?
No, that's not fair on CMP, CMP did not write itself, a developer did..
Shoot the developer..

Anyway I am sure is a straight forward fix, you have all required info
(I EDITED MY PREVIOUS POST)
Enjoy
Let me know if anything is needed :)
Thanks

30
clrmame Discussion / Re: Status
« on: 28 November 2014, 09:33 »
Later tonight when time permits, please re-read my previous post Roman, ::)
Problems with CHDs
1. When "Parse DISK merge tags" is ticked, CHDs are being duplicated in clone_name folders. (Unticking "Parse DISK merge tags" makes a better set, without dupes)
Please stop dupe chds being created.

2. Instead of CHDs having the file extension *.chd, some now have the extension *.chd [clonename]
Please standardise all file extensions for CHDs to be only *.chd

Once you have done this and created a new build "Sexy Beta III",
we will re-visit Oddi's (some needed chds being moved to back-up folder problem)

Thanks !

EDIT:
Ok I just tested with ARMAX's (0.156 CHD ONLY DAT) I can not reproduce the exact problem.
For replicating this bug, his dat is useless, it makes a chd set as I expect.
However, (see above *.chd [clonename]) once CMP has renamed chds to this extension,
CMP itself, no longer recognises the files (*.chd [clonename]) as chd files !

This IS Oddi's problem.
1. CMP is changing the default file extension to a file extension to an unrecognisable file ext. (Even by CMP)
2. Oddi is then placing these unrecognisable (*.chd [clonename]) manually in wrong folders

SO, fix 1. & 2. above, Oddi's problem = fixed
Dont over complicate this bug fix :)

DAT file to reproduce ?
If you don't already have one from EXE & CMP, either one of us will upload one for you..
Oddi & myself are presently using exact same dat file..

31
clrmame Discussion / Re: Status
« on: 28 November 2014, 07:54 »
Hi Roman,
I do not understand Oddi's CHD problem.  :o
(I have suggested "dont list mismatches for bad dumps" <---CMP CHD option should be ticked !)



I do know those CHDs are v4 bad dump flagged.
His get moved to back-up, mine stay put, repeated "New Scan" = no fixes/changes prompted.

I do see a problem with CHDs as follows:
MAME .156 FULL MERGED SET in CMP Scanner/Rebuilder
(Using dat file supplied by Oddi, yes the same DAT file & CHDS, he is having a problem with, I have no problem)
Parse DISK merge tags (TICKED)
I expect to see

\jojo\cap-jjk000.chd
\jojo\cap-jjk-2.chd
\jojo\cap-jjk-3.chd

\sfiii3\cap-33s-1.chd
\sfiii3\cap-33s-2.chd


Instead I see:
jojo\cap-jjk000.chd [jojor2]
jojo\cap-jjk-2.chd [jojor1]
jojo\cap-jjk-3.chd
jojojr1\cap-jjk-2.chd [jojojr1]
jojojr2\cap-jjk000.chd [jojojr2]

\sfiii3\cap-33s-1.chd [sfiii3ur1]
\sfiii3\cap-33s-2.chd
\sfiii3r1\cap-33s-1.chd [sfiii3r1]

See 5x CHDs vs 8x CHDs - Kill the damn dupes will ya :P

EXAMPLE: cap-jjk000.chd [jojor2]
The [jojor2] has now become part of file-name ???



32
clrmame Discussion / Re: Status
« on: 28 November 2014, 03:22 »
Quote
(maybe it was fixed with one of the other fixes)....
.........maybe,
I suggested fixing Funky would make 'other not yet reported problems vanish'
- well, as expected those problem are gone now too.
Great work.

I restored my MAME 0.155 ZIP merged set to what it was... (before 1st CMP Funky Beta)
Just downloaded "Sexy Beta II", ready to destroy my ROM set now.

1. No more unpack errors
2. 'New Scan' completed - no errors.
3. I have not done a Scan and fix on old .155 set  then Rebuilt from .156 update pack
(might try this later - this is what I did first time & this is where I lost some files, during initial "New Scan", before updates)
4. This time I would have had heaps of .156 files in back-up folder (not cleared those)

Heading out to lunch, so far, so GREAT ! - Zero miss....
Second 'New Scan' had fix prompts,
Third 'New Scan' fix prompts,
Fourth 'New Scan' = no errors, no prompts

I am not testing CHDs
Later guys

33
clrmame Discussion / Re: Status
« on: 27 November 2014, 17:40 »
So if you're reading this Roman,
then clearly you are looking for an excuse to get your head out of lines of code...
So is there any progress ?
:)

34
clrmame Discussion / Re: Status
« on: 27 November 2014, 09:06 »
Hey Roman,
You knows me makes easy 4 u to find/repeat bug..
Enjoy DAT, fix this bug first, other not reported bug vanish... haha
Dont u luvs me Engrish.
Later

35
clrmame Discussion / Re: Status
« on: 27 November 2014, 08:50 »
CMP Stable (Merged)
\Funky CMP - MAME v0.156
funkyfig.zip
funkyfiga.zip

CMP Funky Beta (Merged)
\Funky CMP - MAME v0.156
funkyfig.zip







"New Scan", "New Scan" = Loop Forever, DAT attached
Required ROMs
funkyfig.zip
funkyfiga.zip

36
clrmame Discussion / Re: Status
« on: 27 November 2014, 07:52 »
Yes Roman,
full merged ZIP
I just made my last edit to my previous post, so I wont touch that anymore.
Maybe I will edit this one a few times more.

Instead of fix.dat whole .156 dat is saved..
Sorry to be the bearer of bad news.

.156 dat states..
      <rom name="7408.13b" size="524288" crc="1a947f3b" sha1="ad8d52de54c5a507dd759604613e1d85e13db5fd"/>
      <rom name="7408.13b_9efe4c60" merge="7408.13b" size="1048576" crc="9efe4c60" sha1="6462dca2af38517639bd2f182e68b7b1fc98a312"/>

New test CMP Build never solves this problem, it rebuilds the match (7408.13b) in..
A new scan - wants to take it out - wrong size

I could make mini dat - rom combinations for repeating bug & fixing.


37
clrmame Discussion / Re: Status
« on: 27 November 2014, 06:57 »
Test:
Source .155 ZIP merged set
Load .156 DAT - Configure Full Merged Settings, then "New Scan"



I allowed that to continue to completion.
Now rebuilding from Back-up (took a few tries to pick up all available files in back-up folder), then Rebuilding Updates in.

Assuming the Updates were packed & prepared properly..
I should have a full set, but not so..
Miss list is interesting.. I would say I had all these in 0.155 (Example below)
Code: [Select]
18 Wheeler (set 2) [folder: 18w2 - parent: 18w - size: 8kb]
missing rom: 18w_b1.rom1 [18w2] [size: 2048] [CRC32: cbc0fb2c] [SHA1: 66b14f0d76baebbd64e8ed107e536ad811d55273]

Donkey Kong 3 (bootleg with 2xAY8910) [folder: dkong3abl - parent: dkong3 - size: 61kb]
missing rom: dk3ba-1.3l [size: 8192] [CRC32: d4a88e04] [SHA1: 4f797c25d26c1022dcf026021979ef0fbab48baf]
missing rom: dk3ba-2.3m [size: 8192] [CRC32: f71185ee] [SHA1: 6652cf958d7afa8bb8dcfded997bb418a75223d8]
missing rom: dk3ba-3.4l [size: 4096] [CRC32: 67ac65d4] [SHA1: d28bdb99310370513597ca80185ac6c56a11f63c]
missing rom: dk3ba-4.4n [size: 4096] [CRC32: 84b319d6] [SHA1: eaf160948f8cd4fecfdd909876de7cd16340885c]
missing rom: dk3ba-5.7f [size: 4096] [CRC32: 07d3fd88] [SHA1: 721f401d077e3e051672513f9df5614eeb0f6466]
missing rom: dk3ba-6.7g [size: 16384] [CRC32: 31b8401d] [SHA1: 0e3dfea0c7fe99d48c5d984c47fa746caf0879f3]
missing rom: dk3ba-7.7i [size: 16384] [CRC32: a9263275] [SHA1: c3867f6b0d379b70669b3b954e582533406db203]

Frogger (bootleg on Amigo? hardware) [folder: froggeram - parent: frogger - size: 22kb]
missing rom: 1.d2 [size: 2048] [CRC32: b680e622] [SHA1: 233dbefa2aae6e85cb61acd60c49480bd4a3388d]
missing rom: 2.e2 [size: 2048] [CRC32: 32c56a50] [SHA1: 4d215fff6ff002e23aa889292c9c5eb242975f5d]
missing rom: 3.f2 [size: 2048] [CRC32: 4223a053] [SHA1: c19555d2fee4172dff99d7cf65ebb44d1336c06e]
missing rom: 4.h2 [size: 2048] [CRC32: bcd02aa7] [SHA1: 987c35bf9af8bb1083ccbf4d9f912be8d74b3d1f]
missing rom: 5.j2 [size: 2048] [CRC32: b11b36f7] [SHA1: d4e9342be7fa23f30565d7b75fa0fb8c6c82669d]
missing rom: 6.l2 [size: 2048] [CRC32: a239048a] [SHA1: a8dcc0b4bdb51f6e391832d69ba3a8727be59ae7]
CONTINUED>>>>>

Yes, it seems those .155 ROMs were delicious, CMP & 'The Void' has consumed them  :o

Oh boy, I rebuilt some of those Missings into the set,
Scanner Results shows improvement..
But then, exporting a fix_dat ...
Ummm looks like whole .156 DAT was saved.

38
clrmame Discussion / Re: Is this possible?
« on: 29 August 2014, 02:57 »
It would be easy to write a DAT parser, which re-writes DAT files: (in Bulk)
"to put all your roms into one game definition"

The re-written DATs could be used for Scanning & Rebuilding..
The parser could even add tag "Force Packing = unzip"

It can also be done (manually) with TextFX plugin for Notepad very quickly per dat,  but that's the problem, it would need to be done 'per dat'
For a whole TOSEC dat set, one by one -- ahhhh

39
Hi Marc,
Experience has taught me, keeping ALL paths as short as possible gives room for error.
So for P: Drive -- It's P:\_CMP
I usually keep a copy of CMP on the same drive as my set CMP is working with too.
*Obvious advantage*
Let's say I had my CHDs in P:\CHD
A quick CHD Scan would instantly move 'Outdated CHD files' to CMP's backup folder..
P:\_CMP\backup\CHD

Not the case if CMP was on C:, then Gigabytes worth of 'Outdated files' would have to travel from P: to C: = time consuming (Using default backup path anyway)

A TOSEC set, is best kept on a dedicated partition, so the first nested folder would be;
P:\Acorn\Archimedes\Applications
If dedicating a partition was a problem, then (esp TOSEC) I would go P:\_T\Acorn\Archimedes\Applications
But like Roman says, if Rebuilding and Destination path + filename is too long, you would get a Msg Box Error.


40
Using CMP 32 Official Release 4.015...
Using Common Folder structure of:
D:\Apple\II\Compilations\Games\[DO]
I was able to Rebuild perfectly..
ABM (1980)(Muse) & Invasion Force (19xx)(Gordon Lurie) & Missile Defense (1981)(On-Line Systems) & Norad (19xx)(-) & Planet Protector (19xx)(-)[cr] & Rocket Command (1980)(Bozo NYC).zip
(and yes, I ensured "Additionally test SHA1/MD5 for matches" was ticked...)

Pages: 1 [2] 3 4 5 6 7 ... 14

Page created in 0.095 seconds with 21 queries.