bogax

I don't think you need that first and eg .RORa lda SPRITE,x ; ? abcdefgh ror ; h ?abcdefg eor SPRITE,x ; h xxxxxxxx and RorAndTbl,y ; h 0000xxxx eor SPRITE,x ; h abcddefg ror ; g habcddef ror ; f ghabcdde ror ; e fghabcdd ror ; d efghabcd an alternative lda SPRITE,x ; ? abcdefgh and RorAndTbl,y ; ? abcd0000 clc adc SPRITE,x ; a bcd0efgh ror ; h abcd0efg ror ; g habcd0ef ror ; f ghabcd0e ror ; e fghabcd0 ror ; 0 efghabcd of course you have to invert the mask(s) and if you know the carry will be clear you could leave out the clc and possibly gain a couple cycles for rol lda SPRITE,x ; ? abcdefgh asl ; a bcdefgh0 adc #$80 ; b ?cdefgha rol ; ? cdefghab ie three cycles per bit if you do them in pairs but I think you'd need a seperate routine for an odd number of bits

It might be worth pointing out that there's a reason for using eg *4*4 instead of *16

Finally installed bB macro set_hi_nibble {1}=(({2}*4*4^{1})&$F0)^{1} end Compiles just as one would hope .L00 ; macro set_hi_nibble MAC set_hi_nibble .L01 ; {1} = ( ( {2} * 4 * 4 ^ {1} ) & $F0 ) ^ {1} ; complex statement detected LDA {2} asl asl asl asl EOR {1} AND #$F0 EOR {1} STA {1} ENDM

Oh, OK, I get it def is a simple substitution so that that expands to something like: callmacro set_lo_nibble a 5 The def statement supplies the first parameter and you supply the second where you invoke the def'd name.

I'm getting lost. Here's an excerpt of the code from: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#nybblemethis rem **************************************************************** rem * Reusable macros for nybble variables. rem * macro set_lo_nibble {1}={1}&$F0 {1}={1}|({2}&$0F) end macro set_hi_nibble asm lda {1} and #$0f sta {1} lda {2} asl asl asl asl ora {1} sta {1} end end rem **************************************************************** rem * One variable is split into two thanks to rem * macro and def. rem * def PEEK_Game_Level=a&$0F def POKE_Game_Level=callmacro set_lo_nibble a def PEEK_Hit_Points=a/16 def POKE_Hit_Points=callmacro set_hi_nibble a That looks to me like set_lo_nibble and set_hi_nibble both want two parameters and are both only being passed one, am I missing something? If you use exclusive or to swap in nibbles you'll only get the bit's you mask for, So I'd (re)write RevEng's code like this: macro set_hi_nibble asm lda {2} asl asl asl asl eor {1} and #$F0 eor {1} sta {1} end end It might even be possible to write something that swapped different nibbles depending on a parameter (I haven't tryed, didn't seem worth it) I haven't figured out when and where bBasic will choke on complex expressions. If bBasic fails to recognize powers of 2 greaer than 3, would something like this work (again using an xor swap) (1)=(2)*4*4^(1)&$F0^(1) (I don't know how many parentheses you'd have to stick in there to get the order of execution right or if that would make bBasic choke)

Not sure I understand maybe this will help A eor A = 0 A eor 0 = A so A eor B eor A = B so you've got two bytes (letters are nibbles) ab, cd lda ab ; the byte containg ab eor cd ; the byte containg cd and #$F0 ; the high nibble of the accumulator is a eor c the low nibble is 0 eor cd ; the high nibble is a eor c eor c = a the low nibble is 0 eor d ; that is, the accumulator is now ad

I don't understand them thar big words, but I am trying to add 10, then 15, then 20, then 25, then 30, then 35, and so on. Thanks. It's probably nothing The score goes up proportional to the square of the number of bonuses you get so it's going to go up fast. Potentially the first points you score could be microscopic compared to the last points you score. Since you limit it to 7 it's not going to get too far out. You know what you want and I don't so take this with a grain of salt, but I would have guessed that a smaller increment for "a" and a larger limit would work better. (And I'm not at all sure I know what's going on with game play so like I said a grain of salt ie I'm probably speaking out of turn, it's just my gut reaction to the numbers)

Oops, I think I misunderstood what you're doing here. This should be done *after* adding to a, correct? Correct but like I said it's only sure to work if there's no carry out from a digit, which can't happen if what you add <= 6 it should always result in a BCD compliant number but it may not be the right number if you add more than 6 to a digit.

I may be completely off here because I get 180 not 175 so maybe I don't understand what you're doing. Assuming "a" and "score" both start at 0 and both are BCD, 65 looks like 41 BCD so the last "a" you add to "score" will be 40 and by that time "score" will be 180 ie presummably the IF statement does't know the difference and just treats both as straight binary. btw you do know that accumulating a constant in "a" then accumulating "a" in "score" will make "score" go up quadratically (graph "score" and it will be parabolic)

