Jump to content
gauauu

DPC+ kernel and fixed_point_math.asm

Recommended Posts

I've just started playing around with bBasic for the first time, and ran into this question. I'm trying to use the DPC+ kernel, along with the fixed_point_math module.

 

If I include the fixed_point_math module at the beginning of my program, I get an Origin Reverse-indexed error upon compilation (it's over-filling the first bank where the DPC/arm code is supposed to be?):

 
  include fixed_point_math.asm

  set kernel DPC+
  set tv ntsc
  set optimization inlinerand


  goto __Start_Restart bank2

  bank 2

__Start_Restart
....etc

gives:

segment:  1fd4          eqm       vs current org: 202f
 free ram: 0
 DPC free RAM= 603
      -91 bytes of ROM space left in bank 1

spw.bas.asm (1407): error: Origin Reverse-indexed.

Alternatively, I could put the fixed_point_math into a different bank (bank 2?) but it wasn't clear how to make this work -- it seems bBasic keeps trying to do a bank jump to bank 1 to call the fixed point routines.

 

Let me know if I'm missing something obvious, or doing something dumb. Thanks!

 

Share this post


Link to post
Share on other sites

The bB DPC+ format has hardly any space in the first bank, since it has it's kernel there. "include" sticks the included assembly module in the first bank, so it isn't going to work with DPC+.

Try using "inline fixed_point_math.asm" in another bank, somewhere away from the code flow.

A couple things to note - First, you only need to use fixed_point_math.asm if you're mixing 8.8 and 4.4 types together in math assignments. If you stick completely to 8.8 or 4.4 types, or if you don't do math that mixes 8.8 and 4.4 types, it isn't needed, since other fixed point operations are built right into the bB parser. Second, in a bank switched program you can only access include/inline routines from the bank containing the include/inline statement. So in this case, you'd need to limit your mixture of 8.8 and 4.4 types to that single bank.

Share this post


Link to post
Share on other sites

It looks like my inline solution will work for compiling, but not for usage. batari did add bank switching functionality, but it's fixed to bank 1. (as you advised) For now that means you can't mix 8.8 and 4.4 math in DPC+.

 

I've edited my previous post.

Share this post


Link to post
Share on other sites

Thanks, RevEng, that confirms what I was seeing.

 

A couple things to note - First, you only need to use fixed_point_math.asm if you're mixing 8.8 and 4.4 types together in math assignments. If you stick completely to 8.8 or 4.4 types, or if you don't do math that mixes 8.8 and 4.4 types, it isn't needed, since other fixed point operations are built right into the bB parser.

 

Yeah, I found this by experimentation. I was hoping to mix them to save ram space (8.8 is overkill for velocity), but I'll have to try something else.

 

It looks like my inline solution will work for compiling, but not for usage. batari did add bank switching functionality, but it's fixed to bank 1. (as you advised) For now that means you can't mix 8.8 and 4.4 math in DPC+.

 

My other potential solution is a lot more drastic: include it into bank 2, then run a post-processor on the generated assembly to change all the calls so that they work properly in bank 2 instead :)

Share this post


Link to post
Share on other sites

Oh wait, bBasic comes with source code. Changing the bBasic compiler might be easier than making a post-processor :)

 

 

What could possibly go wrong here....

Share this post


Link to post
Share on other sites

If you're going to do that, I think the jsrbank1() in statements.c might be a good place to introduce the change. Maybe use bank 2 as an alternate when DPC+ is being used. (bs==28 when DPC is used).

 

Fixing "include" to use bank 2 for DPC+ would be a bit more complicated, since the command insists on being first in the source (at bank 1). There are ways around that, but it's probably easiest to punt and just manually use the "inline" command in bank 2 for DPC+.

  • Like 1

Share this post


Link to post
Share on other sites

Yeah, that's exactly what I was looking at. Although I'm leaning towards just making sure all my fixed point math happens in bank 2, and changing it to a non-banked jump, just to make it more efficient.

Share this post


Link to post
Share on other sites

The bB DPC+ format has hardly any space in the first bank, since it has it's kernel there. "include" sticks the included assembly module in the first bank, so it isn't going to work with DPC+.

 

Try using "inline fixed_point_math.asm" in another bank, somewhere away from the code flow.

 

A couple things to note - First, you only need to use fixed_point_math.asm if you're mixing 8.8 and 4.4 types together in math assignments. If you stick completely to 8.8 or 4.4 types, or if you don't do math that mixes 8.8 and 4.4 types, it isn't needed, since other fixed point operations are built right into the bB parser. Second, in a bank switched program you can only access include/inline routines from the bank containing the include/inline statement. So in this case, you'd need to limit your mixture of 8.8 and 4.4 types to that single bank.

 

I just remembered to add this to the bB page:

 

randomterrain.com/atari-2600-memories-batari-basic-commands.html#reveng_fp_note

  • Like 1

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