PBP and PBPL

Hi again :D

Noticed that when you have PBP v.2.50 you also have PBPL !

So I tried it with/via Microcode Studio v.3.0.0.5 but run directly to an error:

ERROR: Macro DIV32?CW not found in macro file.

As I just struggled out from previous problem (with the kind help from Darrel) and this one sounds like a big fight ahead...:(
however, hope not!

Suspecting that some data is in a wrong place, but what is there? No idea...

So, the question is, what all should one do before adopting the PBPL?
Should you move some files from one location to another? Or something else?

The software that I try to compile with PBPL is in the same directory as PBP and PBPL, that is C:\PBP...

Thank you in advance

PBPL has LONG (double-words) as a new data type. You don't need DIV32 when using PBPL. Just define your variables as LONGs and do the division.

Quote:

---

Originally Posted by Charles Linquis

PBPL has LONG (double-words) as a new data type. You don't need DIV32 when using PBPL. Just define your variables as LONGs and do the division.

---

Thanks Charles!

Yes I had one DIV32, commented it at got a bunch of errors (126) and warnings (220), 4 errors and 16 warnings . The errors:
Error[126] \PBP\PBPPI18L.LIB 722 : argument out of range (34218 not between 0 and 32767):mad:
and the warnings (two kinds, for .LIB and .MAC):
Warning[220]\PBP\PBPPI18L.LIB 788: address exceeds maximum range for this processor.
Warning[220] c:\pbp\godiam.mac 1414: Address exceeds maximum range for this processor. :(

This processor is PIC18F4550.

So, what should I try next????

Quote:

---

Originally Posted by keymuu

So, what should I try next????

---

Get rid of the DIV32 or do not use PBPL.

Quote:

---

Originally Posted by mackrackit

Get rid of the DIV32 or do not use PBPL.

---

Ok, that would of course solve the situation ;)

However, I have routines that need precise calculation where ... well 16 bit is not enough, I would need about 24 bits to calculate what I need to calculate.

So, if Microchip provides a LONG variable for v2.50 users it should also work... or? :confused:

What is wrong when getting those errors an warnings? Please help!

Quote:

---

Originally Posted by keymuu

So, if Microchip provides a LONG variable for v2.50 users it should also work... or? :confused:

What is wrong when getting those errors an warnings? Please help!

---

IF you use PBPL ...

May be you should declare your DIV relevant vars as LONG ... no ???

IF you use DIV32

May be you've noticed it's ( ONLY ? ) a 31 x 15 bits operation ... Manual $ 4.17.8

Quote:

---

that need precise calculation

---

This sentence always make me laugh !!! may we know about those calculations ???


Alain

PS:

Quote:

---

So, what should I try next????

---

To re-arrange your program not to exceed the 32k limit ... probably some redundant or overkilling calculations ...
BTW ... I remember Skimask ( Wish you a happy new year ,Ski ! ) wrote an interesting paper about that on this Forum ...

Quote:

---

Originally Posted by Acetronics

IF you use PBPL ...

May be you should declare your DIV relevant vars as LONG ... no ???

IF you use DIV32

May be you've noticed it's ( ONLY ? ) a 31 x 15 bits operation ... Manual $ 4.17.8

---

Yes, I know that and have build hundred of lines to calculate what I need (but have not tested that yet),
in one place I need:
'------- ex. L = 349,989/2 = 349989/2 = 174,995 => 174995
'------- ' (L/2)^2 = (L/2) * (L/2) square it
That should give 30 623 250 (=01 d3 46 12h)
and this is not the only one.

So it would really be nicer to use the LONG variable instead of doing tricks and getting the program longer.
By tricking I mean something like this:
lsb = L0.0 : mL0 = L0 >> 1 ' remember lsb, then shift lower 8 bits right
mL0.7 = L1.0: mL1 = L1 >> 1 ' shift middle
mL1.7 = L2.0: mL2 = L2 >> 1 ' shift higher 8 bits right

Or saying it in other words if you can (on the upper level) do the same thing within 10 lines instead of 200 lines, why wouldn't you try to do so then?

Quote:

---

This sentence always make me laugh !!!

---

So, you will live longer...;)

Quote:

---

may we know about those calculations ???

---

I will send the formula later...

Quote:

---