I don't know what you're doing but making sure "a" is BCD compliant may not be enough. You may have to make "a" BCD. That is treat, it as BCD. If you never add more than 6 to "a" then it's relatively simple, mask off the digits individually and test if they're greater than 9 and if a digit is greater than 9 add 6 to it, starting with the ones digit. If you add more than 6 it starts getting messy. If you do add more than 6 there's the possibility of a carry out of the ones digit which you'd have to detect independent of what ever you add to the tens digit. Probably be easiest to treat the digits seperately, ie add the digits one at a time, add the ones digit then adjust, then add the tens digit and adjust. I'm not that familiar with batari Basic but it would be something like: if (a & $0F) > 9 then a = a + 6 if (a & $F0) > $90 then a = a + $60 Edit: That code is just to make "a" BCD compliant (it doesn't convert binary to BCD) Here's code to add "n" to "a" (I hope ) "n" doesn't (necessarily) need to be BCD (if "n" is a single hex digit 0-F it should work) Not sure if this is proper batari Basic temp = (a & $0F) + (n & $0F) : REM seperate ones digit and add them : REM result in temp so they can be : REM decimal adjusted seperately if temp > 9 then temp = temp + 6 : REM decimal adjust the ones digit a = (a & $F0) + temp + (n & $F0) : REM add it all together if a > $9F then a = a + $60 : REM decimal adjust the tens digit

here's a minimum space routine (untested) sec rol ByteToSwap LOOP ror asl ByteToSwap bne LOOP

enter with byte to reverse in a tables not shown code is untested tax and #$0F tay txa lsr lsr lsr lsr tax lda hi_tbl,y ora lo_tbl,x

You don't need to intialize the accumulator (you're shifting it all out any way)

Well, now that I think of it, shouldn't it be FASTER if you leave the constants in? [EDIT: Yes, it is.] I mucked it up some what. I have seen BASICs where it appeared that the end value expression was re interpreted each time through the loop, I couldn't remember if the CBM BASIC was one of them. However I'd expect to initialize the beginning and ending "constants" near the beginning of the program and then just use the loop as needed. As an aside on optimizing BASIC programs, it is (iirc) usually faster to use a dummy FOR-NEXT loop than a GOTO if possible. The FOR-NEXT remembers where it's supposed to go, the GOTO has to scan the line list. And there's lots of other stuff you can do. A little Googling should turn up more. Years ago I timed all that stuff on the VIC20 Some where I've got a compilation of times in "milli-jiffies" No idea where it's gotten to now though

I have no doubt you'll prefer the machine code version, but you should be able to improve the BASIC by taking the constant evaluations and the redundant math out of the loop. Try this: F=55296:L=56295:FOR I=F TO L:POKE I,N:NEXT I don't recall how muti statement lines compare speed wise to going to the next line, but I'd put it all on one line just in case Also I don't think you need to get the constant out of the initial asignment of I, but I did that just in case too

oops, that should be TXS CPY # PHP

