Jump to content

bogax

Members
  • Content Count

    911
  • Joined

  • Last visited

Everything posted by bogax

  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)
  16. The standard kernel keeps the playfield data in RAM and there isn't much of that. Each row in the playfield need 4 bytes of RAM You can jimmy the standard kernel to display more rows but you'll give up 4 variables for each extra row I don't know what the actual limit would be but if nothing else you'd be limited by the amount of RAM you could make available for the playfield
  17. bogax

    bB wish list

    Yes and no I suppose my ideal would be an assembler with syntax similar to bB where appropriate. Something that would facilitate the abstractions with out having them get in the way. Something slightly "higher level" than the usual assembler macros. And speaking of cycle counting, wouldn't it be nice if the language could report byte count or tote up cycles for you (but that's not something I'd expect to see in bB. on the other hand it might be worth while if the purpose of bB is to ease you into assembly)
  18. bogax

    bB wish list

    Sure, some of it Thats what I mean a lot of this is not hard to do in bB but it could be more convenient. It does get kind of messy some times. Some of it would probably better be integrated into bB If I just want to stuff some sound registers from tables indexed with a common index that's not too complicated If I want to modify player x and y positions where the player is specified by an index it might be doable but cost as much as it saved. Some of it might just be messy I'm not sure how you'd introduce an "if CARRY" with out either recreating some of bB to get the bB syntax or introducing a different syntax for your if statments That is to say I think you'd end up replacing some of bB with your preprocessor rather than just having a more convenient way to express some of your bB code Having said that I don't expect RevEng to drop what he's doing and modify bB to my specitications (you know, "your greatest command is my slightest wish") The most I might hope for is somthing like RevEng saying to him self 'suppressing the loading of x is would be useful without messing things up too much and it would only take another line of code, so maybe next time' If I knew more about how bB works I might try it myself Except peeing in other peoples soup isn't very polite. I do like the idea of some sort of macro prepocessor You wouldn't risk messing up bB but it would add another layer of kruft And I'm not sure you wouldn't just end up recreating bB (I haven't thought about it much, certainly that wouldn't be the case for a lot of it) How would you integrate the preprocessor in to the bB syntax? eg in comments? or a block like PREPROCESSOR ... END
  19. bogax

    bB wish list

    f{idx} = 1 ; idx must be a number 0..7, it can't be an expression or variable, it can't even be a named constant if f{idx} then ... Tables some thing like this ; v0t name of volume table ; c0t name of control table ; f0t name of frequency table data v0t c0t f0t v0, c0, f0 ; sets of values defining a note/sound the (values would presummably v1, c1, f1 ; be numbers and the set of values would be like 9, 12, 23 etc) v2, c2, f2 etc end but they'd go into seperate tables and you access them as if you'd put all the vx's in a table named v0t like wise the c's and f's so v0t[0] specifys v0, f0t[2] specifys f2 it would be as if you'd defined tables like this data v0t v0, v1, v2 end data c0t c0, c1, c2 end data f0t f0, f1, f2 end and your code would be something like (using the above suggested syntax, I'd normally do it in assembly and macros) note_ptr = note_ptr + 1 LDX note_ptr AUDV0 = v0t[XREG] AUDC0 = c0t[XREG] AUDF0 = f0t[XREG]
  20. bogax

    bB wish list

    There are things I wish you could do (more directly) in bB And there are common idioms that I think it would be useful to have built in Things that are not hard to do now but could be more convenient Karl G suggested in another thread some facility for multidefinition sprites for animations and such Ranged random numbers is another that comes up frequently Computed bit indexes Maybe transposed tables so you could specify values in sets for eg the sound registers and have them go into seperate tables Perhaps some built in division-by-a-constant routines similar to mutiplication by a constant My wish list is more nuts and bolts I'd like more direct access to the CPU registers and flags It would be nice if the registers were more fully integrated in to the syntax But even a few assembly instructions would help ACC = [expression] do the normal thing but suppress the assignment just leave the result in the accumulator var = mem[XREG] do the normal thing but suppress the loading of x TAX, TXA, LDX, STX so you could do something like ACC = [expression] : TAX : Px = tablex[XREG] : Py = tabley[XREG] without generating a lot of extranious load and store instructions (of course XREG = [expression] would be nicer) Some dedicated if constructs for testing flags would be nice if CARRY then ... or if !CARRY then ... no predicate expression, just test the carry flag (likewise for the z, n, v flags) I generally like the way macros work, although I like to hide the callmacro key word with a def statement But using macros gets messy when trying to let the assembler know what it needs to know about what bB knows Perhaps I need a preprocessor ... I'd be curious to see other's wish lists
  21. heh heh I think they ought to just bite the bullet and learn enough about what's going on under the hood to know what they're doing Its not THAT complicated. I think it would be useful to have some lowest-common-denominator way of choosing among multiple sprite definitions for animations and such built in to bB Something more stream-lined than the usual clumsy, wasteful string of if-thens Given the variety of ways it might be done and the possible tradeoffs it might be better to have a utility that generated bB or assembly and could be more general (in addition to whatever got included in bB) Besides, if bB is going to be augmented I'd rather see the effort go in to other things.
  22. hmm You shouldn't need to align the table as a whole. Freshbrood didn't post his code so it's hard to know what's going on there. As far as aligning the table goes, what's wrong with the align directive you were using? bB sometimes includes some assembly to generate the correct padding. (15 is the length of the table -1) 2511 f730 - if (<*) > (<(*+15)) 2512 f730 - repeat ($100-<*) 2513 f730 - .byte 0 2514 f730 - repend 2515 f730 endif
  23. correct and as needed so eg in the example I pointed to the height never changes so it's set once A slight elucidation of Karl G's point, the table can span a page boundary but an individual sprite definition should not cross a page boundary If all the definitions are in a single page then you'll only need to change the lo byte
  24. This does something like what you want I think.
  25. Functions are gosubs with additional overhead They always pass two parameters whether you specify them or not (but bB is likely to complain if you don't pass any parameters) You can sometimes sort of use them in place of an operand or an expression But I'd just use a subroutine. More predicable. Functions are so finicky they're almost (but not quite) useless Subroutines have overhead, but not much. A gosub uses 12 cycles and two bytes of the stack a = b + c uses 11 cycles Depending on the kernel, the stack might be only 6 bytes so you could only go 3 levels deep provided you don't use any expressions that use stack (and I think drawscreen goes 3 deep) And the way bB uses the stack in expressions is all kinds of goofy
×
×
  • Create New...