bogax

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)

http://users.telenet.be/kim1-6502/6502/hwman.html#AA

Not sure I understand this correctly. but how about BEQ SKIP EOR $80 SKIP EOR $80 looks like it would cost some cycles? but might save you some code. but maybe you can work that saved code into some saved cycles (fewer jumps or something)

Yes, in this case it makes no difference I was just pointing out that my loop doesn't work quite the same as yours My loop works backwards through the data from higher addresses to lower addresses and yours works forward from lower addresses to higher addresses It's also possible to work forward though the data and still use the flags as set by INY the code is just not quite as straight forward (as in easy to immediately understand) I just thought it was more clear to do it the way I did Assuming you are still talking about seperating the digits, the code you were already given shoul work just fine (as far as I can see, if it didn't work, you must have done something wrong) The BCD byte is still just collection of bits the ADC/SBC instructions just treat them differently AND and LSR don't treat them diferently If you clear the decimal mode they'll be treated as straight binary by ADC/SBC

That's a bit of a misstatement. Decimal mode doesn't ignore A-F it fixes them provided you're using BCD. but if (for example) you ADC immediate a non BCD number and it may get it wrong (or it may not, which can be useful for binary to BCD conversion) Instructions other than ADC/SBC can result in non BCD values For future reference, instructions that set the value of A, X or Y and read-modify-write instructions (INC/DEC memory) all set the Z and N flags So, though there's nothing wrong with your code, it might be more usuall to write it something like this: LDY #$03 LDA #$00 SED CLC JSR SUM SUM ADC DATA-1,Y DEY ; sets the Z flag BNE SUM RTS note it adds the numbers in reverse order now

Just for the hell of it, here's a couple that do 256 byte tables. Not as neat, I couldn't think of an elegant way to use y for the counter. They're basically the same, one using selfmodifying code. ldx #$3F lda #$00 tay sta cntr_lo sta cntr_hi sta acc_lo clc bcc ENTER_LOOP LOOP lda cntr_lo adc #$10 sta cntr_lo lda cntr_hi adc #$00 sta cntr_hi lda acc_lo adc cntr_lo sta acc_lo lda sin+191,y adc cntr_hi ENTER_LOOP sta sin+192,y sta sin+128,x eor #$FF sta sin+64,y sta sin,x iny dex bpl LOOP ldx #$3F lda #$00 tay clc bcc ENTER_LOOP LOOP lda #$00 ;cntr_lo adc #$10 sta LOOP+1 ;sta cntr_lo bcc SKIP inc CNTR_HI+1 SKIP lda #$00 ;acc_lo adc LOOP+1 ;add cntr_lo sta SKIP+1 ;sta acc_lo lda sin+191,y CNTR_HI adc #$00 ;cntr_hi ENTER_LOOP sta sin+192,y sta sin+128,x eor #$FF sta sin+64,y sta sin,x iny dex bpl LOOP

As in 16 bits total with 8 integral and 8 fractional bits ? Not sure there's any point, a parabola is just not that close to a sine. It only gives you something like 4 bits of accuracy in the worst case I think the fractional part would be nonsense except for just a few table entries I did 256 bytes per quadrant because it looked to me like that was what the Z80 code was doing and because it fit neatly with using the y register as the counter. What exactly do you want to end up with? Four quadrants in 256 entries in 8.8 format? I might also mention that the code I posted does not result in 2's complement althought that would be easy enough to do.

No one else has responded so I'll take a whack. I can't read that Z80 gibberish so I'm not really sure what it's doing You can generate squares by accumulating a constantly varying difference. That is, the difference between consecutive squares goes up linearly. So to create a parabola you increment a counter and accumulate the the count as you go. This code is just off the top of my head and not really tested so take it with a grain of salt. y is used for the counter (and table pointer) x is used as a table pointer to mirror eor #$FF flips it around the horizontal axis sin0 is the first quadrant, sin1 the second etc The count is accumulated with the low byte in lo and the high byte in a and/or the table ldx #$FF lda #$00 sta lo tay clc bcc ENTER_LOOP LOOP tya adc lo sta lo lda #$00 ADC sin3-1,y ENTER_LOOP sta sin3,y sta sin2,x eor #$FF sta sin1,y sta sin0,x dex iny bne LOOP (Edited to make it look a lot more like a sine and a lot less like an inverted cosine )

I'm kinda curious what other constraints you have and how much accuracy you need My approach would be similar to your suggestion (or groovybee's) but I think the thing to do (if you can) would to generate 100/t when t is determined and then accumulate that as secrets are found. I think you can fit enough accuracy into a byte with scaling but it would be time consuming (but probably not quite so bad as a full blown division) On the other hand if you've got enough time when you generate t and if you already have or could use a GP division why not use that? Also you might accumulate to 200% then divide by 2 and round for accuracy The scaling would look something like this (untested): ldy t sty temp lda #$00 sta percent_of_one_secret_lo lda percent_table,y bne ENTER_LOOP LOOP lsr ror percent_of_one_secret_lo ENTER_LOOP lsr temp bne LOOP sta percent_of_one_secret_hi I think you could use a small table and interpolate, but you'd end up spending 50 cycles or something and only save a few bytes. Then when you find a secret you add percent_of_one_secret to what ever the current percentage is (I think groovybee's get's it wrong by a couple of percent in some cases but I'm not sure I'm reading his code correctly)

