bogax

I'm not an expert but I believe your problem is you've only got enough memory for 12 rows if you want to fill the screen and you make some rows shorter you have to make other rows taller to compensate you need more memory in addition to the options RT mentioned there's the multisprite kernel which uses ROM for the screen but it has it's limitations

while pondering ultima's smooth diagonal movement code it occured to me that a macro to load an 8.8 variable from a table might be a useful thing so I made one. it works I've mutated ultima's code edit: I realised I'd goofed the movement flags lookup table so I fixed it also tweaked the velocities to be more accurate also added a version without the movement flag (bit 7) and test smooth_diagonal_movement_mod2.bas smooth_diagonal_movement_mod2.bas.bin smooth_diagonal_movement_mod3.bas smooth_diagonal_movement_mod3.bas.bin

just for completeness here I've included macros to set and clear bits def testbit = callmacro tb def setbit = callmacro sb def clearbit = callmacro cb macro tb temp1 = bits[{2}] & {1} end macro cb {1} = (bits[{2}] ^ $FF) & {1} end macro sb {1} = bits[{2}] | {1} end

as to the stack it looks like this might work def stackv = callmacro _stk macro _stk asm clc lda {1} adc #<STACKbegin sta DF7LOW lda #$00 adc #>STACKbegin and #$0F sta DF7HI end end stackv a edit: oops goofed it hopefully fixed now

I don't know about the stack This compiles and (at least in this case) seems to produce the correct code def testbit = callmacro tb data bits %00000001, %00000010, %00000100, %00001000, %00010000, %00100000, %01000000, %10000000 end macro tb temp1 = bits[{2}] & {1} end testbit f v : if temp1 then b=0 v selects the bit in f not that you need to use def and a macro they might make it easier to revamp existing code (I just think it makes prettier code )

The Atari uses most of it's time drawing the screen it has to do that periodically, at regular intervals There's a little time left over after it draws the screen before it needs to draw the screen again That's when your game code runs you call drawscreen and it waits for the next interval and draws the screen then runs your code and if your code takes to long it'll miss it's appointed time but it won't draw the screen until you do a drawscreen in your code so if player1x<=5 then player1x=255 : player1y=255 : n=(rand&1) : player1y=rand it's never going to see player1y = 255 there because you immediately set player1y = rand in order for player1y = 255 to have an effect on what's displayed you'd have to call drawscreen after you set player1y = 255 but before you set player1y = rand setting player1y = 255 is completely redundant there since you set the variables q r s t u d v w at the beginning of main, and you only need them to persist for a single line, use temp variables instead dim lb = temp6 dim rb = temp5 dim tb = temp4 dim bb = temp3 lb = player2x-8 rb = player2x+18 tb = player2y+1 bb = player2y-8 rem shoot the lion if missile0x > lb && missile0x < rb && missile0y < tb && missile0y > bb then player2x=255 : player2y=255 : j=0 : score=score+10 : c=c+1 lb = player3x-8 rb = player3x+18 tb = player3y+1 bb = player3y-8 rem shoot the pig if missile0x > lb && missile0x < rb && missile0y < tb && missile0y > bb then player3x=255 : player3y=255 : j=0 : score=score+50 : c=c+1

RAND produces a number between 255 and 0 or you can view it as a fraction between .999 and 0 if you divide by 256 (0.99609375 and 0 actually) we have a problem though. We're working with 8 bit numbers so were restricted to numbers in the range of 0 - 255 suppose we want a random number in the range 10 to 90 (inclusive) we can multiply our random numbers (in the range 0 to .999) by 81 (we'll truncate the fractional part) and add 10 we'll do it in binary because division by 2 is just a shift 81 expressed as a sum of powers of two is 81 = 64 + 16 + 1 our random number is RAND / 256 (0 - .996) so we need: RAND * (64 + 16 + 1) / 256 ie (RAND * 64) / 256 + (RAND * 16) / 256 + (RAND * 1) / 256 or RAND / 4 + RAND / 16 + RAND / 256 but we'll do it in a way that keeps the partial products as large as possible (to mimnimize the number of fractional bits we lose) but such that the partial products are less that 256 since we're using powers of two, the largest power of two we can add something to and have the result be less than 256 is 128 so we'll start with RAND / 2 which will give us a maximum of 127 we'll use the same RAND ie we only call RAND once and divide by 2 and save the result to use to do our calculation divide RAND / 2 by 16 and add RAND / 2 that gives us: RAND / 2 + RAND / 32 divide that by 4 and add RAND / 2 and that's RAND / 2 + RAND / 8 + RAND / 128 and finally divide by 2 to get RAND / 4 + RAND / 16 + RAND / 256 in Bb num = rand/2 : num = ((num / 16 + num) / 4 + num) / 2 + 10 here's some javascript to generate code for a range of random numbers ranged rand generator (pastebin)

Presumably you wont be putting a table in RAM There are easier ways to generate a table to put in ROM If you mean generating positions on the fly then since you always move one step in the major direction and sometimes move 0 steps or 1 step in the other direction I think your speed would vary depending on the angle. If you take 1 pixel in 160 as the minimum tangent ie you're moving in an arc such that you move eg 160 pixels in the x direction and 1 pixel in the y direction that's about .36 degrees or about 1/1000 of a circle if you use a 1 quadrant sine table with linear interpolation and 8 steps per table entry that's a table with 1000 / ( 4 * 8 ) = ~32 entries But of course you'd use some code (and cycles) doing interpolation and scaling and such That is to say I don't think a sine table itself would take much whether or not it would be faster or smaller overall would depend on exactly what you needed to do with it (and you'd still have to determine octants and stuff with a Bresenham's type algorithm)

Lose the hash marks and the colon const frame10lo = <frame10 const frame10hi = >frame10 player0pointerlo = frame10lo player0pointerhi = frame10hi player1pointerlo = frame10lo player1pointerhi = frame10hi data frame10 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 %00000000 end your code is incomplete since you don't set the player1 or player0 height(s) if you used the noinlinedata optimization you'd save 8 bytes

here's a simple animation I did a while ago animated_sprite.bas (Pastebin)

