bogax

rand is just a counter that counts in a funny sequence if you start from the same spot it will count through the same sequence

heh I just realized you're telling it to turn on the 12th line in phline (you want row 10)

1line13.bas has 10 lines in the playfield definition I don't know why pfhline isn't working, but maybe that has something to do with it

this is untested assuming a set of flags in ram consisting of 18 consecutive bytes (for a 16 x 9 matrix) here starting with h also assumes the puzzle is in the middle two byte columns ie the flags are for pfpixels 8..23 x 1..9 with pfpixel 7, 0 being puzzle 0, 0 visited(col, row) will return true (non zero) for a set pixel flag (kinda like pfread) and setvf(col, row) should set a flag the parameters are column x row in pfpixels and assume that the upper right corner of the puzzle matrix is at 1, 1 (at least that's what they're meant to do, like I said, untested) dim vfx = temp1 dim vfy = temp2 dim vfptr = temp3 const vbase = h ; z - 18 const midsb = setbyte + 8 function visited() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vfptr = midsb[vfx] & vbase[vfptr] return function setvf() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vbase[vfptr] = midsb[vfx] | vbase[vfptr] return

I think this is what you want you need to increment by 1 and write another byte then increment by 3 I put some junk on the right of the first one to show where it's going asm ldx level ; ballx ldy x11,x ; level x 11 look up ldx #$0A lda #>col0_dat sta temp4 lda #<col0_dat sta temp3 loop_col0 lda (temp3),y sta var0,x iny inx lda (temp3),y sta var0,x iny inx inx inx cpx #$26 bne loop_col0 end return otherbank data x11 0, 14, 28, 42, 56, 70 end data col0_dat %01111110, %00000000 %01000010, %00000000 %01110110, %11100001 %01101110, %10000001 %01000010, %10000001 %01111110, %11100001 %00000000, %00000000 %00100100, %00000000 %01100110, %00000000 %00111100, %00000000 %00100100, %00000000 %00011000, %00000000 %01100110, %00000000 %00000000, %00000000 %00111100, %00000000 %01011010, %00000000 %01111110, %00000000 %01011010, %00000000 %01100110, %00000000 %00111100, %00000000 %00000000, %00000000 %01000010, %00000000 %01111110, %00000000 %01001010, %00000000 %01111110, %00000000 %01010010, %00000000 %01111110, %00000000 %00000000, %00000000 %01000010, %00000000 %00110010, %00000000 %01011010, %00000000 %01011010, %00000000 %01001100, %00000000 %01000010, %00000000 %00000000, %00000000 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %00000000, %00000000 end

not sure what you mean by overlay you could just swap the pixel visited flags with the play field and/or flicker them

well there's the aux1..aux6 variables which are part of the stack you can probably use (some of) them if you don't go to deep on the stack (I think the score uses some of the aux variables) there's var44..var47 don't know but they may be available if you're only using one sprite there maybe some associated space there you could use my point was, doesn't seem like you would need that much

hmm you need a byte for game state you use 2 bytes for the audio you need 2 bytes for cursor position you need a byte for the level (depending on how many levels, could be part of game state?) (did I miss anything?) that would leave you 20 bytes (and there might be a few others around, stack space or something) assuming you keep 11 rows with a free row and column for 16 X 9 pixels you'd need 18 bytes for pixel visited flags it looks like the cursor moves in pf pixels I think I'd keep the movement/position in pf pixels and translate to sprite coordinates just for display if the puzzle matrix was 16 x 9 and you have free space bordering you need 18 x 11 for position or 5 and 4 bits so you'd have 3 and 4 bits you could use for eg game state you could put the puzzle matrix in the middle of the screen so you'd be dealing with whole bytes

worse than that I think is it's harder to read and keep track of

