bogax

Not that I know anything about it.. According to the Stella Programmers Guide SWCHB{3} should be 1/true for color so if SWCHB{3} then else [bw]

This is easier to see just use search and replace to change the underscores to 0 and the hash marks to 1 hashmk_font_tables.txt

Ah, I see, they are arranged like that sort of each column is a character binary_font_tables.txt

Like lots (most?) problems in programming it's going to come down to trading off speed for memory. (and I was trying to fit as much as possible into bB with a minimum of asm) In this case speed is paramount so you're going to be throwing lots of memory at it. If you want the displayed text to be changeable that means RAM. So it's going to depend on exactly what you want and how many resources you want to devote to it. For the program as it stands the gap is built in. And it's limited to 16 characters. To change either would mean major restructuring and more memory (though not necessarily more RAM particularly if you don't need it to be so arbitrary/changeable, you probably won't be scrolling through long strings of text, but you could probably select among several fixed strings) What it boils down to is you could do a lot better than this but if you can live with the gap and 16 characters there's no reason you can't change the font to something else. (and it would probably not be to much trouble or use to much RAM to make the font selectable but the font uses 160 bytes) What exactly do you want? As for using binary just change the font tables hxr, hxl to binary instead of hex.

set tv ntsc set optimization noinlinedata dim lives_compact = 1 dim p0_orientation = c dim p1_orientation = z dim score1 = score + 1 dim score2 = score + 2 score=1000 intro01 playfield: ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ end z=0 gosub P0 gosub P1 player0height = 6 player1height = 6 intro01loop COLUBK = $08 COLUPF = $0E COLUP0 = $44 COLUP1 = $64 player0x=25 :player0y=50 player1x=125:player1y=50 if z>19 && switchselect then goto intro02 if joy0fire || joy1fire then goto GAMEPLAY drawscreen z=z+1 goto intro01loop intro02 playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ...............................X ...............................X ........X..............X.......X X.......X..............X.......X X.......X..............X.......X X.......X..............X.......X X.......X..............X........ X............................... X............................... XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end z=0 gosub P0 gosub P1 player0height = 6 player1height = 6 intro02loop COLUBK = $08 COLUPF = $0E COLUP0 = $44 COLUP1 = $64 player0x=25 :player0y=50 player1x=125:player1y=50 if z>9 && switchselect then goto intro01 if joy0fire || joy1fire then goto GAMEPLAY drawscreen z=z+1 goto intro02loop GAMEPLAY gosub P0 gosub P1 player0height = 6 p0_orientation = 0 player1height = 6 p1_orientation = 0 lifecolor=$64 lives=192 main lives: %00000000 %11111111 %11111111 %11111111 %11111111 %11111111 %11111111 %00000000 end if switchreset then reboot COLUP0 = $44 COLUP1 = $64 drawscreen score=score-1 temp1 = (score | score1) | score2 if temp1 then main P2WINS z=0 player1: %00111100 %01000010 %10000001 %10000001 %10000001 %10000001 %01000010 %00111100 end player0: %10000001 %01000010 %00100100 %00011000 %00011000 %00100100 %01000010 %10000001 end P2WINSLOOP drawscreen COLUP0 = $44 COLUP1 = $64 z=z+1 if z>20 && switchreset then reboot goto P2WINSLOOP P0 player0: %0000000 %1111100 %1111100 %0111000 %0111000 %0010000 %0010000 %0000100 %0011100 %1111100 %0111100 %0011100 %0001100 %0000100 %0001000 %0011000 %0111100 %1111100 %0111100 %0001110 %0000010 %0000000 %1100000 %1111000 %1111110 %1111000 %1100000 %0000000 %0000000 %1111111 %0111110 %0111100 %0011000 %0010000 %0000000 %0000011 %0011110 %1111110 %0111100 %0011000 %0001000 %0000000 %0001000 %0001000 %0011100 %0011100 %0111110 %0111110 %0000000 %0100000 %0110000 %0111000 %0111100 %0111110 %0111000 %0100000 %1000000 %1110000 %0111000 %0111110 %0111100 %0011000 %0010000 %0000000 %0000110 %0011110 %1111110 %0011110 %0000110 %0000000 %0010000 %0011000 %0111100 %0111110 %0111100 %1110000 %1000000 %0100000 %0111000 %0111110 %0111100 %0111000 %0110000 %0100000 end return P1 player1: %0000000 %1111100 %1111100 %0111000 %0111000 %0010000 %0010000 %0000100 %0011100 %1111100 %0111100 %0011100 %0001100 %0000100 %0001000 %0011000 %0111100 %1111100 %0111100 %0001110 %0000010 %0000000 %1100000 %1111000 %1111110 %1111000 %1100000 %0000000 %0000000 %1111111 %0111110 %0111100 %0011000 %0010000 %0000000 %0000011 %0011110 %1111110 %0111100 %0011000 %0001000 %0000000 %0001000 %0001000 %0011100 %0011100 %0111110 %0111110 %0000000 %0100000 %0110000 %0111000 %0111100 %0111110 %0111000 %0100000 %1000000 %1110000 %0111000 %0111110 %0111100 %0011000 %0010000 %0000000 %0000110 %0011110 %1111110 %0011110 %0000110 %0000000 %0010000 %0011000 %0111100 %0111110 %0111100 %1110000 %1000000 %0100000 %0111000 %0111110 %0111100 %0111000 %0110000 %0100000 end return inline 6lives.asm

