bogax

Macros are also a way to pass values to the assembler from bB.

How many parameters can be passed to a Macro?

WritePFChunk for current_row = 0 to 7 lo_pointer = current_row * 4 print_row = chunk_start + current_row for current_col = 0 to 31 current_bit = current_col & 7 current_byte = current_col / 8 + lo_pointer on maze_ref goto MazeData1 MazeData2 MazeData3 MazeData4 MazeData1 current_byte = Mazes1[current_byte] : goto Continue_WritePFChunk MazeData2 current_byte = Mazes2[current_byte] : goto Continue_WritePFChunk MazeData3 current_byte = Mazes3[current_byte] : goto Continue_WritePFChunk MazeData4 current_byte = Mazes4[current_byte] Continue_WritePFChunk if current_byte & setbits[current_bit] then pfpixel current_col print_row on next next Edit: removed the final goto (it's redundant)

How could you select amongst data statements with a parameter? Only thing I can think of is a case statement. (or IF statements)

Heck! Darn! Other obscenities as required! And since the binary array thread is talking about screen stuff and not bit variables they're backwards there too. How sure are you now .

Another thought. Looks like you could pull the print_row assignment out of the inner loop for current_row = 0 to 7 lo_pointer = current_row * 4 print_row = chunk_start + current_row for current_col = 0 to 31 current_byte = current_col / 8 + lo_pointer current_bit = current_col & 7 if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on next next

That might do it but then you need to intialize lo_pointer Your rows are going to be addressed as 0-7 I can try but you probably want someone who knows what they're doing ;P I'd imagine it something like this: dim current_row = a dim current_col = b dim current_byte = c dim current_bit = d dim print_row = e dim chunk_start = f chunk_start = 20 PROGRAMLOOP DF0FRACINC=128 DF1FRACINC=128 DF2FRACINC=128 DF3FRACINC=128 DF4FRACINC=255 DF6FRACINC=24 if joy0fire then z{0} = 1 if !joy0fire && z{0} then gosub WritePFChunk drawscreen goto PROGRAMLOOP WritePFChunk for current_row = 0 to 7 for current_col = 0 to 31 current_byte = current_col / 8 + lo_pointer[current_row] current_bit = current_col & 7 print_row = chunk_start + current_row if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on next next z{0} = 0 return thisbank bank 3 bank 4 bank 5 bank 6 data lo_pointer 0, 4, 8, 12, 16, 20, 24, 28 end data hellodata %00000010,%01011101,%00010001,%11000000 %00000010,%01011101,%00010001,%01000000 %00000010,%01010001,%00010001,%01000000 %00000011,%11011101,%00010001,%01000000 %00000011,%11011101,%00010001,%01000000 %00000010,%01010001,%00010001,%01000000 %00000010,%01011101,%00010001,%01000000 %00000010,%01011101,%11011101,%11000000 end data setbits %10000000, %01000000, %00100000, %00010000, %00001000, %00000100, %00000010, %00000001 end I used a look up table for lo_pointer because it only costs a couple bytes, doesn't use a variable and is faster edit: ack! wrong! it's significantly slower (forgot that moves it into the inner loop) so using a variable: dim current_row = a dim current_col = b dim current_byte = c dim current_bit = d dim lo_pointer = e dim print_row = f dim chunk_start = g chunk_start = 20 PROGRAMLOOP DF0FRACINC=128 DF1FRACINC=128 DF2FRACINC=128 DF3FRACINC=128 DF4FRACINC=255 DF6FRACINC=24 if joy0fire then z{0} = 1 if !joy0fire && z{0} then gosub WritePFChunk drawscreen goto PROGRAMLOOP WritePFChunk for current_row = 0 to 7 lo_pointer = current_row * 4 for current_col = 0 to 31 current_byte = current_col / 8 + lo_pointer current_bit = current_col & 7 print_row = chunk_start + current_row if hellodata[current_byte] & setbits[current_bit] then pfpixel current_col print_row on next next z{0} = 0 return thisbank bank 3 bank 4 bank 5 bank 6 data hellodata %00000010,%01011101,%00010001,%11000000 %00000010,%01011101,%00010001,%01000000 %00000010,%01010001,%00010001,%01000000 %00000011,%11011101,%00010001,%01000000 %00000011,%11011101,%00010001,%01000000 %00000010,%01010001,%00010001,%01000000 %00000010,%01011101,%00010001,%01000000 %00000010,%01011101,%11011101,%11000000 end data setbits %10000000, %01000000, %00100000, %00010000, %00001000, %00000100, %00000010, %00000001 end damn! more edits: should be current_byte = current_col / 8 + lo_pointer even more editing: fixed the setbits (see below)

I phrased that poorly Suppose you set lo_pointer = 15 (some arbitrary value) then call WritePFChunk then the first time you run the current_col loop current_row = 0 and lo_pointer = 15 at the end of the first pass through the current_row loop lo_pointer will get set to 0 ie 0 * 32 so your passes would go like this current row = 0, lo_pointer = 15 current row = 1, lo_pointer = 0 current row = 2, lo_pointer = 32 current row = 3, lo_pointer = 64 current row = 4, lo_pointer = 96 current row = 5, lo_pointer = 128 current row = 6, lo_pointer = 160 current row = 7, lo_pointer = 192 current row = 8, lo_pointer = 224 9 iterations of the current row loop the first one with what ever lo_pointer is when you call WritePFChunk

possibly I misunderstand your intent. On your first pass through the inner for loop current_col will be 0 and lo_pointer will be whatever you haven't set lo_pointer yet At the end of the first pass through the loop you'll set lo_pointer to current_col * 0 and lo_pointer will be 0 while current_col is 1 (second pass). etc also you'll make 9 passes through the loop (0-8 inclusive) If you multiply by a power of two that's 8 or less Bb will use shifts so * 8 * 4 compiles as shifts * 32 calls the mutiplication routine

Not sure I understand your intentions. If what you mean is you want to do something if the joy stick reads (for example) 14, 13 or 10 ie the same thing for a variety of values you could do something like this org $6000 ;Start of the code start lda #100 ;loads to address sta 1537 ;puts the value 1537 into address loop ldx 632 ;Read joystick STICK0 cpx #14 ;is it n? 14, s is 13, w is 11, nw is 10,sw is 9,e is 7,ne is 6,se is 5 beq dosomething cpx #13 beq dosomething cpx #10 bne loop ;if not - go and read it again dosomething lda 1537 ; reads 1537 - this memory is not used by the OS sta 710 ;color screen with it COLOR2 (color reg 2, playfield 2) cmp #0 ;compare value. is it zero? beq loop ;if it is, loop dec 1537 ;if not, decreases 1537 lda #$f ;resets joystick sta 632 ;read joystick STICK0 jmp loop ;starts over again run start ;begin program execute Of course you could have it do different things for different read values Looks to me like that's going to zip through the colors as long as you're reading one of your chosen values. (but maybe I just don't understand enough about how reading the joystick works) Looks like a pass through the loop only takes 40 or 50 machine cycles at most. You intialize 1537 to 100, but you don't reset it to 100 when it gets to 0 so presumably it goes from 0 to 255 Is that supposed to be jmp start instead of jmp loop? in the sequence: lda 1537 sta 710 cmp #0 beq loop the cmp#0 is redundant Any instruction that could change a register sets the N and Z flags (also the read-modify-write instructions like inc, dec, lsr, ror, asl, rol, a memory location) lda 1537 does cmp #0 implicitly and sta 710 doesn't change the Z flag. What the others said. Presummably, the shadow register contains a debounced value.

This part doesn't compile, claiming there are duplicate labels. So, do I need to dimension a new "cell"? I tried changing it to cellx, but that causes more problems. I can't explain that. All I can say is it worked for me. This was the result: .L08 ; cell = mapx / 8 LDA mapx lsr lsr lsr STA cell .L09 ; cell = mapy * 4 + mapy + cell ; complex statement detected LDA mapy asl asl CLC ADC mapy CLC ADC cell STA cell . ;

A little late replying here... (heh heh) (came across this while Googling something) Just for completeness, here's what I was talking about in Bb temp1=rand/2 temp1=(temp1/4/4+temp1)/4+temp1 which produces .L00 ; temp1 = rand / 2 jsr randomize lsr STA temp1 .L01 ; temp1 = ( temp1 / 4 / 4 + temp1 ) / 4 + temp1 ; complex statement detected LDA temp1 lsr lsr lsr lsr CLC ADC temp1 lsr lsr CLC ADC temp1 STA temp1 in asm jsr randomize sta temp1 lsr lsr lsr lsr lsr adc temp1 lsr lsr adc temp1 lsr sta temp1 Well, not quite what I was talking about. The Bb version mutiplies by .6328125 (1/2 + 1/8 + 1/128) and truncates the partial products The asm version multipies by .62890625 (1/2 + 1/8 + 1/256) and rounds the partial products

Things will be easiest if you can keep one dimension in powers of 2 Then you can use simple shifts and bitwise logical ops for composing the cell and bit addresses, there by avoiding expensive multiplys/divides Bb will use shifts for multiplying and dividing by low powers of two, much faster than full blown mutiplications and divisions (I think a low power of 2 means 8, 4, or 2) Near as I can tell, Bb wants a constant for bit ops so to use a variable you'll have to do it yourself If you have 256 bytes that's 2048 bits So say you have 128 (x coordinate) x 16 (y coordinate) x will be 16 (bytes) * 8 (bits) You can get the bit address (ie the bit you want in the selected cell) by simply masking for the lower 3 bits of x dim mapx = a dim mapy = b dim cell = c dim cellx = d rem x mod 8 cellx = mapx & 7 rem ORing instead of addition saves a clc so it's slightly rem faster and is possible since mapx / 8 is an integral rem power of 2 bytes per row (ie per y) rem mapy * 16 is done as mapy * 4 * 4 so that Bb will use rem shifts rather than invoking a mutilplication subroutine cell = mapy * 4 * 4 | mapx / 8 if map[cell] & setbits[cellx] then score = 1 else score = 0 rem use an adressable set of masks so you can point rem to them with a variable data setbits %10000000, %01000000, %00100000, %00010000 %00001000, %00000100, %00000010, %00000001 end data clearbits %01111111, %10111111, %11011111, %11101111 %11110111, %11111011, %11111101, %11111110 end data map %11111101, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 %10000001, %00000011, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000111, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00011000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000001, %00000010, %00000011, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00011100, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000000, %00000001 %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111, %11111111 end If you want your map to be something closer to square, say, 40 x 51 You could use a look up table for the mutiplication or hard code it ie write a dedicated mutiply routine (or just use the built in multiplication routine which would be slower). I think I'd go with a look up table (if there's room), it'd only cost an extra 40 bytes or so and be a lot faster. Here's hard coded for 40 ie rows of 5 bytes of 8 bits Each row is 5 bytes so you need to mutiply y by 5 (still uses the same map data, but I'm sure it doesn't make sense here) dim mapx = a dim mapy = b dim cell = c dim cellx = d rem x mod 8 cellx = mapx & 7 rem have to use addition this time rem 5 = 1 + 4 cell = mapy + mapy * 4 + mapx / 8 if map[cell] & setbits[cellx] then score = 1 else score = 0 rem use an adressable set of masks so you can point rem to them with a variable data setbits %10000000, %01000000, %00100000, %00010000 %00001000, %00000100, %00000010, %00000001 end data clearbits %01111111, %10111111, %11011111, %11101111 %11110111, %11111011, %11111101, %11111110 end data map %11111101, %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111, %11111111 %11111111, %10000001, %00000011, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000001, %10000000, %00000000, %00000111 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000001, %10000000, %00000000 %00000000, %00011000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000001, %10000000 %00000000, %00000000, %00000001, %00000010, %00000011 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000 %00011100, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000001, %10000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000001, %10000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000001, %10000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000001, %10000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000001 %10000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000001, %10000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000001, %10000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000001, %10000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000001, %10000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %00000000, %00000001 %11111111, %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111, %11111111 end edit: actually cell = mapy * 4 + mapy + mapx / 8 is faster because Bb doesn't stash mapy on the stack while it computes mapy * 4 edit some more: I suppose you all know this already. It's better to avoid the stack altogether cell = mapx / 8 cell = mapy * 4 + mapy + cell saves 2 bytes and 7 cycles yet more edit: fixed setbits and clearbits which were good for bit variables but not screen stuff

You could probably get by with fewer partial products in the reciprocal multiplication.

That's odd Are you sure you didn't divide by 64? ie /4/4/4 instead of /4/4/2 ? I reckon it thusly suppose rand returns 255 then: rand/2 = 127 a/2 = 63 + a = 190 /4 = 47 /4 = 11 /2 = 5 +1 = 6

a=rand/2 a=(a/2 + a)/4/4/2+1 produces .L00 ; a = rand / 2 jsr randomize lsr STA a .L01 ; a = ( a / 2 + a ) / 4 / 4 / 2 + 1 ; complex statement detected LDA a lsr CLC ADC a lsr lsr lsr lsr lsr CLC ADC #1 STA a . ; or in assembly a=rand asm lda a lsr adc a and #$C0 rol rol rol adc #$01 sta a end

Having thought about it only slightly, maybe the code could be simpler and perhaps shorter if the target of the JSR is one of the parameters. And if you resolve to never let the JSR and paramters straddle a page boundary you could simplify things by not having to calculate the return address It would cost another couple of zero page bytes for the subroutine target. ; parameter_pointer is a zero page location ; initialized to zero pla tay pla sta parameter_pointer+1 ; high byte of the return address doesn't ; change so just put it back pha iny lda parameter_pointer,y sta target iny lda parameter_pointer,y sta target+1 iny lda parameter_pointer,y sta parameter1 iny lda parameter_pointer,y sta parameter2 ; etc ; assuming no page crossings so just ; push the low byte of the return address ; back on the stack tya pha jmp (target)

oops yes I think you are correct. I thought it was writing a 0 if the source is 0. On a closer reading it looks like it doesn't write at all if the source is 0 But it looks like it can be done in one pass. By making the source the destination and using a collision detection mask of FF and an XOR and AND mask of FF and either arithmetic sum mode or OR mode the description of OR mode, mode 3: "The written out data dest’ is a result of a bitwise OR of source” and dest. source = ReadSource(); source' = source & blt_and_mask; source'' = source' ^ blt_xor_mask; if (source'' != 0) dest = ReadDest(); if (dest & blt_collision_mask) BLT_COLLISION_CODE = dest; dest' = dest | source''; WriteDest(dest');" So eg in OR mode if the source is 0 it will stay 0 If the source is not 0 then it will get ANDed with the AND mask ie FF (source') That will be XORed with the XOR mask ie FF producing the compliment (source") And that will be ORed with the source producing FF (dest') Then written to the destination ie written back if the destination is the same as the source.

Not sure I understand the problem (or the blitter) so maybe this will be whacked. The problem is to write 0 if the source byte is 0 and write FF if the source byte is non 0. The source just happens to be restricted to powers of 2. (including 0) So do an XOR pass with FF filled destination. to get either 0 or the compliment of the source. Then do an OR pass between the source and the (now compliment destination) to get either 0 or the source OR the compliment (ie FF) Am I missing something?

Similar thread http://www.atariage....-are-different/

if a/2 ^ a & 1 then goto __pause_game __pause_game .L00 ; if a / 2 ^ a & 1 then goto __pause_game ; complex condition detected ; complex statement detected LDA a lsr EOR a AND #1 BEQ .skipL00 .condpart0 jmp .__pause_game .skipL00 . ; .__pause_game ; __pause_game

Not sure I remember the conventions rightly, but assuming bit 0 is the least significant bit ... If you add a 1 to a bit you can, in effect, propagate it to a more significant position via carry If you add two bits together the sum is the XORing of the two You can do both at once in this case by adding 1 to a Then use & to isolate bit 1 to test it (ie a bitwise AND with 2) if (a + 1)& 2 then goto __pause_game __pause_game produces .L00 ; if ( a + 1 ) & 2 then goto __pause_game ; complex statement detected LDA a CLC ADC #1 AND #2 BEQ .skipL00 .condpart0 jmp .__pause_game .skipL00 . ; .__pause_game ; __pause_game That ought to be something like what you want

Not sure how to answer that. My gut reaction is to say there's no magic to it. But it is sort of magical or wonderous or at least fascintaing, maybe that's the key to interest. What it is is pretty mundane 7th grade algebra. you wouldn't have any trouble learning it. Boolean algebra has similar rules/properties

temp6 = (player0y-7)/4

This works (ie bB doesn't choke on it and it assembles) dim ballx_dir = a dim ballx_pos = b macro incv asm inc {1} end end macro decv asm dec {1} end end if ballx_dir & 32 then callmacro incv ballx_pos else callmacro decv ballx_pos used my own names, sorry if that's confusing