bogax

it doesn't work as advertised the BS_jsr+6 comes after the bank switch and so never executes it just so happens that the bank switch ends up in the dloop I haven't figured out how to fix it

well in that case set romsize 16k set optimization inlinerand set optimization noinlinedata def gt_bank = callmacro bsm macro bsm asm lda #>({1}-1) pha lda #<({1}-1) pha ldx {2} lda bankswitch_hotspot-1,x jmp BS_jsr+6 end end q = $55 gt_bank dloop 2 bank 2 a = a data dloop end dloop c = c + 1 if !c & $7F then q = q ^ $FF : COLUBK = q if e && joy0fire then q = q + 4 : COLUBK = q if joy0fire then e = 0 else e = 1 drawscreen goto dloop bank 3 bank 4 (yes , it works)

if I do this def gt_bank = callmacro bsm macro bsm asm lda #>(.{1}-1) pha lda #<(.{1}-1) pha ldx {2} lda bankswitch_hotspot-1,x jmp BS_jsr+6 end end gt_bank dloop 2 it complains about uresolved symbol 1.dloop I don't know where that comes from it seems to produce correct code but won't assemble 90 1004 .L08 ; gt_bank dloop 2 91 1004 0 1004 bsm dloop, #2, 1 1004 2 1004 .L06 3 1004 4 1004 a9 ff lda #>(.dloop-1) 5 1006 6 1006 48 pha 7 1007 8 1007 a9 ff lda #<(.dloop-1) 9 1009 10 1009 48 pha 11 100a 12 100a a2 02 ldx #2 13 100c 14 100c bd f5 1f lda bankswitch_hotspot-1,x 15 100f 16 100f 4c f1 ff jmp BS_jsr+6 copy and paste errror in the previous code (although it seems to work) should have been macro bsm asm lda {2} pha lda {1} pha ldx {3} lda bankswitch_hotspot-1,x jmp BS_jsr+6 end end

it appears to work with just a little trickery set romsize 16k set optimization inlinerand const targetlo = <(.dloop-1) const targethi = >(.dloop-1) def gt_bank = callmacro bsm macro bsm asm lda #{2} pha lda #{1} pha ldx {3} lda bankswitch_hotspot-1,x jmp BS_jsr+6 end end q = $55 gt_bank targetlo targethi 2 bank 2 a = a dloop c = c + 1 if !c & $7F then q = q ^ $FF : COLUBK = q if e && joy0fire then q = q + 4 : COLUBK = q if joy0fire then e = 0 else e = 1 drawscreen goto dloop bank 3 bank 4

What did you use to graph them?

if you add up a bunch of pieces there's more ways to get the middle numbers and you end up with a trapazoidal distribution if you call rand 5 times each time you want a number you'll only get 255/5 different numbers (255 is the length of the rand cycle) if I understand what you mean by wrapping, you're taking rand MOD the screen width and you'll have more of the lower numbers (the numbers 0 to 255-max) MOD is probably the best way if you can spare a variable to (sort of) carry that bias forward edit: but the best thing to do with a spare variable would be use rand16 something like temp1 = myseed myseed = myseed + rand if temp1 > myseed then myseed = myseed - max if myseed > max then myseed = myseed - max

you could put it in a subroutine or a macro

rand is a counter that counts in a funny sequence here rnd and rnd16 are (something like) rand, only in bB this is set up for rand16. for rand you'd have to comment out the dim of rand16 and change the gosub rnd16 in the if statement to gosub rnd dim sc0 = score dim sc1 = score + 1 dim sc2 = score + 2 dim r16 = s dim rand16 = z r = 1 : rand = 1 : r16 = 0 : rand16 = 0 scorecolor = $44 loop if f && joy0fire then gosub rnd16 : temp2 = rand : gosub update_scr if joy0fire then f = 0 else f = 1 drawscreen goto loop rnd if r{0} then r = r/2 ^ $B4 else r = r/2 temp1 = r return rnd16 temp1 = r16 r16 = r16 * 2 if r{0} then r16{0} = 1 if temp1{7} then r = r/2 ^ $B4 else r = r/2 temp1 = r ^ r16 return update_scr sc0 = 0 : sc1 = sc1 & 15 if temp1 >= 100 then sc0 = sc0 + 16 : temp1 = temp1 - 100 if temp1 >= 100 then sc0 = sc0 + 16 : temp1 = temp1 - 100 if temp1 >= 50 then sc0 = sc0 + 5 : temp1 = temp1 - 50 if temp1 >= 30 then sc0 = sc0 + 3 : temp1 = temp1 - 30 if temp1 >= 20 then sc0 = sc0 + 2 : temp1 = temp1 - 20 if temp1 >= 10 then sc0 = sc0 + 1 : temp1 = temp1 - 10 sc1 = (temp1 * 4 * 4) | sc1 sc1 = sc1 & 240 : sc2 = 0 if temp2 >= 100 then sc1 = sc1 + 1 : temp2 = temp2 - 100 if temp2 >= 100 then sc1 = sc1 + 1 : temp2 = temp2 - 100 if temp2 >= 50 then sc2 = sc2 + 80 : temp2 = temp2 - 50 if temp2 >= 30 then sc2 = sc2 + 48 : temp2 = temp2 - 30 if temp2 >= 20 then sc2 = sc2 + 32 : temp2 = temp2 - 20 if temp2 >= 10 then sc2 = sc2 + 16 : temp2 = temp2 - 10 sc2 = sc2 | temp2 return basic_rand.bas.bin

