Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

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.

1

clrmame Discussion / Re: Dates older than 1980 = Invalid?

« on: 23 April 2019, 07:22 »

Well, now that I'm aware of the deeply rooted reason for the limitation in zip files, I'm not going to fight it. Considering that this set is DOS specific and these older dates are probably faked anyway, I can simply change them to the oldest value actually supported.

I have PM'd you a zip copy of the set represented by my earlier example, because I find it interesting that its allegedly pre-DOS autoexec.bat does not list a modified date in winrar or 7zip.  I surmise it is because there is no timestamp actually stored for it, and I'm curious if there can be some method to do the same in clrmamepro, such as setting the dat's rom date field to 0000-00-00 00:00:00 (or "0").

I will respect whatever comes from this, because I know time is not always on our side.

2

clrmame Discussion / Dates older than 1980 = Invalid?

« on: 22 April 2019, 01:56 »

Hello, long time no speak.  I was adapting a dat for DOS era content, and many files are dated 1979-12-03, functionally as placeholders for unknown values.  This is posing a problem for use with clrmamepro as I've found that all dates prior to 1980-01-01 00:00:00 are treated as illegal values.  Was this set arbitrarily? Can it be set so something more accommodating, such as 1900?  The first hard drives were commercially produced even before the UNIX epoch (1970-01-01), and floppy disks were becoming normal during the mid to late 1970s.

Alternatively, is there a way to store a file WITHOUT a date set, or is that a violation of the zip standard?

Example:
game (
   name "Las Vegas Blackjack v1.05 (1982)(Quala Software) [Strategy, Cards]"
   rom ( name "AUTOEXEC.BAT" size 24 date "1979-12-03 00:04:00" crc 282A252C )
   rom ( name "BASICA.COM" size 16256 date "1981-08-04 00:00:00" crc 1DF9FAD6 )
   rom ( name "BLACKJAK.BAS" size 23296 date "1982-07-27 00:06:26" crc 9D3CA6FC )
   rom ( name "COMMAND.COM" size 3231 date "1981-08-04 00:00:00" crc 5016C475 )
   rom ( name "DATE.COM" size 252 date "1981-08-04 00:00:00" crc EEF91299 )
)

Thank you,
Z

3

clrmame Discussion / Re: being bored .... ?

« on: 14 May 2017, 18:08 »

Hi Roman, I am experiencing an old crash when a header skipper tries to read a zipped file smaller than the data region to skip. This used to cause an infinite loop, but I think you fixed that. I guess it's different when zipped. This problem does also exist in the main build. The SNES header xml is barebones, the dat is placeholder, etc.  Virgin pure setup.  I have a quick test sample for you to play with here.  If it also crashes on your system, then you can have a small challenge if you are still bored. 

4

clrmame Discussion / Re: mame .154

« on: 23 July 2014, 22:25 »

A trick some are using is to untick Model 110 (gp_110) in Systems & assigned System-default-paths.

5

clrmame Discussion / Re: mame .154

« on: 23 July 2014, 18:57 »

Thanks for the heads-up Roman!

6

clrmame Discussion / Re: Logging of Rebuilt Source Files

« on: 23 July 2014, 18:55 »

Memory refresh: http://forums.no-intro.org/viewtopic.php?f=2&t=1560&start=0#p5778

7

clrmame Discussion / Re: Dir2Dat

« on: 09 July 2014, 06:22 »

Nice... I never openly questioned this, assuming it was part of some dark Linuxy truth where some manager depended on it being structured that way. I mean... I can't be the only one that still opens some things in notepad on a daily basis and curses Microsoft for only ever devolving.... Seriously, still no support for a fundamental means of portraying carriage returns in their baseline editor after 30 years?  Grumblegrumble

Sent from my pillow

8

clrmame Discussion / Re: [BUG] RAR volume open lockup

« on: 16 December 2013, 21:40 »

We're back in operation! Thanks

9

clrmame Discussion / Re: [BUG] RAR volume open lockup

« on: 16 December 2013, 20:11 »

The issues persists with the 5.1 DLL. test.zip must not be decompressed. Target test.zip directly, not the contained RAR files it will attempt to decompress.

10

clrmame Discussion / [BUG] RAR volume open lockup

« on: 15 December 2013, 07:40 »

The newest version of cmpro x64 (4.012) contains an updated UnRar64.dll (5.0), which introduces a lockup/freeze scenario that pegs the CPU at max until cmpro is terminated.  This is caused by attempting to read, least from the Rebuilder, a multipart RAR that itself has been zipped or RAR'd. Example here. With the previous DLL version (4.20) it failed gracefully with the reported message: foo.part1_12345.rar got volume open error. Using the new DLL with an older version of cmpro does the same lockup, while using the old DLL with the new version of cmpro returns the error message.

