v3.0 bug?: command line options (load at start)

[Mmmm]

What a great emulator! Back in 1996 (I think) I purchased C64S from Miha Peternel, but I abandoned it since it has not been supported for a long time now. I discovered your emulator, and it is really a great piece of work! Games I couldn't play with C64S work perfectly with your CCS64. Thanks!

I recently upgraded from CCS v2.0 to CCS v3.0, beta1.3, and I encountered the following problem (in v2.0 it worked fine!):

The command line options do not work. "CCS ?" doesn't give the options, and a shortcut I made to start a game doesn't work either (shortcut = "C:\Program Files\CCS64\CCS.EXE" "c:\Bestanden\C64\software\newcopy MvW\TOPO EUROPA.prg" -window -autorun)
This shortcut worked fine with v2.0!

I run WinXP Pro (SP1) with DirectX 9.

Is this a known problem? Does a fix exist, or will it not be fixed until the next version? Or am I doing something wrong?

I hope you'll have an answer,

gr Maarten

[Stuart Toomer]

I would assume that the command-line options do not work with CCS64 V3.0 BETA, since this is a pure Windows-based package now, i.e. does not support command-line options. This is no bug - it is probably "working as designed", as Microsoft say.

[iAN CooG/HF]

I would assume that the command-line options do not work with CCS64 V3.0 BETA,

Why don't you ask to Per Hakan Sundell instead?

since this is a pure Windows-based package now, i.e. does not support command-line options.

False. CCS 2.0 as well as WinVice are Windows programs and command line works always as it should be. Anyway, what the heck is a "pure" windows based package?

This is no bug

Maybe not but the manual says that there are command line parameters.

it is probably "working as designed", as Microsoft say.

LOL! This is "pure" disinformation Stuart. Every program can have commandline parameter, GetCommandLine() and __argv/__argc are there for that purpose solely, there's nothing against using command line parameters.
Frankly speaking, Stuart: when you don't have the right answer it's better to not reply at all.
Sincerely,

[Stuart Toomer]

I would assume that the command-line options do not work with CCS64 V3.0 BETA,

Why don't you ask to Per Hakan Sundell instead?

since this is a pure Windows-based package now, i.e. does not support command-line options.

False. CCS 2.0 as well as WinVice are Windows programs and command line works always as it should be. Anyway, what the heck is a "pure" windows based package?

This is no bug

Maybe not but the manual says that there are command line parameters.

it is probably "working as designed", as Microsoft say.

LOL! This is "pure" disinformation Stuart. Every program can have commandline parameter, GetCommandLine() and __argv/__argc are there for that purpose solely, there's nothing against using command line parameters.
Frankly speaking, Stuart: when you don't have the right answer it's better to not reply at all.
Sincerely,

Sorry, I'll ask him! I was only trying to be helpful. He just kept the same HTML instructions from CCS64 V2.0 BETA. Try not to flame me too hard, next time!

[Mmmm]

Gentlemen, gentlemen, please be gentle with eachother!

I agree with iAN that commandline options should be considered Windows-stuff.

BTW: I already emailed PHS, but he never replied (probably too busy coding the next version for us, I hope )

Stuart: I hope that you manage to get an answer from PHS,

Thanks for the effort

gr Maarten

[Stuart Toomer]

I have had a reply back from Hakan. He informs me that most command-line options do work, so I guess it's a case of investigation.

He is busy with his family and also with the updated HardSID support in CCS64 V3.0 BETA, which I am busy testing. The trouble is that I don't seem to have the correct capacitors in my HardSID (8580) card - I am currently using 330pF's, since the supplied 22nF's filter-out way too much sound. I am trying to find out which capacitors I should use, so the speech is correct and the sound doesn't go slow sometimes (this happens in some games when speech occurs). This capacitors thing is really starting to annoy me now. Others have suggested using 2.2nF caps.

[RFBcsa]

Yep, there seems to be a bug with this. It just doesn't work, just like Mmmm described. When I added ,1 to the filename, to state it should load the first file of the D64 image, it returned this (the @ are inversed):
LOAD "@@@@@@@@@@@@@@@@",8,1
PRESS PLAY ON TAPE

[Stuart Toomer]

The problem is that CCS64 V3.0 BETA doesn't like long-file-names in the command-line parameter, since e.g. the following works instead:

CCS C:\TE.PRG -autorun -fastload

I have passed this bug on to Hakan for fixing.

[Stuart Toomer]

Hakan has fixed this and this fix will be in the next version, along with the HardSID support, and various other minor bug-fixes.

[Victor Derks]

FYI:

I am writing a CBM shell extension that supports a context menu when using the right mouse button on a .d64 file. One of the options is to open the .d64 file in CCS64 or to autostart one of the programs. My shellextensions uses CreateProcess to start CCS64.
I noticed the following issues:

- CCS64 fails to start ok when the working dir is something different then the directory where CCS64 is located. It seems to me that CCS64 is looking for data file in the current directory instead of the 'module' directory.

- CCS64 fails to autostart the first program when the -autorun option is used.

- CSS64 fails to open disk image when application name is passed as the first argument to CreateProcess.

[Stuart Toomer]

FYI:

I am writing a CBM shell extension that supports a context menu when using the right mouse button on a .d64 file. One of the options is to open the .d64 file in CCS64 or to autostart one of the programs. My shellextensions uses CreateProcess to start CCS64.
I noticed the following issues:

- CCS64 fails to start ok when the working dir is something different then the directory where CCS64 is located. It seems to me that CCS64 is looking for data file in the current directory instead of the 'module' directory.

- CCS64 fails to autostart the first program when the -autorun option is used.

- CSS64 fails to open disk image when application name is passed as the first argument to CreateProcess.

Some questions:

- The "working directory" of CCS64 (like any other Windows application) needs to be where it is installed, since CCS64.EXE needs to be able to access the ROM files etc.

- We need a command-line example of -autorun that fails. If you are using long file-names, you must encapsulate the file-path/name in "s.

- How do your CreateProcess work? Do it work with other Windows applications?

[Victor Derks]

Hi Stuart,

CCS should use the Win32 GetModuleFileName function to retrieve the fully qualified path. Strip the .exe name with the PathRemoveExtension function and then look for its data files in that directory. That will enable CCS to work oke when it is not started in the installed directory.

The command line option is:

c:\program file\css64\ccs.exe "c:\data file\test.d64" -autorun


CreateProcess is the standard Win32 function that must be used to start a new process. CreateProcess works fine with other C64 emulators.

version 1.1 of the shell extension can be downloaded from www.xs4all.nl/~vbaderks . I will post very soon version 1.2 that has the context menu option (version 1.1 doesn't support a context menu)

[Rebell]

Where can i find all commandline otptions ?

Please post it for V3.0 Beta 1.6 - tnx

[Stuart Toomer]

Where can i find all commandline otptions ?

Please post it for V3.0 Beta 1.6 - tnx

The information is in the CCS64.HTML file, that comes as part of the CCS64 V3.0 BETA package (ZIP file). Please refer to that file. There are lots of options...