Emu48 1.40 odd behavior with 49G
John H Meyers
this same quirk, which previously I had never experienced:
While emulating my HP49G, immediately following any
File > Save [or] Edit > Backup > Save [or Restore]
my next "keypress" invariably invokes my STARTOFF;
similarly, every time I start Emu48 emulating my 49G,
even if I have declined to save upon the previous exit,
my very first "keypress" invariably invokes STARTOFF.
I currently have TOFF stored as #FFFFFFFFFFFFFFFFh
in the current directory, and as this is greater than
the age of the universe (as well as the fact that merely
saving the current state should not change anything, and
that earlier Emu48 versions never exhibited this behavior),
I don't think that this explains anything.
Thanks for anyone else experimenting or furnishing any clue.
[r->] [OFF]
Christoph Giesselink
as ACO told us in the FDP About box "To boldly go where no calculator has
gone before.", so Vger isn't from this universe and independ from the limits
of this one. As Einstein told us: "Time is relative". When we then use the
HP49G #FFFFFFFFFFFFFFFFh TOFF time as reference for the age of our universe,
our universe life is less than one second! ;-)
To say it in simple words, the HP49G v1.19-6 TOFF implementation with high
values is totally buggy. I compared the Emu48 v1.40 behavior with real a 49G
and they behave equal with the #FFFFFFFFFFFFFFFFh TOFF value. You haven't
examine this behavior because you have a STARTOFF function installed,
without the calculator will shut down very quick.
On Emu48 a max. value of #E2858FFFFFFFFh for TOFF worked (not
#E285900000000h), but I recognized somtimes crashes of the calculor OS and
with higher TOFF values I sometimes got a corrupted calculator time in
display. It seem that to high TOFF values cause a buffer overflow destroying
some system variables, but I'm not sure about this. I got really trouble to
reanimate my real HP49G after a crash during tests on the real calc. I found
no reference about the highest valid number for TOFF, somebody else found
one?
I think Emu48 behave in the same way like the real one in this topic. An
explanation of your behavior with the File and Edit menu points maybe, that
all commands you described stop the current emulation doing the menu point
topic and restart/continue the emulation again. Every engine restart
reprogram/adjust the real time clock memory registers in user memory.
Hope this helps,
Christoph
"John H Meyers" <jhme...@miu.edu> schrieb im Newsbeitrag
news:op.s26pr...@news.cis.dfn.de...
Frère-Pierre
news:dq3cbr$mes$00$1...@news.t-online.com...
X
What is the max TOFF value?
Is the timer 32-bit?
a few days sounds reasonable,
while the practical limit for an average user is much lower
John H Meyers
Christoph Giesselink kindly replied:
> To say it in simple words,
> the HP49G v1.19-6 TOFF implementation with high values
> is totally buggy.
Well, I may have introduced a "red herring" here,
in that a turn off immediately upon starting Emu48
has been a recent new phenomenon for me anyway,
ever since I updated to a version saying
"copy/paste stack" in place of "copy/paste string,"
occurring even when my TOFF was always just
a very reasonable #258000h (five minutes),
as I posted here on 2005/12/21:
http://groups.google.com/group/comp.sys.hp48/msg/bfec7f2ecd3d71d1
Only a couple of days ago did I also store that "high value"
into TOFF, which introduced even more new anomalies,
which I mistakenly associated with the earlier issue,
but in fact the immediate turn off on the first action
after starting Emu48 (only for 49G emulation)
never happened with my old Emu48 versions, started only recently,
and occurs with a perfectly normal TOFF as well.
I'm sorry for exaggerating and obfsuscating the issue
by storing a new bad TOFF value, but there was actually
a lesser original issue to begin with, and I resubmit
this more careful report to you again about it now :)
Maybe I have done something else myself that I can't identify,
but it keeps seeming to me to have started occurring
immediately after a version update, with no changes
to my memory image other than small program improvements
and making new "backups" (stored into emulated ports 1 & 2).
> Every engine restart reprogram/
> adjust the real time clock memory registers in user memory.
Even my 49G+ is acting a bit like this,
in that I have scheduled a 4:00am "control alarm,"
intended for my real calcs only,
which does only #0 CLKADJ STARTOFF
(formerly #0 was non-zero, back when CLKADJ accomplished something :)
But when I actually turn on my 49G+ the next day,
it seems to turn itself right back off again,
as if it didn't really "spring" that overdue scheduled
"control alarm" until I just now turned it on.
Has the standard Emu48 been modified in any way
to accomodate anything at all of the 49G+,
or are these curious phenomena merely unrelated coincidences?
Thanks again for your extensive comments and information,
as well as for the ever evolving and invaluable emulator.
[r->] [OFF]
Christoph Giesselink
> [..]
> "copy/paste stack" in place of "copy/paste string,"
> occurring even when my TOFF was always just
> a very reasonable #258000h (five minutes),
> as I posted here on 2005/12/21:
> http://groups.google.com/group/comp.sys.hp48/msg/bfec7f2ecd3d71d1
Sorry, I followed the above thread only for some days so I missed your
question about the copy paste problem.
Definitely every string which is a valid real number will interpreted as
real number when pasting from the clipboard. If the string contain a non
real number character (i.e. space) or using an invalid decimal number format
(i.e. two decimal points, sign character on wrong position, ...) the
clipboard object will still pasted as string.
I done this modification because I often exchange real numbers between an
editor and Emu48 and to have the ability to exchange numbers between a
HP48SX (on Emu48) and HP42S (on Emu42).
> [..]
> Has the standard Emu48 been modified in any way
> to accomodate anything at all of the 49G+,
No it hasn't. The Emu48 emulator versions published on my homepage don't
contain any 49G+ related code.
But in some of the last Emu48 updates I done some bugfixes in the timer
emulation and especially I improved timer2 interrupt accuracy for better
display gray scale emulation (reduced sysnchronisaion losses). Maybe that I
there introduced a new bug?
> or are these curious phenomena merely unrelated coincidences?
When I start my 49G emulation or calling the menu topics you mentioned my
emulated 49G isn't switching off. But I have no TOFF and STARTOFF variable
in use. Maybe interesting what's happen when you temporay remove them from
your emulation?
Another point, somebody put my attention to the case that with the 49G v1.24
ROM version the beep patch don't work any more. The patched function
=makebeep has been moved in v1.24, so using ROM rev 1.24 with the old beep
patch file will corrupt a ROM function. Which ROM version do you use?
I use 1.19-6.
Finally I have still all Emu48 EXE files I officially published (no beta
versions). If I recognized such a behavior like worked earlier and now not
any more, I look for the lasted version which worked properly. Then I look
for the changes in the history and compare the sources of last working and
the first non working version.
So John, when you want to go back to an earlier version to detect this point
of working/nonworking I can send you the EXE's. An archive of the last 11
versions v1.30 (Mar 19th 2002) - v1.40 (Dec 13th 2005) has only a size of
~1MB so it can be send easily by Email.
Cheers
Christoph
John H Meyers
> with the 49G v1.24 ROM version the beep patch doesn't work any more.
> The patched function =makebeep has been moved in v1.24,
> so using ROM rev 1.24 with the old beep patch file
> will corrupt a ROM function. Which ROM version do you use? I use 1.19-6.
I was using some flavor of 1.19-6 in Emu48 up to now, but have just
started using 1.24 today, thanks to your help in another thread.
I don't recall what the =makebeep patch is for;
I've just commented out the patch for my 49G,
and ROM 1.24 in Emu48 now passes the "FullROM" self-test: ON+D,7
With no patch, I presume that I can use ROMUPLOAD in Emu48
to update my real 49G, right?
> when you want to go back to an earlier version...
Yeah, I want to go back maybe a couple of decades
and do some things differently -- can you arrange that?
[r->] [OFF]
Eric Smith
> Definitely every string which is a valid real number will interpreted as
> real number when pasting from the clipboard. If the string contain a non
> real number character (i.e. space) or using an invalid decimal number format
> (i.e. two decimal points, sign character on wrong position, ...) the
> clipboard object will still pasted as string.
Might be useful to have a "Edit/Paste as" submenu that allows overriding
this behavior?