on .. goto/gosub limited to 12 labels?

[+Gemintronic]

I'm trying to write a byte-code interpreter in bB. It'd be nice if I could use on .. goto but I seem to remember a limit of 12. Is this correct? If so, why haven't I seen this on R.T.s reference page?

[+Random Terrain]

I don't know the exact limit, but the bB page says this:

 

If you have too many jumps to put comfortably in a single on … goto statement, you can break it up into multiple on … goto statements. Example:

 

  if x < 4 then on x goto 100 200 300 400
  y = x - 4 : if y < 4 then on y goto 500 600 700 800
  y = x - 8 : if y < 4 then on y goto 900 1000 1100 1200

[bogax]

I think the limit is the line length.

bB doesn't seem to like lines over about 190 characters.

(I can get it to compile for 44 labels)

 

edit: I can't get it to do more than 45 labels

even with a shorter line

I believe when I asked about parameters I was told 46

was the limit, don't know if that's related

Edited April 11, 2013 by bogax

[+Gemintronic]

I think the limit is the line length.

bB doesn't seem to like lines over about 190 characters.

(I can get it to compile for 44 labels)

 

edit: I can't get it to do more than 45 labels

even with a shorter line

I believe when I asked about parameters I was told 46

was the limit, don't know if that's related

 

This would be good info to keep beside the sections on on .. goto/gosub R.T. we BASIC enthusiasts like to bang up against the compilers limits. Dimes to dollars this question will come up again

[+Random Terrain]

How is this first attempt:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#limitations

 

Then if you guys find other limitations, they can be put there too.

[+Gemintronic]

This looks good. I'm trying to think of other gotchas/limitations.

[+Gemintronic]

As a side I am currently able to use this line in a recent game without issue:

 

on room goto A B C D E F G H I J K L M N O P Q R S T U V W X Y

 

It sucks that the labels must be so terse but with R.T.s technique of using layers of on .. goto or on .. gosub it's passable.

[bogax]

If you're going to need more than one if statement to break things up,

on goto will be faster and shorter and constant time

 rem on i goto
 j = i / 8 : k = i & 7
 on j goto slice0 slice1 slice2 slice3
slice0 on k goto lbl_00 lbl_01 lbl_02 lbl_03 lbl_04 lbl_05 lbl_06 lbl_07
slice1 on k goto lbl_08 lbl_09 lbl_10 lbl_11 lbl_12 lbl_13 lbl_14 lbl_15
slice2 on k goto lbl_16 lbl_17 lbl_18 lbl_19 lbl_20 lbl_21 lbl_22 lbl_23
slice3 on k goto lbl_24 lbl_25 lbl_26 lbl_27 lbl_28 lbl_29 lbl_30 lbl_31

 

for on gosub just gosub to the on goto(s)

( the lbl_xx will be the subroutines )

(which will require moving the on gotos out of the way)

 rem on i gosub
 gosub select
.
.
select
 j = i / 8 : k = i & 7
 on j goto slice0 slice1 slice2 slice3
slice0 on k goto lbl_00 lbl_01 lbl_02 lbl_03 lbl_04 lbl_05 lbl_06 lbl_07
slice1 on k goto lbl_08 lbl_09 lbl_10 lbl_11 lbl_12 lbl_13 lbl_14 lbl_15
slice2 on k goto lbl_16 lbl_17 lbl_18 lbl_19 lbl_20 lbl_21 lbl_22 lbl_23
slice3 on k goto lbl_24 lbl_25 lbl_26 lbl_27 lbl_28 lbl_29 lbl_30 lbl_31

Edited April 29, 2013 by bogax

[Cybearg]

But stacking on...goto statements wastes cycles.

 

It would be better to just use some Assembly. It's pretty simple, since it's basically just an array.

 

on temp1 goto go1 go2 go3 go4

 

translates to:

 

LDX temp1
LDA .L03jumptablehi,x
PHA
LDA .L03jumptablelo,x
PHA
RTS
.L03jumptablehi
.byte >(.go1-1)
.byte >(.go2-1)
.byte >(.go3-1)
.byte >(.go4-1)
.L03jumptablelo
.byte <(.go1-1)
.byte <(.go2-1)
.byte <(.go3-1)
.byte <(.go4-1)

 

So, to use your example:

 

asm
LDX room
LDA .roomjumptablehi,x
PHA
LDA .roomjumptablelo,x
PHA
RTS
end

 

That'll handle the actual jump, so put that where you want the on...goto statement to execute, then somewhere in the file (probably at the end of your game) put the tables it points to:

 

