Next version of bB

[ScumSoft]

Oh yes thank you.

[Byte Knight]

My one wish would be that the DPC+ games would be compatible with the Flashback 2...

[+batari]

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.

[ScumSoft]

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.

[RevEng]

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.

[ScumSoft]

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

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

[jrok]

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

[RevEng]

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.

[jrok]

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

[RevEng]

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.

[jrok]

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

[+batari]

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.

[jrok]

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

[+Philsan]

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

[+batari]

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.

[+Random Terrain]

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?

[+Philsan]

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.

[RevEng]

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.

[PAC-MAN-RED]

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

[ScumSoft]

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

[PAC-MAN-RED]

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

[RevEng]

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.

[PAC-MAN-RED]

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

[+batari]

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

[+Philsan]

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.