ScumSoft Posted July 14, 2011 Share Posted July 14, 2011 Oh yes thank you. Quote Link to comment Share on other sites More sharing options...
Byte Knight Posted July 15, 2011 Share Posted July 15, 2011 My one wish would be that the DPC+ games would be compatible with the Flashback 2... Quote Link to comment Share on other sites More sharing options...
+batari Posted July 15, 2011 Author Share Posted July 15, 2011 My one wish would be that the DPC+ games would be compatible with the Flashback 2... It's not currently possible due to a flaw in the FB2. The FB2's A12 line never goes low as it should when accessing the TIA/RIOT, and because of this, there is no way to tell if the system is accessing DPC+ registers or the TIA. There may be a hardware workaround for this if Curt can tell us if there is a proper A12 line anywhere on the board that we can get to. Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 21, 2011 Share Posted July 21, 2011 I think I figured out the stack issue, it's more of an oversight than a bug I believe. The stack pointer is decremented before the write to it, so push $FF into stack 200 and it ends up at stack 199 Try and pull from stack 200 and you get the wrong value, instead pull from 199 and you get your #$FF back. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 22, 2011 Share Posted July 22, 2011 I think I figured out the stack issue, it's more of an oversight than a bug I believe. The stack pointer is decremented before the write to it, so push $FF into stack 200 and it ends up at stack 199 Try and pull from stack 200 and you get the wrong value, instead pull from 199 and you get your #$FF back. My initial example was wrong, but the bug was there. 1 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 22, 2011 Share Posted July 22, 2011 Well that's the problem with tackling bugs that were already fixed I'm very pleased with the quickness of bug squishing, carry on. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 22, 2011 Share Posted July 22, 2011 (edited) I'm not sure if this is a bug, but it seems that the vblank command does not work with the DPC+ kernel. Programs compile with the "vblank" keyword, but they crash on boot. Perhaps this is just a limitation due to routines that are running during the kernel's vertical blank? Edited July 22, 2011 by jrok Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 22, 2011 Share Posted July 22, 2011 I'm not sure if this is a bug, but it seems that the vblank command does not work with the DPC+ kernel. Programs compile with the "vblank" keyword, but they crash on boot. Perhaps this is just a limitation due to routines that are running during the kernel's vertical blank? It looks like bB isn't automatically sticking the vblank code in the same bank as the kernel anymore. (bank 1 for DPC+). Try moving your vblank statment and code to bank 1, and it should work there. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 22, 2011 Share Posted July 22, 2011 (edited) I'm not sure if this is a bug, but it seems that the vblank command does not work with the DPC+ kernel. Programs compile with the "vblank" keyword, but they crash on boot. Perhaps this is just a limitation due to routines that are running during the kernel's vertical blank? It looks like bB isn't automatically sticking the vblank code in the same bank as the kernel anymore. (bank 1 for DPC+). Try moving your vblank statment and code to bank 1, and it should work there. I did try that. Sorry I forgot to mention it. Also tried bank6 just in case, but it caused a crash either way. I haven't even tried running any code within the statement yet, since the declaration itself with no executed code causes a crash. Edited July 22, 2011 by jrok Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 22, 2011 Share Posted July 22, 2011 When you say you don't have any code, do you mean there's no "return" statement? You'll need one. I was able to replicate the issue with a small test program, and putting it in bank 1 worked for me. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 22, 2011 Share Posted July 22, 2011 (edited) When you say you don't have any code, do you mean there's no "return" statement? You'll need one. Yeah, it returns. I just meant that I'm not running any code before the return. I was able to replicate the issue with a small test program, and putting it in bank 1 worked for me. Perhaps you can upload it? I've attached a small demo program of my own demonstrating what's happening for me. When I compile the attached source file and run it in latest stable releases of Stella, I only get a bunch of white lines. See my attached binary for the way it looks when I compile with the vblank routine commented out. vblanktest.bas vblanktest.bas.bin EDIT: I was just about to hit post, when I decided to try something first. If you download and compile my source as is, I'm guessing you'll see the same fatal bug that I saw. The reason seems to be that I declared vblank before any other instructions, which appears to break the program. If you move it below that first bankswitch instruction, for instance, and re-compile, the program works normally. I'm not sure if this relates at all to the stack bug we were looking at yesterday, but it seems like adding junk code (temp1=temp1, etc) above the vblank declaration doesn't squash the bug, but it changes the way the bug looks in Stella. Edited July 22, 2011 by jrok Quote Link to comment Share on other sites More sharing options...
+batari Posted July 22, 2011 Author Share Posted July 22, 2011 bB always starts execution at the beginning of the .bas file. If you put vblank there with a return, bB will start out with the return which can never work as there is nothing to return from yet. Quote Link to comment Share on other sites More sharing options...
jrok Posted July 22, 2011 Share Posted July 22, 2011 (edited) bB always starts execution at the beginning of the .bas file. If you put vblank there with a return, bB will start out with the return which can never work as there is nothing to return from yet. Oh, okay. I thought that the order that vblank appeared within the code was abstracted, and that the compiler would automatically determine when it executes (so long as it was declared within the proper bank). Edited July 22, 2011 by jrok Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 23, 2011 Share Posted July 23, 2011 Fred, remember to add playfield plotting commands to DPC+ kernel otherwise I cannot upgrade my L.E.M. game (I use pfvline to draw Moon's surface)! Quote Link to comment Share on other sites More sharing options...
+batari Posted July 23, 2011 Author Share Posted July 23, 2011 Fred, remember to add playfield plotting commands to DPC+ kernel otherwise I cannot upgrade my L.E.M. game (I use pfvline to draw Moon's surface)! I will look into this in a bit. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted July 23, 2011 Share Posted July 23, 2011 Fred, remember to add playfield plotting commands to DPC+ kernel otherwise I cannot upgrade my L.E.M. game (I use pfvline to draw Moon's surface)! I will look into this in a bit. Speaking of looking into things, I heard that the new stuff doesn't have collision detection between sprites and the playfield. Is that the way it will always be? Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 23, 2011 Share Posted July 23, 2011 Speaking of looking into things, I heard that the new stuff doesn't have collision detection between sprites and the playfield. Is that the way it will always be? I hope not! It would be catastrophic for L.E.M. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 23, 2011 Share Posted July 23, 2011 Speaking of looking into things, I heard that the new stuff doesn't have collision detection between sprites and the playfield. Is that the way it will always be? collision() works the same as always, and I just verified that it's fine in DPC+. There are a few wrinkles when using collision() with the DPC+ or multisprite kernels - the virtual sprites are all player1 so you can't use collision() to detect collisions between them, and when a virtual sprite collides with the playfield you won't know exactly which one did it without coordinate checking. 1 Quote Link to comment Share on other sites More sharing options...
PAC-MAN-RED Posted July 24, 2011 Share Posted July 24, 2011 Could bB support the ability to allow, for example, Up & Down to be pressed simultaneously on a modified Joystick? I'm wondering because I've modified a Sega Genesis controller to have one button as Up and another as Down allowing them both to be pressed at the same time. Thank you, Illya Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 24, 2011 Share Posted July 24, 2011 (edited) No mod needed, just tell your code to check for both being pressed like this: if joy0up && joy0down then goDosomething Edited July 24, 2011 by ScumSoft Quote Link to comment Share on other sites More sharing options...
PAC-MAN-RED Posted July 24, 2011 Share Posted July 24, 2011 No mod needed, just tell your code to check for both being pressed like this: if joy0up && joy0down then goDosomething Thanks for the quick reply, but when I use the joy0up and joy0down in combination in the program - nothing happens. The program compiles fine, but no "joy". Illya Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 24, 2011 Share Posted July 24, 2011 In stella, go to options->input settings->devices & ports, and ensure "Allow all 4 directions on joystick" is checked off. Stella blocks illegal joystick directions by default, to avoid unintended consequences in games. Quote Link to comment Share on other sites More sharing options...
PAC-MAN-RED Posted July 24, 2011 Share Posted July 24, 2011 In stella, go to options->input settings->devices & ports, and ensure "Allow all 4 directions on joystick" is checked off. Stella blocks illegal joystick directions by default, to avoid unintended consequences in games. Ah yes, that did the trick. Thank you. Illya 1 Quote Link to comment Share on other sites More sharing options...
+batari Posted July 28, 2011 Author Share Posted July 28, 2011 (edited) 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. bb11d.zip Edited July 28, 2011 by batari 4 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 28, 2011 Share Posted July 28, 2011 Thank you Fred. In my program, when sprite collides with playground, it explodes (no need to check coordinates). So, how should I change if collision(playfield,player1) then Could someone (Jurrell?) post a complete folder with new bB version (if possible without personal add-ons). I've tried to upgrade my folder with new bB version but the resulting .bins don't work. 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.