That's a somewhat involved question. Processor uses 8 bit bytes and does things in binary. You could sort of think of it as similar to how people deal with "normal" (base ten, 0..9) numbers a digit at a time. 8 bits gives you 256 possibilities so it's kinda like the computer uses digits that are 0..256. but you can think of that byte as two hexadecimal, base 16 digits ie like it was two digits that are 0..15 People are used to dealing with base ten so the processor has the abilitiy to treat bytes as decimal for addition and subtraction So instead of treating a byte as two base 16 digits it can treat a byte as two decimal digits. All that to say you get two decimal digits per byte. The score has six digits so it uses three bytes But bB only treats them as a single six digit decimal number for addition with the score An if-then statement does the normal processor/bB thing with bytes So your if then statement with score only uses the first two (least significant) digits of score, ie the first byte (besides the score is in BCD, Binary Coded Decimal and bB let's you use decimal for other stuff but it's actually binary which can mess you up. 10 in BCD is 16 in binary so set the score to 10 and compare to 15 and score>15 is true) You could do an if then on each of the score bytes but since you're testing for 0 there's a simpler faster way. bB is happy with if a | b then but it doesn't like if a | b | c then a | b is a bitwise ORing of a and b "or" ("|") is 0 | 0 = 0 0 | 1 = 1 1 | 0 = 1 1 | 1 = 1 so 1 | (don't care) = 1 a | b does that for corresponding bits in the the bytes and puts the corresponding result bit in to the corresponding bit of the result byte bit0 | bit0 to bit0 of the result like wise for bits 1, 2, .. 7 so if any bit of a, b, c is 1 ie if any of a, b, c is not 0 Then the result of a | b | c will not be zero but if they are all zero the result will be zero. Since you need somewhere to put the result untill you can test it, but only untill you can test it, you use a temp variable. That's what the temp variables are for (well, they're for stuff that the kernel needs a temp variable for but you can use them too since they're only used by the kernel during drawscreen) (bB also uses them for eg passing values to or in function or for doing math or stuff) (except for temp 7 there are 7 temp variables temp1 .. temp6 are used by the kernel during drawscreen temp7 is used for bankswitching) dim score1 = score + 1 is just to give a name to the second byte of the score that you can use in bB. Score is actually a constant that is the location in memory of the variable score. dim score1 = score + 1 just names the next following location in memory score1 And I probaly confused you by using if !temp1 then x=x x=x is just a placeholder because you need something after the then. what you would want is if !temp1 then P2WINS if you give an if statement a single value it will treat it like if value <> 0 then ie a non zero value is true the ! prefix inverts that so if !temp1 then is like if temp1 = 0 then but it's faster and uses less code (less ROM) if the if-then statement is close enough to your target (P2WINS in this case) you don't need the goto and that's also faster and uses less code since P2WINS is right after the if-then statement, what you should actually do is temp1 = score | score1 | score2 if temp1 then main but you may have to add the goto to the if-then if you add more stuff between the if-then and main edit: something I forgot (parenthesis) temp1 = (score | score1) | score2 if temp1 then main If it doesn't have the parenthesis bB will stash score on the stack and compute score1 | score2 first.