Assuming you mean 7-25 including 7 and 25 in the range and assuming you don't mind it not being too random, (and assuming I'm understanding the batari Basic manual correctly) I think this will do it temp1=rand/2 temp2=temp1+temp1/2 temp1=temp1+temp2/8 temp1=temp1/8+7 or maybe you can lose some of the assignments temp1=rand/2 temp1=((temp1+(temp1+(temp1/2))/8)/8)+7 The order the math is done in (and hence the parenthesis) is important to preserve accuracy (like the difference between the 0-15 range and the multiples of 4). Again, I'm not very failiar with batari Basic. It's basically multiplying by 1/16 + 1/128 + 1/256 = .07421875 which is close to but less than 19/255 to get a range of 0-18 and then adding 7 The multiplication is done in such a way as to preserve as much accuracy as possible in the partial products without over flowing. eg rand/2 is the 1/16 part but multiplied by 8 which is reduced to 1/16 by the final division by 8 etc. any way good luck with it (I haven't actuall tryed it.. )

Sure and I would guess that the 0-15 result is more like what he wants than the multiples of 4. I was just pointing out that (at least as I understand it) there will be a difference.

I'm not very good at math, so I'll do that. I was thinking along the lines of having the number stay below 255 so it will work, coupled with the fact of what I already knew about bB and variables and doing random stuff with them (which isn't very much.) Thank you. I'm not very familiar with batari Basic, but as I understand it will just do 8 bits unless you tell it otherwise. The fractional bits will get truncated. So (rand/64)*4 will produce a multiple of 4, ie one of 12,8,4 or 0 rand/16 will produce a number 0 to 15 (inclusive)

PHP is three cycles Assuming you were willing to use self modifying code and reserve the X register to the pupose you could TSX CPY # PHP

. . if clearstyle = 6 then block = next_block6[z] That code above adds a 6th animation. and..this would be the data statement for it: data next_block6 0,1,2,3,4,9,14,19,24,23,22,21,20,15,10,5,6,7,8,13,18,17,16,11,12 end Adding those two lines of code above causes me to be -138 bytes, It sounds like you're saying that after adding the 5 data blocks and their correspnding "if clearstyle = then block = next_block6[z]" statements you have 152 bytes left. and that adding another block of 25 bytes and another if-then-assignment uses up that 152 bytes and wants another 138 bytes so that the if-then-assignment plus the 25 data bytes adds up to 152+138 = 290 bytes. I'd expect that the if-then statement might use maybe 8 (or so) bytes and an assignment and table look up maybe 10 bytes. so that adding a 6th block your way would cost maybe 60-70 bytes (or something like that), much less than 290 bytes (note that the way I was suggesting should only cost 25 + 2 bytes for each additional block) I would expect that the changes I suggested (without adding a 6th data block) would save you 50-60 bytes or something like that. But like I said I'm not familiar with batari Basic so maybe there's a lot more going on than I expect (or maybe I'm completely missunderstanding what you're saying) (if you do try my suggestion I'd be curious as to how it works out)

Since that looks like you're wrapping clearstyle at the number of blocks, then maybe you're incrementing clearstyle. If so, you could build the increment into a look up table So incrementing clearstyle becomes: clearstyle = cs_lut[clearstyle] data cs_lut 1,2,3,4,5,1 end and do away with the if-then wrapping altogther. Of course. you have to initialize clear style.

I'm not sure how to interpret that but it sounds like you're saying that an if-then-assignment statement plus 25 data bytes takes 152 + 138 bytes. that sounds like too much. Or maybe you mean it requires 138 bytes, but that still sounds like a lot. Maybe a lookup table for clearstyle would help. (I RTFM a little so maybe this is closer to what batari Basic wants) Something like: levelcomplete clearstyle = cs_wrap[clearstyle] temp1 = row_offset[clearstyle} temp2 = temp1 + 24 for z = temp1 to temp2 block = next_block1[z] blockcolor[block] = pink for y = 0 to 3 gosub my_drawscreen bank2 cursorcolor = brown next blockcolor[block] = blue next data cs_wrap 1,1,2,3,4,5,1 end data row_offset 0,0,25,50,75,100 end data next_block1 0,1,2,3,4,9,14,19,24,23,22,21,20,15,10,5,6,7,8,13,18,17,16,11,12 0,2,4,6,8,10,12,14,16,18,20,22,24,1,3,5,7,9,11,13,15,17,19,21,23 24,23,22,21,20,15,16,17,18,19,14,13,12,11,10,5,6,7,8,9,4,3,2,1,0 4,3,9,14,8,2,1,7,13,19,24,18,12,6,0,5,11,17,23,22,16,10,15,21,20 0,5,10,15,20,21,16,11,6,1,2,7,12,17,22,23,18,13,8,3,4,9,14,19,24 end

I'm not familiar with batari BASIC so I don't know how you'd have to do this or if it would save you any thing. Put all the data in a two dimensional array and make clearstyle the row address (or derive the row address from clearstyle) Something like this: levelcomplete if clearstyle = 125 then clearstyle = 0 for z = clearstyle to clearstyle + 24 block = next_block1[z] blockcolor[block] = pink for y = 0 to 3 gosub my_drawscreen bank2 cursorcolor = brown next blockcolor[block] = blue next data next_block1 0,1,2,3,4,9,14,19,24,23,22,21,20,15,10,5,6,7,8,13,18,17,16,11,12 0,2,4,6,8,10,12,14,16,18,20,22,24,1,3,5,7,9,11,13,15,17,19,21,23 24,23,22,21,20,15,16,17,18,19,14,13,12,11,10,5,6,7,8,9,4,3,2,1,0 4,3,9,14,8,2,1,7,13,19,24,18,12,6,0,5,11,17,23,22,16,10,15,21,20 0,5,10,15,20,21,16,11,6,1,2,7,12,17,22,23,18,13,8,3,4,9,14,19,24 end

In the case of using a single rand it's just a hard coded multiplication by .625 which scales 255 to 159.375, close to 160 Obviously you can't map 255 values to 160 values with out collisions. In this case (approximately) every second value comes up twice and the rest once for all 255 original values. If you divide the 0-160 range in to groups of 2 consecutive values then any group is equally likely (again, approximately). If it were me, for this application, I'd just leave it at that. Does it really matter if it comes out to position 5 twice in 255 and position 4 once in 255? (or that 160 is left out) I don't know how batari BASIC works. A more serious problem IMO is if the fractional parts of the partial products are truncated. To get a nicer distribution you realy need 16 bits both in the math and the random value. (but especially the math)