+Random Terrain Posted March 7, 2011 Share Posted March 7, 2011 Any more bugs? Have any of these old bugs mentioned on the bB page been fixed yet? playfield: <off> <on> (pixels) end Because of a bug in the preprocessor, <off> and <on> do not work at this time, but when the problem is fixed in a future update of bB, they will be optional and allow you to change the off/on symbols for the playfield pixels. The kernel will automatically detect if two or more sprites are overlapping and will automatically flicker them, so you don't need to do this yourself. It should be noted that the flicker algorithm isn't perfected yet. Under certain conditions, some sprites might not display correctly. This is a known bug and it's being looked at. There seems to be a bug where the top row will not be the color you selected if pfcolors is outside of your main loop. Quote Link to comment Share on other sites More sharing options...
+batari Posted March 7, 2011 Author Share Posted March 7, 2011 Fred, have you fixed the less than 312 scanlines PAL50 problem with player1colors enabled? I assume so - I added in RevEng's patch. Quote Link to comment Share on other sites More sharing options...
+batari Posted March 7, 2011 Author Share Posted March 7, 2011 playfield: <off> <on> (pixels) end Because of a bug in the preprocessor, <off> and <on> do not work at this time, but when the problem is fixed in a future update of bB, they will be optional and allow you to change the off/on symbols for the playfield pixels. Just fixed this one. The kernel will automatically detect if two or more sprites are overlapping and will automatically flicker them, so you don't need to do this yourself. It should be noted that the flicker algorithm isn't perfected yet. Under certain conditions, some sprites might not display correctly. This is a known bug and it's being looked at. I discovered a bug in the flicker algorithm when adding it to DPC+. It is a very simple fix so I added it to the regular multisprite kernel. There seems to be a bug where the top row will not be the color you selected if pfcolors is outside of your main loop. I'll have to look into this one, as I think it was actually designed to work this way (so not really a bug) but if having to maintain a pfcolors definition in your main loop is a pain, I can look into changing this. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 7, 2011 Share Posted March 7, 2011 There seems to be a bug where the top row will not be the color you selected if pfcolors is outside of your main loop. I'll have to look into this one, as I think it was actually designed to work this way (so not really a bug) but if having to maintain a pfcolors definition in your main loop is a pain, I can look into changing this. If it turns out to be a pain to change, I can delete the bug stuff and just tell people it must be part of the main loop. Doesn't really matter to me unless the defining of colors slows things down. Quote Link to comment Share on other sites More sharing options...
+grafixbmp Posted March 7, 2011 Share Posted March 7, 2011 Does this new DPC+ kernel allow for individual sprite NUSIZ settings? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted March 7, 2011 Share Posted March 7, 2011 Does this new DPC+ kernel allow for individual sprite NUSIZ settings? It says this in batari's blog: Each sprite allows its REFPx and NUSIZx set independently Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 7, 2011 Share Posted March 7, 2011 (edited) Sounds like Batari is resolving issues overall due to the extra DPC code. Everyone wins no matter what kernel is used! Joy! I wonder if Pitfall II vertical scrolling can be duplicated in bB.. hmmmn.. Edited March 7, 2011 by theloon 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted March 7, 2011 Author Share Posted March 7, 2011 Does this new DPC+ kernel allow for individual sprite NUSIZ settings? It says this in batari's blog: Each sprite allows its REFPx and NUSIZx set independently Yes, there are 9 variables: _NUSIZ1, and NUSIZ2-NUSIZ9 that allow NUSIZ settings, and the REFPx setting is passed in bit 3 of these variables. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 8, 2011 Share Posted March 8, 2011 Fred, have you fixed the less than 312 scanlines PAL50 problem with player1colors enabled? I assume so - I added in RevEng's patch. The problem is still present. I attach my program so you can do tests: TestPAL50Plr1clrsBug.zip I have added "set tv pal" to your DPC+ test program but nothing changes. Do you plan to add PAL 50 to this kernel? BTW, I too now have to add spaces before and after "=" in "sdata musicData = x". Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 8, 2011 Share Posted March 8, 2011 The fix I applied for the PAL scanline issue just added 1 to the vblank_time when it was 57, making it 58. (The cleaner solution would be to just make it 58 for pal in the first place, but I wanted to avoid changing the bB binaries.) A quick way to reproduce the bug is with the following code... set tv pal set kernel_options player1colors dim frame=a scorecolor=$0f gameloop frame=frame+1 frame=frame&31 rem ** burn a variable amount of time for t=0 to frame z=z next drawscreen goto gameloop Quote Link to comment Share on other sites More sharing options...
+batari Posted March 8, 2011 Author Share Posted March 8, 2011 The fix is not in the version I posted but has been added to the code for the next release. 2 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 8, 2011 Share Posted March 8, 2011 (edited) The fix is not in the version I posted but has been added to the code for the next release. Thank you. And regarding I have added "set tv pal" to your DPC+ test program but nothing changes. Do you plan to add PAL 50 to this kernel? Edited March 8, 2011 by Philsan Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted April 7, 2011 Share Posted April 7, 2011 I'm in the planning phase of my next game and I have a few questions about the new release: By "any resolution" of the playfield, does this mean a max of 32 rows? Also, will future extra variables (non a-z) be determined by the playfield resolution? For example, if you use a resolution of 24 rows would you get 32 extra variables as in the Superchip? Thanks! Quote Link to comment Share on other sites More sharing options...
+batari Posted April 7, 2011 Author Share Posted April 7, 2011 I'm in the planning phase of my next game and I have a few questions about the new release: By "any resolution" of the playfield, does this mean a max of 32 rows? No, the maximum is as many scanlines as the kernel displays (I'm not sure offhand what this is, but it's somewhere around 180-190.) This is achieved by setting DFxFRACINC to 255. Also, "any resolution" is not entirely true. I will work up a chart of values of DF#FRACINC that "work" and show approximately what resolution they provide.Also, will future extra variables (non a-z) be determined by the playfield resolution? For example, if you use a resolution of 24 rows would you get 32 extra variables as in the Superchip? Thanks! No, you always have the same 26 variables no matter what you do with the playfield. Extra variables in DPC+ are only available indirectly by using the stack feature. Quote Link to comment Share on other sites More sharing options...
+batari Posted April 8, 2011 Author Share Posted April 8, 2011 (edited) As promised, here is a table of some playfield values that should work in the DPC+ kernel. These aren't the only values that work, or the only combination of values that work, so I encourage experimentation if you're doing something different (such as not aligning color changes to playfield rows.) The value stored to the DF0FRACINC-DF3FRACINC registers determines how many scanlines it takes to change a playfield row. When using these registers, you shouldn't be thinking about the number of rows in the playfield but rather approximately how many scanlines tall each playfield row is. Currently the kernel displays 176 scanlines, but this is subject to change. The first row in the table below is the number of scanlines in each row. The next is the approximate resolution (rounded up, and may change.) Next is DF(0-3)FRACINC, which control the number of scanlines in each row of each playfield swath. Last is the PF color value (DF4FRACINC). Complicating matters somewhat is that color updates occur half as often so not all playfield values can have colors that work nicely with them. If this is the case, a dash is shown in place of DF4FRACINC. A "*" in the resolution column means that the bottom row isn't full height. Also, the values for DF4FRACINC may also be stored to DF6FRACINC if you wish to match the background colors with the playfield rows. Scanlines Resolution DF(0-3)FRACINC DF4FRACINC 1 176 255 -- see below - 2 88 128 255 --- see below 3 59 * 86 - 4 44 64 128 5 36 * 52 - 6 30 * 43 86 7 26 * 37 - 8 22 32 64 9 20 * 29 - 10 18 * 26 52 11 16 24 - 12 15 * 22 44 13 14 * 20 - 14 13 * 19 38 15 12 * 18 - 16 11 16 32 18 10 * 15 30 19 10 * 14 - 20 9 * 13 26 22 8 12 24 24 8 * 11 22 26 7 * 10 20 29 7 * 9 - 32 6 * 8 16 37 5 * 7 - 44 4 6 12 52 4 * 5 10 64 3 * 4 8 86 3 * 3 6 128 2 * 2 4 176 1 1 or 0 1 or 0 Note: storing 255 in these registers doesn't work quite right yet. More about this another time. Edited April 8, 2011 by batari Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 8, 2011 Share Posted April 8, 2011 As promised, here is a table of some playfield values that should work in the DPC+ kernel. Thanks. Will you be posting bB 1.1 beta build release C in your blog so we'll have the best, least buggy version? Quote Link to comment Share on other sites More sharing options...
Dan Iacovelli Posted April 13, 2011 Share Posted April 13, 2011 just curious, are you going to post the finished release in the forum or in the blog Quote Link to comment Share on other sites More sharing options...
+batari Posted April 14, 2011 Author Share Posted April 14, 2011 I'm hoping to get the playfield functions done before posting the next version. I'll probably post it to the blog again. When I am satisfied that most of the bugs are gone, I will upload everything to bataribasic.com. 3 Quote Link to comment Share on other sites More sharing options...
Master_Programmer Posted April 20, 2011 Share Posted April 20, 2011 (edited) EDIT i've NEVER been able to get ANY multisprite kernels to work for me. Edited April 21, 2011 by Master_Programmer Quote Link to comment Share on other sites More sharing options...
Master_Programmer Posted April 20, 2011 Share Posted April 20, 2011 (edited) Nevermind. i'm an idiot. i put down "DCPplus" instead of "DPCplus" EDIT: New error. see above post. Edited April 20, 2011 by Master_Programmer Quote Link to comment Share on other sites More sharing options...
+batari Posted April 20, 2011 Author Share Posted April 20, 2011 The problem likely lies in the code below: set romsize 32kSC includesfile DPCplus.inc You can't combine Superchip and DPC+, and DPC+ uses its own kernel. All you need is: set kernel DPC+ The includesfile will automatically be used and the binary automatically set to 32k. Quote Link to comment Share on other sites More sharing options...
Master_Programmer Posted April 21, 2011 Share Posted April 21, 2011 The problem likely lies in the code below: set romsize 32kSC includesfile DPCplus.inc You can't combine Superchip and DPC+, and DPC+ uses its own kernel. All you need is: set kernel DPC+ The includesfile will automatically be used and the binary automatically set to 32k. Thank you SO MUCH!!! i'm gonna remove, and finish the project code i posted....as i meant to make it a secret project.... DX Quote Link to comment Share on other sites More sharing options...
Master_Programmer Posted April 21, 2011 Share Posted April 21, 2011 (edited) C:\bb>2600bas PSYCHO.BASbatari Basic v1.01 ©2005-2007 User-defined DPCplus.inc found in the current directory User-defined banksw.asm found in the current directory 2600 Basic compilation complete. User-defined DPCplusheader.asm found in current directory User-defined score_graphics.asm found in current directory User-defined DPCstartup.asm found in current directory User-defined DPCplus_kernel.asm found in current directory User-defined DPC_waveforms.asm found in current directory User-defined DPC_ORG.asm found in current directory User-defined banksw.asm found in current directory User-defined DPCplusfooter.asm found in current directory User-defined DPC_frequencies.h found in current directory DASM V2.20.07, Macro Assembler ©1988-2003 free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank --- Unresolved Symbol List COLUP2 0000 ???? (R ) COLUP3 0000 ???? (R ) COLUP4 0000 ???? (R ) COLUP5 0000 ???? (R ) begin_bscode dff4 ???? start_bank6 bff4 ???? (R ) bscode_length 0000 ???? (R ) BS_return e000 ???? (R ) DPC_graphics_end dff4 ???? (R ) BS_jsr e00e ???? (R ) Fatal assembly error: Source is not resolvable. C:\bb> i made ONLY the changes you told me to make. I'll try removing the "Smartbranching" option, but i doubt that'll help from the look of the error Edited April 21, 2011 by Master_Programmer Quote Link to comment Share on other sites More sharing options...
+batari Posted April 26, 2011 Author Share Posted April 26, 2011 C:\bb>2600bas PSYCHO.BASbatari Basic v1.01 ©2005-2007 User-defined DPCplus.inc found in the current directory User-defined banksw.asm found in the current directory 2600 Basic compilation complete. User-defined DPCplusheader.asm found in current directory User-defined score_graphics.asm found in current directory User-defined DPCstartup.asm found in current directory User-defined DPCplus_kernel.asm found in current directory User-defined DPC_waveforms.asm found in current directory User-defined DPC_ORG.asm found in current directory User-defined banksw.asm found in current directory User-defined DPCplusfooter.asm found in current directory User-defined DPC_frequencies.h found in current directory DASM V2.20.07, Macro Assembler ©1988-2003 free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank free ram: 7 $1ae1 bytes of ROM space left in bank 6 $d180 bytes of ROM space left in graphics bank --- Unresolved Symbol List COLUP2 0000 ???? (R ) COLUP3 0000 ???? (R ) COLUP4 0000 ???? (R ) COLUP5 0000 ???? (R ) begin_bscode dff4 ???? start_bank6 bff4 ???? (R ) bscode_length 0000 ???? (R ) BS_return e000 ???? (R ) DPC_graphics_end dff4 ???? (R ) BS_jsr e00e ???? (R ) Fatal assembly error: Source is not resolvable. C:\bb> i made ONLY the changes you told me to make. I'll try removing the "Smartbranching" option, but i doubt that'll help from the look of the error Based on your errors above, it appears you have all of the files from the includes folder copied into the current folder. The proper way to set up bB is to leave the files alone, then set the bB environment variable to point to the path where bB executables are, and the PATH environment variable should also include this path. For example, if your bB executables are in c:\atari2600\bB: set bB=c:\atari2600\bB set path=%path%;%bB% And, use a separate folder for your .bas files (for example, c:\atari2600\mygame) Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted April 26, 2011 Share Posted April 26, 2011 (edited) Maybe this should go in the bugs thread? (1) "if switchreset then reboot" doesn't work, because the parser treats "reboot" as a label instead of as a command. The following works as an alternative: if !switchreset then goto loop rem - or just "if !switchreset then loop" if "loop" is near enough or smartbranching is on reboot (2) "if switchreset" and "if !switchreset" could be shortened by 2 bytes: ; currently compiles like this: lda #1 bit SWCHB ; then checks with BNE or BEQ ; this saves 2 bytes: lsr SWCHB ; then check with BCC or BCS (3) If batari Basic will always set the IRQ/BRK vector the same as the RESET vector, "reboot" could also be shortened by 2 bytes: ; currently compiles like this: JMP ($FFFC) ; this saves 2 bytes: BRK (Thanks, Omegamatrix!) Michael Edited April 26, 2011 by SeaGtGruff Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.