one of the things I really like about Bb is the way it does this and getting rid of that clumsy peek-poke stuff I just wish we had register variables you don't need a name all of these produce correct code (but of course writing to ROM is not very useful) rem if you want to store to a numeric location use indexing with an index of 0 a = 255 $d6[0] = 255 a[0] = 255 214[0] = 255 rem a[$07] is h h = a[$07] 0[221] = 255 $ABCD[a] = h $ABCD[a] = 16383[h] testd[$FF] = testd[1] data testd 00, 00, 00, 00 end 1631 f45d .L00 ; rem if you want to store to a numeric location use indexing with an index of 0 1632 f45d 1633 f45d . 1634 f45d ; 1635 f45d 1636 f45d .L01 ; a = 255 1637 f45d 1638 f45d a9 ff LDA #255 1639 f45f 85 d6 STA a 1640 f461 . 1641 f461 ; 1642 f461 1643 f461 .L02 ; $d6[0] = 255 1644 f461 1645 f461 a9 ff LDA #255 1646 f463 a2 00 LDX #0 1647 f465 95 d6 STA $d6,x 1648 f467 . 1649 f467 ; 1650 f467 1651 f467 .L03 ; a[0] = 255 1652 f467 1653 f467 a9 ff LDA #255 1654 f469 a2 00 LDX #0 1655 f46b 95 d6 STA a,x 1656 f46d . 1657 f46d ; 1658 f46d 1659 f46d .L04 ; 214[0] = 255 1660 f46d 1661 f46d a9 ff LDA #255 1662 f46f a2 00 LDX #0 1663 f471 95 d6 STA 214,x 1664 f473 . 1665 f473 ; 1666 f473 1667 f473 . 1668 f473 ; 1669 f473 1670 f473 .L05 ; rem a[$07] is h 1671 f473 1672 f473 . 1673 f473 ; 1674 f473 1675 f473 .L06 ; h = a[$07] 1676 f473 1677 f473 a2 07 LDX #$07 1678 f475 b5 d6 LDA a,x 1679 f477 85 dd STA h 1680 f479 . 1681 f479 ; 1682 f479 1683 f479 .L07 ; 0[221] = 255 1684 f479 1685 f479 a9 ff LDA #255 1686 f47b a2 dd LDX #221 1687 f47d 95 00 STA 0,x 1688 f47f . 1689 f47f ; 1690 f47f 1691 f47f . 1692 f47f ; 1693 f47f 1694 f47f . 1695 f47f ; 1696 f47f 1697 f47f .L08 ; $ABCD[a] = h 1698 f47f 1699 f47f a5 dd LDA h 1700 f481 a6 d6 LDX a 1701 f483 9d cd ab STA $ABCD,x 1702 f486 . 1703 f486 ; 1704 f486 1705 f486 .L09 ; $ABCD[a] = 16383[h] 1706 f486 1707 f486 a6 dd LDX h 1708 f488 bd ff 3f LDA 16383,x 1709 f48b a6 d6 LDX a 1710 f48d 9d cd ab STA $ABCD,x 1711 f490 . 1712 f490 ; 1713 f490 1714 f490 .L010 ; testd[$FF] = testd[1] 1715 f490 1716 f490 a2 01 LDX #1 1717 f492 bd 9d f4 LDA testd,x 1718 f495 a2 ff LDX #$FF 1719 f497 9d 9d f4 STA testd,x 1720 f49a . 1721 f49a ; 1722 f49a 1723 f49a . 1724 f49a ; 1725 f49a 1726 f49a . 1727 f49a ; 1728 f49a 1729 f49a . 1730 f49a ; 1731 f49a 1732 f49a .L011 ; data testd 1733 f49a 1734 f49a 4c a1 f4 JMP .skipL011 1735 f49d testd 1736 f49d 00 00 00 00 .byte.b 00, 00, 00, 00 1737 f4a1 1738 f4a1 .skipL011 1739 f4a1 .

oops, yup I goofed it try this temp1 = SWCHA / 16 ^ %00001111 if temp1 then c = last_direction_table[temp1] data last_direction_table %00000000, %00000010, %00000100, %00000000, %00001000, %00100000, %10000000, %00000000, %00010000, %01000000, %00000001 end here's a comparison (using d for mine and c for yours) top line is yours, the one below it is mine the bottom line is just for reference to show which bits are which the bit of asm at the end tells DASM to show the number of bytes between the labels var40 = $55 COLUPF = $55 loop rem This section sets a value for the last direction the joystick was pushed if joy0up then c{1}=1:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0down then c{1}=0:c{2}=1:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0left then c{1}=0:c{2}=0:c{3}=1:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=1:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0up && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=1:c{6}=0:c{7}=0:c{0}=0 if joy0up && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=1:c{7}=0:c{0}=0 if joy0down && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=1:c{0}=0 if joy0down && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=1 mark1 temp1 = SWCHA / 16 ^ %00001111 if temp1 then d = last_direction_table[temp1] data last_direction_table %00000000, %00000010, %00000100, %00000000, %00001000, %00100000, %10000000, %00000000, %00010000, %01000000, %00000001 end mark2 var32 = c var36 = d drawscreen goto loop asm echo (.mark1-.loop)d echo (.mark2-.mark1)d end SWCHA_encode.bas SWCHA_encode.bas.bin

here's some unsolicited advice unrelated to your problems the joy sticks are on SWCHA the SWCHA bits are like this rldurldu bits 7..4 are joy0 and bits 3..0 are joy1 if a switch is pressed it reads as a 0 eg joy0 right-up would be 01101111 you can invert the bits (so that a pressed switch reads as 1 and an unpressed switch as 0) by exclusive ORing with 1 eg (in Bb) (SWCHA still right-up) temp1 = SWCHA ^ %11110000 and temp1 will be %10011111 if you divide by 2 you shift the bits to the right filling the upper bits with 0 so (SWCHA still right-up) temp1 = SWCHA / 16 and temp1 will be %00000110 (SWCHA still right-up) temp1 = SWCHA / 16 ^ %00001111 and temp1 will be %00001001 some combinations can't happen eg down-up right_left corresponds to 12 in decimal there are 16 possible combinations all of 12..15 correspond to left-right simultaneously ie they can't happen 11 corresponds to %00001011 which would be left-down-up ie can't happen so the possiblities range from 0..10 rearranging this rem This section sets a value for the last direction the joystick was pushed if joy0up then c{1}=1:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0down then c{1}=0:c{2}=1:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0left then c{1}=0:c{2}=0:c{3}=1:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=1:c{5}=0:c{6}=0:c{7}=0:c{0}=0 if joy0up && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=1:c{6}=0:c{7}=0:c{0}=0 if joy0up && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=1:c{7}=0:c{0}=0 if joy0down && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=1:c{0}=0 if joy0down && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=1 so that it's in order rem This section sets a value for the last direction the joystick was pushed rem rldu c if joy0up then c{1}=1:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 rem 0001 %00000010 if joy0down then c{1}=0:c{2}=1:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 rem 0010 %00000100 rem down-up rem 0011 %00000000 if joy0left then c{1}=0:c{2}=0:c{3}=1:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=0 rem 0100 %00001000 if joy0up && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=1:c{6}=0:c{7}=0:c{0}=0 rem 0101 %00100000 if joy0down && joy0left then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=1:c{0}=0 rem 0110 %10000000 rem left-down-up rem 0111 %00000000 if joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=1:c{5}=0:c{6}=0:c{7}=0:c{0}=0 rem 1000 %00010000 if joy0up && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=1:c{7}=0:c{0}=0 rem 1001 %01000000 if joy0down && joy0right then c{1}=0:c{2}=0:c{3}=0:c{4}=0:c{5}=0:c{6}=0:c{7}=0:c{0}=1 rem 1010 %00000001 you can put all that into a table temp1 = SWCHA / 16 ^ %00001111 : c = last_direction_table[temp1] data last_direction_table %00000000, %00000010, %00000100, %00000000, %00001000, %00100000, %10000000, %00000000, %00010000, %01000000, %00000001 end and save a lot of time and bytes personally I generally translate the switches to something like compass directions ie c might run from eg 0..10 proceeding clockwise around the compass 1 = up-right, 2 = right, 3 = right-down, etc (I'm not suggesting you should do that, it's not necessarily the best way, but it's a possibility to consider) this could be an advantage if you want to use c with on gosub or on goto also if you want to set or clear a bunch of bits in c at once you can do it all at once if you want to clear all the bits in c, c = %00000000 (or just c = 0) ORing a bit with 0 will not affect it ORing a bit with 1 will result in a 1 ANDing a bit with 1 will not affect it ANDing a bit with 0 will result in a 0 if c = %hgfedcba and you want to set bits dc then c = c | %00001100 and c will be %hgfe11ba ie the letters will be unchanged, 0 or 1 whatever they were c = c & %11110011 c will be %hgfe00ba I think all this is explained on RT's page

