bB with native 64k cart support - 1.1d.reveng

[pitfall_jerry]

 

It works on my Windows 7 64-bit system. You might want to right click and set the compatibility mode to something other than Windows 8 if you are having a problem.

I tried that and got the same error message. Went all the way back to Windows 95.

[RevEng]

Just an update that pitfall_jerry and I resolved the issue in PM. It seems that Windows 8.1 64-bit doesn't like gcc cross-compiled Windows binaries if they're static compiled. Removing the static flags resolved the issue, and should work fine for other versions of Windows.

 

I'll release a versioned update (hopefuly) this weekend.

 

 

Is there any "special way" to detect collision between player0 and player1 in DPC+?

Because as soon as you do this

I took a brief look at the source, and it seems that DPC+ collision(player0,player1) should already be ignoring virtual players. When I get a second I'll look in more detail, to see if I've missed something or if its a bug.

[+Gemintronic]

I may be tripping ballx, but, I thought the y coordinate of the virtual sprite with the collision was stored somewhere temporarily.. ?

[RevEng]

Is there any "special way" to detect collision between player0 and player1 in DPC+?

It seems batari intentionally overrode DPC+ collision(player0,player1) to just use the hardware collision registers, instead of the virtual sprite collision routines. I think he did that to allow the programmer to easily check every player collision in one sweep.

 

In the first post you'll find version 24, which supports collision(player0,_player1) for collision checking only player0 and player1.

 

The new version also has the compilation options that should keep Windows 8.1 happy.

 

 

I may be tripping ballx, but, I thought the y coordinate of the virtual sprite with the collision was stored somewhere temporarily.. ?

I recall him saying that with one of the releases, but that may have changed. I don't see signs of it in the DPC+ collision check code, nor in the kernel itself.

[iesposta]

Thank you! That really helps!

 

"In the first post you'll find version 24, which supports collision(player0,_player1) for collision checking only player0 and player1."

[+Random Terrain]

I'm not sure how long this problem has been around, but here it is anyway in case you can fix it. The bottom visible line in the standard kernel messes up when scrolling. Here it is messing up when scrolling left or right:

 

youtube.com/watch?v=bWPmQGuW214

http://www.youtube.com/watch?v=bWPmQGuW214

 

 

Here it is messing up when scrolling up or down:

 

youtube.com/watch?v=vJ0mgg8Yu8c

http://www.youtube.com/watch?v=vJ0mgg8Yu8c

[+Gemintronic]

It also happens in my 4 way scrolling demonstration

http://atariage.com/forums/topic/218190-smooth-vertical-scrolling-from-data-want-4-way/

 

We should use a pre RevEng bB and see if it still happens there. If it's a batari thing maybe we should have him take a gander.

[RevEng]

The glitches ARE NOT present when RR is compiled in batari's official 1.0 (though other bugs are present), and ARE present when RR is compiled with his 1.1 and later series.

 

When I first saw it, I thought for a second I may have introduced it with the score shake fix, but neither of these versions has my fix in them.

 

I'm seeing if I can track down the source of it by comparing the two, but no luck so far.

[RevEng]

Ok, it seems like the standard kernel last-line handling code was over a cycle. Oddly enough the 1.0 version has a specific fix for it, but somehow the fix was reverted from 1.1 and on.

 

The first post has the fixed version.

[+Gemintronic]

I appreciate that fix. I think 4 way scrolling is officially a thing in bB thanks to this. Also the 64k support to hold such levels

[+Random Terrain]

Ok, it seems like the standard kernel last-line handling code was over a cycle. Oddly enough the 1.0 version has a specific fix for it, but somehow the fix was reverted from 1.1 and on.

 

The first post has the fixed version.

 

Thanks, but it doesn't seem to be working correctly yet. Here's a program that you can try. Just scroll up until stuff is on the screen, then move left or right until you see the mess up:

 

mini_ex_scroll_mess_up_2013y_11m_16d_2138t.bas

 

mini_ex_scroll_mess_up_2013y_11m_16d_2138t.bin

[RevEng]

Odd. It fixed the issue with theloon's code, so this is likely another issue entirely.

 

I'll look into it.

 

[edit - definitely another issue. This one is present all the way back to bB v1.0]

[RevEng]

I think I have it fixed. There was another cycle overage leading into the last playfield line when blank lines were used. Weird that it's never been discovered until now.

RT, let me know if this works fine for you and I'll update the first post.

[attachment moved to first post]

[+Random Terrain]

Thanks. If you run the example that I posted, you'll see that it doesn't use no blank lines. It's now a little harder to make the problem happen, but it's clearly still happening. You may want to add a few drawscreens to slow things down and make it easier for you to see the problem. I can make another video if you need it.

 

