Jump to content
IGNORED

DPC+ kernel and fixed_point_math.asm


gauauu

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!

 

Link to comment
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.

Link to comment
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.

Link to comment
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 :)

Link to comment
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
Link to comment
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
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...