you're not calling rand in the if satement just testing the rand variable assign rand to a temp variable and test it try temp1 = rand if temp1 < 100 then goto one etc

dim p1y = player1y.p ; p is the fractional part if player1y > player0y then p1y = p1y - 0.5

depends on what you're trying to do this is probably what you want

This is all pretty basic Go read some stuff Memory is like a bunch of little boxes or slots with coins in them The coins can be heads or tails If it's heads it's a 1 if it's tails it's a 0 The boxes are numbered (the number is its address) and you refer to a particular box by its number Being restricted to values of 0, 1 isn't very convenient so the boxes hold groups of coins (call them bits) In the 2600 processor the groups are 8 bits each bit has two possible values 0,1 so the total possibilities for the group are 2**8 or 256 or 0..255 (that's where the 0..255 for a variable comes from) Go read about binary numbers The groups are ordered and individual bits are refered to by a number. You could call it the bit address The bits correspond between groups, bit 0 in this group corresponds to bit 0 in that group, b1 to b1, b2 to b2 etc Each bit can have (will usually have) a particular meaning/signifigance depending on its "position" (number, bit address, whatever) We generally refer to the group of eight bits as a byte. If I say a = b the processor looks at bit 0 in b and sets bit 0 in a to be the same. If it's coins, if coin 0 in b is tails then coin 0 in a gets set to tails if b0 is heads a0 gets set to heads Likewise for the other bits in the group/byte So in effect b is copied to a Actually, the processor has a special box in it, the accumulator, that it uses for temporary stuff and what actually happens is b gets copied to the accumulator and then the accumulator is copied to a a and b are just names for the box numbers (the addresses) It happens that a, b, c have a sequence, an order (alphabetical) and the addresses have an order (numerical order) bB is set up so they correspond if you index a variable a = a[3] it takes a as corresponding to index 0 and adds 3 (a is an address, a name for a location where a number is stored) so a[0] is a and a[3] and d are two different ways of refering to the same location I could impliment a stack in bB as dim stack_pointer = s ; makes stack_pointer another name for location s dim stack = a s = 0 push_z stack_pointer = stack_pointer + 1 : stack[stack_pointer] = z pull_z z = stack[stack_pointer] : stack_pointer = stack_pointer - 1 of course you don't want a dedicated routine for each variable, you'd have a macro or a function that took z as a parameter so it might be push z pull z The stack is a way of squeezing access to a bunch of locations into a single location Go read about stacks I'm not very familiar with DPC+ but I think it's something like this the ARM processor has it's own memory and the 2600 doesn't have much And the 2600 doesn't have much of it's address space exposed and not much to share The stack is a way of using the same address for a bunch of different locations so the 2600 can use some of the ARM memory without using much of the 2600's space The ARM does something similar to the above code with its memory and the 2600 just sees/uses a single location, the stack (which is virtual, it's really the ARM running the routines, although there maybe an actuall location associated with the stack, like I said I'm not that familiar with it)

yes, but you can't calculate the bit specified the number in the brackets has to be a number literal not a variable or an expression and it doesn't always show an error if eg you use a variable you don't have to do all eight bits if you use the table dim bitstoswap = b dim idx = i const sbits0 = setbyte + 8 ; set a bit var31 = var31 | sbits0[idx] ; clear a bit var31 = (sbits0[idx] ^ %11111111) & var31 ; swap in bits 2, 3, 6 var31 = ((sbits0[idx] ^ var31) & %01001100) ^ var31 ; swap in bits 2, 3, 6 var31 = ((var31 ^ bitstoswap) & %01001100) ^ var31 it would be nice to build macros but bB macros are just DASM macros and DASM wouldn't understand the indexing so it would have to be done in ASM dim idx = i const sbits0 = setbyte + 8 def set_bit = callmacro stb_m def clear_bit = callmacro clb_m ; parameters target variable, number of bit to set macro stb_m asm ldx {2} lda sbits0,x ora {1} sta {1} end end ; parameters target variable, number of bit to clear macro clb_m asm ldx {2} lda sbits0,x eor #$FF and {1} sta {1} end end ; usage set_bit var31 idx clear_bit var31 idx

