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

[RevEng]

Anybody up for a real hardware test?

 

dpcpfscroll.bas.bin

[+Random Terrain]

Anybody up for a real hardware test?

 

dpcpfscroll.bas.bin

 

I downloaded it to the Harmony cart on my real Atari 2600 and made a short video of it using a Hauppauge WinTV-HVR-850 video capture thingy:

 

youtube.com/watch?v=V0LbMoWC6YY

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

[RevEng]

Looks right, so far as I can tell. Did the numbers scroll smoothly, without any jumping?

[+Random Terrain]

Looks right, so far as I can tell. Did the numbers scroll smoothly, without any jumping?

 

It looks like it does in the video. A tiny bit jerky. Not as smooth as in Stella. If you make it full screen, you can see it better.

[iesposta]

I didn't notice any jumping.

I'll try it on H6er RF next.

[iesposta]

Smooth there also!

Is that PF or wide players? Let's see, is it April?

[RevEng]

Works smooth for me too... I just kicked the wife off the TV with the 2600 to check.

 

Here's the sample .bas for DPC+ pfscroll. It creates the 0, 1, 2 playfield lines with 3 separate playfield: commands with scrolling in-between, and then scrolls the whole lot.

 

dpcpfscroll.bas

 

Unlike pfscroll for the other kernels, the syntax is "pfscroll [value]" or "pfscroll [variable]". Also, it does a coarse scroll (1 PF line at a time) so if you want smooth scrolling you need a fine DF#FRACINC resolution.

 

The first post will get an update shortly.

[RevEng]

Version 22 is now in the first post.

 

The updates...

• DPC+ pfscroll added.
• the glitch PF1 line at the bottom of the screen was removed

I squeezed the heck out of the DPC+ ARM code to accomplish DPC+ pfscroll. Without major changes to enable code in other banks, bB DPC+ is pretty much done.

 

Thanks for testing, RT and iesposta!

[+Random Terrain]

Can the screen scroll down too, or just up?

[RevEng]

Sure. The playfield strips are 256 bytes in size, so use "pfscroll 255" to scroll down by 1, "pfscroll 254" to scroll down by 2, etc.

[+Random Terrain]

Sure. The playfield strips are 256 bytes in size, so use 255 to scroll down by 1, 254 to scroll down by 2, etc.

 

Thanks. That should kill two birds with one stone. I can make a DPC+ version of Gyvolver and finally get that thing finished and I could probably also use your new pfscroll to place random sections on the screen for a maze game or adventure game or whatever.

[iesposta]

I can no longer pick a different font.

It locks running the bin.

[RevEng]

Thanks for the highly specific bug report! There was an extra unused space character at the end of the custom score fonts that pushed us over the edge. That's how tight we are for ARM code.

 

I trimmed the space character off, since it wasn't present in the standard font, and using custom fonts no longer locks things up. Version 23 is now in the first post.

 

One additional note - I'm going to stop adding features to this dist and just fix bugs from here on out. I think the next step would be deeper roadmap type work - like changing DPC+ custom functions to use a compiled module approach - but I don't have the time to devote to that.

 

I would rather batari take back the reigns anyway, as it was never my intention to take bB development away from him. I just wanted to add 64k support, fix up a few rough edges, and provide a single zip method of getting the latest fixed version on all supported platforms.

[Yoshiatom]

A couple of questions:

 

Is this compatible with VBb?

If I compile a with a non 64k game with the normal bB and then compile the same game with this modified version, will there be a difference between the two .bin files?

[RevEng]

It's compatible with vbb.

 

There may be minor differences between binaries compiled with this and older versions because I fixed some general bB bugs.

[jwierer]

A couple of questions:

 

Is this compatible with VBb?

If I compile a with a non 64k game with the normal bB and then compile the same game with this modified version, will there be a difference between the two .bin files?

vbB just calls out to the compiler you have it configured to use. You may have some missing 64k keywords that for now, you would need to add to a custom dictionary in your vbB settings. Compiling with different versions of the compiler for non-64k games *should* be the same, through RevEng may have fixed other bugs. At this point it may be best just to use the latest bB since RevEng has been killing bugs left and right

 

-Jeff

[Yoshiatom]

vbB just calls out to the compiler you have it configured to use. You may have some missing 64k keywords that for now, you would need to add to a custom dictionary in your vbB settings.

I'm not sure what you mean, could you be less vague?

 

Compiling with different versions of the compiler for non-64k games *should* be the same, through RevEng may have fixed other bugs. At this point it may be best just to use the latest bB since RevEng has been killing bugs left and right

You say that like debugging bB is a bad thing, am I missing something?

 

EDIT: As I'm here I may ask another vBb question: Does VisualbB_1.0_Build_554 have the title screen kernel?

Edited September 29, 2013 by Yoshiatom

[jwierer]

I'm not sure what you mean, could you be less vague?

 

You say that like debugging bB is a bad thing, am I missing something?

 

EDIT: As I'm here I may ask another vBb question: Does VisualbB_1.0_Build_554 have the title screen kernel?

I can be less vague, but choose to be more direct Yes vbB is compatible, but you'll be missing verbs that you will need to manually add.For bB just use the latest and report bugs if you find them. vbB 554 doesn't have the title screen wizard which is what I think you meant to ask since the title screen kernel is a seperate download for bB.

[Yoshiatom]

I see. I'll stick to the normal bB. But is vbB 554 the latest version? And does what you said mean that the title screen wizard is only in a special build of vbB? This should be the last of my questions.

[jwierer]

554 is a pretty stable build, but if you want all the latest bells and whistles, grab the work in progress build from my blog. Eventually, I'll clean it up and post a newer one to the main thread.

[RevEng]

I see. I'll stick to the normal bB.

When Jeff is talking about using the latest bB, he means my latest bB, in the first post here.

[Yoshiatom]

vbB is working ok, I just need to figure out how to make a title screen!

Thanks.

[iesposta]

RevEng,

This is what I was trying to do, re: Page Flipping.

It sort of works!

On real hardware it bounces up and down one scanline, on Stella it does not.

I am going to post it in my QbBertari thread because I need help with not changing direction in mid-jump.

 

QbBscroll220130929e.bas

QbBscroll220130929e.bin

[RevEng]

I think the line bouncing on real hardware is because DF#FRACINC isn't being set prior to each drawscreen.

 

I didn't want to trace the logic, but I set the background color to RED after every DF#FRACINC setting, and I set the background color to BLACK after each drawscreen. The result was the game flickered RED and BLACK on alternate frames, which means one of the frames didn't get DF#FRACINCed.

 

As a best practice, move those DF#FRACINC settings right before each drawscreen. Its harder to miss them that way.

[iesposta]

I think the line bouncing on real hardware is because DF#FRACINC isn't being set prior to each drawscreen.I didn't want to trace the logic, but I set the background color to RED after to every DF#FRACINC setting, and I set the background color to BLACK after each drawscreen. The result was the game flickered RED and BLACK on alternate frames, which means one of the frames didn't get DF#FRACINCed.As a best practice, move those DF#FRACINC settings right before each drawscreen. Its harder to miss them that way.

Yes, that was it. Yet again that bug bites!