To re-arrange your program not to exceed the 32k limit ... probably some redundant or overkilling calculations ...

---

There still room for the program to grow. At the moment 28632 bytes used + 1k for the bootloader... so the limit is not close yet, but I think tricking would bring it fast closer:(

Quote:

---

BTW ... I remember Skimask ( Wish you a happy new year ,Ski ! ) wrote an interesting paper about that on this Forum ...

---

What kind of story would that paper tell?

Still I think, if Microchip provides PBPL then it also should work... you could convert your existing program to using LONG if you have use to it. If you have then remove your DIV32 (possible R0 and R2) and use LONG variables instead. Isn't that neat?

Or do you not think so???

keymuu,

Have you seen this?
http://www.melabs.com/resources/articles/longs.pdf

For what it is worth, I have been going the 18F way just so I can use LONGS and not have to do the "tricks".

You still have to deal with the decimal point in the usual way, but we have to have a challenge some place :)

Quote:

---

Originally Posted by mackrackit

keymuu,

Have you seen this?
http://www.melabs.com/resources/articles/longs.pdf

For what it is worth, I have been going the 18F way just so I can use LONGS and not have to do the "tricks".

You still have to deal with the decimal point in the usual way, but we have to have a challenge some place :)

---

Thanks Mackrackit.

We do not have floating point variables so we have to deal with the decimal point somehow else. When you have enough bits (32) it is so easy to ... we have ten fingers ;)

I have not seen that earlier, I will print that article longs.pdf and read it tomorrow or so when I do not have my computer in front of me.

So, is it really true that nobody can tell what caused the errors and warnings in #3 ... :confused:

Please, if you can give some hints of what might cause those errors and warnings, please let me know

Can we see the code that gave the errors?

Quote:

---

Originally Posted by mackrackit

Can we see the code that gave the errors?

---

The code is not ready, not tested, except for i/o-extender, eeprom and rtc, the "big picture" is just written but not tested except for compilation:

The attached code compiles without errors with PBP,
but not with PBPL (gives those errors in #3)...:(

Really hoping it reveals something :)

To be honest I have not played with USB yet, so I may be full of it as usual... but I may have found a solution.
Read Steve's note on this post.
http://www.picbasic.co.uk/forum/show...8&postcount=99

Quote:

---

Originally Posted by mackrackit

To be honest I have not played with USB yet, so I may be full of it as usual... but I may have found a solution.
Read Steve's note on this post.
http://www.picbasic.co.uk/forum/show...8&postcount=99

---

I'm using PIC 18F4550 :rolleyes:
You say that you may have found solution... Are you referring to the 18F4550.BAL? If so then the solution is not there, because I have that file in C:\PBP directory. If you are pointing to something else, please let me know what you are pointing at! Thank you anyway for trying to help me on this matter...

You can see the code that can be compiled without errors with PBP but not with PBPL...

...So, do you have any other suggestions, how to proceed from here...?

You can't put these lines in your program.

Code:

---

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

---

They are in that .bal file Dave was talking about.

And you need the .bal in the USB18 folder, not the one in the PBP folder.
<br>

Quote:

---

Originally Posted by Darrel Taylor

You can't put these lines in your program.

Code:

---

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

---

They are in that .bal file Dave was talking about.

And you need the .bal in the USB18 folder, not the one in the PBP folder.
<br>

---

Thanks Darrel!

I'm confused, I have the same file in both places and when comparing them, they are equal. I do not know how there could be a difference between a file that is in two places, they should be equal, shouldn't they?
If they aren't equal, which one is more valid, or 100% valid? :confused:

Maybe I have overwritten one? Could this be possible?????

The problem here is not yet solved, but thank you all for your help so far. :)

I will take a brake and will be back again after 8 days, in the meanwhile I shall .... don't be envious ... perhaps I tell you afterwords what I did during those 8 days...;)

It's very likely that you've overwritten one.
Here's what they should look like...
<table border=1><tr><td>PBP folder

Code:

---

'****************************************************************
'*  18F4550.BAL                                                *
'*                                                              *
'*  By        : Leonard Zerman, Jeff Schmoyer                  *
'*  Notice    : Copyright (c) 2007 microEngineering Labs, Inc.  *
'*              All Rights Reserved                            *
'*  Date      : 06/29/07                                        *
'*  Version  : 2.50                                            *
'*  Notes    : Long                                            *
'****************************************************************

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
'EEPROM  $F00000, $F000FF
LIBRARY "PBPPI18L"
'LIBRARY "PBPUS18L"

        include "PIC18EXT.BAS"

