+batari Posted August 23, 2005 Share Posted August 23, 2005 (edited) Here's Alpha 0.3. I am crossing my fingers that there won't be too many bugs. I haven't had much time to test everything, so it's possible that some of the new features have bugs or even fatal bugs without workarounds. But the good news is that the Alpha 0.2 bugs have been fixed, or at least I believe they have been. One thing I should note about porting your 0.2a programs to 0.3a: bit access now uses {braces} instead of parens because I wanted to use parentheses for user functions, and I couldn't figure out a way to tell the difference. I thought is made more sense that functions should use parens, since this is pretty much standard across the board. Other bugs, such as the inverted bit operations and collisions, now work as they should. So you need to change these and any other workarounds for the Alpha 0.2 bugs. I know there will be bugs in the new stuff, and thanks to all for bearing with me until bB matures. The sooner the bugs are found, the sooner they will be fixed. Enjoy! batari_basic_alpha3_source.zip batari_basic_alpha3.zip Edited August 23, 2005 by batari Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2005 Share Posted August 23, 2005 Thanks. Did you say that you only need to make a quick adjustment to the IDE for this to work with it? Quote Link to comment Share on other sites More sharing options...
+batari Posted August 23, 2005 Author Share Posted August 23, 2005 Thanks. Did you say that you only need to make a quick adjustment to the IDE for this to work with it? 916779[/snapback] Yes, and I included the new file you need in the zip above. It's the 2600baside.bat file. I do think that 2600ide should be updated though, as the DOS screen really shouldn't disappear. It not only displays how many bytes are free, but also it now has useful information about any errors it finds. I don't know if there's a workaround for this or not. I just noticed that the sample.bas file was screwy so I fixed it above. It's still a pretty simple sample but a little bit more complicated - it contains a few weird code sequences for no other reason than to show how they work. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2005 Share Posted August 23, 2005 I must be doing something wrong because the screen is flipping or flashing (using Stella), it's hard to tell which. The score looks like it is flashing on and off. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 23, 2005 Author Share Posted August 23, 2005 I must be doing something wrong because the screen is flipping or flashing (using Stella), it's hard to tell which. The score looks like it is flashing on and off. 916800[/snapback] I found problems in sample.bas, so I updated the posts above. I think you're the only one who got the funky sample.bas - The screen in this one will indeed flash. In the fixed sample, it only flashes when the two sprites collide, which is what I intended to do. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2005 Share Posted August 23, 2005 I should have said that I was using one of my own programs. I'll try your sample program and see what happens. Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted August 23, 2005 Share Posted August 23, 2005 (edited) I noticed the help file has most of the info highlighed in black. is it only me or does everybody else see this. Edited August 23, 2005 by Dan Iacovelli Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2005 Share Posted August 23, 2005 (edited) Here's an example of something that works OK with the old version, but messes up using the new: rem * Create alias for each variable. dim blockx = a dim blocky = b dim delay = d rem * Setup. COLUPF = 90 : delay = 0 blockx = 16 : blocky = 5 rem * Main game loop starts here. gameloop scorecolor = 158 drawscreen rem * Begin delay. delay = delay + 1 if delay < 3 then goto gameloop delay = 0 rem * End delay. rem * Delete block and move it to new position. pfpixel blockx blocky off if joy0up && blocky > 1 then blocky = blocky - 1 if joy0down && blocky < 10 then blocky = blocky + 1 if joy0left && blockx > 1 then blockx = blockx - 1 if joy0right && blockx < 31 then blockx = blockx + 1 if joy0fire then score = score + 1 pfpixel blockx blocky on goto gameloop It's just a simple thing that lets you move a block around the screen with the joystick and it seems like it would work with either version. Is it just my computer or does the Stella screen mess up when you run that with the new version of bB? This question is for anyone reading this post. Does the code work for you? Thanks. I'll be back tonight. Edited September 8, 2005 by Random Terrain Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted August 23, 2005 Share Posted August 23, 2005 My work in progress also wouldn't work under the new bB; I did some playing around trying to isolate the problem and, though I still don't know what is going on, I did discover that this rather simple program does not run correctly. Don't know why: rem smartbranching on rem init setup scorecolor = $0E MainLoop drawscreen goto MainLoop Help? Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted August 23, 2005 Share Posted August 23, 2005 Here's an example of something that works OK with the old version, but messes up using the new: rem * Create alias for each variable. dim blockx = a dim blocky = b dim savex = c dim savey = d dim delay = e rem * Setup. COLUPF = 90 : delay = 0 blockx = 16 : blocky = 5 savex = 16 : savey = 5 rem * Main game loop starts here. gameloop scorecolor = 158 drawscreen rem * Begin delay. delay = delay + 1 if delay < 3 then goto gameloop delay = 0 rem * End delay. rem * Delete block and move it to new position. if joy0up && blocky > 1 then savey = savey - 1 if joy0down && blocky < 10 then savey = savey + 1 if joy0left && blockx > 1 then savex = savex - 1 if joy0right && blockx < 31 then savex = savex + 1 if joy0fire then score = score + 1 pfpixel blockx blocky off blockx = savex : blocky = savey pfpixel blockx blocky on goto gameloop It's just a simple thing that lets you move a block around the screen with the joystick and it seems like it would work with either version. Is it just my computer or does the Stella screen mess up when you run that with the new version of bB? This question is for anyone reading this post. Does the code work for you? Thanks. I'll be back tonight. 916923[/snapback] I don't get anything on it I use Z26. Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted August 23, 2005 Share Posted August 23, 2005 on side note: when I tried to do my game in the new version the screen was jumping. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted August 23, 2005 Share Posted August 23, 2005 (edited) I think I've found the problem: if missile0height and missile1height are zero or one (edit), the kernel breaks. Zero also happens to be the default value of those two variables, so if you do not define them explicitly, the kernel will break. This will not work: rem smartbranching on rem init setup scorecolor = $0E rem missile0height = 2 rem missile1height = 2 MainLoop drawscreen goto MainLoop And this will not work: rem smartbranching on rem init setup scorecolor = $0E missile0height = 0 missile1height = 1 MainLoop drawscreen goto MainLoop But this works just fine: rem smartbranching on rem init setup scorecolor = $0E missile0height = 2 missile1height = 2 MainLoop drawscreen goto MainLoop This seems like something worth fixing or at least documenting...I'm assuming it isn't documented, of course Anyway, moral of story: Make sure to define missile0height and missile1height as greater than one! Edited August 23, 2005 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted August 23, 2005 Share Posted August 23, 2005 (edited) the following code gives me screen flicker in the new version DB: 1 rem smartbranching on 5 dim shipx=x dim shipy=y dim ship2x=a dim ship2y=b 6 dim missilex=c dim missiley=d dim life=l 10 shipx=45: shipy=82 46 player1: %00111110 %01000001 %00100010 %00010100 %00001000 end 50 pfhline 1 1 30 60 drawscreen 70 COLUP1=120 : COLUPF=120:player1x=shipx: player1y=shipy 80 if joy0left then shipx=shipx-1 90 if joy0right then shipx=shipx+1 goto 60 I erased most of my code from my game but this is the basic. Edited August 23, 2005 by Dan Iacovelli Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted August 23, 2005 Share Posted August 23, 2005 Just to be clear, you can't do this, correct? if FrameCounter & 7 = 0 then Temp = 0 I get all kinds of weird errors when I do this. Instead, I have to do this: Temp2 = FrameCounter & 7 if Temp2 = 0 then Temp = 0 Is that correct? Quote Link to comment Share on other sites More sharing options...
+batari Posted August 23, 2005 Author Share Posted August 23, 2005 (edited) I think I've found the problem: if missile0height and missile1height are zero or one (edit), the kernel breaks. Zero also happens to be the default value of those two variables, so if you do not define them explicitly, the kernel will break. This will not work: rem smartbranching on rem init setup scorecolor = $0E rem missile0height = 2 rem missile1height = 2 MainLoop drawscreen goto MainLoop And this will not work: rem smartbranching on rem init setup scorecolor = $0E missile0height = 0 missile1height = 1 MainLoop drawscreen goto MainLoop But this works just fine: rem smartbranching on rem init setup scorecolor = $0E missile0height = 2 missile1height = 2 MainLoop drawscreen goto MainLoop This seems like something worth fixing or at least documenting...I'm assuming it isn't documented, of course Anyway, moral of story: Make sure to define missile0height and missile1height as greater than one! 916937[/snapback] Ouch! That's a pretty bad bug... but I know why it's happening - it was my attempt to save cycles in the kernel. I have fixed it, and I should probably post a quick update because this will break a lot of games. Until then, you can fix it yourself by editing the std_kernel.asm file, and changing the two "dex" instructions near the top of the file (lines 9 and 11) to "inx" and changing the adc #3 on line 170 to adc #4 I've started looking into the problem with bit access that vdub_bobby pointed out, and yes, I have confirmed this bug and I'm looking into the cause. Edited August 23, 2005 by batari Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted August 23, 2005 Share Posted August 23, 2005 Ouch! That's a pretty bad bug... but I know why it's happening - it was my attempt to save cycles in the kernel. I have fixed it, and I should probably post a quick update because this will break a lot of games. Until then, you can fix it yourself by editing the std_kernel.asm file, and changing the two "dex" instructions near the top of the file (lines 9 and 11) to "inx" I've started looking into the problem with bit access that vdub_bobby pointed out, and yes, I have confirmed this bug and I'm looking into the cause. Now that's service! Thanks, batari Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 23, 2005 Share Posted August 23, 2005 (edited) Just to be clear, you can't do this, correct? if FrameCounter & 7 = 0 then Temp = 0 I get all kinds of weird errors when I do this. Instead, I have to do this: Temp2 = FrameCounter & 7 if Temp2 = 0 then Temp = 0 Is that correct? 917034[/snapback] Shouldn't that be two && not just one &? Oh, you're doing something different. Edited August 23, 2005 by Random Terrain Quote Link to comment Share on other sites More sharing options...
supercat Posted August 23, 2005 Share Posted August 23, 2005 I'll have to download bB and start playing with it. Seems very promising. Biggest limitation I can see at this point is that games don't get much memory for their own use even when using a custom kernel (though I suppose it should be possible to reclaim the memory for the playfield). Did you see my earlier suggestion (a few weeks ago) about display lists? Did you understand it? One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games. Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM. The RAM data are then stored consecutively to fill in the inserts. Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254]. Don't know if such a kernel would be worth the effort, but it might be somewhat cute. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 23, 2005 Author Share Posted August 23, 2005 Did you see my earlier suggestion (a few weeks ago) about display lists? Did you understand it? I must have missed this - it doesn't ring a bell. One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games. Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM. The RAM data are then stored consecutively to fill in the inserts. Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254]. Don't know if such a kernel would be worth the effort, but it might be somewhat cute. 917300[/snapback] I've thought about this - it would be interesting to add a print statement, but of course the statement would do nothing unless you were using the stellar-track type kernel. I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard. Quote Link to comment Share on other sites More sharing options...
supercat Posted August 24, 2005 Share Posted August 24, 2005 I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard. The display-list concept wasn't for character-based games. That's a new idea I just had yesterday when the fact came up that Robinett Basic could do "PRINT" and Batari Basic can't. The display list concept would allow the user to supply a list giving the height and source address for each playfield "row". Instead of having eleven rows of playfield data that are sixteen pixels high, a programmer could have e.g. one that's 16 high, four that are eight high, one that is 80 high, another four that are eight high, and one that's 16 high (e.g. for a tank-blasting game where the players sit at the top and bottom of the screen behind "shields), or one could have a row that's 16 high, followed by nine that are 8 high, followed by one that's 96 high (e.g. for a "Breakout"-style game). My preferred implementation would probably be to have the display list contain pairs of numbers where the first item in each pair would be the number of double-lines minus one, and the second would be the RAM address where the data should be found. Specifying the RAM address may or may not be worthwhile; it would allow some extra versatility if non-active rows of display data could be duplicated, and it would allow some interesting special effects, but it might also cause confusion. Having a means of specifying ROM addresses as well might be interesting, but would probably complicate things too much to be useful in-kernel. I haven't looked at your kernel code, but I would think it should be possible to handle display lists if you used a striped playfield, and if you unrolled one level of looping (so that the first line-pair of a display-list item would use special code), meaning the minimum display-list-item size would be two line-pairs. A game like "Man Goes Down" (but without the pretty colored fruits) could be implemented either by having many display lists in ROM and switching between them, or by putting the display list in RAM. If your kernel is already using four temp locations to hold the current row of playfield data (I would guess that it probably must) the only extra RAM required for display-list support would be two bytes to hold the display-list pointer. If you can spare that space, adding display lists could greatly improve the versatility of what already seems to be a very promising platform. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 24, 2005 Author Share Posted August 24, 2005 I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard. The display-list concept wasn't for character-based games. That's a new idea I just had yesterday when the fact came up that Robinett Basic could do "PRINT" and Batari Basic can't. The display list concept would allow the user to supply a list giving the height and source address for each playfield "row". Instead of having eleven rows of playfield data that are sixteen pixels high, a programmer could have e.g. one that's 16 high, four that are eight high, one that is 80 high, another four that are eight high, and one that's 16 high (e.g. for a tank-blasting game where the players sit at the top and bottom of the screen behind "shields), or one could have a row that's 16 high, followed by nine that are 8 high, followed by one that's 96 high (e.g. for a "Breakout"-style game). My preferred implementation would probably be to have the display list contain pairs of numbers where the first item in each pair would be the number of double-lines minus one, and the second would be the RAM address where the data should be found. Specifying the RAM address may or may not be worthwhile; it would allow some extra versatility if non-active rows of display data could be duplicated, and it would allow some interesting special effects, but it might also cause confusion. Having a means of specifying ROM addresses as well might be interesting, but would probably complicate things too much to be useful in-kernel. I haven't looked at your kernel code, but I would think it should be possible to handle display lists if you used a striped playfield, and if you unrolled one level of looping (so that the first line-pair of a display-list item would use special code), meaning the minimum display-list-item size would be two line-pairs. A game like "Man Goes Down" (but without the pretty colored fruits) could be implemented either by having many display lists in ROM and switching between them, or by putting the display list in RAM. If your kernel is already using four temp locations to hold the current row of playfield data (I would guess that it probably must) the only extra RAM required for display-list support would be two bytes to hold the display-list pointer. If you can spare that space, adding display lists could greatly improve the versatility of what already seems to be a very promising platform. 917363[/snapback] I remember your post now. That could be done without too much trouble because of the way the code is written. The blank line just loads a counter with 8, so instead this could load from an indexed table or something. But since there is no scanline counter in the kernel, the compiler would need to ensure that the total sum of the display list values is correct. I'd just need to find a couple of cycles, really. The display list will not fit in RAM, however, it would have to be hard-coded into ROM at compile time. Maybe I'll do this soon - it should be easy enough. But yeah, the display list concept could also work with printed characters on screen. Quote Link to comment Share on other sites More sharing options...
+batari Posted August 24, 2005 Author Share Posted August 24, 2005 Just testing out the fixed point math... Just by making this simple example using inertia, I found that 4.4 types aren't working quite right so I used 8.8 for everything. It looks like these basically work. By playing around, though, I can see room for improvement the fixed point math implementation. Also, include isn't working either... if you use include, your program won't work at all I fixed this - like all bugs so far, it was something simple/stupid. If you need to include something, use an includes file for now. inertia.bas inertia.bas.bin Quote Link to comment Share on other sites More sharing options...
potatohead Posted August 24, 2005 Share Posted August 24, 2005 I'll have to download bB and start playing with it. Seems very promising. Biggest limitation I can see at this point is that games don't get much memory for their own use even when using a custom kernel (though I suppose it should be possible to reclaim the memory for the playfield). Did you see my earlier suggestion (a few weeks ago) about display lists? Did you understand it? One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games. Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM. The RAM data are then stored consecutively to fill in the inserts. Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254]. Don't know if such a kernel would be worth the effort, but it might be somewhat cute. 917300[/snapback] I'm liking this idea for a more flexible playfield. You can claim the playfield memory this way: dim extravariable=playfield+44 {45, 46, 47} One question I had was this: Assuming extravariable has been defined as shown above, is extravariable[index] now legal? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.