Yes I just think it's a clever hack (OK, so it's not a killer hack..) I presume it was originally in C

Just joined these forums so sorry if I'm a little late to this party Here's a couple of my favorites First the counter eor something with its self you get 0 eor something with 0 you get its self lda counter inc counter eor counter and #$F0 eor counter sta counter Of course you can insert bits from one byte into another byte (not just from a changed version of itself) Used eg for setting pixels ========= Parity is just an xoring of bits A simple sum is just an xoring of bits 0+0=0 0+1=1 1+0=1 1+1=0 Disregarding the carry obviously Carry is a way of propagating bits across a byte (sort of) 000a +0111 =a??? We can combine the two to get parity and collect "bits" across a byte ;parity of A sta temp asl eor temp and #b10101010 adc #b01100110 and #b10001000 adc #b01111000 ;now the parity is in the sign bit ========= Already posted this to a different thread Rotate two bits left through the carry asl adc #$80 rol Do it twice to swap nibbles ============ Kernigans method for counting set bits in a byte This code lifted directly from dclxvi in the 6502.org programming forum http://forum.6502.org/viewtopic.php?p=6993...highlight=#6993 TAX BEQ L2 LDX #0 SEC L1 INX STA SCRATCH SBC #1 AND SCRATCH BNE L1 TXA L2 RTS

OK, back to divide by seven Again, untested (yes, I should set up to do that) sta temp lsr lsr lsr adc temp ror lsr cmp #$3F adc #$00 lsr

ACK! Yes, right, those were supposed to be ror's

I edited that third routine. It will still fail at 228 and there's no good way to fix that with it rotating left instead of right (that I can think of at least) Oh well, it was only ment to be an illustration, I guess that's as good an illustration as any I think with division into eight bits the simple straight forward way is going to be the best we can do here's a division by 10 similar to your division by 15 UNTESTED! sta temp lsr sec adc temp sta temp lsr lsr lsr lsr adc temp lsr lsr lsr lsr I expect, if you care to test it, you'll get around to that before I do hmm wonder it something similar can be done for division by 7

My bad I should have said the code was untested and just for illustration I was trying to point out that most of these routines (obviously not the LUTs) are multiplication by reciprocals and that the reciprocals are repeating decimals (binimals? ) and the fact that they're repeating could probably be used to advantage. The first routine is meant to be essentially the divide by 7 routine previously posted by djmips except that I have it with the dividend starting out in A instead of in memory (which I also failed to mention). I figured it was so simple and straight forward it would be good for illustration Sounds like you used an lsr where you should have an ror? The second and third routines will fail for values over 227. I believe that could be fixed by moving the last sta and adc down one shift so you get the carry into A before you save it to temp like so: sta temp lsr lsr lsr adc temp ror sta temp lsr lsr lsr lsr lsr lsr adc temp ror lsr hmm dividing 6 by 7 should be like this sta temp 00000110. 00000110 lsr 00000011.0 lsr 00000001.1 lsr 00000000.1 adc temp 00000111.0 sta temp 00000111.0 00000111 ror 00000011.1 lsr 00000001.1 lsr 00000000.1 lsr 00000000.0 lsr 00000000.0 lsr 00000000.0 adc temp 00000111.0 ror 00000011.1 lsr 00000001.1 lsr 00000000.1 For the third routine I'll have to look at it again, I might well have screwed something up

Sure it's basically just reciprocal multiplication divide by 7 1/7 = .001001001001001... sta temp 1. lsr .1 lsr .01 lsr .001 adc temp 1.001 leave the carry alone to round ror .1001 lsr .01001 lsr .001001 adc temp 1.001001 ror .1001001 lsr .01001001 lsr .001001001 what I find intriguing is that, since they're all repeating decimals, you can (sort of) accumulate accuracy sta temp 1. lsr .1 lsr .01 lsr .001 adc temp 1.001 sta temp 1.001 ror .1001 lsr .01001 lsr .001001 lsr .0001001 < I've skipped an addition here lsr .00001001 lsr .000001001 adc temp 1.001001001 ror .1001001001 lsr .01001001001 lsr .001001001001 obviously doesn't help any in the case of dividing an 8 bit number by 7 but I've gotten to the point where it's less work to rol sta temp xxxxxxxx 1. lsr xxxxxxxx .1 lsr 0xxxxxxx .01 lsr 00xxxxxx .001 adc temp xxxxxxxx 1.001 sta temp xxxxxxxx 1.001 rol jjjjjjjx .00000001001 I've (in effect) jumped a byte to the right rol jjjjjjxx .0000001001 the j's are junk that would have been rol jjjjjxxx .000001001 shifted out now I have to mask them off and #$F8 00000xxx .000001001 still slightly faster adc temp xxxxxxxx 1.001001001 ror xxxxxxxx .1001001001 lsr 0xxxxxxx .01001001001 lsr 00xxxxxx .001001001001 OK, that doesn't help much either but it might if you were dividing more than 8 bits by a constant and in the cases where the repeating part is some integral fraction of a byte as is the case for eg division by 10 or 15 I could acummulate a full bytes worth and not have do any actual shifting at all But I don't know if it's likely to be useful for any case of an 8 bit dividend. (or usefull at all for that matter, but I'm thinking 16 bit binary to decimal) For example Omegamatrix managed to do a pretty good job on division by 15 with just some rounding. Edit:changed some lsr's to the rol's they should have been (second and third rol)