PBP and PBPL

[mackrackit]

I am afraid I do not understand now. I was thinking the only reason to chop the number up (factor it) was because at one point the value was larger than 32 bits, then once that was dealt with 16 bit had it covered.

Is the math working correctly now for your formula?

What am I missing here.

As far as the code size goes with PBPL, every value is a LONG, even 1. So that is where the extra code space comes from.

I did not mention in the previous mail that I don't trust in PBPL, as it seems to me that it can not correctly show how much space your code will take when you are as close to the limit as 3k or so.

The code space used as far as I know is calculated correctly in PBP or PBPL. What is making you think other wise?

[keymuu]

I am afraid I do not understand now. I was thinking the only reason to chop the number up (factor it) was because at one point the value was larger than 32 bits, then once that was dealt with 16 bit had it covered.

Is the math working correctly now for your formula?

What am I missing here.

As far as the code size goes with PBPL, every value is a LONG, even 1. So that is where the extra code space comes from.


The code space used as far as I know is calculated correctly in PBP or PBPL. What is making you think other wise?

Ok, I was ambiguous ... sorry

Please, take a look at #26, there I try to explain why PBPL can't be trusted.

However, the main point shortly:
As the code is now compiled without errors or warnings with PBP it is 26406 bytes + bootloader=1k.

If I compile it, the same code, with PBPL it is 28682 bytes (???), however with a bunch of warnings and one
"Error[126] \PBP\PBPPI18.LIB 690 : argument out of range (32940 not between 0 and 32767)"
and I learned earlier it indicates that the code exceeds 32k.

I do not know why or how it can tell: 28682 bytes used
and on the other hand that the code exceeds 32k

The PBPL didn't convince me at all, not at all.... How could I proceed from here when not yet implemented all the calculation I need?

There is not so much calculations but this situation can not promise a future for PBPL in this project!

So, this is the reason why I try to come along with the 16bit PBP and not trusting the PBPL.....

I believe that it can be done somehow, by calculating small pieces at time, but I have not yet discovered how.... please help

[mackrackit]

Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.

[keymuu]

Can you post the current cod if it has changed from the last time. Then maybe Darrel can find the problem.

Please find the attached file testest.txt, it is not so much different from the previous one because I have not have time to develop it when chasing this ... problem...

Hopefully it still reveals something

[mister_e]

Could you at least upload ALL your files here? all .BAS, .ASM, .BAL etc etc in a ZIP file, this way we will work with all the same stuff.

and this...

BANKA   $0000, $005F
BANK0   $0060, $00FF
BANK1   $0100, $01FF
BANK2   $0200, $02FF
BANK3   $0300, $03FF
BANK4   $0400, $04FF
BANK5   $0500, $05FF
BANK6   $0600, $06FF
BANK7   $0700, $07FF

is useless.

AND if you're using a 4550, you're out of codespace... as stated before... time for some code optimization.

The obvious would be to move all text string into an external EEPROM or some part in the internal one.

I don't know how crazy the compiler go with it, but you define some variable here and there (at east in gettext sub)...

[keymuu]

Could you at least upload ALL your files here? all .BAS, .ASM, .BAL etc etc in a ZIP file, this way we will work with all the same stuff.

and this...

BANKA   $0000, $005F
BANK0   $0060, $00FF
BANK1   $0100, $01FF
BANK2   $0200, $02FF
BANK3   $0300, $03FF
BANK4   $0400, $04FF
BANK5   $0500, $05FF
BANK6   $0600, $06FF
BANK7   $0700, $07FF

is useless.

AND if you're using a 4550, you're out of codespace... as stated before... time for some code optimization.

The obvious would be to move all text string into an external EEPROM or some part in the internal one.

I don't know how crazy the compiler go with it, but you define some variable here and there (at east in gettext sub)...

Attached PBProj.txt, change txt to jar and unzip it - et voilà ...

The BANKs was still hanging there for no reason, now they are not there any more.

I'm using 4550 and I think there is still much to go before the code ready and finished, so I'm sure that I will try to stay away from PBPL = trouble

The plan is to eventually move all strings to an external EEPROM. If you are referring to the test loop, well it will not stay as well as not the 4 line LCD either.

It doesn't seem to change anything if moving them up from gettext. When building it is nice to have/see them in the first place where you use them. At last you then would collect all to one bunch. But as long there are not local variables then...
... and on this stage before the frame is totally working the code is more as a test underlying...

The question is still how to calculate R
R = (L/2)*(L/2)/H/1000
when for ex. L= 350123 and H=37234 (in reality L=350,123 and H=37,234)
How could one split (divide, using DIV32 R0,R2 etc) to get PBP calculate the correct answer?

Thanks

[Darrel Taylor]

The question is still how to calculate R
R = (L/2)*(L/2)/H/1000
when for ex. L= 350123 and H=37234 (in reality L=350,123 and H=37,234)
How could one split (divide, using DIV32 R0,R2 etc) to get PBP calculate the correct answer?

(L/2)*(L/2)

The result of that alone is over 30 Billion.

/H

DIV32 is actually a DIV31/15. The maximum divisor for DIV32 is 15-bits or 32767
37234 is too much.

/1000

There's at least 3 decimals of precision you won't need, so why are the numbers so big to begin with? (rhetorical question)

<hr />

Let me open a whole new "Can of Worms", and suggest that you use the Microchip Floating Point Math module.
http://www.melabs.com/resources/fp.htm

It'll handle your numbers.
It takes a little getting used to, but it works.
<br>

[keymuu]

The attachment was missing from previous .... it is her now , sorry

[mister_e]

never mind... still thinking too loud here