Search the Community
Showing results for tags 'bBasic'.
Found 4 results
I think that "Atari 2600 programming" subforum could be improved to keep topics better organized. Currently there's a subforum for batari Basic, while the main forum and the "2600 programming for newbies" should be focused on assembly language, but the forum descriptions don't clearly state that and many threads about basic are often posted outside the dedicated subforum. I suggest to create a separate subforum for "Assembly", move the threads currently in the main 2600 programming forums there, as well as the "programming for newbies" subforum and maybe add an equivalent one inside the "batari basic" one. When "SpiceC" will be available, a third subforum with the same structure could be added.
Goals: -> Get practice using the multisprite kernel -> Observe the flicker management algorithm for virtual sprites in action. Design: -> Implement the playfield as a dark grey checkerboard to facilitate line counting -> Use numbers for the sprite graphics to identify them on screen. -> Arrange the sprites in a tight line so side by side veritcal differences are easier to measure. -> Joy 0 moves the sprites. Up and down move virtual sprites 1 through 5 at different velocities to cause combinations of overlap. -> Joy 0 left and right moves P0, M0, M1 and the ball vertically. Implementation: multitest.txt.bin multitest.txt Lessons learned: -> M0 and M1 are drawn 1 scanline lower than all the other graphics which are aligned to the 2LK kernel line. This is not unsurprising, but may need to be considered for collision detection. -> COLUP0 must be set every frame. The kernel resets it to black during drawscreen. -> BUG? If a sprite or the ball is visible at the bottom line pair on the screen the last row of pixels is drawn for a 3rd scanline below the last PF graphics. -> With the screenheight set to 84: -----> P0's lower left corner of screen is x = 0, y = 11. -----> P1's through P5 lower left corner of screen is x = 8, y = 8. -----> For M0, M1 the lower left corner is x = 1, y = 1, but M0 and M1 droop 1 scanline down. -----> Ball lower left corner is x = 1, y = 2. -> Flicker behavior is the same for pfheight values of 1, 3 and 7. -> Setting pfheight to 0 scrambles the screen as documented in the bBasic manual, but you can see when repositionings are being done. -> Virtual sprites require a horizontal gap of 2 lines to reposition without flicker. -> Flickering fails for some cases when more than 2 sprites overlap. Recommendations for improving bBasic: -> The language is fine, but the portion of the manual for the mulity sprite kernel has some unclear language. ------> What is the default value for pfheight? ------> The screenheights of 80 and 84 only work with some pfheights all 7 or less, but pfheight can be 15 and 31. What are the legal screenheights for those values. A table of legal combinations of screenheight and pfheight would make things more clear and complete. Up Next: -> TBD
For my first bBasic program I choose to stay with tradition and write a Hello World program. For non-programmers reading this, there is a bit of a tradition in programming with a new language to start with a simple program that simply outputs "Hello World" to the user. Goals: -> Minimal source code size -> Simple white text on a black background. -> no user interaction. Design: -> Use the standard bBasic kernel to render an asymetrical playfield image of "Hello World". The 32 pixel resolution requires a less than pretty font to show 10 characters, but that is a problem common to all VCS programs and not exclusive to bBasic. Implementation: helloworld.txt helloworld.txt.bin Lessons learned: -> Remarks need to be indented! -> Labels can not be followed by a colon like in DASM. Recommendations for improving bBasic: -> Looking at the .asm output from the compiler I see that the entire language library is included even if I never use most of the functions. Randomize for example and all the PF scroll functions are included in the image even though I didn't use them. I understand why this was done, but it would greatly reduce ROM consumption if unused functions were not included leaving more room for user defined code. Up Next: -> Can we do PF height animations?