OK one more y is now the page and temp2 the level index that saves a couple of bytes and a couple cycles in the loop back to incrementing x branches into the loop to avoid an unneeded increment of the pointers load_new_level3 const number_of_levels = 4 ; initialize the playfield asm ldx #$2B loop_pf lda pf_dat,x ; col0 will be over written but it's probably not worth trying to avoid sta var0,x dex bpl loop_pf ; initialize pointers ldy #<col_dat lda level sta temp1 lda #>col_dat sta temp2 ldx #var8 bne enter_col0_loop loop_col ; increment the data pointer tya clc adc #number_of_levels tay bcc increment_playfield_pointer inc temp2 increment_playfield_pointer inx inx inx inx enter_col0_loop ; move the column 0 data lda (temp1),y sta $00,x cpx #var28 bne loop_col end return otherbank data pf_dat %11111111, %11111111, %11111111, %11111111 %00000000, %00000001, %00000000, %00000000 %00000000, %00001001, %01000101, %01110100 %00000000, %00001101, %01000101, %00010101 %00000000, %00001001, %01000101, %00010110 %00000000, %11001001, %01000101, %01110100 %00000000, %00001001, %01000101, %00010100 %00000000, %00011101, %01110101, %01110100 %00000000, %00000001, %00000000, %00000000 %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111 end data col_dat %01111110, %00100100, %00111100, %01000010 %01000010, %01100110, %01011010, %01111110 %01110110, %00111100, %01111110, %01001010 %01101110, %00100100, %01011010, %01111110 %01000010, %00011000, %01100110, %01010010 %01111110, %01100110, %00111100, %01111110 end

you could substitute your times 11 (44) code for the table I think I figured break even was about 8 levels incidentally I think you weren't initializing y in your original code here the [byte] column 0 playfield data is transposed so essentially there's a table for each row of the playfield and the data is selected by the level and you loop through the tables so now you can have 256 levels or whatever you can fit into the bank (which ever is less the times 11 and indexing is built into the pf_ptr_dat table and x is just a pointer it compiles but I didn't go beyond the first level load_new_level3 const number_of_levels = 3 asm ldx #$2B loop_pf lda pf_dat,x ; col0 will be over written but it's probably not worth trying to avoid sta var0,x dex bpl loop_pf lda #<col_dat sta temp1 lda #>col_dat sta temp2 lda #$00 sta temp3 loop_col ; get the playfield pointer ldy temp3 ldx pf_ptr_dat,y ; get the level pointer and move the column 0 data ldy ballx lda (temp1),y sta $00,x ; increment the data pointer lda temp1 clc adc #number_of_levels sta temp1 bcc *+4 inc temp2 ; increment the playfield pointer pointer inc temp3 cpx #var40 bne loop_col end return otherbank data pf_ptr_dat var0, var4, var8, var12, var16, var20, var24, var28, var32, var36, var40 end data pf_dat %00000000, %11111111, %11111111, %11111111 %00000000, %00000001, %00000000, %00000000 %00000000, %00001001, %01000101, %01110100 %00000000, %00001101, %01000101, %00010101 %00000000, %00001001, %01000101, %00010110 %00000000, %11001001, %01000101, %01110100 %00000000, %00001001, %01000101, %00010100 %00000000, %00011101, %01110101, %01110100 %00000000, %00000001, %00000000, %00000000 %00000000, %11111111, %11111111, %11111111 %00000000, %11111111, %11111111, %11111111 end data col_dat %11111111, %11111111, %11111111 %00000000, %00000000, %00000000 %01111110, %00100100, %00111100 %01000010, %01100110, %01011010 %01110110, %00111100, %01111110 %01101110, %00100100, %01011010 %01000010, %00011000, %01100110 %01111110, %01100110, %00111100 %00000000, %00000000, %00000000 %11111111, %11111111, %11111111 %11111111, %11111111, %11111111 end

in bB they're temp1 and temp2 I'd probably give them aliases ptrlo, ptrhi

must be something else going on the playfield color changed, the score is corrupted, the movement is messed up edit fixed some of that score is still corrupted, but I suppose you're using custom characters

heck! darn! (other obscenities as required) there were some goofs I fixed them, but apparently I didn't save them hopefully fixed now

something like this maybe? (I didn't include the tables) how many levels? this needs an extra byte per for the x 11 table and assumes col0 data is all in one page so 256/11 = 23 levels max ldx #$2B loop_pf lda pf_dat,x ; col0 will be over written but it's probably not worth trying to avoid sta var0,x dex bbl loop_pf ldx level ; ballx ldy x11,x ; level x 11 look up ldx #$00 lda #>col0_dat sta temp2 lda #<col0_dat sta temp1 loop_col0 lda (temp1),y sta var0,x iny inx inx inx inx cpx #$2C bne loop_col0 edit: the ending value for x is 44 (not var44, duh )

it's just a 16 bit LSFR dim sc0 = score dim sc1 = score + 1 dim sc2 = score + 2 dim rndbBlo = rand16 dim rndbBhi = rand dim rand16 = z dim right_edge_flag = r dim left_edge_flag = l scorecolor = $33 COLUBK = 0 COLUPF = 68 var40 = $55 : var41 = $AA draw if joy0right then right_edge_flag = 0 else right_edge_flag = 1 if joy0left then left_edge_flag = 0 else left_edge_flag = 1 drawscreen if joy0right && right_edge_flag then temp1 = rand : goto display if joy0left && left_edge_flag then temp1 = unrand() : goto display goto draw display var36 = rndbBhi : var37 = rndbBlo 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 goto draw function unrand() asm lda rndbBlo lsr lda rndbBhi rol bcc skip_eor16 eor #$68 skip_eor16 sta rndbBhi ror rndbBlo eor rndbBlo rts end joy0right rand forward joy0left unrand() backwards the screen is the LFSR (the bottom row is just to show where the bits are) the score is the return value (I didn't actually do an exhaustive test, but it looks like it works ) unrand16.bas unrand16.bas.bin

search the forums this stuff comes up fairly often and there's been lots of good stuff posted about it basically a television (at least in the before times) draws the screen periodically (frames) including things that have to happen periodically during the frame (lines) the processor provides the information for the picture in real time (more or less) only parts of those periods are visible the visible part takes most of the period there's a little time left over after the visible part before the next frame must start that's when your program runs you run some program and then tell it to wait for the next frame (with a drawscreen) if it takes too much time (ie too many lines, they're periodoic) it'll miss the next frame in order to know how much time you're using your best bet is probably to look at the assembly that bB produces and figure it out from that there's probably debugging stuff that would help I don't know if Stella gives you clock level timing but I can't think of any reason why it couldn't so it probably does

