|Re: [hatari-devel] asm56000.ttp problem|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On torstai 08 tammikuu 2015, Laurent Sallafranque wrote:
> I've just tested with hatari 1.4 and the behaviour is the same.
> At first glance, I would suspect either a EOF problem (the line not
> working is the last one) or the parameter string used into tomshell.tos
> If I call directly asm56000.ttp, I've got another behaviour.
> If I call asm56000.ttp from tosshell.tos without arguments, I've got the
> same behaviour as above
> If I call asm56000.ttp from tosshell.tos with the following arguments
> (-A -B decoder.asm >make\debug.txt), I get the error message.
If you just want to use the program instead of debugging problems
in running tosshell, I suggest giving the arguments to the program
with Hatari facilities:
hatari-prg-args.sh --conout 2 -- ./asm56000.ttp -A -B decoder.asm
("hatari-prg-args.sh" is script for tools/ directory, latest version
of that and of Hatari need to be in your $PATH for above to work.
Or you can hardcode your latest Hatari build path to the script.)
Alternatively, you could use "hconsole", the Hatari remote control shell.
It requires a bit more effort, but you automate a lot more with it and
it should work already with Hatari v1.6 release (and later).
Here's how you would automate same with "hconsole" & EmuTOS shell:
$ hconsole.py commands.txt --exit -- -d tmp/ -m --tos etos512k.img
(i.e. run hconsole commands from "commands.txt" and exit after
giving them Hatari, start Hatari with "-d tmp/ -m --tos etos512k.img"
options, where "tmp" is the directory where asm56000.txt is.)
----- commands.txt content ------
# without this EmuTOS boot takes 10s more
setopt --fastfdc on --fast-forward on
# wait for EmuTOS to boot
# Invoke EmuCON with ^Z: Control down, press Z, Control up
# press Return
# output command to execute
text asm56000.ttp -A -B decoder.asm > debug.txt
# wait for build to finish
# show saved command output
text type debug.txt
(Files in tools/hconsole/ have more info on hconsole.)
> I would say that the >make\debug.txt parameter is not correctly
> interpreted, but I have no clue how to verify this.
In debugger doing at program start (pc=text):
Tells about command line parameters given to program and
about the GEMDOS open file descriptors state. Can you
provide that with full GEMDOS trace?
PS. Are you using Miro's Qt/C++ based LOD -> binary converter?
I've converted that into plain ANSI-C so that it can be run also
under Hatari (as part of my native BadMood builds under Aranym/MiNT),
in case you're interested...
> Le 08/01/2015 21:21, Nicolas Pomarède a écrit :
> > Le 08/01/2015 21:17, Laurent Sallafranque a écrit :
> >> Hi all,
> >> It seems that there's a bug into hatari with asm56000.ttp.
> >> I tried to recompile the mpeg2 library for some tests and it doesn't
> >> work.
> >> Mikro has tried on his falcon and it works.
> >> The thread for more infos is there :
> >> http://dhs.nu/bbs-coding/index.php?request=4814
> >> It seems that something goes wrong when using hatari, but I don't know
> >> exactly where to start from.
> >> I've activated the gemdos traces but I don't see anything that jumps
> >> on me.
> > Hi,
> > did you try with some older Hatari versions ? With old cpu core or new
> > cpu core ? I guess it should not require cycle exactness, so it should
> > work with any cpu config.
> > It could help to track regression.
> > Nicolas