+Gemintronic Posted August 12, 2013 Share Posted August 12, 2013 I just installed 3.9 and I get black flashes when running this binary. Just another data point. 1 Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted August 12, 2013 Author Share Posted August 12, 2013 I just installed 3.9 and I get black flashes when running this binary. Just another data point. I guess it's not related to Stella then. It's been a while since I've looked at it, but I can do a review of the code and see if there are any obvious errors. Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted August 12, 2013 Author Share Posted August 12, 2013 I can't seem to replicate the problem now on 3.8.1 or 3.9, it's working fine on both. The only obvious potential problem I see is the number of lines I used in the playfield. According to the original chart posted by batari, setting DF(0-3)FRACINC to 255 should provide 176 lines of playfield resolution and I have 175 defined. Maybe that's the problem? This version simply adds one line of playfield resolution to the bottom. Unfortunately I can't really troubleshoot this without being able to replicate the problem. dpcgame7.bin dpcgame7.txt Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 12, 2013 Share Posted August 12, 2013 That doesn't seem to help, but compiling with official 1.1d does. There seems to be a difference between the binaries produced here between the bB releases, but the asm produced doesn't have anything unusual, so I'm thinking it's some arm issue. [edit - definitely an arm code issue, though not an obvious one] Leave it with me guys. I'll push and pull on it tonight. 1 Quote Link to comment Share on other sites More sharing options...
+Atarius Maximus Posted August 12, 2013 Author Share Posted August 12, 2013 That doesn't seem to help, but compiling with official 1.1d does. There seems to be a difference between the binaries produced here between the bB releases, but the asm produced doesn't have anything unusual, so I'm thinking it's some arm issue. [edit - definitely an arm code issue, though not an obvious one] Leave it with me guys. I'll push and pull on it tonight. Thanks Mike, we'll leave it to the expert. I was compiling with the older version of bb (not the updated one) which is why I couldn't replicate the problem again. The binary that RT posted flashes to black and has an unsteady scanline count regardless of the Stella version. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 13, 2013 Share Posted August 13, 2013 I've updated my code to v10, and with the program seems to work the same as with previous bB versions, without the blackout. I think it was some kind of arm alignment issue I'm not up to speed on. Shrinking my added pfread command appears to have done the trick. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 13, 2013 Share Posted August 13, 2013 I've updated my code to v10, and with the program seems to work the same as with previous bB versions, without the blackout. I think it was some kind of arm alignment issue I'm not up to speed on. Shrinking my added pfread command appears to have done the trick. Problem seems to be gone. Thanks. 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 13, 2013 Share Posted August 13, 2013 RevEng, The last post batari left said, "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: multiple player definitions (untested) pfpixel, pfvline and pfhline 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. Smooth scroll in from left or right (upper two bits of NUSIZ control this.) There is more, and I'll expand on that later." About that last line, can you find any undocumented DPC+ commands in the source code? I have looked and remember seeing something near the end of one of the files... Thanks for implementing pfread, what a bonus. I'll have to learn how to use that. Also the next command hacked in could be vertical Playfield scrolling so I can make Xevious and Bump N Jump. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 13, 2013 Share Posted August 13, 2013 Nothing has jumped out at me so far. I'll go on a more detailed hunt tomorrow. At this point I'm going to avoid adding any new commands, fix any further bugs that pop up in the next few weeks, try to hand off to batari, and call it done. The future of the language belongs in batari's hands. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted August 13, 2013 Share Posted August 13, 2013 The future of the language belongs in batari's hands. Hopefully all future updates and fixes can be posted in once place, like you have done here. Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 13, 2013 Share Posted August 13, 2013 About that last line, can you find any undocumented DPC+ commands in the source code? I dug for a bit. I don't see any undocumented DPC+ commands in the source. Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 13, 2013 Share Posted August 13, 2013 I was particularly interested in these: I don't think I have ever seen them, let alone know how to use them or if they work. You can see other things that do work and are used like missile0y, etc. RAMcopybegin? statusbarlength? lifecolor? lifepointer? lives? I think Scumsoft was doing things with ram copy, but he is no longer around. RAMcopybegin = SpriteGfxIndex RAMcopylength = *-RAMcopybegin missile0y ds 1 missile1y ds 1 bally ds 1 missile0height ds 1 missile1height ds 1 ballheight ds 1 statusbarlength ds 1 ; needed? aux3 = statusbarlength lifecolor ds 1 pfscorecolor = lifecolor aux4 ds 1 lifepointer ds 1 lives ds 1 pfscore1 = lifepointer pfscore2 = lives aux5 = pfscore1 aux6 = pfscore2 playfieldpos ds 1 temp1 ds 1 ; used in sprite flickering temp2 ds 1 ;are obliterated when drawscreen is called. temp3 ds 1 temp4 ds 1 temp5 ds 1 temp6 ds 1 temp7 = topP1x ; This is used to aid in bankswitching KERNEL_LINES = 178*76/64 ; warning: not all values will work OVERSCAN_LINES = 128+33*76/64 ; again, not all values work C_function = FETCHER_BEGIN CcodeData = C_function + 4 playerpointers = CcodeData + RAMcopylength P1GFX = playerpointers + 38 P1COLOR = P1GFX + 256 P0GFX = P1COLOR + 256 P0COLOR = P0GFX + 256 PF1L = P0COLOR + 256 PF2L = PF1L + 256 PF1R = PF2L + 256 PF2R = PF1R + 256 PFCOLS = PF2R + 256 JUMPTABLELO = PFCOLS + 256 JUMPTABLEHI = JUMPTABLELO + 12 P1HMP = JUMPTABLEHI + 12 P1SKIP = P1HMP + 13 NUSIZREFP = P1SKIP + 12 scoredata = NUSIZREFP + 12 BKCOLS = scoredata + 96 STACKbegin = BKCOLS + 256 USERSTACK = STACKbegin + 256 ; stack starts here and goes down!!!! Quote Link to comment Share on other sites More sharing options...
RevEng Posted August 13, 2013 Share Posted August 13, 2013 The RAMcopy memory is just used for some sprite-ordering kernel prep. I don't see it tied to any bB functions. I do see some apparently broken code for pfscores. If you enable it as-is right now, it will mess up the 6th score character. Maybe that's what batari was referring to. 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.