Jump Command delayed

[codingPF]

Hi, i am just new to this and had a try on the calculator program as a start. I noted that the jump command causes a significant delay in the overall processing i.e. the jump function is execute about 2 seconds delayed. Is this the expected behaviour?

[nomeata]

No, usually the jump command is quick. Can you describe precisely what you observe? Can you reproduce it with a smaller GME file, e.g. one with just two scripts and one jump? Do you have an old or a new (with audiobooks) pen?

[codingPF]

Ok...i reduced the example to below code (no more content in yaml)

  JF_p1_next:
  - P(A00_ok)
  F_eins:
  - P(A00_ok) J(JF_p1_next)
scriptcodes:
  F_eins: 1001
  JF_p1_next: 9901
speak:
  A00_ok: "OK"

The output is: "OK"...4 seconds...."OK"

Yes this the new pen with audiobooks etc... Update: tttool version is tttool-win32-1.5.1

[nomeata]

Can anyone with an old pen reproduce this?

The audio file (found in the tts-cache subdirectory) is short as expected?

Karsten reported something similar on https://lists.nomeata.de/archive/tiptoi/2015/001042.html but for him the problem somehow disappeared.

[KaVo2009]

Hi there,

I was now able to compare the old against the new stick regarding the JUMP "performance".

While doing so I slightly changed the above code to the following:

product-id: 955

init: 
 $n:=0

welcome: bing

scripts:
  go:
  - $n<100? $n:=0 P(ok) J(schleife)

  schleife:
  - $n<25? $n+=1 J(schleife)
  - $n==25? P(ok)

speak:
 ok: "ok"

Pushing on the Go OID the stick says ok, then it takes a moment, then it says again ok.

I entered a loop in order to avoid one time effects and bad time taking.

That mentioned moment took on the old stick approx. 3.5 seconds, while it took the new stick more than 40 seconds. So, if I am not mistaken, there is a material change in the performance.

Next I am looking for an official GME that easily would allow to compare the new sticks performance on original jump code sections against the old one...

Karsten V.

[nomeata]

Next I am looking for an official GME that easily would allow to compare the new sticks performance on original jump code sections against the old one...

Thanks. If we can observe it here we can talk to Ravensburger about it :-)

[KaVo2009]

Well, it is not that easy to find a good and comprehensive section in an official book. With the following lines I hope to be able explaining what I did.

First, I do not find any kind of loop in the official books I got (or better we got, in total more than 15 official books and games). So I chose one that I thought is easy to be analysed, I chose Grundschulwörterbuch Englisch.

I exported its GME and generated an YAML. It uses $51 to set the mode. Mode 2 in this register defines it to be erzählen mode (I figured it out by sound 133, which is the identifier sound for that mode). Now when you tip on the sentence "I call my father "daddy"" on page 8 while being in mode 2 then it goes through this script code:

4122:

• $51==1? P(160)
• $51==2? $51:=1 J(4122)

So t at least here is one Jump in use. It first brings the mode back to 1 (entdecken) then jumps back to the same section and plays the designated sentence "P(160)".

