Re: [hatari-devel] asm56000.ttp problem

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

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
sleep 3

# Invoke EmuCON with ^Z: Control down, press Z, Control up
keydown 29
keypress Z
keyup 29

# press Return
keypress 28

# output command to execute
text asm56000.ttp -A -B decoder.asm > debug.txt
keypress 28

# wait for build to finish
sleep 3

# show saved command output
text type debug.txt
keypress 28
---------------------------------

(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):
	info basepage
	info gemdos

Tells about command line parameters given to program and
about the GEMDOS open file descriptors state.   Can you
provide that with full GEMDOS trace?


	- Eero

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...


> Regards
> Laurent
> 
> 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