# bogax

Members

911

247 Excellent

## 1 Follower

• Rank
Dragonstomper

• Gender
Male

## Recent Profile Visitors

11,997 profile views

1. ## Selecting a bit?

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. ## Selecting a bit?

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. ## Selecting a bit?

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. ## Counting Bits

you could do your table lookup a nibble at a time table lookup has the advantage of constant time (and is probably faster)
5. ## Vertical bars appearing at the screen sides

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. ## Need help with 8.8 fractions

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. ## Need help with 8.8 fractions

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. ## Need help with 8.8 fractions

not sure I'm following all this but the 0..99 score will be in BCD
9. ## How do you change m and p separately in NUSIZ0?

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. ## bB wish list

A version of on goto that uses a jmp indirect and doesn't use the stack
11. ## Pac_Man Eat n Run

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. ## Pac_Man Eat n Run

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. ## Pac_Man Eat n Run

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. ## Score, variables and mathematics question

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. ## 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)
×
• Forums
• Clubs

• All Activity

• #### Subscriptions

×
• Create New...