[The forum software started loading slower than dial-up for me yesterday and it's still just as slow or sometimes not loading at all. The non-forum AtariAge pages load fast, but the circle on the tab keeps spinning as if more stuff needs to load. I'm telling you this in case you get no more replies from me for a long time. There's no guarantee that I'll be able to read your posts or that I'll be able to reply if I can read them. I hope this actually gets posted instead of getting lost in spinning circle world.]

[+Gemintronic]

It could also be correct behaviour at this point. Check out my modified R.T. example that doesn't seem to do it:

   dim vidmem=$a4

   COLUBK = $C4
   COLUPF = $CE

__init

   for temp5 = 0 to 47 : vidmem[temp5] = 195 : next

__Main_Loop

   if joy0up then pfscroll up
   if joy0down then pfscroll down
   if joy0left then pfscroll left
   if joy0right then pfscroll right

   if playfieldpos <> 8 then goto __Skip_Draw

__Skip_Draw

   drawscreen

   goto __Main_Loop

[RevEng]

Yeah, I mentioned it was a blank lines issue. (as opposed to a "no-blank lines issue".)

I'm not seeing any glitching at all with version 26. Here's a compiled version with extra drawscreens, but I can't see a problem. Anyone else?

mini_ex_scroll_mess_up_reveng.bas.bin

[+Random Terrain]

Yeah, I mentioned it was a blank lines issue. (as opposed to a "no-blank lines issue".)

 

I'm not seeing any glitching at all with version 26. Here's a compiled version with extra drawscreens, but I can't see a problem. Anyone else?

 

mini_ex_scroll_mess_up_reveng.bas.bin

 

If you run the .bin file that I posted below, you'll see that it looks like a little bite has been taken out of the block on the left side:

 

 

mini_ex_scroll_mess_up_2013y_11m_17d_1900t.bin

 

That is not present in the .bin file that you posted. Why would I have a bite taken out and you have no bite taken out of it?

[RevEng]

I'm not sure. The "bite" was the glitch I fixed in version 26, which I attached a few posts up. Are you sure you successfully switched vbb to version 26?

 

To be sure, stick this in your project directory and rebuild it. Its the standard kernel from 26.

 

[attachment removed]

[+Random Terrain]

I'm not sure. The "bite" was the glitch I fixed in version 26, which I attached a few posts up. Are you sure you successfully switched vbb to version 26?

 

To be sure, stick this in your project directory and rebuild it. Its the standard kernel from 26.

 

std_kernel.asm

 

Well, slap my ass and call me Suzy! Thanks! That fixed it! When I went to put your file in the project folder, there was an std_kernel.asm file already in it, so I deleted it instead of downloading yours to the folder. That file was overriding your changes. Now I'm using the one in the actual bB folder. I need to mention that somewhere on the bB page or the VbB page. I should say something like "Make sure that an old std_kernel.asm file is not in your project folder. You'll always be using the old std_kernel.asm file instead of the new one that comes with the latest version of bB."

[RevEng]

I'll pass on the ass slap, Suzy, but I updated the first post with version 26.

 

[jwierer]

A quick search didn't pull up anything so I apologize is this is FAQ, but is this supposed to work with the peephole optimization option (i.e., -O). When I use that, I get a zero byte file and I can't remember that happening in the original bB builds.

 

Thanks,

Jeff

[RevEng]

It looks like the 2600bas.bat batch files from bB 1.1, bB 1.1d, and my versions are missing the "-i" option from the optimize postprocess commands. Adding it back in fixes the issue.

 

Oddly enough, bB 1.0 has it right.

 

It's an easy enough fix, but I think I should probably wait for SeaGTGruff and you to hash out the space issue, add the "-i" to the optimize postprocess command in his version (its missing there too), and adopt that batch file here in a new version.

[jwierer]

I fixed spaces by just resetting the bB environment variable to Windows 8.3 file format prior to compile. It required one API call to determine the string. The end user is blissfully unaware of what is happening in the background This will be in a future release.

[RevEng]

jrok recently prodded me on the fact that there was no longer enough room in the first DPC+ bank to implement a vblank routine, even if the vblank routine was a completely minimal bankswitch to another routine.

 

Even though I announced a feature freeze earlier, leaving DPC+ vblank useless would be creeping into bug territorry. I revisited the ARM source and eventually found another way to squeeze out some more bytes. While I was in, I implemented some easy changes with the newfound space, and left enough for the bB coder to implement a short vblank handler.

 

Said changes are...

• we now have the ability to reduce the number of DPC+ virtual sprites, so unused vsprite memory can be reclaimed ("set dpcspritemax #", where # is a number from 1-9)
• the space character at the end of the score fonts were re-enabled. (set any digit to $A to blank it)

This release also features a batch file that has the optimize "-i" fix, and works from CLI when bB is in a directory path that contains spaces. (Support for spaces from vbb will be in an upcoming vbb release.)

 

See the first post for the updated version. Special thanks to jrok and RT for doing testing!

[+Gemintronic]

Does the extra space character also work in the multi-kernel framework? I'd love to use characters 0-9 for letters in an RPG

 

0123456789A

ATCKFISHLE_

 

ATTACK

CAST

ITEM

FLEE