bogax

Here the idea is the timer counts 1/10 second intervals whitch is 6 drawscreens a time slice is a count of 16 ie 1.6 second it sets the playfield color once per time slice the slices are counting 0..3 in bits 4 and 5 of timer if its slice 0 it sets the playfield color to the background color to blank the playfield if its not slice 0 it restores the playfield color so blank for 1.6 seconds playfield for 4.8 seconds after 4 cycles the timer rolls over and returns you could fiddle with the timing by changing the number of drawscreens per delay and/or number of counts per time slice untested levelend player0x=250: player0y=150 timer = 0 levelend2 timer = timer + 1 if !timer then a = a + 1: g = 0: h = 0: b = 0: return otherbank if timer & $0F then tenth_second_delay ; if timer mod 16 <> 0 ; if timer mod 16 is 0 change the playfield if !timer & $30 then COLUPF = background_color: goto tenth_second_delay ; if timer is the zeroeth multiple of 16 blank the playfield ; otherwise unblank COLUPF = playfield_color tenth_second_delay drawscreen drawscreen drawscreen drawscreen drawscreen drawscreen goto levelend2

You could blank the playfield by setting the playfield colors rather than redrawing the playfield You could slow things by using two drawscreens for each period

a variant of Karl G's for loop if (temp1 & 3) <> 1 then skip for temp1 = 21 to 129 step 12 if player0x = temp1 then gosub coldet2 goto skip next skip

The more usual way is to check for a player-playfield collision and then convert player coordinates to playfield coordinates and use pfpixel

I disagree (about fastest) you would do all 10 if statements for most numbers

if you gosub in the middle of a bunch of if statements you will return to the middle of the if statements and do a bunch of if statements you don't need to do your numbers are (n * 12) + 21 you can subtract 21 and test for a multiple of 12 that is in range any multiple of 12 will be a multiple of 4 you can test for a multiple of 4 by testing for bits 0 and 1 being 0 that will immediately eliminate 3/4 of possible numbers if you subtract 21 from a number 0..20 you get a result in the range (256 - 21) to 255 so you can eliminate numbers > 129 - 21 divide by 4 and look for multiples of 3 (12 = 3 * 4) you could look for numbers that are n mod 3 = 0 but probably simpler and faster to just use a lookup table something like this (untested) [code] temp1 = player0x - 21 if temp1 & 3 || temp1 > 108 then skip temp1 = temp1 / 4 if x3tbl[temp1] then gosub coldet2 skip data x3tbl 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1 end [/code] edit: fixed the table edit: Crap! ok, this time I really fixed the table..

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

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

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

you could do your table lookup a nibble at a time table lookup has the advantage of constant time (and is probably faster)

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)

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

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

not sure I'm following all this but the 0..99 score will be in BCD

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

A version of on goto that uses a jmp indirect and doesn't use the stack

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)

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)

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

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

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)

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

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)

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

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]