Search the Community
Showing results for tags 'bBasic'.
-
For about a month I have been studying a little bit of Assembly through the great material gathered on the Random Terrain website. (https://www.randomterrain.com/atari-2600-memories.html#assembly_language) Although I managed to create my own kernel, several parts of it I still don't understand. And instead of spending effort with such deep learning, I researched if it was possible to simply create a kernel for batariBasic and continue programming in bB. I found this post which presents a way to use a custom kernel. With some modifications I got to this version below. It's a 2LK and I'm trying to use the same variables as bB to control the players, but this is the problem: I can't (I don't have enough knowledge) use the players pointer correctly. Could anyone clarify my ideas? Player0Draw = $A4 ; I'm not using the vars (0-47) Player1Draw = $A5 BackgroundPtr = $A6 ; $A7 .customdrawscreen custom_eat_overscan ;bB code runs during overscan. We wait for overscan to finish so the ;frame timing doesn't get screwed up. lda INTIM bmi custom_eat_overscan custom_do_vertical_sync ;just a standard vsync lda #2 sta WSYNC ;one line with VSYNC sta VSYNC ;enable VSYNC sta WSYNC ;one line with VSYNC sta WSYNC ;one line with VSYNC lda #0 sta WSYNC ;one line with VSYNC sta VSYNC ;turn off VSYNC custom_setup_vblank_timing ;use bB timing variables so it should work with both PAL and NTSC ifnconst vblank_time lda #42+128 else lda #vblank_time+128 endif sta TIM64T ; feel free to throw useful pre-kernel code in here, so long as it ; completes before vblank is over. custom_eat_vblank ;wait for vblank to complete lda INTIM bmi custom_eat_vblank lda #0 sta WSYNC sta VBLANK custom_setup_visible_timing ;my preference is to use TIM64T to ensure a full screen is drawn. lda #230 sta TIM64T ;------------------------------------------------------------------------------ ; Desenha a parte superior da tela ; 192 - 22 scanlines = 192 - (11*2) = 170 lda #$02 ; Cor cinza no PF sta COLUPF ; COR no PF lda #1 ; sta CTRLPF ; Liga o REFLECT ldx #11 UpperSection: sta WSYNC lda customPFPattern,x sta PF0 sta PF1 sta PF2 lda customPFColor,x sta COLUBK sta WSYNC dex bne UpperSection stx PF0 stx PF1 stx PF2 ; y position lda #80 adc player0height sbc player0y sta Player0Draw ;------------------------------------------------------------------------------ ;-- AREA DE JOGO ;------------------------------------------------------------------------------ ; Desenha a área de jogo ; 170 - 160 scanlines = 170 - (80*2) = 10 (base ... not implemented) ldy #80 ; Carrega o y com o tamanho da área de jogo KernelLoop: ; 15 - todal de 15 ciclos, vindos do bne KernelLoop ; Continuação da segunda linha do 2LK ; precalcula os dados usados na primeiralinha do 2LK lda player0height ; 2 17 - altura do Player0 - IMPORTANTE!! este valor deve ser altura-1 dcp Player0Draw ; 5 22 - Decrementa Player0Draw e compara com a altura bcs DoDrawGrp0 ; 2 24 - (3 25) se o Carry estiver setado, player0 está na scanline atual lda #0 ; 2 27 - caso contrário, desliga o player0 .byte $2C ; 4 31 - $2C = BIT with absolute addressing, trick that ; causes the lda (HumanPtr),y to be skipped DoDrawGrp0: ; 25 - 25 ciclos do pior caso na linha bcs DoDrawGrp0 lda (player0pointer),y ; 5 30 - carrega o formato do player0 <<----------------------------- It's not working sta WSYNC ; 3 33 - Aguarda o fim da scanline ;------------------------------------------------- ; começo da primeira linha do 2LK sta GRP0 ; 3 3 - @ 0-22, desenha o player0 efetivamente (entre os ciclos 0 e 22) lda (BackgroundPtr),y ; 5 8 - Atualizo a linha do BG sta COLUBK ; 3 11 - guardo o valor do BG no resitrador COLUPF lda (player0color),y ; 5 16 - Pega a cor do Player0 sta COLUP0 ; 3 19 - seta a cor do Player0 ; todo esse código acima precisa estar entre o ciclo 0 e 22 ; para adicionar mais alguma coisa neste scanline, é preciso liberar algo acima ; sobraram apenas 3 ciclos ... é possível ainda colocar algum padrão de PF em PF1 e PF2 ;-------------------------------------------------- ; pre calcula os dados necessáriso para a segunda linha do 2LK ; lda player1height ; 2 21 - altura do Player0 - IMPORTANTE!! este valor deve ser altura-1 ; dcp player1y ; 5 26 - Decrementa Player1Draw e compara com a altura ; bcs DoDrawGrp1 ; 2 28 - (3 18) se o Carry estiver setado, player1 está na scanline atual ; lda #0 ; 2 31 - caso contrário, use 0 para desligar o player1 ; .byte $2C ; 4 35 - $2C = BIT with absolute addressing, trick that ; causes the lda (BoxPtr),y to be skipped DoDrawGrp1: ; 28 - 28 ciclos vindo do bcs DoDrawGRP1 ; lda (player1pointer),y ; 5 32 - Carrega a aparencia do player1 sta WSYNC ; 3 35 - Aguarda o inicio de uma nova scanline ;--------------------------------------- ; inicio da segunda linha do 2LK ; sta GRP1 ; 3 3 - @0-22, desenha o player1 efetivamente (entre os ciclos 0 e 22) ; lda (player1color),y ; 5 8 - Pega a cor do Player1 ; sta COLUP1 ; 3 11 - seta a cor do Player1 ; todo o codigo acima precisa estar entre os ciclos 0 e 22. ; ainda há 11 ciclos sobrando, talvez um playfield ou ball, ou missile ; possa entrar aqui neste ponto. dey ; 2 13 - decrementa o y bne KernelLoop ; 2 15 - se não for igual a zero, pula plá pra cima ;------------------------------------------------------------------------------ ;------------------------------------------------------------------------------ ;------------------------------------------------------------------------------ sty COLUBK custom_eat_visible ;wait for the visible display to complete lda INTIM bne custom_eat_visible custom_setup_overscan_timing ifnconst overscan_time lda #35+128 else lda #overscan_time+128-3-1 endif sta TIM64T lda #%11000010 sta WSYNC sta VBLANK ;bB macro to return from a bank-switch gosub or from a regular gosub. RETURN customPFPattern .byte %11011001 .byte %11111111 .byte %11011001 .byte %11001001 .byte %11011111 .byte %11011001 .byte %11011001 .byte %11001001 .byte %01001001 .byte %01001001 .byte %01001001 .byte %01001001 .byte %11001001 .byte %00001000 .byte %00001000 .byte %11001001 .byte %11011001 customPFColor: .byte $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00, $AA, $00 Thanks in advance.
-
I am having an issue with reading if a playfield pixel is on using bBasic and the DPC+ kernel. I have a playfield that is 32x44 pixels (each 4x4). There is color banding such that each even row (starting with 0, TOP) is the same color, and each odd row (starting with 1, BOTTOM) is another color. Each playfield pixel I am interested in is 4x8, consisting of a top colored one color, and a bottom of a different color. What I am trying to do is check if either the TOP or BOTTOM of a playfield pixel is already turned on. If it is, then get another random pixel. The code bellow will eventually fill the screen, and will loop endlessly searching for an unfilled bottom playfield pixel. I have a similar subroutine for the pfpixelTOP, but when the TOP pixel is already filled in, the code below doesn’t recognize it is already filled in, and fills in the bottom anyway. What am I doing wrong for the check top and check bottom already filled pfread calls? Is there a way in Stella to debug the DPC+ ram values or bBasic (I.e. could I assign temp5 to a bBasic variable or read/display the pfpixels status var000-var127?) __mainLoop gosub __fillPlayfield ; playfield is 32 x 44 ; each pixel is 4x4 DF6FRACTION = 128 DF4FRACTION = 128 DF0FRACINC=64 DF1FRACINC=64 DF2FRACINC=64 DF3FRACINC=64 drawscreen goto __mainLoop __fillPlayfieldBottom __checkPFBottom ; get random X pixel range 0-31 temp3 = (rand & 31) __nextVert ; get random bits covering Y range ; only need 22, since each pfpixel consists of top+bottom temp5 = (rand & 31) ; outside random range for bottom 1-43 if temp5 > 21 then goto __nextVert temp5 = (temp5 * 2)+1 ; check bottom already filled if pfread(temp3,temp5) then __checkPFBottom ; check top already filled if pfread(temp3,temp5-1) then __checkPFBottom ; not already filled, so fill it pfpixel temp3 temp5 on return
-
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.
-
RevEng and I cooked up something that might be interesting. Who can figure out what you are looking at? I made the video "Blair Witch Project - Shaky Cam Style" on purpose, Trent would probably appreciate it.
-
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?