temp5 = (rand&15)+(rand&2) will produce a number 0..15 or 17 temp6 = (rand&3)+(rand&3)+4 will produce a number 4..10

you don't show what counter is presummably its an 8.8 variable if counter is less than 40 then temp2 will be 251 or greater 39/8 = 4 4 - 5 = -1 = 255 a data statement can be anywhere in the same bank bB normally inserts a jump (like a goto) around each data statement if you use the noinlinedata optimization it will omit the jumps and you have to put the data statement out of the code path (eg after a goto or a return)

speed wise this is (almost) the best I came up with (the bank switch code is in one spot which I then goto it adds 3 cycles but saves a bunch of code) this is somewhat faster than the tables maybe 5..6 if statments, half a scan line or so (on average, around 40 cycles) I tried to make the intervals even y doesn't get set. looks like it gets set to 0 in bank three anyway spreading the if statements out keeps the branches short enough that the target labels are in range so you don't have to use goto's z = rand if z > 127 then gt_127 if z > 85 then set_3 if z > 42 then set_2 set_1 g = 21 : x = 17 : w = 6 : k = 14 : rem flame, shield, lyre, key room var5 = 6 : rem gorgon room var3 = 1 : var1 = 5 : rem troll room var8 = 4 : var0 = 15 : rem snake room var6 = 16 : var7 = 12 : t = 7 : rem hero, seer, theif room goto go_bnk3 set_2 g = 21 : x = 23 : w = 14 : k = 7 : rem flame, shield, lyre, key room var5 = 6 : rem gorgon room var3 = 14 : var1 = 4 : rem troll room var8 = 5 : var0 = 7 : rem snake room var6 = 7 : var7 = 12 : t = 5 : rem hero, seer, theif room goto go_bnk3 gt_127 if z < 171 then set_4 if z < 213 then set_5 go_bnk3 goto _start bank3 set_3 g = 21 : x = 8 : w = 7 : k = 14 : rem flame, shield, lyre, key room var5 = 7 : rem gorgon room var3 = 15 : var1 = 6 : rem troll room var8 = 23 : var0 = 4 : rem snake room var6 = 16 : var7 = 6 : t = 5 : rem hero, seer, theif room goto go_bnk3 set_4 g = 12 : x = 21 : w = 14 : k = 7 : rem flame, shield, lyre, key room var5 = 16 : rem gorgon room var3 = 2 : var1 = 5 : rem troll room var8 = 4 : var0 = 7 : rem snake room var6 = 9 : var7 = 15 : t = 17 : rem hero, seer, theif room goto go_bnk3 set_5 g = 21 : x = 7 : w = 11 : k = 16 : rem flame, shield, lyre, key room var5 = 9 : rem gorgon room var3 = 23 : var1 = 12 : rem troll room var8 = 5 : var0 = 15 : rem snake room var6 = 7 : var7 = 14 : t = 4 : rem hero, seer, theif room goto go_bnk3