A minikernel that displays two sqinty little 4 digit hexadecimal numbers (3 x 5 font) The numbers are in score with aux1 as the fourth byte/most significant byte Uses all the temp registers except temp7 all the score pointers and all the aux variables (but only aux1 needs to be persitent) Takes about 380 bytes It's not quite perfected I haven't managed to get the horizontal postioning to work so there's a bit of a gap in the middle of each of the four digits. I doubt it's much of any real use but it could be used to display memory addresses and such (or decimal numbers) fire will scroll the digits I've only tried it in Stella don't know if it would work on the real hardware. Ok, with SpiceWare's help I've fixed the gap I'd say 'now it's perfect' except I had to kludge it so much to get the timing right. The code is not as pretty and there's more asm (I was trying to keep that to an absolute minimum) Besides, I prefer the extra color clock gap between the bytes for hex. hex_minikernel_4.bas hex_minikernel_4.bin hex_minikernel_4_2.bas hex_minikernel_4_2.bin

I don't understand what you're doing so maybe this is non sequitor do you understand that the collision flags get set during drawscreen and will reflect the missile position at that time also c01d2 has missile1y = missile1y + 1 is that really what you wanted? In render ws01 = 4 is not in your test range(s)

I fixed the thing its just a matter of shuffling things around a bit (and putting them where I probably should have in the first place) But I don't understand why it happens. I'm using stella so maybe it's an issue with stella. As to the page it's probably the splash ad (free hosting) here's direct links I don't know that they'll work any better. hex_minikernel_2.bas hex_minikernel_2.bin I used to have that problem with older browsers. I wonder if any one else has that problem (no one else has mentioned it) (probably because nobody bothers to look at it ) the working version (not well tested) hex_minikernel_3.bas hex_minikernel_3.bin hex_minikernel_3.bas hex_minikernel_3.bin

I'm trying to write a minikernel but some how I've gotten the timing screwed up. Initialization of the TIA happens (mostly) during the first line. Among other things GRP1, GRP0, VDELP1 and VDELP0 get set to $00. RESP1 gets set at cycle 34 (there's 31 cycles before the sta RESP1) then some set up happens for 3 lines and on cycle 69 of the fourth line GRP1 gets set for display on the fifth line but it seems to be appearing on the fourth line. I can't figure out what I've done wrong. code here: http://basicplay.netau.net/

score is not a normal variable. it's a three byte 6 digit decimal (normal variables are one byte binary) you'll probably have to do something like this dim score1 = score + 1 dim score2 = score + 2 temp1 = (score | score1) | score2 if !temp1 then x=x and yes, do post your code when you ask a question about it

Ok I'm assuming that means that the bB code is in the ARM flash ROM program space (and not that there's some external 6507 speed ROM that the ARM can read) So couldn't you put some ARM code in a data stament then define a function 255 call (maybe just a few words?) that calls code in that data statement using the functionality that's already there except for the few words in function 255? edit I recognize that there may be permissions or protections or something that might have to be adjusted, but you wouldn't have to change mappings or move a lot of stuff around or generally rearrange things would you?

I was thinking something like having a data statment that contained the ARM code eg scrolling routines and then being able call them from where ever ARM normally runs from. If the bB code ROM space is actually in an external serial ROM or something like that it probably wouldn't work but if the bB code is in the ARMs program ROM space then maybe there'd be no problem.

I have no idea how either the Harmony or the ARM it's self is set up. Can the ARM run from pseudo ROM space in flash? If not can it run from the display queue? Or some piece of RAM that you could copy an auxilliary routine to from ROM.

If I'm reading that correctly the problem is that queueing will only take data from the pseudo-ROM space. How hard do you think it would be to include the queue? Any non-obvious (or obvious for that matter) gotchas you could mention?