And as a result, being in mode 2, then tipping onto the above line >> I am not able to identify any material delay in the output of the new and the old stick. Puuh, that is not what I expected. Perhaps it is to short to be correctly measured (I don't think so).

Now I don't think it would help to add the above used multiplier loop, then assemble it and try again with old and new stick, as the code is then now longer the official one, would it.

Be free to comment if my approach is not sufficient or if you can hint how to better check oifficial code...thanks...

Karsten V.

[uli42]

On Mon, Jan 4, 2016 at 10:19 PM, KaVo2009 notifications@github.com wrote:

Now I don't think it would help to add the above used multiplier loop, then assemble it and try again with old and new stick, as the code is then now longer the official one, would it.

Generating a yaml file from an existing gme and the assemble the yaml back will generate a working gme (minus the games). So I think the next step should be to do just that with the "Grundschultwörterbuch Englisch" and verify if the behaviour changed.

Uli

[MKdent]

Hello, I'm a new user of your great tttool and I just bought a pen 2 weeks ago. I can confirm that problem: tried out the calculator progam and took quite some time between the jump commands. I do have a new pen with firmware V5-24-1 .

Michael

[KaVo2009]

Okay, next try...

While doing the assemble of the Grundschuldwörterbuch Englisch.yaml tttool complains to many open files. The official gme is 79 MB fat, the media option generates 10.668 files with 108 MB. tttool stops at 2839.ogg. So I am not able to perform the suggested comparison.

I will look now for a smaller file with a JUMP and then indicate the results...

Karsten V.

[KaVo2009]

Here I am again with some sort of results (sort of).

I now focussed onto the star wars book. It offers the mode HANDLUNG ($79=2). Being in that mode and then clicking on the name of Boba Fett, the code first sets $79 onto 1 (equals entdecken mode) , jumps again to the same script and then plays off no. 28 (saying Boba Fett). It lloks like this:

3897:

• $79==1? $79:=2 P(136) $81:=3897 $83:=0 mode Handlung activated, play sound
• $79==2? P(136) $81:=3897 $83:=0
• $79==3? $79:=2 P(136) $81:=3897 $83:=0

4145:

• $79==1? P(28) $81:=4145 $83:=0 play “bobba fett”
• $79==2? $79:=1 J(4145) mode entdecken activated
• $79==3? $79:=1 J(4145)

Now when you do this (first activate mode HANDLUNG then click on the name Boba Fett) it is doing this with any significant delay. It appears to speak the name directly.

When I assemble the exported code (by the way it is afterwards 7 MB smaller than the official GME) and do the same on that one, I have the feeling that it is then not playing the sound directly, it feels like a small pause of close to one second. But it is as well that small (not 4 seconds), that it might be related to the usual delay that is given when you don't tip on the oid perfectly.

I went through comparison cycles several times (official versus re-assembled GME), and I assured myself that my feeling of the pause in the re-assembled version is not imaginary, it is really there, but as said, the pause is really not long like several seconds (just one).

I hope that helps a bit, I am again free for furher sugestions...

Karsten V.

[nomeata]

I hope that helps a bit, I am again free for furher sugestions...

I believe it does help, as it shows that there is something wrong... If we only knew what.

Can you compare the raw bytes of the original and the modified file, using

./tttool script --raw original.gme 4145
./tttool script --raw assembled.gme 4145

[KaVo2009]

Hi again,

it looks like this, there are differences, see first line two last entries are in original "1C 00" and in assembled "2A 01" (whatever that means). See the output below:

First the assembled one:

Script for OID 4145:
01 00 00 4F 00 F9 FF 01 01 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 31 10 53 00 F9 FF 01 00 00 01 00 2A 01
01 00 00 4F 00 F9 FF 01 02 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00
01 00 00 4F 00 F9 FF 01 03 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00
01 00 00 4F 00 F9 FF 01 04 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 05 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 06 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 07 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 08 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 09 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0A 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0B 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0C 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0D 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0E 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0F 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 10 00 00 00 00 00

Then the original one:

Script for OID 4145:
01 00 00 4F 00 F9 FF 01 01 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 31 10 53 00 F9 FF 01 00 00 01 00 1C 00
01 00 00 4F 00 F9 FF 01 02 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00
01 00 00 4F 00 F9 FF 01 03 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00
01 00 00 4F 00 F9 FF 01 04 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 05 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 06 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 07 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 08 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 09 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0A 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0B 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0C 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0D 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0E 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0F 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 10 00 00 00 00 00

regards

Karsten V.

[nomeata]

Thats the number of the audio file to play; this variation is expected. Very strange then.

[KaVo2009]

You are far more familiar with these topics than I am, but isn't the audio play file the same (name / content)?

[KaVo2009]

Most likely this is not relevant, but 3897 looks slightly different as well; see first line 88 turns 8B:

the assembled one:

Script for OID 3897:

01 00 00 4F 00 F9 FF 01 01 00 04 00 4F 00 F9 FF 01 02 00 00 00 E8 FF 01 00 00 51
 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 8B 00
01 00 00 4F 00 F9 FF 01 02 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 39 0F 53
 00 F9 FF 01 00 00 01 00 8B 00
01 00 00 4F 00 F9 FF 01 03 00 04 00 4F 00 F9 FF 01 02 00 00 00 E8 FF 01 00 00 51
 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 8B 00
01 00 00 4F 00 F9 FF 01 04 00 05 00 00 00 FF FA 01 FF FF 4F 00 F9 FF 01 02 00 00
 00 E8 FF 01 00 00 51 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 8B 00
01 00 00 4F 00 F9 FF 01 05 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 06 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 07 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 08 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 09 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0A 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0B 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0C 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0D 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0E 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0F 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 10 00 00 00 00 00

The original one:

01 00 00 4F 00 F9 FF 01 01 00 04 00 4F 00 F9 FF 01 02 00 00 00 E8 FF 01 00 00 51
 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 88 00
01 00 00 4F 00 F9 FF 01 02 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 39 0F 53
 00 F9 FF 01 00 00 01 00 88 00
01 00 00 4F 00 F9 FF 01 03 00 04 00 4F 00 F9 FF 01 02 00 00 00 E8 FF 01 00 00 51
 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 88 00
01 00 00 4F 00 F9 FF 01 04 00 05 00 00 00 FF FA 01 FF FF 4F 00 F9 FF 01 02 00 00
 00 E8 FF 01 00 00 51 00 F9 FF 01 39 0F 53 00 F9 FF 01 00 00 01 00 88 00
01 00 00 4F 00 F9 FF 01 05 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 06 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 07 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 08 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 09 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0A 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0B 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0C 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0D 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0E 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 0F 00 00 00 00 00
01 00 00 4F 00 F9 FF 01 10 00 00 00 00 00

[nomeata]

You are far more familiar with these topics than I am, but isn't the audio play file the same (name / content)?

There are no names in the GME file; all audio files are put in one list and then addressed by their index. And their order is not preserved when exporting and importing, hence the number can change. These are always the last (few) numbers of a line, so that really shouldn’t cause any difference in behavior.

[KaVo2009]

Hi there again, I am still dealing with this topic. It seems my latest investigation was either not scientifically enough or driven by my wish to solve this issue (or both). Anyhow the approach followed up until now was not sufficient.

Is it possible that we are missing something based on an unknown part of the GME original code? I understand the export and the script function deal with known code sections.

So as a conclusion why question would be, might it make sense to compare the original GME and the re-assembled version via HEX code directly?

[KaVo2009]

Going on...

I cut down the original Star Wars YAML to the below code (so only to the investigated sections):

media-path: media/Star Wars - Episode I-VI_%s
speak: null
language: null
welcome: 1347,1348
product-id: 80
comment: CHOMPTECH DATA FORMAT CopyRight 2009 Ver2.10.0901
scripts:
  4145:
  - $79==1? P(28) $81:=4145 $83:=0
  - $79==2? $79:=1 J(4145)
  - $79==3? $79:=1 J(4145)

3897:
  - $79==1? $79:=2 P(136) $81:=3897 $83:=0
  - $79==2? P(136) $81:=3897 $83:=0
  - $79==3? $79:=2 P(136) $81:=3897 $83:=0
  - $79==4? C $79:=2 P(136) $81:=3897 $83:=0

init: $79:=1 $80:=99
scriptcodes: null

It still reacts as described before, so no major (longer than 1 second) delay between clicking on the OID and the sound comning from the stick.

Now looking for solutions it came to my mind to try whther our problem might be drivem by having PLAY commands in a line before doinf the jump, so I put in 4145 the P(28) and it looks like this

media-path: media/Star Wars - Episode I-VI_%s
speak: null
language: null
welcome: 1347,1348
product-id: 80
comment: CHOMPTECH DATA FORMAT CopyRight 2009 Ver2.10.0901
scripts:
  4145:
  - $79==1? P(28) $81:=4145 $83:=0
  - $79==2? P(28) $79:=1 J(4145)
  - $79==3? $79:=1 J(4145)

3897:

  - $79==1? $79:=2 P(136) $81:=3897 $83:=0
  - $79==2? P(136) $81:=3897 $83:=0
  - $79==3? $79:=2 P(136) $81:=3897 $83:=0
  - $79==4? C $79:=2 P(136) $81:=3897 $83:=0

init: $79:=1 $80:=99
scriptcodes: null

Now guess what happened, I have a pause a delay between the two spoken (Bobba Fett).

I exported the gme again to show the raw (hope this helps):

01 00 00 4F 00 F9 FF 01 01 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 31 10 53 00 F9 FF 01 00 00 01 00 03 00
01 00 00 4F 00 F9 FF 01 02 00 03 00 00 00 E8 FF 01 00 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 01 00 03 00
01 00 00 4F 00 F9 FF 01 03 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00

This is how it looked like without the additional play command:

01 00 00 4F 00 F9 FF 01 01 00 03 00 00 00 E8 FF 01 00 00 51 00 F9 FF 01 31 10 53 00 F9 FF 01 00 00 01 00 03 00
01 00 00 4F 00 F9 FF 01 02 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00
01 00 00 4F 00 F9 FF 01 03 00 02 00 4F 00 F9 FF 01 01 00 00 00 FF F8 01 31 10 00 00

Does this explain something?

I hope this time the info is correct & helpful ...

Karsten V.

[KaVo2009]

Tonight i will check the results of both yaml versions on the old stick and see if there is an ending pause on the ogg file. I'll give an update...

Karsten V.

[KaVo2009]

So, next step, doing the same on the old stick: there is no delay like on the new one.

So the pause is only given if a play command is set prior to a jump instruction in the same line (and that only on the new stick).

Can somebody confirm?

Karsten V.

[KaVo2009]

And here comes the funny & doubtful part (so I will recheck it tonight):

If I put it like this

media-path: media/Star Wars - Episode I-VI_%s
speak: null
language: null
welcome: 1347,1348
product-id: 80
comment: CHOMPTECH DATA FORMAT CopyRight 2009 Ver2.10.0901
scripts:
  4145:
  - $79==1? P(28) $81:=4145 $83:=0
  - $79==2? $79:=1 J(4145) P(28) 
  - $79==3? $79:=1 J(4145)
  3897:
  - $79==1? $79:=2 P(136) $81:=3897 $83:=0
  - $79==2? P(136) $81:=3897 $83:=0
  - $79==3? $79:=2 P(136) $81:=3897 $83:=0
  - $79==4? C $79:=2 P(136) $81:=3897 $83:=0
init: $79:=1 $80:=99
scriptcodes: null

there is NO pause between the two sounds (Bobba Fett).

A PLAY after a JUMP in the same line (makes no sense to me) is still being played and avoids the pause.

VERY STRANGE! As I said I will recheck it again tonight.

But if it's going to confirmed, then I am fine again with the new stick...

Karsten V.

[KaVo2009]

C O N F I R M A T I O N

When you want to avoid (on the new player stick) having the pause/delay you need to put the PLAY commands after the jump (int he same line), that's all

Karsten V.

[nomeata]

When you want to avoid (on the new player stick) having the pause/delay you need to put the PLAY commands after the jump (int he same line), that's all

Great, thanks for the analysis!

And it will still play the audio, on both sticks?

I wonder what happens if you put two jump commands in one line. Which one wins? Or will both be played, one after another (which would be great!)?

[uli42]

What if the sound is referenced by a register that gets changed after the play command (in the original order)? Or is there no such play command existing?

Uli

Vom Smartphone gesendet.

----- Ursprüngliche Nachricht ----- Von: "Joachim Breitner" notifications@github.com Gesendet: ‎14.‎01.‎2016 00:24 An: "entropia/tip-toi-reveng" tip-toi-reveng@noreply.github.com Cc: "uli42" uli42@gmx.de Betreff: Re: [tip-toi-reveng] Jump Command delayed (#124)

When you want to avoid (on the new player stick) having the pause/delay you need to put the PLAY commands after the jump (int he same line), that's all Great, thanks for the analysis! And it will still play the audio, on both sticks? I wonder what happens if you put two jump commands in one line. Which one wins? Or will both be played, one after another (which would be great!)? — Reply to this email directly or view it on GitHub.

[nomeata]

What if the sound is referenced by a register that gets changed after the play command (in the original order)? Or is there no such play command existing?

I think we have tried once, and found that the Play command does not support registers. But you can try again, to make sure.

[KaVo2009]

Next step, the result of clicking on below OID section1 is:

section1:
 - P(eins) J(section2) P(zwei)
section2:
 - P(drei)

is "eins zwei drei" without delay.

section3:
 - P(eins) J(section4) P(zwei) J(section4)
section4:
 - P(drei)

is "eins zwei ....................drei..................drei" with pauses.

And:

section5:
- P(eins) J(section6) P(zwei) J(section7) 
section6:
- P(drei)
section7:
- P(eins)

says (with pauses) "eins zwei...............eins"

So the last jump wins...

Karsten V.

[KaVo2009]

Sorry, in my prior comment the formating got lost...

[nomeata]

So it seems that the pen keeps track of the jump target, updates it with the J command, and does the jump at the end.

About formatting: Have a look at https://guides.github.com/features/mastering-markdown/, and remember that you an edit your posts.

[uli42]

On Thu, Jan 14, 2016 at 9:02 PM, KaVo2009 notifications@github.com wrote:

section3: P(eins) J(section4) P(zwei) J(section4)

section4: P(drei)

is "eins zwei ....................drei..................drei" with pauses.

Hmm, so both jumps are executed, and both produce a delay. What happens, when you put the first jump to the beginning of the line? Waht happens when there's one or more additonal play command(s) after the last jump?

section5: P(eins) J(section6) P(zwei) J(section7)

section6: P(drei)

section7: P(eins)

says (with pauses) "eins zwei...............eins"

So the last jump wins...

This kind of contradicts the previous finding: in section3 both jumps lead to the same destination an both where executed. Here the section5 line looks identical but has two different destinations but only the last one gets executed. I would have expected "eins zwei ............. drei ............. eins.

Uli

[KaVo2009]

Thanks for the comments, based on the queries i ran a recheck and need to post a correction: This one

section3:
 - P(eins) J(section4) P(zwei) J(section4)
section4:
 - P(drei)

creates "eins zwei ....................drei" with pauses.

This one

section3:
 - J(section4) P(eins) P(zwei) J(section4)
section4:
 - P(drei)

creates "eins zwei ....................drei" as well.

And this one

section3:
 - P(eins) J(section4) P(zwei) J(section4) P(zwei)
section4:
 - P(drei)

creates "eins zwei zwei drei" without pauses (that's surprising). Only one jump per line is executed, but to avoid pauses it is enough that jump is simply not the last instruction.

Cross check, this one

section3:
 - P(eins) J(section4) P(zwei) J(section4) P(zwei) J(section4)
section4:
 - P(drei)

creates "eins zwei zwei............................drei" with the pause.

So I hope the logic is now clear or has anybody a further wish ;-) to let a construction be tested?

so far

Karsten V.

[KaVo2009]

ps: how is it possible to acchieve a proper layout in here (this is obviously off topic)?

[nomeata]

ps: how is it possible to acchieve a proper layout in here (this is obviously off topic)?

Put the code between lines with ``(see https://guides.github.com/features/mastering-markdown/, selectCode` under examples)

[uli42]

On Fri, Jan 15, 2016 at 6:12 AM, KaVo2009 notifications@github.com wrote:

Only one jump per line is executed, but to avoid pauses it is enough that jump is simply not the last instruction.

In the nineties I once programmed a PA-RISC processor with assembler code. That architecture had an optimization which lead to unexpected results if you were not aware of it: On every branch or jump the instruction directly after the jump instruction was also executed. So you had to introduce NOPs after the jump or reorder the code before the jump and move one instruction to after the jump. Maybe we have something similar here and need some kind of NOP instruction here. Maybe 0000 after the jump will suffice, someone should test. Or and AND operation of a register on itself.

Uli

[KaVo2009]

Now you lost me. I am willing to perform the requested check, but l need to better understand, what I shall do. Can you be a bit more precise? What is this NOP? (Sorry my experiences in the 90s covered only Pascal and Delphi)...

Karsten V.

[uli42]

On Fri, Jan 15, 2016 at 1:11 PM, KaVo2009 notifications@github.com wrote:

Now you lost me. I am willing to perform the requested check, but l need to better understand, what I shall do. Can you be a bit more precise? What is this NOP? (Sorry my experiences in the 90s covered only Pascal and Delphi)...

Don't worry ;-) NOP means "No Operation", a dummy command that does nothing. I meant that tttool should insert a NOP automatically if a jump is the last instruction in a line. But we have not found such a command (yet) so we have to find a replacement, an operation that effectively does nothing, e.g. bitwise AND of a register's content with itself or adding 0 to a register. Something like that. What you could test is inserting such dummy commands after the last jump ans see if that kills the pause. The other ideas was to append 0000 to a line (2 null bytes) and see if that also helps. This is something one must do using a hexeditor, tttool cannot do this, I think.

Uli

[KaVo2009]

Strange things go on & sort of no confirmation, this

section1:
 - P(eins) J(section2) P(zwei) J(section4) $zahl+=0
section2:
 - P(drei)

sounds like "eins zwei................drei"

Is it correct that this would result would not support the "no operation at the" assumption or shall I use something else at the end?

Karsten V.

[nomeata]

Interesting example. What is the code of section4, i.e. the last jump?

[KaVo2009]

Räusper, it is based on the lazy guy, doing cut copy paste and not completely and carefully doing the required changes, that means that the jump in section1 was linked to secton2 and not to section4, sorry for that.

[KaVo2009]

Continueing ...

This one

section1:
 - P(eins) J(section2) P(zwei) J(section2)
section2:
 - P(drei)  $zahl+=0

sounds as well like "eins zwei................drei"

Karsten V.