it wont work but I like your thinking but I also don't think look up tables will be faster than only a few if statements and is 1 & 1 = 1 0 & 1 = 0 1 & 0 = 0 0 & 0 = 0 5 is %00000101 bit wise & is like so (corresponding bits are ANDed) %00000101 & %11111111 = %00000101 where there's a 0 in either, the result will have a 0 so rand & 5 can produce only 4 possibilities %00000000, %00000001, %00000100, %00000101 I think this will give you 0..5 temp1 = rand/2 : y = (temp1/2 + temp1)/32 look up tables would have a more consistent timing and probably use less code in the given example there may not be enough if statements to make it worth while but it looks like there may be several other places in the code where it would here's some table code (the data statements would have ot be moved out of the way) a table look up uses the x register as an index, since x doesn't change here it doesn't need to keep being loaded so the macro loads the variable without reloading the x register with the value it already contains set optimization noinlinedata dim ptr = temp1 def mov_in = callmacro mvim macro mvim asm lda {2},x sta {1} end end ptr = rand/2 if ptr > 106 then skip_rand_5 ptr = (ptr/2 + ptr)/32 g = g_dat[ptr] mov_in k k_dat mov_in t t_dat mov_in w w_dat mov_in x x_dat mov_in var3 v3_dat mov_in var5 v5_dat mov_in var6 v6_dat mov_in var7 v7_dat mov_in var8 v8_dat data g_dat 21, 21, 21, 12, 21 end data k_dat 14, 7, 14, 7, 16 end data t_dat 7, 5, 5, 17, 4 end data w_dat 6, 14, 7, 14, 11 end data x_dat 17, 23, 8, 21, 7 end data v3_dat 1, 14, 15, 2, 23 end data v5_dat 6, 6, 7, 16, 9 end data v6_dat 16, 7, 16, 9, 7 end data v7_dat 12, 12, 6, 15, 14 end data v8_dat 4, 5, 23, 4, 5 end on gosub and on goto also use table lookups

there's a gap 100..109 where y doesn't get set

you're indexing your table with the bank number(?) in this case a macro is sort of like an inlined function

this works, but it's getting messy the to_bank macro just loads the target address to the stack you then have to goto the bank switch code at the beginning of the bank the location of the bank switch code has to be the same in all banks and the beginning of the bank seemed simplest since you have to jump around it in the first bank there's padding in the rest (in place of the jump/goto) set romsize 16k set optimization inlinerand set optimization noinlinedata def to_bank = callmacro bsm def go_to = callmacro gtom macro bsm asm lda #>({2}-1) pha lda #<({2}-1) pha ldx {1} end end macro gtom asm jmp {1} end end def bswitch = callmacro bswm macro bswm asm nop nop nop lda bankswitch_hotspot-1,x rts end end goto skip_BS_code bs1 asm lda bankswitch_hotspot-1,x rts end skip_BS_code gosub init to_bank 2 dloop goto bs1 init q = $55 COLUBK = q COLUPF = $33 return thisbank bank 2 bs2 bswitch data dloop end 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 go_to dloop bank 3 bank 4

if you're just trying to compute your target you can set something up with on gosub and on goto put gotos for each bank (or each possible target bank) in each bank tha you might be coming from and a dispatch on goto for each possible target in the bank in other words on gosub to a goto bank (in the current bank) that goes to an on goto in the target bank that selects the routine you want in that bank