Without electronics

Here's a better picture of how the interlacing is meant to work in NTSC (from this page) If the scan returns to the top at the same place horizontaly (instead of being displaced by half as in that picture) you would presumably scan the even and odd fields in exactly the same place horizontaly In the olden days that wasn't possible be cause the half line displacement was built into the TV it's self and it could take seconds or minutes (or never) for the television to sync with the signal

I don't know what flicker you're talking about. yes "normally" every other line is blacked out. with a crt television its not apparent because the screen doesn't have time to actually go black the phosphors continue to phosphoresce between fields so yes, it only sends the "first" field but it sends it twice per NTSC frame (30fps) or (60 fps if you prefer) I don't recall how the 2600 is set up so I don't know if the lines in the individual fields are actually interleaved by the 2600 (I don't think so) with older TVs they would be because that's just the way the TV worked but maybe (probably?) not with modern TVs

For the question as posed I choose jiffy But I suspect that anywhere RT would be using the term I'd use frame or possibly field even though technically I think of an NTSC frame as two 1/60 second interlaced fields and so a frame would be 1/30 of a second

you can create your own version of on gosub and on goto with just a little assembly asm jmp (temp5) end will jump to whatever location you specify in variables temp5, temp6 with the lo byte of the location in temp5 and the hi byte in temp6 Bb prepends a "." to labels, "my_label" in Bb becomes ".my_label" in the assembly labels are 16 bit but you can specify the lo byte, "<.my_label" or the hi byte, ">.my_label" you can't generally use "<.my_label" in Bb but you can in a constant declaration or a data statement so const ml_lo = <.my_label const ml_hi = >.my_label temp5 = ml_lo : temp6 = ml_hi asm jmp (temp5) end works in Bb and is sort of like goto my_label for on a gosub it would be something like set optimization noinlinedata if player0x > 160 then a = (rand/32) gosub on_a on_a temp5 = jump_table_lo[a] : temp6 = jump_table_hi[a] asm jmp (temp5) end data jump_table_lo <.PF0, <.PF1, <.PF2, <.PF3, <.PF4, <.PF5, <.PF6, <.PF7 end data jump_table_hi >.PF0, >.PF1, >.PF2, >.PF3, >.PF4, >.PF5, >.PF6, >.PF7 end PF0 rem some stuff return PF1 rem some stuff return PF2 rem some stuff return PF3 rem some stuff return PF4 rem some stuff return PF5 rem some stuff return PF6 rem some stuff return PF7 rem some stuff return of course it's more trouble than a simple on gosub and it uses 3 more bytes (provided you use the noinlinedata optimization which saves you three bytes per data statement. Bb inserts a hidden goto to go past the data whether it needs to or not, of course you have to be sure you have no in line data) on gosub is limited to what you can fit on a single line while data statements can have up to 256 items and span multiple lines I second the "post your code" suggestion I'd suggest that you use rand16 if you can affored the extra byte of ram since you've got 8 things you're choosing amongst and 8 is a power of 2 and if you're zero based you can lose the "+ 1" so you can do this instead and save a few bytes a = rand & 7