11

clrmame Discussion / Re: BUG: 7z and dat changes: loss of files even with "backup" turned on

« on: 13 October 2013, 23:54 »

This problem stems from a 4GB (2³² bytes) limitation somewhere. Be sure you use a 64-bit version of 7-Zip (and of course clrmamepro), and avoid use of ZIP as traditional implementations of it are also not 4GB aware.  CMPro might back up as ZIP however, so that would be a problem.

Newer versions of 7-Zip support direct renaming of 7zipped files without recompression, but I have been unable to get it to work yet, using 7zr.exe 9.22b.

Not sure if this is still relevant, but this post from 2010 (result #1 when Googling the 7z error message) offers a probable solution.

12

clrmame Discussion / Re: Rebuild log (+ typo?)

« on: 24 July 2013, 01:12 »

Above and beyond the improvements I was expecting... The reporting works fine, but also, the color scheme does not conflict with my darkness now! When did you slip that in?

Thank you Roman!

13

clrmame Discussion / Rebuild log (+ typo?)

« on: 22 July 2013, 12:42 »

I have had need for more extensive rebuild logging. '[EXISTS]' hardly helps when I am trying to find what certain files were matched after rebuild+removal. I also see '[SKIPPED Reason: ]' which appears incomplete.  Existence is probably determined easily based on the loaded cache, but it would be useful to not have to manually calculate the hash of the file and search that in the datfile for the associated filename.

Secondarily, I wonder why the .cmp config entry "bRebuilder_ShowStats" has a leading b.

14

clrmame Discussion / Re: cbr,cbz.cb7,cbt file support

« on: 12 April 2013, 02:11 »

Wasn't me Oo
I am not against this request. It goes to show there is interest and use of CMPro beyond the emu community.

15

clrmame Discussion / Re: cbr,cbz.cb7,cbt file support

« on: 01 April 2013, 10:07 »

Extensions are definitely arbitrary; the best way to be sure what type a file is would be to read its header, but doing that check on every file is a huge slowdown/time waster.  Referencing a list of supported extensions/type correlation is faster, and is with the assumption that a collector can provide files with an extension correctly identifying the file type.

Lazy indeed.. just do this in command prompt (shift+right-click in directory -> Open command window here): ren *.cbz *.zip ...then after scanning, do this: ren *.zip *.cbz

I am more inclined to ask for read support of gz, tar, lzh/lha archive types (maybe pipe it through 7zip)...

16

clrmame Discussion / Re: strange 7z warnings

« on: 24 March 2013, 04:24 »

Those BIN files have matching hash info, along with "Kochira Katsushika-ku Kameari Kouen Mae Hashutsujo - High-Tech Buil Shinkou Soshi Sakusen! no Maki (Japan) (Track 6).bin", which is the longest entry in your datfile.

If the temp process creates a dir named after the set, the total length of the path for extracted file = 267 characters. The native path limit is 260, so I can see how you might run into trouble handling that.  How it becomes a cascading error is beyond me though.

The only other entry that might be too long is "Simple 1500 Jitsuyou Series Vol. 13 - Shinri Game - Soreike x Kokology - Kokoro no Uso no Makafushigi (Japan)" at 263, then it's "Kidou Senshi Gundam - Gihren no Yabou - Zeon no Keifu (Japan) (Disc 1) (Earth Federation Disc) (v1.x)" at 257 and below.

17

clrmame Discussion / Re: CrlMAMEPro not responding

« on: 24 March 2013, 04:01 »

Not truly interested in going off-topic, but XP SP3 was released on official channels. Anything claiming otherwise is either an old nlite-built install image with hacked up SP2 or slipstreamed SP3, or mistaken.

18

clrmame Discussion / Re: CrlMAMEPro not responding

« on: 08 March 2013, 10:07 »

Just invoked this problem in the Rebuilder today... my RAMdisk had been filled to max without realizing.  Clicking cancel prompts for stop, but neither answer works.  Had to kill the process to close the program.

19

clrmame Discussion / Re: clrmamepro 4.010 released

« on: 18 February 2013, 23:44 »

This shall be the build I make a donation for. Thank you.

20

clrmame Discussion / Re: 7Zip Compression Size Problem?

« on: 08 February 2013, 01:11 »

If you want to 'fix' the 'issue' of it not compressing as much, set -ms=on and rebuild.  Again, this is ill advice.  You shouldn't want the extra overhead.

Other reading: http://romshepherd.com/smf/index.php/topic,677.msg2958.html#msg2958