Well thanks for that little tutorial. Unfortunately I couldn't get Stella to run last time I tryed installing it. (apparently Stella won't run without Stella.ini and I suppose you have to run Stella to create it or something ) (I haven't tryed to dope it out yet)

I'm not intimately familiar with all EEPROMs but basically modern EEPROMs are self programming. You write a block and then wait for it to program it's self. You could probably get the 2600 to program it if you could figure out how to get the data to the 2600 in the first place. It's possible that there'd be something funny about how you address things but probably you just tie a couple of address lines and use ony 64k of your 256k chip. T'were me, I think I'd tie them to switches so you could use the entire 256k even if you had to switch manually. The problem might be finding a 5V chip. edit incidently this question comes up fairly often, if not in these forums then in similar forums. A little Googling will probably find you at least part of the answer. You might start with http://www.6502.org/ For programming a 22v10 you probably need to find a programmer. You might be able to do it yourself if you can find an equivalent GAL (Google GALblaster) Modern CPLDs are much easier to deal with. (and more available)(and have more to them) you might want to try to adapt. Whatever happened to [i think it was] Supercat's idea of making every access to the cartridge a read-then-write and letting the cartridge and the CPU fight it out (if it's supposed to be a write cycle the CPU wins otherwise you write back what you just read)?

I goofed some cut and paste so here's a revised version. This will compile but of course that doesn't mean it makes any more sense For the weird assignments that iesposta pointed out I just changed the = to + like so missile0x = missile0x + 0 set romsize 32kSC set kernel_options no_blank_lines vars player0x = 50 player0y = 44 rem a = cast number rem making a 0 based simplifies things slightly rem b = missile distance rem c = player direction rem putting assignemts to the same value continguously rem on the same line is faster and uses less ROM a = 0 : b = 0 : c = 0 missile0x = player0x missile0y = player0y goto missilecast wallfound dim b_ = temp1 rem b/10 by table look up rem the table only has entries for b = 0..50 rem I'd either use a multiple of a power of 2 rem or use some asm to divide by 10 b_ = div10[b] rem the cast number is now 0..15 rem 0 based is slightly simpler if you're rem not using 0 as a flag ie something like rem if !a then skip_all_that var0[a]=d[b_] b = 0 missile0x = player0x missile0y = player0y missilecast playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X X..............................X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end b = b + 1 if 7 < a && a < 16 then z = 7 - a dim c_ = temp1 if a then c_ = c | 4 rem it depends on exactly what you're doing rem but on goto or on gosub are generally rem faster and less code if you've got more than rem 4 or 5 if clauses rem could be on goto if speed is more rem important than space on c_ gosub c00 c01 c02 c03 c10 c11 c12 c13 goto missilecast skip if collision(missile0, playfield) || b = 50 then goto wallfound rem at least in this bit you never get here unless rem a = 0 and a never gets set to 0 (?) rem ie making case number 0 based may mess this up rem you never get here unless a = 0 so you never goto render if a > 16 then goto render goto missilecast c00 missile0x = missile0x + 0 : rem if facing north missile0y = missile0y - 1 return c01 missile0x = missile0x + 1 : rem if facing east missile0y = missile0y + 0 return c02 missile0x = missile0x + 0 : rem if facing south missile0y = missile0y + 1 return return c03 missile0x = missile0x - 1 : rem if facing west missile0y = missile0y + 0 return c10 missile0x = missile0x - z : rem if facing north missile0y = missile0y - 1 return c11 missile0x = missile0x + 1 : rem if facing east missile0y = missile0y - z return c12 missile0x = missile0x + z : rem if facing south missile0y = missile0y + 1 return c13 missile0x = missile0x - 1 : rem if facing west missile0y = missile0y + z return data div10 0,0,0,0,0,0,0,0,0,0 1,1,1,1,1,1,1,1,1,1 2,2,2,2,2,2,2,2,2,2 3,3,3,3,3,3,3,3,3,3 4,4,4,4,4,4,4,4,4,4 5 end render

I think the bB sets aside space for four whether you you use it or not (in groups of four eg if you have five then it uses space for eight) Might as well use four if you want

The playfield colors are in table(s) in ROM and can't be changed. I suppose it might just barely be possible use RAM since you wouldn't be using it for the title any way but I wouldn't bet on it. For one thing the pfcolors table(s) seem to come in 44 byte chunks and you'ld be pressed to find that much RAM. The simplest thing would probably be to create a few pfcolors statements with different colors and choose one at random with on gosub or some such. edit And roughly speaking e is a constant with the value $DA which is the address of the variable. When you put it in the color statement it get's interpreted as a color.

here's something you could try I've added it to the player0_parameterized.bas mentioned above (and changed it to use a player0 statement with a constant) rem this will read a byte into the score rem it's padded to exactly one page so it rem shouldn't change the page alignment rem if it's removed rem you will have to change the assignment of rem temp4 to whatever you want to read, of course rem and it will have to be a simple variable rem or a constant, indexing will throw the total off temp4 = player0pointer score = 0 if temp4{7} then score = score + 128 if temp4{6} then score = score + 64 if temp4{5} then score = score + 32 if temp4{4} then score = score + 16 if temp4{3} then score = score + 8 if temp4{2} then score = score + 4 if temp4{1} then score = score + 2 if temp4{0} then score = score + 1 rem this is just padding temp4 = 0 : temp4 = 1 : temp4 = 2 : temp4 = 3 temp4 = 4 : temp4 = temp4[0] + 6

There's some of that here. player0_parameterized.bas uses player0pointer I forgot to mention that using a player statement has the advantage that bB takes care of the page boundaries http://basicplay.netau.net/ I don't have one there that uses a constant with a player statement but I've got one somewhere. Really the easiest thing is just to assign the low byte of the player pointer to a playfield variable and read it that way (which assumes you have playfield variables you can assign to). Of course you have to decipher the binary then and it takes 4 bytes which you may have to subtract when you remove the assignment. edit oops player0_parameterized.bas was the wong file now fixed and augmented (see below) and uses a player0 statement with a constant.

If you put your sprite data in to a data stament you'll have a name that you can use to refer to the sprite data and you won't have to use a variable to save the pointer. You also save a few bytes of code that sets up the pointers which you would be duplicating. But you have to make sure the data doesn't cross a page boundary or at least make sure no individual sprite crosses a page boundary (in which case you'ld have to deal with all 16 bits of the pointer).(I'll have to play with it some more but it sounds like page crossings may not be a problem with the DPC+ kernel) Making sure the data doesn't cross a page boundary is just a small bit of asm and not a problem. simplest I think is to just tell DASM to page align it. asm align 256 end That may not be needed in which case it'll just waste space. If the total of your sprite data approaches 256 bytes (so that there's a good chance that it would cross a page boundary) might as well put it all in one place and use the page alignment and of course the asm needs to go immediately before the block of data you're aligning. This (which I lifted from a list file) fills with 0 bytes if the data would cross a page boundary. You have to supply it with the length of the data. rem fills in with zero bytes if necesary so that rem the sprite table doesn't cross a page boundary asm if (<*) > (<(*+datalength)) repeat ($100-<*) .byte 0 repend endif end If you use the usual player definiton for the data you can still use a constant and save the variable, but it's trickier because the name is the line number so pretty much any change to the program will likely change the name. You can dig into the asm listing and find the address or you could read it from the player pointer (then put it in a constant). I think once you get the sprite data settled, if bB is putting it into it's own bank, the address will remain the same provided the length of the actual data doesn't change.

Ah, ok I think I've got it. Thanks. So is there a bit of unused RAM where you could write sprite data and point the pointers to? Perhaps if eg the queue grows up you could let the sprite data grow down and write to the top of the display data area. I suppose if it's documented any where it's in the ARM code. I could try and fill the queue and see where it runs out of space except maybe it wouldn't. Guess I'll just have to try it. Thanks again.

I haven't read all of that thread yet but it lools to me like there you're just copying pointers around (only changing the pointers). I can do that, that works. What I was trying to do is change what the pointers are pointing to and I can't get that to work. Looking at some of the comments in the files in the includes folder it looks like it should work. edit here's an excerpt from DPCplus.h ;---------------------------------------- ; The Data Fetchers can also be used to update the contents of the 4K ; Display Data bank. Point the Data Fetcher to the data to change, ; then Write to it The Data Fetcher's pointer will be incremented AFTER ; the data is written. ; ; point Data Fetcher 1 to the sprite data ; lda #<SpriteData ; sta DF1LOW ; lda #>SpriteData ; sta DF1HI ; ; then update it ; LDA #$FF ; STA DF1WRITE ; changes data at SpriteData ; LDA #$81 ; STA DF1WRITE ; changes data at SpriteData + 1 ;----------------------------------------