Jump to content

bogax

Members
  • Content Count

    902
  • Joined

  • Last visited

Community Reputation

240 Excellent

1 Follower

About bogax

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male

Recent Profile Visitors

11,622 profile views
  1. bogax

    bB wish list

    A version of on goto that uses a jmp indirect and doesn't use the stack
  2. 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)
  3. 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)
  4. 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
  5. 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
  6. 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)
  7. 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
  8. 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)
  9. 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
  10. 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]
  11. 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
  12. 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.
  13. 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
  14. 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
  15. This does something like what you want I think.
×
×
  • Create New...