Jump to content
IGNORED

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


RevEng

Recommended Posts

Anybody up for a real hardware test?

 

attachicon.gifdpcpfscroll.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

  • Like 1
Link to comment
Share on other sites

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

 

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.

  • Like 1
Link to comment
Share on other sites

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!

  • Like 4
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by Yoshiatom
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...