Re: [hatari-devel] program autostart, visual studio Hatari compilation

[ Thread Index | Date Index | More Archives ]


On 24.10.2021 20.49, Eero Tamminen wrote:
On 24.10.2021 19.50, Charles Curley wrote:
Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:
Hatari has a shell script that inserts Atari
program arguments to its basepage using debugger
and conditional breakpoints:

Nice! I was not aware of that.

For my use, it does too much. It appears to parse the argument to a
program to make sure that the argument is a proper file specification.

It should do that only for arguments that have
same (unix) path prefix as the Atari program you
are running.  Reason for this is that those paths
need to be converted, like this:
     /path/to/some.prg /path/to/file.ext

But I guess that script may do the file existence
checks also if one does not give any path for the
Atari program.  I'll fix that if it's the case...

$ hatari-prg-args -- everest.prg test1 test2 test3

open Everest text editor with windows for 3 new
text files that do not exist yet.

I.e. I cannot reproduce your problem.

That prevents me from using it to pass arbitrary arguments to a program.

I use fastforth on the Atari, and would like to pass snippits of Forth
code to fastforth so that it can execute them on loading. For example:

C:\FF\FAST4TH.TTP 3 list

Should work fine as:
  hatari-prg-args -- /path/to/fast4th.ttp 3 list

NOTE1: Similarly to normal Hatari autostart
feature, GEMDOS HD C: root will be the directory
where the started program is.

NOTE2: one can use "--auto" option for auto-start
and separate options for disk mounts, if program
needs to be started from somewhere else than
GEMDOS HD C: root.  Due to its awkwardness, it's
mainly intended to be used for autostarting things
from disk images, but one can use it also with
GEMDOS HD. "hatari-prg-args" does not support that

	- Eero

Or someone might want to run a compile:


So how do I strip out that checking?

If you are running Hatari from the same
directory where your Atari program is,
like this:

The workaround is using this instead:

Mail converted by MHonArc 2.6.19+