I didn't explain very well Perhaps some of this is not as obvious as I think (I'm thinking) we're optimizing for time First thing I note is that you test for counter values and when you find one, you set var31 then test for more values that you know it can't be. Usually I think of a table look up as (probably) trading ROM space for speed. In this case you said you'd chosen "weird counter numbers" for timing so I regularized The intervals and added a guard condition for multiples of 8 ie if counter & 7 then .. so now 7 out of 8 times you only do one if test If you really needed the weird numbers you could still eg test for values between say, 40 and 100 and skipped 40% of the time (if your counter went 0..100) and done only two tests That's more code and more time but it's probably a net gain You could go farther and test for numbers that are eg equal to - greater than an even multiple of 4 but less than the next odd multiple (if that fit the values you were looking for) that would add another test but cut out half the possibilities if counter & 4 then You might do a binary search if you had more weird values Or you might use a look up table, but then you'd need like 60 entries if the values could be anything 40..100 A look up table would still be lot faster even if it didn't save any space I didn't really figure it out, but I think in this case you'd still save a few bytes of ROM And tables can be completely arbitrary none of this needs assembly except perhaps to have an idea of the time and space I would certainly encourage you to learn the assembly and read the list file to see what you're getting and a bit of assembly can be really useful even if you're using bB I especially like RevEng's suggetion (somewhere in this forum) of getting the assembler to print the difference (amount of code) between two lables

it's true it uses less ROM but the point is it uses less time (and something closer to only the time necessary)

the kernel has a table called setbyte that it uses for setting pixels in the playfield and other stuff it varies depending on how the playfield is structured in this case it would be (in bB) something like data setbyte $80, $40, $20, $10, $08, $04, $02, $01, $01, $02, $04, $08, $10, $20, $40, $80, $80, $40, $20, $10, $08, $04, $02, $01, $01, $02, $04, $08, $10, $20, $40, $80 end I just made v31_data an alias for setbyte (which was totally unnecessary) playfield statements get their own tables for the whole playfield

my point was that you're doing a bunch of if statements that you don't need to do most of the time actually this makes more sense and if that last byte in the table is meant to be a 1 then you could use the table the kernel uses const v31_data = setbyte if counter & 7 then skip_v31 temp1 = counter/8 - 5 if temp1 < 8 then var31 = v31_data[temp1] skip_v31

do fewer if statements temp1 = counter/8 - 5 if !counter & 7 && temp1 < 8 then var31 = dat[temp1] data dat $80, $40, $20, $10, $08, $04, $02, $00 end

presumably you want to switch characters the first time you see the switch is pressed and ignore it if it's still pressed ie you need to remember the switch state from last time and then change characters only if it wasn't pressed last time and is pressed this time. something like this if switchselect && enable then gosub change_character if switchselect then enable = 0 else enable = 1

here's one. not perfect temp1 = rand/2: temp1 = (((((temp1/2 + temp1)/2 + temp1)/2 +temp1)/2 + temp1)/4 + temp1)/8 + temp1 + 4

perhaps you could keep the sprites in the same page and just flip the lo byte of the pointer something like AreWeChanging: lda P0FrameCounter cmp #10 bne SkipFlip FlipSpritePointer: lda #0 sta P0FrameCounter lda P0SpritePtr; lo byte pointer for P0 Sprite eor #<P0Sprite1 ^ <P0Sprite2 sta P0SpritePtr SkipFlip: or if a power of 2 will do for the count let the counter run and AND with a 2**n - 1 and bne

tay and #%000000111 tax tya lsr lsr lsr tay lda dis_solid,y and number_to_bit,x rts

I would expect that you'll find it easiest to maintan a seperate variable for your velocity One, the player positions are in increments of a pixel and that's probably too coarse. Your velocities would be 1 pixel, 2 pixels, 3 pixels etc per frame ie speed across the screen in the x direction in (rougly) 3 seconds, 1.5 seconds, 1 second You'll probably want fractional velocities (and acceleration). And two you will need to remember your velocities for your inertia effects You could probably contrive something with flags and counters but you would still be using extra variables (but they might serve additional purposes) If you are willing to unravel the bits yourself you dont need to use bBs built in 8.8 math, you might eg pack two 1.3 (4 bit) variables into a byte which would give you velocities 0..2 (0..1.875 actually) pixels/frame and velocities in increments of 1/8 pixel/frame

edit never mind

it's also less random