PBP and PBPL

[mackrackit]

Looks like you are on the right track.

I think the problem now might be to many (()).. The compiler is confused.

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000

L8 = 8 * Lint
LT = L8 + Ldec
R = LT * LT /4 / H / 1000

Maybe???

[keymuu]

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000

L8 = 8 * Lint
LT = L8 + Ldec
R = LT * LT /4 / H / 1000

Maybe???

Thanks Dave!

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.

So, your idea is excellent, no doubt When dealing with the reliably basic 16bits one should be able to shop the thing even smaller.... or perhaps, if one could fool PBP somehow and use DIV32 where the result is 32 bit. The manual 4.17.8 DIV32 (page 37) says:
"PBP and PBPW's multiply (*) function operates as 16-bit x 16-bit multiply yielding a 32 bit internal result. ....
....
In many cases it is desirable to be able to divide the entire 32-bit result of the multiply by a 16-bit number for ...
...
..... DIV32 relies that a multiply was just performed and that the internal compiler variables still contain the 32-bit result of the multiply...."
Those internal are referred as R0 and R2, right? R0=High and R2=Low, correct?

Then multiplication (manual 4.17.1) there are two operators '*/' and '**'
"The '*/' operator discards the least significant byte of the result (byte0) and returns the 4 higher bytes to the result variable...
... The '**' operator is similar, but ignores two bytes instead of one.... This gives a result that is shifted 16 places to the right..."
Are here any known internal variables (like R0,R2) involved?

Could one possible use the above, using R0,R2 and so, to achieve to do what I'm trying to do?

Please, if you know could you shear you knowledge of how to use internal variables for DIV32, how about those for multiplication?

I did a small check and it seems to me that PBP is using R0-R8 for something.
I kind of know that R0 and R2 is for DIV32, however never utilized them yet.
I suppose that those others are also some intermediate variables. If you know would you please be so kind and tell where they are used and if you want to you could also perhaps give some examples of the use..

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