PORTL  VAR    PORTB
PORTH  VAR    PORTC
TRISL  VAR    TRISB
TRISH  VAR    TRISC

        include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------*

---

</td><td>USB18 folder

Code:

---

'****************************************************************
'*  18F4550.BAL                                                *
'*                                                              *
'*  By        : Leonard Zerman, Jeff Schmoyer                  *
'*  Notice    : Copyright (c) 2007 microEngineering Labs, Inc.  *
'*              All Rights Reserved                            *
'*  Date      : 05/09/07                                        *
'*  Version  : 2.50                                            *
'*  Notes    :                                                *
'****************************************************************

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
'EEPROM  $F00000, $F000FF
'LIBRARY "PBPPI18L"
LIBRARY "PBPUS18L"

        include "PIC18EXT.BAS"

PORTL  VAR    PORTB
PORTH  VAR    PORTC
TRISL  VAR    TRISB
TRISH  VAR    TRISC

        include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------*

---

</td></tr></table>

Quote:

---

If they aren't equal, which one is more valid, or 100% valid?

---

They are both 100% valid.
One is used for USB, the other is used for NON USB programs.
<br>

Quote:

---

Originally Posted by Darrel Taylor

It's very likely that you've overwritten one.
Here's what they should look like...

They are both 100% valid.
One is used for USB, the other is used for NON USB programs.
<br>

---

Thank you Darrel, you have sharp eyes and clearly a brain behind those eyes!

I'm back from a nice one week refreshing holiday, with new energy...

After correcting my own mistake (overwriting 18F4550.bal) there was “real” progress :), reduced the amount of errors [126] and warnings [220] to only four, but brought back “an old problem”... :(
“ERROR: Macro USBINIT? Not found in macro file”
and those three other errors also (usbservice,usbin,usbout).

Searched around this thread “ERROR: Macro USBINIT? Not found in macro file” and read every mail that was somehow related to this situation and the only difference I could find was that PBPUSB18.MAC should be in C:\PBP\USB18 directory. I checked that and did not find PBPUSB18.MAC file in C:\PBP\USB18 directory. Why did my USB work earlier without that file in USB18 directory?

So to try something I dropped a copy of it there, as advised somewhere around here, but unfortunately it did not help this kind of an old problem... I had USB working earlier with PBP but what now when trying to get PBPL working?

Any suggestions how to proceed from here? :confused:

Quote:

---

.... don't be envious ... perhaps I tell you afterwords what I did during those 8 days...

---

WELLL.... make me turn green :)<hr />

The compiler doesn't actually look in the USB18 folder.

Any files in that folder that are needed for your program should be COPIED into the same folder as your project.

And your project should not be in the PBP folder. It should be in it's own separate folder somewhere else.

The macro not found error usually means that it's not finding LIBRARY "PBPUS18L" in the .bal file. If you haven't COPIED the .bal file from the USB18 folder into your project folder, then it finds the one in the PBP folder, which has the wrong library line commented.
<br>

Quote:

---

Originally Posted by Darrel Taylor

WELLL.... make me turn green :)<hr />

---

Green is one of the major colors of nature...:D

Quote:

---

The compiler doesn't actually look in the USB18 folder.

---

Ok

Quote:

---

Any files in that folder that are needed for your program should be COPIED into the same folder as your project.

---

I have learned that somewhere earlier... but ...

Quote:

---

And your project should not be in the PBP folder. It should be in it's own separate folder somewhere else.

---

This is kind of new to me! I have known that that all (including your project) should be in the same in same folder, meaning all should be in C:\PBP. I was earlier wondering why MicroCode Studio has as default folder C:\Program Files\Mecanique\MCS ? Maybe this explains it then... and I should have copied things there instead of the contrary action... copying all to C:\PBP

Quote:

---

The macro not found error usually means that it's not finding LIBRARY "PBPUS18L" in the .bal file. If you haven't COPIED the .bal file from the USB18 folder into your project folder, then it finds the one in the PBP folder, which has the wrong library line commented.
<br>

---

In the C:\PBP\USB18 folder I can only find PBPUS18L.LIB no other files with the name "PBPUS18L", and it looks like this:

Code:

---

;****************************************************************
;*  PBPUS18L.LIB                                                *
;*                                                              *
;*  Notice    : Copyright (c) 2007 microEngineering Labs, Inc.  *
;*              All Rights Reserved                            *
;*  Date      : 05/09/07                                        *
;*  Version  : 2.50                                            *
;*  Notes    : PIC18 USB library w/ longs                      *
;****************************************************************

        include "\PBP\PBPPI18L.LIB"
        goto MAINPROG
        include "USB18.INC"
        include        "USBDESC.ASM"        ; Application specific descriptors
        include "USB18MEM.ASM"
        include        "USB18.ASM"

MAINPROG

---

Is that looking normal?

The same file is also in C:\PBP folder as well as
PBPUS18.MAC.
pbppic18.lib
pbppic18.mac
PBPPIC18.RAM
PBPUS18L.MAC
USB18.asm
USB18Mem.asm
usb18.inc
18F4550.bal
18F4550.BAS

The 18F4550.BAL looks like this:

Code:

---

'****************************************************************
'*  18F4550.BAL                                                *
'*                                                              *
'*  By        : Leonard Zerman, Jeff Schmoyer                  *
'*  Notice    : Copyright (c) 2007 microEngineering Labs, Inc.  *
'*              All Rights Reserved                            *
'*  Date      : 05/09/07                                        *
'*  Version  : 2.50                                            *
'*  Notes    :                                                *
'****************************************************************

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
'EEPROM  $F00000, $F000FF
'LIBRARY "PBPPI18L"
LIBRARY "PBPUS18L"

        include "PIC18EXT.BAS"

PORTL  VAR    PORTB
PORTH  VAR    PORTC
TRISL  VAR    TRISB
TRISH  VAR    TRISC

        include "PBPPI18L.RAM"

'*-----------------------* EOF 18F4550.BAL *--------------------*

---

Is that looking ok?

I created a new folder C:\PBP\Proj where I copied all those files also with my project, so now something still are missing from folder "Proj" when getting those same four USBmacro errors. I can't figure out what is still missing.
What can be missing?

Can you see what is missing?

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

Quote:

---

Originally Posted by mackrackit

I can not help much with the USB problem, but I would store my projects in a directory some place other than a sub directory of PBP. C:\projects woud be good. Most of my projects are on a flash drive or a SD card to make it easy to move from machine to machine.

When you have projects in the PBP ditectory and it comes time to upgrade them you will have to go find all of your "stuff" before it is deleted or over written during the new install.

---

Thanks Dave! :)

Really interesting. What you said is of course true and logical.

I moved all from C:\PBP\Proj to C:\PBProj and compiled again I got rid of those four errors and instead I got "too many errors" meaning four Error[126] \PBP\PBPPI18.LIB 722 : argument out of range (34218 not between 0 and 32767) and that line in .LIB file is "CALL Label", and that drills me, does that mean Label is too far away or what? If this is true, how can one correct that? This brings me back almost to square one :(

Quote:

---

argument out of range (34218 not between 0 and 32767)

---

That means your program is larger than the 32k bytes (16k words) available on the 4550.
<br>

Quote:

---

Originally Posted by Darrel Taylor

That means your program is larger than the 32k bytes available on the 4550.
<br>

---

:confused: Could that mean anything else? :confused:

When compiling with PBP (not PBPL) it is 28632 bytes and of course there can not be any longs yet involved when still struggling to get it compile with PBPL. Or, would PBPL build bigger code than PBP when not using VAR LONGs ?

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

Quote:

---

Originally Posted by Darrel Taylor

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

---

Thank you Darrel, thank you indeed :) You are real PIC wizard :p

So, I will see in future if it is worth to go back to PBP from PBPL...
The code compiled before with PBP=28632 bytes, then I moved away from the code that math that needs more precision and compiled it then with PBP=26026. This indicates that my 16 math eats 2606 bytes that later can be replaced with 32bit math and surely not taking so many lines (and bytes), I removed 280 lines. Now compiled with PBPL=28274, it will be interesting to see how close to limit (32k) the final compilation will be.

Thanks again, and thank you all others also, Dave, Alain, Charles ... :)

Quote:

---

Originally Posted by Darrel Taylor

In PBPL, ALL system variables are LONGs. ALL intermediate math is done as LONGs. Even multiplying 2 bytes can use LONGs.

Longs take more code than words.
So a PBPL program will ALWAYS be larger than a PBPW program.
<br>

---

Hopefully this is the last question on this subject:

When using PBPL you are not allowed in any part of your formula to have any intermediate results over 32bits! Is this a correct claim or not?:confused:

The question arise from the following formula:
R = ( (H^2) + ((L/2)^2) ) / H and for example
where
L = 315,103 -> 315103 (=LONG)
H = 37,234 -> 37234 (=WORD)

That should give R=703,9 (=WORD)

But instead of that you run to a strange error. When I remove that formula from the program it compiles correctly altogether to 28640 bytes. When I change the formula just to (L/2)*(L/2) gives also a similar error
Error[126].... (32770 not between 0 and 32767) indicating that the (L/2)*(L/2) would take 4130 byte (=32770-28640)
If I use the original formula (R=...) then the exceeding number groves from 32770 to 32886 an increase of 116 byte.

What is going on? Is it really true that you can not calculate in the middle of your formula any bigger value than 2 147 483 647!
(L/2)*(L/2) gives 2 482 247 515 and that is just little over ;) but it is over and one could suspect that to be the reason to this.

How to overcome such a situation? Please let me know:)

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

Quote:

---

Originally Posted by mackrackit

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

---

Thanks Dave!

Nice try... however it doesn't work, you need all the bits to get the result R correct. Easy to test this with Excel :o

Actually (L/2)^2 could be calculated earlier in the PC and programmed as a constant to PIC. Then it would reduce the formula
to
R=(H*H + Lsqr2)/H
and
in this case the constant Lsqr2 = 24 822 475 152 and this is too big also for the LONG variable but now used only as a input to the formula. We could also see the formula like this:
R= (H*H)/H + Lsqr2/H = H + Lsqr2/H, this would reduce all calculation to just one little bit tricky (too many bits) part

=> Lsqr2/H

How could this be compiled easily? 35 bits with 16 bits, is it easily done or does it demand some special technique?

If you know, please advice ...

Quote:

---

Originally Posted by mackrackit

Try dividing "L" by 10 at the first to knock it down a bit.
Then after all of the other calculations multiply the 10 back in.
As long as the final result is smaller than a LONG it should work.

It might keep everything down to word size too.

---

Dave! After all there might be some idea ...:cool:

Let's say L=350123 and H=37234

And as you remember Lsqr2/H = L*L/2*2/H
that also could be written
L/4 * L/H

Then L/4=87530,75 ................. L/4 still over 16bits :(
L/H=9,403314175 ........
But if we divide L with 8 we get L/8=43765,375
and if we take the integer part 43765 (within 16bits!) and the decimal part 0,375. Let us call the integer part Lint and the decimal part Ldec, and we could first calculate Ldec= 8*0,375 = 3
Now we would have everything small enough... After the calculation we need to divide the result with 1000 and after that use only one decimal.

We are seeking for (L/2)*(L/2)/H/1000 ........if we write the formula

((8*Lint)+Ldec) * ((8*Lint)+Ldec)/ 4 / H / 1000 we will get the same result but

PBP does not compile it correctly and you get 0 as the result. If you remove the /1000 you still get 0. If you do not divide by H you get 1022, if you try ((8*Lint)+Ldec)/1000 you get 22. ?????????? it should give 350 !

You can see what I'm trying to do... How should one split things to go right in such a situation?
Could you please help me with this "small" problem :)

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

Quote:

---

Originally Posted by mackrackit

((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. :mad:

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

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.

Quote:

---

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?

Quote:

---

Originally Posted by 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.


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 :o ... 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 :confused:

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

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

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

Quote:

---

Originally Posted by mackrackit

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

Hopefully it still reveals something :o

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

Code:

---

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

Quote:

---

Originally Posted by 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...

Code:

---

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 :rolleyes:

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...:cool:
... 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 :)

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

never mind... still thinking too loud here :D

Quote:

---

Originally Posted by keymuu

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>