asm
.roomjumptablehi
.byte >(.A-1)
.byte >(.B-1)
.byte >(.C-1)
.byte >(.D-1)
.byte >(.E-1)
.byte >(.F-1)
.byte >(.G-1)
.byte >(.H-1)
.byte >(.I-1)
.byte >(.J-1)
.byte >(.K-1)
.byte >(.L-1)
.byte >(.M-1)
.byte >(.N-1)
.byte >(.O-1)
.byte >(.P-1)
.byte >(.Q-1)
.byte >(.R-1)
.byte >(.S-1)
.byte >(.T-1)
.byte >(.U-1)
.byte >(.V-1)
.byte >(.W-1)
.byte >(.X-1)
.byte >(.Y-1)
.byte >(.Z-1)
.roomjumptablelo
.byte <(.A-1)
.byte <(.B-1)
.byte <(.C-1)
.byte <(.D-1)
.byte <(.E-1)
.byte <(.F-1)
.byte <(.G-1)
.byte <(.H-1)
.byte <(.I-1)
.byte <(.J-1)
.byte <(.K-1)
.byte <(.L-1)
.byte <(.M-1)
.byte <(.N-1)
.byte <(.O-1)
.byte <(.P-1)
.byte <(.Q-1)
.byte <(.R-1)
.byte <(.S-1)
.byte <(.T-1)
.byte <(.U-1)
.byte <(.V-1)
.byte <(.W-1)
.byte <(.X-1)
.byte <(.Y-1)
.byte <(.Z-1)
end

 

... So you're doing exactly what bB would do, but you're just cutting out the batariBasic middle-man. And the nice thing is that these tables can have up to 256 entries (maybe more?): far more than you could hope for with a list in bB itself.

 

Just make sure to make two table entries for each jump: one for the high (>) and one for the low (<)

[bogax]

But stacking on...goto statements wastes cycles.

 

It would be better to just use some Assembly. It's pretty simple, since it's basically just an array.

 

That's cheating

 

(I don't think RT is doing assembly)

[bogax]

You can put the labels into a table in bB

You need to add a period to the beginning

of the label(s) because that's what bB does

The label, "label" is actually ".label"

in the asm bB produces

 

So (with a minimum of asm trickery ) you can

do (something like) this

 

 rem on i goto

 temp1 = lbls_lo[i] : temp2 = lbls_hi[i]

 asm
 jmp (temp1)
end

 data lbls_lo
 <.lbl_00, <.lbl_01, <.lbl_02, <.lbl_03
end

 data lbls_hi
 >.lbl_00, >.lbl_01, >.lbl_02, >.lbl_03
end

 

This uses 2 more cycles and eight more bytes than Cybearg's

(and two temp variables)

 

 

Cybearg's label tables in bB

 

 rem on room goto

 asm
 LDX room
 LDA lbls_hi,x
 PHA
 LDA lbls_lo,x
 PHA
 RTS
end

 data lbls_hi
 <(.lbl_00-1), <(.lbl_01-1), <(.lbl_02-1), <(.lbl_03-1)
end

 data lbls_hi
 >(.lbl_00-1), >(.lbl_01-1), >(.lbl_02-1), >(.lbl_03-1)
end

[+Gemintronic]

@Cybearg:

Frankenpooching asm into bB isn't for the standard user. At best canned libraries and routines are suitable. We have a pretty good idea how the title screen kernel works and interacts with other code whereas custom labels like the ones suggested above are proprietary to a single game and thus cannot build a common base of knowledge.

[Omegamatrix]

But stacking on...goto statements wastes cycles.

 

It would be better to just use some Assembly. It's pretty simple, since it's basically just an array.

 

 

Very good! And yes, you can do up to 256 entries that way. If all of the jumps are within the same page you don't need a look up table for the high address, just manually add it after, i.e.:

 

asm
 LDX room
 LDA #>(.A)
 PHA
 LDA .roomjumptablelo,x
 PHA
 RTS
end

 

 

 

Now if that won't work because the jumps could be to anywhere, then you could also write the lookup table as shown below. This is only good for 128 entries, but using "word" instead of "byte" is easier to maintain because the label is in a single table (and not split into two). It doesn't save you any bytes in the rom... you are just using a neater way of writing the label.

 

asm
 LDX room
 LDA .roomjumptable+1,x
 PHA
 LDA .roomjumptable,x
 PHA
 RTS
end

 

asm
.roomjumptable
 .word (.A-1)
 .word (.B-1)
 .word (.C-1)
 .word (.D-1)
 .word (.E-1)
 .word (.F-1)
 .word (.G-1)
 .word (.H-1)
 .word (.I-1)
 .word (.J-1)
 .word (.K-1)
 .word (.L-1)
 .word (.M-1)
 .word (.N-1)
 .word (.O-1)
 .word (.P-1)
 .word (.Q-1)
 .word (.R-1)
 .word (.S-1)
 .word (.T-1)
 .word (.U-1)
 .word (.V-1)
 .word (.W-1)
 .word (.X-1)
 .word (.Y-1)
 .word (.Z-1)
end

 

 

Finally, you may also lay the table horizontally to take up less space is your .bas or asm file:

 

asm
 .word (.A-1),(.B-1),(.C-1),(.D-1),(.E-1),(.F-1),(.G-1),(.H-1),(.I-1)
 .word (.J-1),(.K-1),(.L-1),(.M-1),(.N-1),(.O-1),(.P-1),(.Q-1),(.R-1)
 .word (.S-1),(.T-1),(.U-1),(.V-1),(.W-1),(.X-1),(.Y-1),(.Z-1)
end

 

 

So yeah, not to hard at all, and you can do many labels.