ROM 2.15 and HP 48GII: Height of ABUFF
Andreas Möller
I just noticed that ABUFF gives a 131x80 GROB on a HP 48GII with ROM
2.15.
Is this supposed to be this way ?
After all the screen of HP 48GII is only 131x64.
Regards,
Andreas
TW
> 2.15.
>
> Is this supposed to be this way ?
There is no support for the 48GII in 2.15 AFAIK
TW
Andreas Möller
thanks for the answer, I tested this in debug4x with emu48 running the
HP 48GII.
Also I am not very familiar with the HP 48GII, so please excuse my
missing knowledge ;-)
Now IIRC there are two versions of the HP 48GII, the older one having
only a serial port and the newer one with serial port and USB.
Some very short questions if you know them from memory:
The ROM of the older 48GII can not be updated ?
The ROM of the newer 48GII can be updated ?
If so, which ROM version can be run on the 48GII ?
And most important: What is the height of ABUFF on a real machine ?
Will it always be 131x64 or are there exceptions ?
I am preparing the release of my GUISLV and I´d like to ensure that it
will run on the 48GII as well and for the correct handling of the
screen I need to know the height of ABUFF.
TIA,
Andreas
John H Meyers
and TURNMENUON not bother decreasing it again?
(although RECLAIMDISP does shrink it again).
I seem to recall that using either VV or ED in Jazz (in HP48)
lengthened ABUFF but never shrank it again,
but so what? No other software that I ever used
was affected in any way by leaving it that way.
Does DOLCD> GROBDIM DROP give the correct actual screen heght
(in pixels) on all models of HP48/49/50, or is HP48Gii an exception?
If you can obtain the actual screen height,
as well as any grob's actual dimensions,
is that sufficient to produce working software?
[r->] [OFF]
Andreas Möller
> Doesn't TURNMENUOFF increase the height of ABUFF
This is done inside TURNMENUOFF in SYS-RPL.
To be more specific I am talking about VDISP ( = display grob addr
which is before TEMPOB in RAM and is always 131x64 or 131x80
regardless if the menu is shown or not).
Now if you run emu48 emulating a 48GII with ROM 2.15 than this is
131x80 but it should be only 131x64 but as Tim pointed out this might
be the case because the ROM for the 49G+ / 50G is used. The problem
might vanish if a ROM 2.15 compiled for the 48GII will be used.
> Does DOLCD> GROBDIM DROP give the correct actual screen height
This is too slow, I has to be done in ML or even better: the whole
purpose of this is to avoid any display checks !
> If you can obtain the actual screen height,
> as well as any grob's actual dimensions,
> is that sufficient to produce working software?
Well, no.
I thought I´d be very clever and wrote the display routines that
access the bottom of the screen by counting from the end of the GROB
(as opposed to counting from the beginning) so that I do not have to
check the display size.
This works fine as long as the display GROB matches the physical size
of the screen, otherwise I am accessing parts of the display which are
of the physical screen.
Now this can be fixed by checking VDISP at the beginning of the
program and ensure that this matches the physical resolution of the
screen. That way no checks are needed except for this one at the
start.
Again, this might only be a problem in using the wrong ROM with the
wrong emulation but it would be nice if the software behaves always
the same, regardless if it is a real machine or an emulator ;-)
Thanks for your thoughts,
Andreas
John H Meyers
>> Does DOLCD> GROBDIM DROP give the correct actual screen height
> This is too slow
My programs do it exactly once per invocation,
then they save the numeric result for re-use.
Somewhere within DOLCD>, however,
is code which just determines the actual screen height
(in fact, it is at the very beginning);
how long does it take to execute just that code?
How hard to even pick up the address for calling it,
right out of the DOLCD> function itself?
Surely you can do this!
Meanwhile, when did ROMs stop being compiled for ALL the models,
at the same time, with just a couple of hardware instructions
distinguishing which is which?
It's very difficult to believe that it isn't very easy
to accomodate all hardware AND emulators
in one simple and all-inclusive program,
with no issue of execution time -- those who desire
simplest SysRPL (which works over the entire 48/49/50 series)
can do it in three words (7.5 bytes),
wasting the time to make one grob, one time, that only gets dropped,
while those who are in a great hurry can invest a bit more in ML,
to dig into the very beginning of just the first of those functions.
[r->] [OFF]
TW
> missing knowledge ;-)
Neither do I. When we were talking about the 50g vs 48gII for 2.15 I
was thinking there is a completely separate ROM. That may have been
the case with the older unit. I am not sure about the new one.
> The ROM of the older 48GII can not be updated ?
Nope.
> The ROM of the newer 48GII can be updated ?
Yup.
> If so, which ROM version can be run on the 48GII ?
No idea. Let me know what you find out.
> And most important: What is the height of ABUFF on a real machine ?
No idea.
> Will it always be 131x64 or are there exceptions ?
No idea.
> I am preparing the release of my GUISLV and I´d like to ensure that it
> will run on the 48GII as well and for the correct handling of the
> screen I need to know the height of ABUFF.
Are there not other ways to get it?
TW
Andreas Möller
DOLCD> is ROM dependent !
Code from 1.19-6
(DOLCD> 2EF03 -> FPTR 1 AA=1:6E90E)
::
BINT64
BINT_131d
MAKEGROB
ABUFF
ZEROZERO
BINT_131d
# 38
SUBGROB
OVER
ZEROZERO
GROB!
HARDBUFF2
OVER
BINT0
# 38
GROB!
;
Code from 2.09
(DOLCD> 2EF03 -> FPTR 1 AA=1:6EB22)
::
PTR 2F3D1
BINT_131d
MAKEGROB
ABUFF
ZEROZERO
BINT_131d
IsBigApple_
ITE
BINT72
BINT56
SUBGROB
OVER
ZEROZERO
GROB!
HARDBUFF2
OVER
BINT0
IsBigApple_
ITE
BINT72
BINT56
GROB!
;
Whereas PTR 2F3D1 gives the height of the current machine:
(2F3D1 -> FPTR 1 578=1:65D8B)
::
IsBigApple_
case
BINT80
BINT64
;
> How hard to even pick up the address for calling it,
> right out of the DOLCD> function itself?
Since this is ROM dependent it can not be used, only the result of
DOLCD> is correct for all ROM versions. And as you can see DOLCD> is a
long and slow SYS-RPL program, at least when it needs to be called
often.
> Meanwhile, when did ROMs stop being compiled for ALL the models,
> at the same time, with just a couple of hardware instructions
> distinguishing which is which?
I do not know. How many people are working on the ROM ?
> It's very difficult to believe that it isn't very easy
> to accomodate all hardware AND emulators
There are a couple of ML entries but do not forget that the Saturnator
and EMU48 not always behave the same. Who´s right or wrong is beyond
my knowledge. But finding these "differences" takes hours of
frustration ;-)
> in one simple and all-inclusive program,
> with no issue of execution time --
Well, there are quite some possibilities.
Take the most recent:
ROM 2.15 works with emu48 emulating a 48GII. Now, is this a bug or a
feature ?
How should a program that uses the whole screen over the entire 49
series behave ?
Only cover the real machines or run as correct as possible on the
emulators, too ? Only run on a specific machine ? Compile different
versions for different machines ? Then what if the “wrong” version is
installed ? Another test needed in the software...
> those who desire
> simplest SysRPL (which works over the entire 48/49/50 series)
> can do it in three words (7.5 bytes),
> wasting the time to make one grob, one time, that only gets dropped,
This is fine if you only need one test, BUT if you are getting into
graphics speed is important. So for faster results you can save the
result of the test somewhere and instead of testing again you have
already the result BUT why do all this testing ?
If I do graphics in ML the fastest way is to write directly into VDISP
without any checks BUT for that it has to be ensured that the GROB has
the same size as the physical display. And as I have just discovered I
can not rely on this, at least for the emulators (I do not have a
48GII to test it on a real machine). And I end up with writing my own
routine which resizes VDISP as I need it...
Just a short history of the various changes:
There is ROM 1.19-6 as the last unofficial ROM for the Saturn, with
trick you can upgrade until 2.09 (where VDISP and ABUFF are 131x80, at
least in the emulator). There was the first ROM for the ARM-machines
which did not support the whole screen (something around ROM 1.20),
then there where some pointers which allowed you to write into the
header, then there was ROM 2.00 which gave a 131x80 VDISP on the 49G+
so no need for the header patches anymore (but they are still present
in the ROM), etc. and for sure I have forgotten some...
Also there are still a lot of applications in the ROM which do not
take advantage of the larger screen in the 49G+/50G.
> while those who are in a great hurry can invest a bit more in ML,
> to dig into the very beginning of just the first of those functions.
Again, this can not be used because it is ROM dependent so you end up
with your own routine which resizes VDISP to your desired size and
then you do not have to worry about anything...
Hopefully that shed some light into the various display problems.
However, it looks as this is working fine and that I can release my
GUISLV (which is using the so slow DoinputForm as I do not want to
recode everything, unfortunately Raymond does not make his SpeedUI
available for the FHB) for all machines (49G/48GII/49G+/50G) shortly.
Regards,
Andreas
Andreas Möller
> there is a completely separate ROM.
Well, the ROM code contains areas where the height is tested, as in
YHIpatch ( FPTR 1 578). And there are various areas where the code is
compiled depending on conditional assembly (f49GPLUS) like in
=SHRINKVDISP or in the CAS. But who knows if a ROM 2.15 for the 48GII
was compiled and published ?
Can one flash a 48GII (the newer ones) with the ROM for the 49G+ ?
> No idea. Let me know what you find out.
ROM 2.15 looks o.k. in the emulator at a first glance but for sure all
this f49GPLUS definitions are there because they mean something ;-)
> > And most important: What is the height of ABUFF on a real machine ?
> No idea.
>
> > Will it always be 131x64 or are there exceptions ?
> No idea.
O.K. I have a fast ML code based on SHRINKVDISP which can be used to
ensure that VISP and ABUFF are corrected to the needed/desired size,
then I do not need to test the screen anymore.
> > I am preparing the release of my GUISLV and I´d like to ensure that it
> > will run on the 48GII as well and for the correct handling of the
> > screen I need to know the height of ABUFF.
>
> Are there not other ways to get it?
All other ways are slower and DoIFIRoot is already so slow because it
relies on DoInputForm and the display handling of this is so
incredible slow. The core routines of it should be rewritten (eg. the
update of the flags for the FAreaStates is done in SYS-RPL and a
rewrote of this in ML took me 30 min. and is 20 times faster :-)
I´ll keep you informed.
Regards,
Andreas
TW
From my understanding there must be a separate build for the 48gII and
there has never been one released for that calculator anyway. Since
2.15 really doesn't add a whole lot, I don't think it was worth our
time to spend doing it and testing. When/if there are important and
significant changes that will be reconsidered.
TW