Here's a slightly different version with the pfcolor data (still) in a data statement. color_number is now just the index into the playfield color data table and still gets looked up with another table. there's a line with a value that's ORed with $00. if temp6{4} then color_number = nextc[color_number] : temp5 = $00 | nextc[color_number] apparently Bb optimizes out the second loading of the index (presumably because it's the same name) the ORing with $00 is just a minimal code way of preventing that (but not minimum, I could have rearranged the code and done away with the OR) I kludged in a minikernel to display the pointer and color_number in hex pfcolortable is on the left and color_number is on the right I should have mentioned that the pfcolor data table needs the correct page alignment the only thing I did to accomodate that is the order of the data statements set kernel_options pfcolors set optimization noinlinedata dim pfcolor_pointerlo = $F0 dim pfcolor_pointerhi = $F1 dim current_color = c dim color_number = d const pfcolorslo = <(pfc_table - 84) const pfcolorshi = >(pfc_table - 84) playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end color_number = 0 : current_color = pfc_table[color_number] pfcolor_pointerlo = pfcolorslo + 4 : pfcolor_pointerhi = pfcolorshi loop temp6 = ((SWCHA ^ $FF) & f) & $30 : f = SWCHA if !temp6 then skip_scroll_pfcolors if temp6{4} then color_number = nextc[color_number] : temp5 = $00 | nextc[color_number] if temp6{5} then temp5 = color_number : color_number = prevc[color_number] pfcolor_pointerlo = temp5 + pfcolorslo : current_color = pfc_table[color_number] skip_scroll_pfcolors scr0 = color_number scr3 = pfcolor_pointerhi : scr2 = pfcolor_pointerlo COLUPF = current_color drawscreen goto loop function rev() temp2 = temp1 & $0F temp1 = temp1 / 16 temp1 = revlo[temp2] * 16 | revlo[temp1] return data revlo $00, $08, $04, $0C, $02, $0A, $06, $0E $01, $09, $05, $0D, $03, $0B, $07, $0F end const nextc = prevc + 8 data prevc $1B, $18, $19, $1A, $00, $01, $02 $03 $04, $05, $06, $07, $08, $09, $0A $0B, $0C, $0D, $0E, $0F, $10, $11 $12, $13, $14, $15, $16, $17, $18 $19, $1A, $1B, $01, $02, $03, $00 end data pfc_table $02, $DE, $2E, $E6 $36, $BE, $4E, $C6 $56, $9E, $6E, $A6 $76, $7E, $8E, $86 $96, $5E, $AE, $66 $B6, $3E, $CE, $46 $D6, $1E, $EE, $26 $DE, $2E, $E6, $02 $BE, $4E, $C6, $36 $9E, $6E, $A6, $56 $7E, $8E, $86, $76 $5E, $AE, $66, $96 $3E, $CE, $46, $B6 $1E, $EE, $26, $D6 $2E, $E6, $02, $DE $4E, $C6, $36, $BE $6E, $A6, $56, $9E end minikernel const minikernel = .minikernel dim scr2 = score dim scr1 = score + 1 dim scr0 = score + 2 dim scr3 = var44 dim gr0tmp = var45 rem each digit has a pointer in to the table(s) rem there are four bytes per line, numbered 3..0 from rem left to right. each byte has a left and a right rem digit so the pointer for the third digit from rem the left is p2l and each pointer has a lo and a hi byte dim p0llo = score + 3 dim p0lhi = score + 4 dim p1llo = score + 5 dim p1lhi = score + 6 dim p2llo = score + 7 dim p2lhi = score + 8 dim p3llo = temp1 dim p3lhi = temp2 dim p0rlo = temp3 dim p0rhi = temp4 dim p1rlo = temp5 dim p1rhi = temp6 dim p2rlo = aux3 dim p2rhi = aux4 dim p3rlo = aux5 dim p3rhi = aux6 const lthi = >hxl const rthi = >hxr const ltlo = <hxl const rtlo = <hxr macro get asm lda ({1}),y ora ({2}),y sta {3} end end macro loadx asm ldx #{1} end end macro loady asm ldy loff,x end end macro delay asm bit $FF end end rem last cycle of sta RESP1 is 39 WSYNC = $00 GRP0 = $00 : GRP1 = $00 REFP0 = $00 : REFP1 = $00 NUSIZ0 = $02 : NUSIZ1 = $02 callmacro delay VDELP0 = $00 : VDELP1 = $00 : RESP1 = $00 : RESP0 = $00 HMP1 = $B0 : HMP0 = $C0 COLUP0 = $06 : COLUP1 = $06 p3lhi = lthi : p2lhi = lthi WSYNC = $00 HMOVE = $06 p1rhi = rthi : p0rhi = rthi : p3rhi = rthi : p2rhi = rthi p0rlo = (scr0 & $0F) + rtlo : p0llo = (scr0 / 16) + ltlo p3rlo = (scr3 & $0F) + rtlo : p3llo = (scr3 / 16) + ltlo WSYNC = $00 p1lhi = lthi : p0lhi = lthi p2rlo = (scr2 & $0F) + rtlo : p2llo = (scr2 / 16) + ltlo p1rlo = (scr1 & $0F) + rtlo : p1llo = (scr1 / 16) + ltlo callmacro loadx $05 rem 42..50 cycles to second sta GRP1 WSYNC = $00 hexloop callmacro loady callmacro get p0llo p0rlo gr0tmp WSYNC = $00 asm dex bpl .hexskip bmi .hexexit end hexskip callmacro get p3llo p3rlo GRP1 callmacro get p2llo p2rlo GRP0 callmacro get p1llo p1rlo GRP1 GRP0 = gr0tmp asm bne .hexloop end hexexit GRP1 = $00 : GRP0 = $00 return asm if (<*) > (<(*+$05)) repeat ($100-<*) .byte 0 repend endif end rem there's a table of left digits and a rem table of right digits rem there's a line in each table corresponding rem to the each display line numbered 4..0 rem loff is the table offsets for each line data loff $00, $40, $30, $20, $10, $00 end asm if (<*) > (<(*+$50)) repeat ($100-<*) .byte 0 repend endif end data hxr $07, $02, $06, $07, $01, $07, $03, $07, $07, $07, $02, $06, $03, $06, $07, $07 $05, $06, $01, $01, $03, $04, $04, $01, $05, $05, $05, $05, $04, $05, $04, $04 $05, $02, $02, $07, $05, $06, $07, $02, $07, $07, $07, $06, $04, $05, $06, $06 $05, $02, $04, $01, $07, $01, $05, $04, $05, $01, $05, $05, $04, $05, $04, $04 $07, $07, $07, $07, $01, $06, $07, $04, $07, $06, $05, $06, $03, $06, $07, $04 end asm if (<*) > (<(*+$50)) repeat ($100-<*) .byte 0 repend endif end data hxl $70, $20, $60, $70, $10, $70, $30, $70, $70, $70, $20, $60, $30, $60, $70, $70 $50, $60, $10, $10, $30, $40, $40, $10, $50, $50, $50, $50, $40, $50, $40, $40 $50, $20, $20, $70, $50, $60, $70, $20, $70, $70, $70, $60, $40, $50, $60, $60 $50, $20, $40, $10, $70, $10, $50, $40, $50, $10, $50, $50, $40, $50, $40, $40 $70, $70, $70, $70, $10, $60, $70, $40, $70, $60, $50, $60, $30, $60, $70, $40 end pfcolors_wtable.bas pfcolors_wtable.bin

here's some code that puts the colors in a table in a data statement conversion from color number to table index is done with another table this is set up to step through the colors using joy0 up-down color number is on the playfield on the third line from the bottom the color table pointer is the second line from the bottom the bottom is just to mark where the nibbles are set kernel_options pfcolors set optimization noinlinedata dim pfcolor_pointerlo = $F0 dim pfcolor_pointerhi = $F1 const pfcolorslo = <(pfc_table - 84) const pfcolorshi = >(pfc_table - 84) dim color_number = d playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end color_number = 27 pfcolor_pointerlo = pfcolorslo : pfcolor_pointerhi = pfcolorshi loop temp1 = (SWCHA ^ $FF) & f : f = SWCHA if !temp1 then skip_scroll_pfcolors if temp1{4} then color_number = color_number + 1 : if color_number = 28 then color_number = 0 if temp1{5} then color_number = color_number - 1 : if color_number = $FF then color_number = 27 temp1 = color_number + 1 : if temp1 = 28 then temp1 = 0 pfcolor_pointerlo = pfcidx[temp1] + pfcolorslo skip_scroll_pfcolors temp1 = pfcidx[color_number] : COLUPF = pfc_table[temp1] var29 = rev(pfcolorslo) var33 = rev(color_number) var40 = $F0 : var41 = $0F var36 = pfcolor_pointerhi var37 = rev(pfcolor_pointerlo) drawscreen goto loop function rev() temp2 = temp1 & $0F temp1 = temp1 / 16 temp1 = revlo[temp2] * 16 | revlo[temp1] return data revlo $00, $08, $04, $0C, $02, $0A, $06, $0E $01, $09, $05, $0D, $03, $0B, $07, $0F end data pfc_table $02, $DE, $2E, $E6 $36, $BE, $4E, $C6 $56, $9E, $6E, $A6 $76, $7E, $8E, $86 $96, $5E, $AE, $66 $B6, $3E, $CE, $46 $D6, $1E, $EE, $26 $DE, $2E, $E6, $02 $BE, $4E, $C6, $36 $9E, $6E, $A6, $56 $7E, $8E, $86, $76 $5E, $AE, $66, $96 $3E, $CE, $46, $B6 $1E, $EE, $26, $D6 $2E, $E6, $02, $DE $4E, $C6, $36, $BE $6E, $A6, $56, $9E end data pfcidx $00, $04, $08, $0C, $10, $14, $18 $01, $05, $09, $0D, $11, $15, $19 $02, $06, $0A, $0E, $12, $16, $1A $03, $07, $0B, $0F, $13, $17, $1B end

