Jump to content
batari

Next version of bB

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Well that's the problem with tackling bugs that were already fixed :)

I'm very pleased with the quickness of bug squishing, carry on.

Share this post


Link to post
Share on other sites

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 by jrok

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by jrok

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by jrok

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by jrok

Share this post


Link to post
Share on other sites

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)!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

No mod needed, just tell your code to check for both being pressed like this:

 

if joy0up && joy0down then goDosomething

Edited by ScumSoft

Share this post


Link to post
Share on other sites

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". :D

 

Illya

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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 by batari
  • Like 4

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...