Jump to content

bogax

Members
  • Content Count

    911
  • Joined

  • Last visited

Community Reputation

247 Excellent

1 Follower

About bogax

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male

Recent Profile Visitors

11,997 profile views
  1. yes you could do that if eg you're going to access bits randomly if you're doing a byte at a time a table would be better
  2. the setbyte table is for a row of playfield pixels some bytes in the playfield are reversed but which ones depends on kernel/kernel options you'd have to limit x
  3. here's one way setbyte is the kernel table for selecting bits (for eg setting playfield pixels) the exact form of setbyte depends on the kernel but you could do your own table if neccesary if setbyte[x] & b then a{6} = 1 else a{6} = 0
  4. you could do your table lookup a nibble at a time table lookup has the advantage of constant time (and is probably faster)
  5. no idea what you're doing.. shouldn't the SMPSN0: be after the lda? also do you know what the carry is at that point? (may not matter) edit oh hell I just realized what you're doing. never mind (I'll go back to sleep now)
  6. It occurs to me that you might as well build the BCD index conversion into the table(s) (sort of) using a bipartite table I think it would be about as fast and take less ROM something like temp1 = scr & $0F temp2 = scr / 16 binary = lo_tbl[temp1] + hi_tbl[temp2] data lo_tbl 0, 5, 3, 8, 10, 13, 15, 18, 20, 23 end data hi_tbl 0, 26, 51, 77, 102, 128, 154, 179, 205, 230 end
  7. index = score & $F0 : index = (index / 4 + index)/2 : index = (score & $0F) + index edit: the order and parenthesis are important or else bB will do goofy things with the stack
  8. not sure I'm following all this but the 0..99 score will be in BCD
  9. NUSIZ0 = NUSIZ0 & $0F Your mask is inverted. You're clearing the missile nybble and retaining the player nybble. You end up with the old player nybble ORed with the new player nybble
  10. bogax

    bB wish list

    A version of on goto that uses a jmp indirect and doesn't use the stack
  11. You don't need to be afraid of gosubs but you do need to use them sparingly because there isn't much stack. Your code is kind of convoluted and I didn't try very hard to follow it so I may misunderstand your intentions. It looks to me like you're using gosubs where you don't need them and probably don't want them. You're also doing way to much bank swithching in my opinion. (bank switching is expensive in both time and space)
  12. I think you've got 5 spots on the stack with the multisprite kernel on gosub uses two but one of them only while it executes on gosub pushes it's target on to the stack from a table then does a return so it "returns" to it's target (it also leaves a real return address on the stack) on goto does the same without first pushing a (real) return address, so on goto uses one level of stack it's possible with a microscopic amount of assembler (a single jmp indirect instruction) to do the on goto without using the stack but then you have to do the address table yourself (not hard)
  13. You have 12 copies (or so) of this code (probably the same for Up Down) on _Frame_Counter gosub __Frame_LR_00 __Frame_LR_01 __Frame_LR_02 __Frame_LR_01 : return just put one copy in one place and change it to an on goto then jump to that. eliminate the redundancy and one gosub less deep
  14. The $ indicates a hexadecimal number In decimal the digits are 0..9 in hexidecimal the digits are 0..15 except we don't use decimal numbers for 10..15 we use A..F So the hexidecimal digits are 0..F normally you'd get a carry from the lo digit to the hi digit at F in hexadecimal 1 + F = $10 which is 16 in decimal With bcd (binary coded decimal) the digits only go from 0..9 and the carry comes from any number over 9 So $20 is hexadecimal for (decimal) 32 (2 * 16) which is interpreted as 20 decimal in bcd (normally 20 decimal would be $14 in hexadecimal ie 1*16 + 4) The score is six bcd digits in three bytes except they are backwards in memory score[0] to score[2] from HIGHEST to lowest each bcd digit is a 4 bit nibble RT has some stuff about dealing with nibbles
  15. bogax

    bB wish list

    One thing I would really like to see in bB Is some way to control bB's emission of "#" in macro parameters RevEng "fixed" it for somebody and now bB sticks "#" all kinda places I don't want them (although to be fair, they don't seem to do any harm. DASM seems to ignore extraneous "#" and the fix does fix what it intended to I think)
×
×
  • Create New...