Here's some code that scrolls the playfield colors up. It keeps a frame counter and advances by one color by adding 4 to pfcolortable (the color table pointer which I called pfcolor_pointer in Bb) whenever the lowest 4 bits of the frame counter = 0 (so every 16 frames ~1/4 second) It adds 4 to the pfcolor_pointer because the colors are every 4th entry in the table When its scrolled up by 24 colors it subtracts 24 x 4 (96) from pfcolortable That is, the 24th sets the pointer back to the beginning of the table) pfcolor_pointer = pfcolor_pointer - 0.375 (0.375 is 96, see below) It maintains color_number in parallel to keep track of where it is in the colors rather than messing with pfcolortable in the if statement predicate tmp and pfcolor_pointer are 8.8 Bb variables (since we're messing with 16 bit pointers) Constants (like the above mentioned 96) need to be expressed in that format so it's 96 / 256 rounded up to three decimal places ie pfcolor_pointer = pfcolor_pointer - 0.375 likewise, 4 is 0.016 in 8.8 format The pfcolors in the pfcolors statement are 24 colors followed by the first 10 repeated (the last screen is the first screen offset by 1 color, and there's 11 colors per screen) Now I'm guessing it's a bug in the kernel or I may have goofed something but the kernel only displays 10 lines of color, skipping the first line. so the color of the first line of playfield has to be set in the main loop (thats normal) and pfcolortable has to be offset by 1 color The pfcolors statement sets pfcolortable (the variable which I'm calling pfcolor_pointer in Bb) to the location of the pfcolors table - 84 (I didn't try to figure out why) tmp is used as a pointer to get the first color (with a dab of asm) in the first_color function. The location of tmp ($9E) is passed to the first_color function and it returns the byte pointed to by tmp. tmp is first set to pfcolor_pointer + 84 - 4 tmp = pfcolor_pointer + 0.313 The compiler complains about an extraneous end statement but I'm guessing that's a bug in the parsing evoked due to using the asm statement in a function edit: my bad. a function doesn't need an end statement, it just needs to return The code produced seems correct no doubt the numbers would change with different numbers of colors or different kernel options/paramters, etc set kernel_options pfcolors pfcolors: $16 $1E $26 $2E $36 $3E $46 $4E $56 $66 $6E $76 $7E $86 $8E $96 $9E $AE $B6 $BE $C6 $CE $D6 $DE $16 $1E $26 $2E $36 $3E $46 $4E $56 $66 end rem name the 16 bit variables used for pointers dim tmp = temp4.temp3 dim pfcolor_pointerlo = $F0 dim pfcolor_pointerhi = $F1 dim pfcolor_pointer = pfcolor_pointerhi.pfcolor_pointerlo dim frame_counter = c dim color_number = d frame_counter = 0 : color_number = 0 playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end rem the kernel displays the 10 lines starting rem with the second, so offset the pfcolor_pointer rem to point to the color for the second line rem by adding 4 to it which is 0.016 in 8.8 format rem and the colors are every 4th entry in the rem pfcolortable table pfcolor_pointer = pfcolor_pointer + 0.016 loop frame_counter = frame_counter + 1 if frame_counter & $0F then skip_scroll_pfcolors color_number = color_number + 1 : pfcolor_pointer = pfcolor_pointer + 0.016 rem if we're at the end of the table go back to the beginning by subtracting rem 24 x 4 from the pointer ie 0.375 in 8.8 format if color_number = 24 then color_number = 0 : pfcolor_pointer = pfcolor_pointer - 0.375 skip_scroll_pfcolors rem set the tmp pointer to the location of the color rem of the first line tmp = pfcolor_pointer + 0.313 COLUPF = first_color($9E) drawscreen goto loop function first_color asm tax lda (0,x) rts end end

