|Re: [hatari-devel] program autostart, visual studio Hatari compilation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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:
=> C:\SOME.PRG C:\FILE.TXT
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
Or someone might want to run a compile:
E:\COMPILER\MAKE -q -z SNARK.OBJ
So how do I strip out that checking?
If you are running Hatari from the same
directory where your Atari program is,
The workaround is using this instead: