+batari Posted August 8, 2011 Author Share Posted August 8, 2011 I think I've read somewhere here where it was being talked about bB.v11d causing compile issues and that using bB.v11c resolved them for now. This reminds me - did v.11d fix your compile issues you had earlier with extra statements being added to if-thens? I had to guess at what the issue might be and I changed two things in keywords.c, but one of them caused issues with other people's code, so I've reverted that one. If your issue is still there, I may just revert both. 2 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted August 8, 2011 Share Posted August 8, 2011 Actually it did, sorry I forgot to get back to you on that one Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 9, 2011 Share Posted August 9, 2011 (edited) So try what I've attached below, bB.v11c + updated DPCplus.arm + custom2.bin update. No Visual Batari included, just replace your existing Atari2600\bB folder with the contents of this one. Thanks, that works. No more crashing, but the score bounces when the screen is scrolled. One of the files in link below used to get rid of the bounce: http://www.atariage.com/forums/topic/133529-updated-bb-files-to-download/ I'm just not sure if we can use any of those files anymore since bB has changed. Here's a related post that you might want to check out: http://www.atariage.com/forums/topic/73160-bug-report-thread/page__st__125__p__1517363#entry1517363 After looking back, it seems that std_kernel.asm is what we need to look at for fixing the score jitter/bounce. It was fixed at one time, but now the latest version of std_kernel.asm seems to be missing the score jitter fix. I compared the std_kernel.asm files using WinMerge, but I don't know enough about asm to see where the problem might be. Edited August 9, 2011 by Random Terrain Quote Link to comment Share on other sites More sharing options...
+batari Posted August 9, 2011 Author Share Posted August 9, 2011 Here is a new 2600basic.exe with the troublesome change reverted. Please let me know if this still fixes issues while not crashing with vbB. If it does work, if you guys want to create another archive with all the latest bB and vbB files, that will be good. What I want to do is create an automated Windows installer including all of these files as admittedly the current way to get a working, up-to-date version of bB running is a bit clunky. bb11d_2600basic.zip Quote Link to comment Share on other sites More sharing options...
jwierer Posted August 9, 2011 Share Posted August 9, 2011 That fixes the problem I had with bB crashing code using colons. Thanks, Jeff Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 9, 2011 Share Posted August 9, 2011 After looking back, it seems that std_kernel.asm is what we need to look at for fixing the score jitter/bounce. It was fixed at one time, but now the latest version of std_kernel.asm seems to be missing the score jitter fix. I compared the std_kernel.asm files using WinMerge, but I don't know enough about asm to see where the problem might be. Here's an example of the score bounce: scrolling_test_2011y_08m_09d_0251t.bin scrolling_test_2011y_08m_09d_0251t.bas Quote Link to comment Share on other sites More sharing options...
+Philsan Posted August 9, 2011 Share Posted August 9, 2011 I have to change score color often in my program but if I use scorecolors: $0A $0A $0A $0A $0A $0A $0A $0A end more than once the program doesn't compile. * Would it be possible to include support for collisions between missile0/1 and a virtual sprite? * If we aren't using the playfield pixels in our program, is there a way to recover that memory for other uses? * I noticed that when we use the pfscore option, the pfscore2 bits are mirrored on either side of the score. Not sure if this is a bug or not. Will it be possible to use pfscore1 as before? Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted August 22, 2011 Share Posted August 22, 2011 Hey Batari, This is huge, I've just skimmed it, but I need to read it over complete. I've been meaning to re-write my game Atomic Meltdown, and from the looks of this, I now can and add all the features that weren't there before. I need to refresh myself on my BatariBasic!!! -Disjaukifa Quote Link to comment Share on other sites More sharing options...
disjaukifa Posted August 22, 2011 Share Posted August 22, 2011 Here is a new 2600basic.exe with the troublesome change reverted. Please let me know if this still fixes issues while not crashing with vbB. If it does work, if you guys want to create another archive with all the latest bB and vbB files, that will be good. What I want to do is create an automated Windows installer including all of these files as admittedly the current way to get a working, up-to-date version of bB running is a bit clunky. Hey Batari, Can we get a Mac OS X build of this? Thanks Disjaukifa Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted October 30, 2011 Share Posted October 30, 2011 Any idea of when pfread will be implemented? I could really use that. pfscroll would be nice too, but I'd love to have pfread. Is it harder to program than pfpixel? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 19, 2011 Share Posted December 19, 2011 pfread is also my workaround for using the extra space on the Melody board. I heard we could eventually use more of the storage space on the Melody, but only for graphics. If pfread becomes available again I can simply pfread playfield data stored in that extra space and throw it into the stack. Quote Link to comment Share on other sites More sharing options...
jbs30000 Posted December 20, 2011 Share Posted December 20, 2011 Well, if anybody knows the read addresses for the playfield then we could make our own pfread routines as a temporary measure until an official routine is made. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted December 20, 2011 Share Posted December 20, 2011 Well, if anybody knows the read addresses for the playfield then we could make our own pfread routines as a temporary measure until an official routine is made. The DPC+ Demo seems to have a clue in DPCPlus.h. I don't have enough assembly knowledge to see how it's implemented in DPCPlus.asm. http://www.atariage.com/forums/topic/163495-harmony-dpc-programming/ ;---------------------------------------- ; Data Fetcher ;---------------------------------------- ; There are 8 Data Fetchers which are used to access data stored in the Display ; Data bank. Before using, you must point the Data Fetcher at the data to read ; via DFxLOW and DFxHI. After each read the Data Fetcher will update to point ; to the next byte of data to return. ; ; psuedo code* to point Data Fetcher 1 to the color data ; lda #<(ColorDataPosition - HowFarDownScreen) ; sta DF1LOW ; lda #>(ColorDataPosition - HowFarDownScreen) ; sta DF1HI ; .... ; then in the kernel read the Data Fetcher and update the color, takes 7 cycles ; LDA DF1DATA ; STA COLUP0 ; ; * see DPCplus.asm for actual code ;---------------------------------------- DF0DATA DS 1 ; $08 DF1DATA DS 1 ; $09 DF2DATA DS 1 ; $0A DF3DATA DS 1 ; $0B DF4DATA DS 1 ; $0C DF5DATA DS 1 ; $0D DF6DATA DS 1 ; $0E DF7DATA DS 1 ; $0F Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted June 8, 2012 Share Posted June 8, 2012 Is the msdpc.bas still working for people? Is it time for another semi official release of bB with all of the random fixes already in there? I get this: Compile started at 6/8/2012 9:01:50 AM Compiling C:\bB11\msdpc.bas DASM V2.20.07, Macro Assembler (C)1988-2003 free ram: 7 $1ae1 bytes of ROM space left in bank 1 --> HMdiv 1a41 bytes of ROM space left in bank 2 bytes of ROM space left in bank 3 bytes of ROM space left in bank 4 bytes of ROM space left in bank 5 bytes of ROM space left in bank 6 $d1a0 bytes of ROM space left in graphics bank free ram: 7 $1ae1 854 bytes of ROM space left in bank 1 2960 bytes of ROM space left in bank 2 3923 bytes of ROM space left in bank 3 3923 bytes of ROM space left in bank 4 3923 bytes of ROM space left in bank 5 3923 bytes of ROM space left in bank 6 $d1a0 3329 bytes of ROM space left in graphics bank free ram: 7 2960 bytes of ROM space left in bank 2 3923 bytes of ROM space left in bank 3 3923 bytes of ROM space left in bank 4 3923 bytes of ROM space left in bank 5 3923 bytes of ROM space left in bank 6 $d1a0 3329 bytes of ROM space left in graphics bank free ram: 7 2960 bytes of ROM space left in bank 2 3923 bytes of ROM space left in bank 3 3923 bytes of ROM space left in bank 4 3923 bytes of ROM space left in bank 5 3923 bytes of ROM space left in bank 6 $d1a0 3329 bytes of ROM space left in graphics bank --- Unresolved Symbol List Fatal assembly error: Source is not resolvable. Errors were encountered during assembly. Quote Link to comment Share on other sites More sharing options...
Grebnedlog Posted August 28, 2012 Share Posted August 28, 2012 Hi! I have a bug report about missile color and a question regarding collision detection for bB v1.1d. I'm playing around with the missiles now and there's no way to control the missile color. I've added COLUM0 and COLUM1 variables to (sort of) control missile color. The colors won't work while the missile is on the same scanline as a player but it should work fine otherwise. This patch has three files: DPCstartup.asm, DPCplusbB.h and custom/bin/custom2.bin. Unzip into the includes folder. Some of this isn't tested very well so let me know if there are any issues. I've noticed that the missile default color works as expected for COLUM1 and COLUM0 on the scanlines that come after their respective sprites. But for COLUM0, the colors will default to 0 (black) on non-player0 scanlines that come before it. I've included a small program to demonstrate this (move joystick up and down to change the vertical position of the sprites. DPCMissileColor.bas.bin DPCMissileColor.bas Here is the latest build. It fixes many of the issues that have been reported since the last release, and adds some requested features in DPC+. I added: ... Collision detection: * Pixel-perfect collision(player#,player#) where # is 0-9, for any two real or virtual player sprites (doesn't support NUSIZ changes yet, sorry.) * A kernel_option controls an in-kernel read of a standard hardware collision register (example: set kernel_options collision(player1,playfield) will return the y-coordinate where the first such collision occurs, so you can later figure out what sprite it was.) Value is returned in temp4 after a drawscreen. What value is returned in temp4 if two virtual sprites are colliding with the playfield after the same drawscreen? This happens fairly often in a program I am trying to write, and whenever it does, temp4 doesn't seem to return any of the virtual players y-coordinates (nor "0", nor "255"). I would try to trace the address myself, but unfortunately I am a novice at Stella Debugger. Is it possible to write a post-collision statement in batari basic that accounts when two or more virtual sprites are colliding with the background simultaneously (i.e. "if temp4 = [some value] then..." Thanks! Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted November 17, 2012 Share Posted November 17, 2012 Is post #254 the latest version now? http://www.atariage.com/forums/topic/176401-next-version-of-bb/page__st__250#entry2344745 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted November 17, 2012 Share Posted November 17, 2012 My searches reveal no newer version. Maybe we can bribe batari with commons for Harmony carts. Maybe 30 for status updates and 100 for single letter revisions 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted November 28, 2012 Share Posted November 28, 2012 I started off around two years ago when Batari had just released 1.1 so I have no experience with the original bB, or what is different. That said, I think I see something wrong. That template Scumsoft has in that thread, and that VBB uses, shows: ; ***************************************************** ; * BANK 6 ; ***************************************************** bank 6 rem temp1 = temp1 not required here as this bank is for graphics only rem However I have placed my TitleScreen here with no apparent consequences But Bank 6 is a full empty bank that I am using like Banks 2 thru 5! (Bank 1 is almost full with Basic kernel) There seems to be a bank AFTER that for graphics. Am I crazy? 4K x 6 banks is 24K plus 4K graphics 28K ??? 4K x 7 banks is 28K plus 4K graphics = 32K Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 1, 2012 Share Posted December 1, 2012 6 x 4k + graphics 4k + ARM bankswitching code = 32K ...is how I understand it. Quote Link to comment Share on other sites More sharing options...
iesposta Posted December 1, 2012 Share Posted December 1, 2012 6 x 4k + graphics 4k + ARM bankswitching code = 32K ...is how I understand it. You are right. It is just a Visual batari Basic template error. Sorry, twice now I've been confused and thought an error was with basic when it really was in the visual basic editor. See the above template says bank 6 is for graphics only, but the compiler output shows a full bank: Quote Link to comment Share on other sites More sharing options...
jwierer Posted December 1, 2012 Share Posted December 1, 2012 The compiler, not vbB, is generating that output. Quote Link to comment Share on other sites More sharing options...
iesposta Posted December 1, 2012 Share Posted December 1, 2012 See also Post 268, this thread. In vbB, choose New Item, DPC+ Kernel, and open the project. You get a template. It ends with: ; ***************************************************** ; * BANK 6 ; ***************************************************** bank 6 rem temp1 = temp1 not required here as this bank is for graphics only rem However I have placed my TitleScreen here with no apparent consequences I am pointing out this is wrong. temp1 = temp1 is required here, and it is a full bank. It is not just for graphics only. The graphics bank is after bank 6's 4K bank. Quote Link to comment Share on other sites More sharing options...
jwierer Posted December 1, 2012 Share Posted December 1, 2012 Ok so I just need to un-rem that statement. Thanks, Jeff Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 6, 2013 Share Posted March 6, 2013 DPC+ bug report... the 1.1d version of the DPCplus_kernel has a timing error if you don't use "set kernel_options collision...". lda #<DF3FRACDATA ;53 sta PF1 ; 56 ifnconst DPC_kernel_options ;sleep 8 ; timing is off - results in a garbled screen sleep 5 ; this is better else bit DPC_kernel_options if (DPC_kernel_options > $3F) Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 17, 2013 Share Posted March 17, 2013 Another 1.1d DPC+ bug report... the COLUM0 feature only works when missile0 is below player0's y position, not above. This is a problem when the bB coder changes the player0 y position to be off-screen. To fix this it takes changes to both the main.c ARM code and the DPC+ 6507 kernel... ; fix for DPCplus_kernel.asm ; display COLORs from top of screen, not the top of the sprite... ; sec ; not needed anymore lda #<(P0COLOR-1) ; sbc player0y sta DF0LOW sta temp2 lda #>(P0COLOR-1) ; sbc #0 sta DF0HI // change main.c... // copy player color list to exact position in color data // instead of just the top of the data area... /* my_memcpy(queue+(dfhigh(0)<<+dflow(0), flashdata+(RIOT[player0color+1]<<+RIOT[player0color], 0, RIOT[player0height]); */ my_memcpy(queue+(dfhigh(0)<<+dflow(0)+RIOT[player0y], flashdata+(RIOT[player0color+1]<<+RIOT[player0color], 0, RIOT[player0height]); Tested and working fine. 1 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.