The short answer is no, it's not too hard. I'd go further and say it's an exceptionally good first language. It's fairly simple and will give you a lot of what you need to know as a foundation for more "advanced" stuff. You're probably just at the steep part of the learning curve. Keep slogging and in a month or three you'll look back and say 'I really have learned some stuff' The way you're doing it is sort of jumping in at the deep end. That's not a bad way, but it's probably not the easiest way. You sort have two things to learn simultaneously, the intracacies of the 6502 and the intracacies of the 2600 You need to know the 6502 to do the 2600, but you don't need to know the 2600 to learn the 6502 It's kinda like you want to write a novel in a language you're just learning. You probably wouldn't try to learn the language ONLY by reading the some novels but reading the novels isn't at all a bad way to learn the language. There are fairly painless ways to explore simple stuff on the 6502 Two that I like are this Javascript emulator and Michal Kowalski's 6502 emulator And don't over look Batari basic. You can play with the 2600 without knowing all the intracacies, (you can feed it assembly, it doesn't have to be BASIC). When you're ready, try writing a minikernel You might want to poke around on 6502.org

Here I've taken your code and altered it to illustrate some stuff, mostly why you need the .lst file I added another pfcolors statement so you can see what happens I added some Bb equivalents to the pfcolors statements (that refer to the table Bb produces) I added a data statement with the table (same data) called my_pfcolors_table The junk data is just to push Bb's pfcolors table across a page boundary (I used the my_pfcolors_table data. In retrospect, I should have used something completely different to set it apart) The rem statements at the end are just to mark the end of the Bb code in the .lst file I've only included the pertinent part of the .list file (well, some. it doesn't show why Bb does what it does) this compiles but is UNTESTED (and it doesn't do anything) set kernel_options pfcolors dim pfcolortable_lo = pfcolortable dim pfcolortable_hi = pfcolortable + 1 rem this just gives a name to use that wont change if rem the label pfcolorlabel3 between compiles const Bb_pfcolor_table_01 = pfcolorlabel13-84 const Colors1A_lo = <Bb_pfcolor_table_01 const Colors1A_hi = >Bb_pfcolor_table_01 Level1ColorsA pfcolors: $B6 $B6 $B4 $B4 $C4 $C4 $D4 $D4 $E4 $E4 $F4 $F4 $24 $24 $34 $34 $44 $44 $54 $54 $64 $64 $74 $74 $84 $84 $86 $86 $88 $88 $8A $8A $8C $8C $8E $8E end COLUPF = $B6 pfcolortable_hi = Colors1A_hi pfcolortable_lo = Colors1A_lo More_pfcolors pfcolors: $A0 $A1 $A2 $A3 $A4 $A5 $A6 $A7 $A8 $A9 $AA $AB $AC $AD $AE $AF $B0 $B1 $B2 $B3 $B4 $B5 $B6 $B7 $B8 $B9 $BB $BA $BC $BD $BE $BF $C0 $C1 $C2 $C3 end const More_pfcolors_lo = <(Bb_pfcolor_table_01 + 1) const More_pfcolors_hi = >(Bb_pfcolor_table_01 + 1) COLUPF = $A0 pfcolortable_hi = More_pfcolors_hi pfcolortable_lo = More_pfcolors_lo const my_colors_lo = <(my_pfcolors_table - 84) const my_colors_hi = >(my_pfcolors_table - 84) data my_pfcolors_table $B6,$A0,0,0 $B4,$A1,0,0 $B4,$A2,0,0 $C4,$A3,0,0 $C4,$A4,0,0 $D4,$A5,0,0 $D4,$A6,0,0 $E4,$A7,0,0 $E4,$A8,0,0 $F4,$A9,0,0 $F4,$AA,0,0 $24,$AB,0,0 $24,$AC,0,0 $34,$AD,0,0 $34,$AE,0,0 $44,$AF,0,0 $44,$B0,0,0 $54,$B1,0,0 $54,$B2,0,0 $64,$B3,0,0 $64,$B4,0,0 $74,$B5,0,0 $74,$B6,0,0 $84,$B7,0,0 $84,$B8,0,0 $86,$B9,0,0 $86,$BA,0,0 $88,$BC,0,0 $88,$BD,0,0 $8A,$BE,0,0 $8A,$BF,0,0 $8C,$C0,0,0 $8C,$C1,0,0 $8E,$C2,0,0 $8E,$C3,0,0 end COLUPF = my_pfcolors_table[0] pfcolortable_lo = my_colors_lo pfcolortable_hi = my_colors_hi data junk $B6,$A0,0,0 $B4,$A1,0,0 $B4,$A2,0,0 $C4,$A3,0,0 $C4,$A4,0,0 $D4,$A5,0,0 $D4,$A6,0,0 $E4,$A7,0,0 $E4,$A8,0,0 $F4,$A9,0,0 $F4,$AA,0,0 $24,$AB,0,0 $24,$AC,0,0 $34,$AD,0,0 $34,$AE,0,0 $44,$AF,0,0 $44,$B0,0,0 $54,$B1,0,0 $54,$B2,0,0 $64,$B3,0,0 $64,$B4,0,0 $74,$B5,0,0 $74,$B6,0,0 $84,$B7,0,0 $84,$B8,0,0 $86,$B9,0,0 $86,$BA,0,0 $88,$BC,0,0 $88,$BD,0,0 $8A,$BE,0,0 $8A,$BF,0,0 $8C,$C0,0,0 $8C,$C1,0,0 $8E,$C2,0,0 $8E,$C3,0,0 end rem the rest of the code rem rem rem rem 1634 f45e .L00 ; set kernel_options pfcolors 1635 f45e 1636 f45e . 1637 f45e ; 1638 f45e 1639 f45e . 1640 f45e ; 1641 f45e 1642 f45e .L01 ; dim pfcolortable_lo = pfcolortable 1643 f45e 1644 f45e .L02 ; dim pfcolortable_hi = pfcolortable + 1 1645 f45e 1646 f45e . 1647 f45e ; 1648 f45e 1649 f45e . 1650 f45e ; 1651 f45e 1652 f45e .L03 ; rem this just gives a name to use that wont change if 1653 f45e 1654 f45e .L04 ; rem the label pfcolorlabel3 between compiles 1655 f45e 1656 f45e . 1657 f45e ; 1658 f45e 1659 f45e .L05 ; const Bb_pfcolor_table_01 = pfcolorlabel13 - 84 1660 f45e 1661 f45e . 1662 f45e ; 1663 f45e 1664 f45e .L06 ; const Colors1A_lo = < Bb_pfcolor_table_01 1665 f45e 1666 f45e .L07 ; const Colors1A_hi = > Bb_pfcolor_table_01 1667 f45e 1668 f45e . 1669 f45e ; 1670 f45e 1671 f45e . 1672 f45e ; 1673 f45e 1674 f45e .Level1ColorsA 1675 f45e ; Level1ColorsA 1676 f45e 1677 f45e .L08 ; pfcolors: 1678 f45e 1679 f45e a9 b6 lda # $B6 1680 f460 85 08 sta COLUPF 1681 f462 - ifconst pfres 1682 f462 - lda #>(pfcolorlabel13-132+pfres*pfwidth) 1683 f462 else 1684 f462 a9 f5 lda #>(pfcolorlabel13-84) 1685 f464 endif 1686 f464 85 f1 sta pfcolortable+1 1687 f466 - ifconst pfres 1688 f466 - lda #<(pfcolorlabel13-132+pfres*pfwidth) 1689 f466 else 1690 f466 a9 67 lda #<(pfcolorlabel13-84) 1691 f468 endif 1692 f468 85 f0 sta pfcolortable 1693 f46a . 1694 f46a ; 1695 f46a 1696 f46a .L09 ; COLUPF = $B6 1697 f46a 1698 f46a a9 b6 LDA #$B6 1699 f46c 85 08 STA COLUPF 1700 f46e .L010 ; pfcolortable_hi = Colors1A_hi 1701 f46e 1702 f46e a9 f5 LDA #Colors1A_hi 1703 f470 85 f1 STA pfcolortable_hi 1704 f472 .L011 ; pfcolortable_lo = Colors1A_lo 1705 f472 1706 f472 a9 67 LDA #Colors1A_lo 1707 f474 85 f0 STA pfcolortable_lo 1708 f476 . 1709 f476 ; 1710 f476 1711 f476 . 1712 f476 ; 1713 f476 1714 f476 .More_pfcolors 1715 f476 ; More_pfcolors 1716 f476 1717 f476 .L012 ; pfcolors: 1718 f476 1719 f476 a9 a0 lda # $A0 1720 f478 85 08 sta COLUPF 1721 f47a - ifconst pfres 1722 f47a - lda #>(pfcolorlabel13-131+pfres*pfwidth) 1723 f47a else 1724 f47a a9 f5 lda #>(pfcolorlabel13-83) 1725 f47c endif 1726 f47c 85 f1 sta pfcolortable+1 1727 f47e - ifconst pfres 1728 f47e - lda #<(pfcolorlabel13-131+pfres*pfwidth) 1729 f47e else 1730 f47e a9 68 lda #<(pfcolorlabel13-83) 1731 f480 endif 1732 f480 85 f0 sta pfcolortable 1733 f482 . 1734 f482 ; 1735 f482 1736 f482 . 1737 f482 ; 1738 f482 1739 f482 .L013 ; const More_pfcolors_lo = < ( Bb_pfcolor_table_01 + 1 ) 1740 f482 1741 f482 .L014 ; const More_pfcolors_hi = > ( Bb_pfcolor_table_01 + 1 ) 1742 f482 1743 f482 . 1744 f482 ; 1745 f482 1746 f482 . 1747 f482 ; 1748 f482 1749 f482 .L015 ; COLUPF = $A0 1750 f482 1751 f482 a9 a0 LDA #$A0 1752 f484 85 08 STA COLUPF 1753 f486 .L016 ; pfcolortable_hi = More_pfcolors_hi 1754 f486 1755 f486 a9 f5 LDA #More_pfcolors_hi 1756 f488 85 f1 STA pfcolortable_hi 1757 f48a .L017 ; pfcolortable_lo = More_pfcolors_lo 1758 f48a 1759 f48a a9 68 LDA #More_pfcolors_lo 1760 f48c 85 f0 STA pfcolortable_lo 1761 f48e . 1762 f48e ; 1763 f48e 1764 f48e . 1765 f48e ; 1766 f48e 1767 f48e . 1768 f48e ; 1769 f48e 1770 f48e .L018 ; const my_colors_lo = < ( my_pfcolors_table - 84 ) 1771 f48e 1772 f48e .L019 ; const my_colors_hi = > ( my_pfcolors_table - 84 ) 1773 f48e 1774 f48e . 1775 f48e ; 1776 f48e 1777 f48e . 1778 f48e ; 1779 f48e 1780 f48e .L020 ; data my_pfcolors_table 1781 f48e 1782 f48e 4c 1d f5 JMP .skipL020 1783 f491 my_pfcolors_table 1784 f491 b6 a0 00 00 .byte.b $B6,$A0,0,0 1785 f495 1786 f495 b4 a1 00 00 .byte.b $B4,$A1,0,0 1787 f499 1788 f499 b4 a2 00 00 .byte.b $B4,$A2,0,0 1789 f49d 1790 f49d c4 a3 00 00 .byte.b $C4,$A3,0,0 1791 f4a1 1792 f4a1 c4 a4 00 00 .byte.b $C4,$A4,0,0 1793 f4a5 1794 f4a5 d4 a5 00 00 .byte.b $D4,$A5,0,0 1795 f4a9 1796 f4a9 d4 a6 00 00 .byte.b $D4,$A6,0,0 1797 f4ad 1798 f4ad e4 a7 00 00 .byte.b $E4,$A7,0,0 1799 f4b1 1800 f4b1 e4 a8 00 00 .byte.b $E4,$A8,0,0 1801 f4b5 1802 f4b5 f4 a9 00 00 .byte.b $F4,$A9,0,0 1803 f4b9 1804 f4b9 f4 aa 00 00 .byte.b $F4,$AA,0,0 1805 f4bd 1806 f4bd 24 ab 00 00 .byte.b $24,$AB,0,0 1807 f4c1 1808 f4c1 24 ac 00 00 .byte.b $24,$AC,0,0 1809 f4c5 1810 f4c5 34 ad 00 00 .byte.b $34,$AD,0,0 1811 f4c9 1812 f4c9 34 ae 00 00 .byte.b $34,$AE,0,0 1813 f4cd 1814 f4cd 44 af 00 00 .byte.b $44,$AF,0,0 1815 f4d1 1816 f4d1 44 b0 00 00 .byte.b $44,$B0,0,0 1817 f4d5 1818 f4d5 54 b1 00 00 .byte.b $54,$B1,0,0 1819 f4d9 1820 f4d9 54 b2 00 00 .byte.b $54,$B2,0,0 1821 f4dd 1822 f4dd 64 b3 00 00 .byte.b $64,$B3,0,0 1823 f4e1 1824 f4e1 64 b4 00 00 .byte.b $64,$B4,0,0 1825 f4e5 1826 f4e5 74 b5 00 00 .byte.b $74,$B5,0,0 1827 f4e9 1828 f4e9 74 b6 00 00 .byte.b $74,$B6,0,0 1829 f4ed 1830 f4ed 84 b7 00 00 .byte.b $84,$B7,0,0 1831 f4f1 1832 f4f1 84 b8 00 00 .byte.b $84,$B8,0,0 1833 f4f5 1834 f4f5 86 b9 00 00 .byte.b $86,$B9,0,0 1835 f4f9 1836 f4f9 86 ba 00 00 .byte.b $86,$BA,0,0 1837 f4fd 1838 f4fd 88 bc 00 00 .byte.b $88,$BC,0,0 1839 f501 1840 f501 88 bd 00 00 .byte.b $88,$BD,0,0 1841 f505 1842 f505 8a be 00 00 .byte.b $8A,$BE,0,0 1843 f509 1844 f509 8a bf 00 00 .byte.b $8A,$BF,0,0 1845 f50d 1846 f50d 8c c0 00 00 .byte.b $8C,$C0,0,0 1847 f511 1848 f511 8c c1 00 00 .byte.b $8C,$C1,0,0 1849 f515 1850 f515 8e c2 00 00 .byte.b $8E,$C2,0,0 1851 f519 1852 f519 8e c3 00 00 .byte.b $8E,$C3,0,0 1853 f51d 1854 f51d .skipL020 1855 f51d . 1856 f51d ; 1857 f51d 1858 f51d .L021 ; COLUPF = my_pfcolors_table[0] 1859 f51d 1860 f51d a2 00 LDX #0 1861 f51f bd 91 f4 LDA my_pfcolors_table,x 1862 f522 85 08 STA COLUPF 1863 f524 . 1864 f524 ; 1865 f524 1866 f524 .L022 ; pfcolortable_lo = my_colors_lo 1867 f524 1868 f524 a9 3d LDA #my_colors_lo 1869 f526 85 f0 STA pfcolortable_lo 1870 f528 .L023 ; pfcolortable_hi = my_colors_hi 1871 f528 1872 f528 a9 f4 LDA #my_colors_hi 1873 f52a 85 f1 STA pfcolortable_hi 1874 f52c . 1875 f52c ; 1876 f52c 1877 f52c . 1878 f52c ; 1879 f52c 1880 f52c .L024 ; data junk 1881 f52c 1882 f52c 4c bb f5 JMP .skipL024 1883 f52f junk 1884 f52f b6 a0 00 00 .byte.b $B6,$A0,0,0 1885 f533 1886 f533 b4 a1 00 00 .byte.b $B4,$A1,0,0 1887 f537 1888 f537 b4 a2 00 00 .byte.b $B4,$A2,0,0 1889 f53b 1890 f53b c4 a3 00 00 .byte.b $C4,$A3,0,0 1891 f53f 1892 f53f c4 a4 00 00 .byte.b $C4,$A4,0,0 1893 f543 1894 f543 d4 a5 00 00 .byte.b $D4,$A5,0,0 1895 f547 1896 f547 d4 a6 00 00 .byte.b $D4,$A6,0,0 1897 f54b 1898 f54b e4 a7 00 00 .byte.b $E4,$A7,0,0 1899 f54f 1900 f54f e4 a8 00 00 .byte.b $E4,$A8,0,0 1901 f553 1902 f553 f4 a9 00 00 .byte.b $F4,$A9,0,0 1903 f557 1904 f557 f4 aa 00 00 .byte.b $F4,$AA,0,0 1905 f55b 1906 f55b 24 ab 00 00 .byte.b $24,$AB,0,0 1907 f55f 1908 f55f 24 ac 00 00 .byte.b $24,$AC,0,0 1909 f563 1910 f563 34 ad 00 00 .byte.b $34,$AD,0,0 1911 f567 1912 f567 34 ae 00 00 .byte.b $34,$AE,0,0 1913 f56b 1914 f56b 44 af 00 00 .byte.b $44,$AF,0,0 1915 f56f 1916 f56f 44 b0 00 00 .byte.b $44,$B0,0,0 1917 f573 1918 f573 54 b1 00 00 .byte.b $54,$B1,0,0 1919 f577 1920 f577 54 b2 00 00 .byte.b $54,$B2,0,0 1921 f57b 1922 f57b 64 b3 00 00 .byte.b $64,$B3,0,0 1923 f57f 1924 f57f 64 b4 00 00 .byte.b $64,$B4,0,0 1925 f583 1926 f583 74 b5 00 00 .byte.b $74,$B5,0,0 1927 f587 1928 f587 74 b6 00 00 .byte.b $74,$B6,0,0 1929 f58b 1930 f58b 84 b7 00 00 .byte.b $84,$B7,0,0 1931 f58f 1932 f58f 84 b8 00 00 .byte.b $84,$B8,0,0 1933 f593 1934 f593 86 b9 00 00 .byte.b $86,$B9,0,0 1935 f597 1936 f597 86 ba 00 00 .byte.b $86,$BA,0,0 1937 f59b 1938 f59b 88 bc 00 00 .byte.b $88,$BC,0,0 1939 f59f 1940 f59f 88 bd 00 00 .byte.b $88,$BD,0,0 1941 f5a3 1942 f5a3 8a be 00 00 .byte.b $8A,$BE,0,0 1943 f5a7 1944 f5a7 8a bf 00 00 .byte.b $8A,$BF,0,0 1945 f5ab 1946 f5ab 8c c0 00 00 .byte.b $8C,$C0,0,0 1947 f5af 1948 f5af 8c c1 00 00 .byte.b $8C,$C1,0,0 1949 f5b3 1950 f5b3 8e c2 00 00 .byte.b $8E,$C2,0,0 1951 f5b7 1952 f5b7 8e c3 00 00 .byte.b $8E,$C3,0,0 1953 f5bb 1954 f5bb .skipL024 1955 f5bb . 1956 f5bb ; 1957 f5bb 1958 f5bb . 1959 f5bb ; 1960 f5bb 1961 f5bb .L025 ; rem the rest of the code 1962 f5bb 1963 f5bb .L026 ; rem 1964 f5bb 1965 f5bb .L027 ; rem 1966 f5bb 1967 f5bb .L028 ; rem 1968 f5bb 1969 f5bb .L029 ; rem 1970 f5bb 1971 f5bb - ifconst pfres 1972 f5bb - if (<*) > (254-pfres*pfwidth) 1973 f5bb - align 256 1974 f5bb - endif 1975 f5bb - if (<*) < (136-pfres*pfwidth) 1976 f5bb - repeat ((136-pfres*pfwidth)-(<*)) 1977 f5bb - .byte 0 1978 f5bb - repend 1979 f5bb - endif 1980 f5bb else 1981 f5bb - if (<*) > 206 1982 f5bb - align 256 1983 f5bb endif 1984 f5bb - if (<*) < 88 1985 f5bb - repeat (88-(<*)) 1986 f5bb - .byte 0 1987 f5bb - repend 1988 f5bb endif 1989 f5bb endif 1990 f5bb pfcolorlabel13 1991 f5bb b6 a1 00 00 .byte.b $B6, $A1,0,0 1992 f5bf b4 a2 00 00 .byte.b $B4, $A2,0,0 1993 f5c3 b4 a3 00 00 .byte.b $B4, $A3,0,0 1994 f5c7 c4 a4 00 00 .byte.b $C4, $A4,0,0 1995 f5cb c4 a5 00 00 .byte.b $C4, $A5,0,0 1996 f5cf d4 a6 00 00 .byte.b $D4, $A6,0,0 1997 f5d3 d4 a7 00 00 .byte.b $D4, $A7,0,0 1998 f5d7 e4 a8 00 00 .byte.b $E4, $A8,0,0 1999 f5db e4 a9 00 00 .byte.b $E4, $A9,0,0 2000 f5df f4 aa 00 00 .byte.b $F4, $AA,0,0 2001 f5e3 f4 ab 00 00 .byte.b $F4, $AB,0,0 2002 f5e7 24 ac 00 00 .byte.b $24, $AC,0,0 2003 f5eb 24 ad 00 00 .byte.b $24, $AD,0,0 2004 f5ef 34 ae 00 00 .byte.b $34, $AE,0,0 2005 f5f3 34 af 00 00 .byte.b $34, $AF,0,0 2006 f5f7 44 b0 00 00 .byte.b $44, $B0,0,0 2007 f5fb 44 b1 00 00 .byte.b $44, $B1,0,0 2008 f5ff 54 b2 00 00 .byte.b $54, $B2,0,0 2009 f603 54 b3 00 00 .byte.b $54, $B3,0,0 2010 f607 64 b4 00 00 .byte.b $64, $B4,0,0 2011 f60b 64 b5 00 00 .byte.b $64, $B5,0,0 2012 f60f 74 b6 00 00 .byte.b $74, $B6,0,0 2013 f613 74 b7 00 00 .byte.b $74, $B7,0,0 2014 f617 84 b8 00 00 .byte.b $84, $B8,0,0 2015 f61b 84 b9 00 00 .byte.b $84, $B9,0,0 2016 f61f 86 bb 00 00 .byte.b $86, $BB,0,0 2017 f623 86 ba 00 00 .byte.b $86, $BA,0,0 2018 f627 88 bc 00 00 .byte.b $88, $BC,0,0 2019 f62b 88 bd 00 00 .byte.b $88, $BD,0,0 2020 f62f 8a be 00 00 .byte.b $8A, $BE,0,0 2021 f633 8a bf 00 00 .byte.b $8A, $BF,0,0 2022 f637 8c c0 00 00 .byte.b $8C, $C0,0,0 2023 f63b 8c c1 00 00 .byte.b $8C, $C1,0,0 2024 f63f 8e c2 00 00 .byte.b $8E, $C2,0,0 2025 f643 8e c3 00 00 .byte.b $8E, $C3,0,0 2026 f647 if ECHOFIRST 2389 bytes of ROM space left

First off, you should post your code Level1ColorsA is the name of your routine/label in Bb but in the assembly code that Bb emits it will have a "." appended, ".Level1ColorsA" I don't recall about pfcolors specifically, but Bb probably moves the table to the end of the code and (I believe) to the last bank for multi bank stuff. and (as I believe Batari was alluding to above) Bb rearranges the table Compile something simple and see what Bb does with it. you may have to coax Bb (or DASM really) to produce a .lst file (its a DASM switch somewhere in the make file) Actually, that's an assumption. I've never used Visual Bb (and another assumption, I assume you're using Visual Bb) Once you've figured out what's going on I'd suggest you put the tables in a data statement. Bb won't monkey with it and you'll have better control.

Post your code Don't move player1 every frame