DPC+ kernel and fixed_point_math.asm

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?):

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.

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.

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

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

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

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.

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.