Win32 version of Psy-Q Tools

This is a great find Puto, should stop people winging about snasm68k not working on XP/Vista/their Toaster. Woot for psygnosis!

 

I think I've tried compiling Megamix with asm68k at one point, but it didn't work too well. I'll try giving it a shot now, though, if it really is that much better.

 

Okay, so I've tried assembling the ROM, including adding the align macro, and the only error I get is "Possible Illegal Address" with absolutely no info on the line there was an error on, or anything else particularly useful in correcting the assembly error. Is there some sort of parameter I need to set, or is it just generally unhelpful like that?

 

That win32 build of asm68k is groovy. Unfortunately, although it supports long filenames, it doesn't support filenames with spaces, due to the way the command line parser was written. I've modified the asm68k executable to get around this annoying limitation. You can download the modified version from the following URL:
http://www.mediafire.com/?1gb36mznxtm

 

Would you be able to modify the executable further to get rid of the limitation on how many paths you can use in an include? I'm unable to use the include directive because my source is in "C:\Documents and Settings\Dustin\Desktop\S1 Megamix\" (4 subdirectories, not including _inc). Trying to compile will lead to an "out of memory" error, and I'd rather not have to move my source just because of this.

Note that I AM using relative paths, just like every other include/incbin used.

 

No, it doesn't. For most programs that would be the case, but asm68k tokenizes the command line itself, it doesn't use the argument separation provided by Windows. Their command line parser is written in such a way that when a space is encountered as part of a filename or path, it considers that it must have reached the end of the filename. In the case of the comma-separated filename list at the end of the command line, the first time it encounters a space, it considers it must have reached the end of the entire list. If you send it the following command line:
asm68k "source file.asm", "object file.bin"
It will read in "source", but as soon as it reaches the first space, it will think it has reached the end of the list of filenames. When it encounters the start of the word "file", it will terminate and give you the error "Unexpected characters at end of command line".

I don't know what the maximum number of include paths is, but it's a lot more than 4. One thing to be careful about is I've had to modify the way the /j option works to specify additional include paths. The command line parser needs to know when it has reached the end of the path. You might be getting the error you are getting because it can't find the end of the path.

For include paths, asm68k originally knew it had reached the end of the path when it encountered a space. That rule no longer applies. I was going to make it mandatory to have to enclose all include paths with quotes, but due to the way their parser works, I would have had to make major modifications to pull that off. Instead, I made it necessary to terminate all include paths with an asterisk. Eg, if you want to specify an include path with my modified version, you need to use the following form:
asm68k /j ".\Folder\Subfolder with spaces in name\*" "source.asm", "target.bin"

Note the '*' at the end of the path. I modified the usage instructions for the program to indicate this. Yes, this rule kinda sux. I only did a simple modification to the binary to make these corrections however. Removing the need to give some kind of special character to indicate the end of the include path would have required rebuilding their command line parser. It wasn't worth it from my point of view.

 

Heh, I just realised Tweaker was talking about the include directive too, not the command line.

Yeah, it seems like asm68k has some fairly small buffers allocated for storing paths at several points, and since it fully resolves and stores the paths to all files it references, that severely limits the maximum path depth. The maximum path depth of any file referenced by an include seems to be around 65 characters. The maximum depth of any path specified on the command line seems to be around 100 characters.

I'll see what I can do about raising the maximum. It could be really simple, or it could be an absolute nightmare. Depends on how they've coded it.

 

Guys, if you want to limit the number of subfolders you can just fake using the subst command.

Subst Q: C:\batman\goku\vegeta\freepornforeveryone\lol\rofl\ftw\1337\turd\sup

You'll get a virtual redirect to that long folder, so if you run something from Q: (or any other free letter) it will think that it's in the root folder.

 

Ok, the issue with path lengths was actually fairly simple. The problem occurred when the asm68k executable itself was in a deep subdirectory. A small buffer was being used to store the current working directory of the program in order to build relative paths. I've increased the buffer size from 0x60 bytes to 0xFF bytes. What that means is that this program should be able to reference any path up to 255 characters, either passed from the command line or specified in an include statement. That's the maximum path length that this program can possibly support, without shifting it to use a newer class of file I/o API.

You can download the new edit from http://www.mediafire.com/?1gb36mznxtm

 

Uh, bad news for you... Windows doesn't parse the command line, it just takes away the program name and sends the string straight to you in lpszCmdLine as one of the arguments of WinMain(). It's included in GetCommandLine(), but Windows never gives you all arguments separated. The program has to do it manually.

Later I'll write here the parser I made for the ASL. It handles everything properly (as long as it's ASCII :P), takes into account quotes (single and double) and even more, doesn't have any limit on the number of arguments (it allocates as many memory as arguments are there), so the only limit you can have is imposed by Windows itself.

 

Well, first of all, asm68k is built as a console application, not a windows GUI application. This means they use the main() function, not WinMain(), so they are provided with argument separation. Secondly, all windows apps, even GUI apps which use WinMain, have access to the CommandLineToArgvW() function nowadays, which provides standard tokenization of the command line in unicode.

Doing manual tokenization of the command line is rarely a good idea. There are times when it is justified, however there are quite a few subtleties to Windows command line parsing that are rarely emulated fully. Eg, does your parser acknowledge escape codes, such as \" to preserve quotes passed on the command line?