Prev: Problems with headers in User-RPL
Next: Convert units on HP50 as on HP48
From: Claudio Lapilli on 2 Apr 2007 12:33
On Apr 2, 4:28 am, "Stefano Priore" <Stefano.Pri...(a)gmail.com> wrote:

> Hmm, there are still some bugs to iron out in FMAN...

Not that I know of... let's see:

>
> 1) CUT doesn't work correctly: it performs always a COPY

It works correctly. Look next to the name of the original object,
you'll see a "D" indicating it's a deleted object when you use cut.

> 2) When I pack some banks the program errors out with a "EVAL: Bad
> Argument Value" error. It must be noticed that I run FMAN putting it
> on the stack and pressing EVAL. After the error FMAN is still on the
> stack and no memory looks corrupted.

If you get an error is because the operation failed, most likely
because you don't have enough memory to do the packing, but it could
happen that your bank is corrupted somehow and it's giving you an
error. It's an assembler program dealing with low-level stuff, so if
you see an error messsage it's because the condition was detected and
the error delibratedly generated, no data corruption should occur in
such case. The stack is restored to what it was when you called the
program, as in any error condition. So this is not a bug, it's an
error condition properly dealt with.
Don't worry, if there's an error I didn't take care of, your calc will
crash and probably wipe off your memory, no nice error messages when
you do low-level stuff :-). But I'm confident it's working fine, as I
didn't lose my memory yet.

Still, I don't know what could be wrong with that specific bank,
though. Try deleting all objects first, then repack.


Claudio

From: Damir on 2 Apr 2007 12:37

......
>
>Still, I don't know what could be wrong ...
>
......

Maybe older version?

Damir
From: John H Meyers on 2 Apr 2007 19:41
On Sat, 31 Mar 2007 18:48:46 -0500, Claudio Lapilli wrote:

> I fixed a bug on PFREE, also improved the free memory calculation,
> added support for the big screen and skipped the flash banks
> that are no longer used in the ARM models.

Then it's already not 49G compatible; by the way,
PFREE (written for 49G) manages to keep working in 49G+ etc.,
although it might be good to suppress it from displaying anything
for non-existent areas.

> [PTR 35069] is TYPELIB?,
> it may be unsupported but it's on EXTABLE

Not in mine -- downloaded yesterday from
http://www.hpcalc.org/details.php?id=3245
http://www.hpcalc.org/hp49/programming/entries/extable.zip

> it should be the same between 49G and the G+ models.

The code I find at that address in my ROM [claiming to be 2.10] is:

35069 A=A-1 A
3506B A=DAT1 P
3506F GOC 3509B ["Error: Insufficient Memory" if I look there!]
35072 CLRST
35074 GONC 350E7
35077 LC 725802686351C

Is that what you find in your ROM?

[r->] [OFF]
From: Claudio Lapilli on 2 Apr 2007 22:29
On Apr 2, 7:41 pm, "John H Meyers" <jhmey...(a)nomail.invalid> wrote:
> On Sat, 31 Mar 2007 18:48:46 -0500, Claudio Lapilli wrote:
> > I fixed a bug on PFREE, also improved the free memory calculation,
> > added support for the big screen and skipped the flash banks
> > that are no longer used in the ARM models.
>
> Then it's already not 49G compatible; by the way,
> PFREE (written for 49G) manages to keep working in 49G+ etc.,
> although it might be good to suppress it from displaying anything
> for non-existent areas.

Well, I added "detection" of the new model but supposedly keeping old
model compatibility.
I used the new virtual opcode BIGAPP?, which IIRC should simply be
ignored in the old hardware. My logic worked fine becaue I tested it
with the emulator on a 48GII, which returns false to the BIGAPP?
question and the program worked fine, and adapted its display to the
smaller screen correctly.
At this point I don't know what could be causing incompatibiliy with
the old model. If it's true that the old hardware ignores the new
opcode, then it should simply work like it does on a 48GII.


>
> > [PTR 35069] is TYPELIB?,
> > it may be unsupported but it's on EXTABLE
>
> Not in mine -- downloaded yesterday fromhttp://www.hpcalc.org/details.php?id=3245http://www.hpcalc.org/hp49/programming/entries/extable.zip

Sorry, I should have said EXTABLE2 from Carsten Dominik. I've used his
address database for years and is very reliable and more complete than
the official.

>
> > it should be the same between 49G and the G+ models.
>
> The code I find at that address in my ROM [claiming to be 2.10] is:
>
> 35069 A=A-1 A
> 3506B A=DAT1 P
> 3506F GOC 3509B ["Error: Insufficient Memory" if I look there!]
> 35072 CLRST
> 35074 GONC 350E7
> 35077 LC 725802686351C
>
> Is that what you find in your ROM?

Yes, identical code (but that's not the code that gets executed,
though, it doesn't make any sense). And I also got the strange error
in Nosy when I tried to look there. But TYPELIB? is not causing a
problem. I just tried :: CK1 TYPELIB? ; with different objects on the
stack and got the expected behavior (TRUE for LIBS, FALSE for
everything else).
I've used the same PTR in FixSTO of the ARMToolbox and it never
failed, tested by lots of people with rom versions starting with 1.23
up.

Claudio

From: John H Meyers on 3 Apr 2007 02:48
On Mon, 02 Apr 2007 21:29:49 -0500, Claudio Lapilli wrote:

> I just tried :: CK1 TYPELIB? ; with different objects
> on the stack and got the expected behavior
> (TRUE for LIBS, FALSE for everything else).

> I've used the same PTR in FixSTO of the ARMToolbox and
> it never failed, tested by lots of people with rom versions
> starting with 1.23 up.

Okay, :: CK1 PTR 35069 ; seems to work in "2.10" --
it's "Nosy" that didn't work, then :)

[r->] [OFF]
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Problems with headers in User-RPL
Next: Convert units on HP50 as on HP48