▼
Posts: 1,368
Threads: 212
Joined: Dec 2006
Hi all,
Forgive the very rudimentary nature of this question, but I just got an HP49G+ and have never owned an HP49G, so I really don't know.
Are programs, libraries, and files that run on the HP49G in general usable or not on the 49G+?
I ask because I am trying to load and run the Demo version of Hrast's HP41X. I can load and save it according to the documentation's very clear instructions, but on trying to run the emulator the keypad doesn't respond, and I can't escape the hung program without taking out a battery.
Is this something peculiar to me, this library, or a general 49G/G+ intercompatibility issue?
I already have a question into Hrast directly about HP41X specifically, but I thought I would post it here to see if there were some general guiding principles regarding the compatibility between these two calculators.
Les
▼
Posts: 709
Threads: 104
Joined: Nov 2005
I own neither, but have read on comp.sys.hp48 that there have been changes in the ROM. I would presume that Hrast's programs are written in low-level languages so that ROM changes could affect compatibility. Also, I recall reading that even within the HP49G+ series some of the keycodes have changed as the ROM was updated.
It's rather late now, and I'm not sure what I wrote even makes sense =) I'll double check this post tomorrow and see if I can add some references.
Han
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
Are programs, libraries, and files that run on the HP49G in
general usable or not on the 49G+?
For pure UserRPL source code (no SYSEVAL, LIBEVAL, FLASHEVAL, or
menu 256 commands), the 49G and 49g+ should, for the most part, be
interchangeable. Exceptions would be that animations may well run
faster on the 49g+, the keyboard mapping is a bit different, and
the 49g+ display has 80 pixel rows instead of 64. Of course, the
49G doesn't have IR at all, and the 49g+ has IrDA and USB for I/O,
along with the "RedEye" IR for printing to the 82240A/B; the
defaults for I/O and printing flags may well differ, and IOPAR
certainly does. Also, some 49G bugs were fixed in the 49g+, and
some may have been added, which may make a difference.
Much the same should apply to programs and libraries that use
supported SysRPL commands and assembly language
instructions. But note that some new assembly language instructions
are added with the 49g+; they won't work with the 49G, and I'm not
sure whether they're considered "supported".
If you use something unsupported, it may or may not work on another ROM
revision.
Quote:
I ask because I am trying to load and run the Demo version of
Hrast's HP41X. I can load and save it according to the
documentation's very clear instructions, but on trying to run the
emulator the keypad doesn't respond, and I can't escape the hung
program without taking out a battery.
Is this something peculiar to me, this library, or a general
49G/G+ intercompatibility issue?
I don't know.
Quote:
I already have a question into Hrast directly about HP41X
specifically, but I thought I would post it here to see if there
were some general guiding principles regarding the compatibility
between these two calculators.
In case he doesn't answer (or doesn't know), where did you find
the demo program? Maybe I'll try it on both a 49G and a 49g+.
For what it's worth, here's a snippet of some SysRPL/Assembler
code (MASD syntax) that I used for determining which 49 series
calculator a program is running on:
%%HP: T(3)A(R)F(.);
C$ $
!NO CODE
!RPL
::
* Preceding code here.
* Check whether the program is running on an emulated Saturn ("Apple").
* Returns FALSE for 49G, TRUE for 49g+ or 48gII. IsApple_ won't work on ROMs
* earlier than 1.22.
* The way it works is that the opcode for BUSCC is 80B, and the (Saturn)
* opcode for XM=0 is 821. Extable doesn't include the BUSCC instruction, so I
* use its opcode instead. On a 49G (and earlier models), BUSCC is effectively
* a NOP instruction, and of course XM=0 clears XM. But on the 49g+ and 48gII,
* with the emulated "Saturn+", BUSCC is the "key" to the newly added
* instructions, and the opcode 80B821 (BUSCC XM=0) turns out to be "HST=1 1",
* or another way of saying "set XM". From there, ?XM=0 tests whether XM was
* cleared (49G), or set (48gII or 49g+).
CODE
$80B ; BUSCC opcode. NOP on 49G, but beginning of
; HST=1 1 on Apple.
XM=0 ; Clears XM on 49G, but rest of HST=1 1 on
; Apple.
?XM=0 ; 49G?
SKIPYES ; Dummy GOYES to complete test.
{ ; Dummy block to skip.
} ;
GOVLNG ="PushF/TLoop" ; T/F based on carry. Label quoted to keep
; Masd from treating it as an expression.
ENDCODE
* If it is a 49g+ ("BigApple") or 48gII ("MidApple"), then check which one.
* Return TRUE for 49g+, FALSE for 48gII. If it's a 49G, then just return
* another FALSE.
DUP
ITE
IsBigApple_ (49g+?)
DUP
* FALSE FALSE : 49G
* FALSE TRUE : N/A
* TRUE FALSE : 48gII
* TRUE TRUE : 49g+
* Remaining code here.
;
@
Regards, James
Edited: 1 June 2006, 2:47 a.m.
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
PS:
To get out of the hung program you could try a warmstart by pressing C while holding down ON. If that doesn't work (because of the keyboard not responding), try forcing a warmstart with a paperclip in the the little reset hole in the back of the calculator.
Regards, James
Posts: 1,368
Threads: 212
Joined: Dec 2006
Thanks, gents.
Hrast quickly responded to me and indeed there is an entirely different set of libraries for the G+. There are really very different beasts.
You have to ask Hrast directly for access to the demo versions of HP41X. He has been very kind and helpful to me--above and beyond the call of duty actually, considering I haven't bought his software yet and as an essentially recreational user I am not sure I will yet, since it is a bit expensive and oriented to the serious professional user.
My question is still out there regarding the general compatibility issues. I am grateful for the quick feedback I received so far.
Les
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
I wouldn't think the 49G and 49g+ would be all that different, as long as he
sticks to supported entry points.
Using unsupported entry points may well tie the code to particular ROM
revisions, which strikes me as particularly hazardous with the "ROM" being
actually in flash memory.
I'll add that with the 49g+, it's possible to work with the underlying ARM
processor, as well as with the emulated Saturn+ processor. HP-GCC (see
http://hpgcc.org/) is intended to let you compile C code to run on the
49g+, but note that some find its license rather "restrictive".
I wouldn't personally have much use for HP41X; I'd much rather have an RPL
calculator.
Regards, James
▼
Posts: 381
Threads: 32
Joined: Mar 2006
I wouldn't think the 49G and 49g+ would be all that different, as long as he sticks to supported entry points.
This is not a matter of supported/unsupported entries because a few entry points I need for initialization and finalization are supported since HP-48SX. After the initialization, I "cover" the ROM with RAM card(s) and during the execution of the emulator the ROM is disabled (not physically because it cannot be disabled but virtually because it is covered with RAM) and I am not calling a single ROM subroutine until you exit the emulator. The emulator has total control over the machine including interrupts (for example, ON+C is resetting the emulator and not the HP-48GX). 99.99% of the emulator is written in pure machine language and this is where things are much more complicated when you deal with your own interrupt handler, direct memory CONFIGuration/UNCONFIGuration, direct keyboard scanning, direct display handling, direct serial port handling, etc. At this level HP-49G+ is not so very much compatible with HP-49G. You have to "dive" more deeply to see that things aren't so simple as they look at first.
I wouldn't personally have much use for HP41X; I'd much rather have an RPL calculator.
We all have our own preferences. I prefer to have HP-11C/12C/15C/16C/41C/42S RPN, HP-71B BASIC and HP-48GX RPL on the same machine. It is just many times more powerful than a single RPL, at least for me ...
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
For your 49g+ project, are you working at the level of the
emulated Saturn processor, or are you going "deeper" to the
underlying physical ARM processor?
If you're working at the emulated Saturn level, are you using the
newly added Saturn+ opcodes, or sticking to the opcodes available
with the physical Saturn?
Regards, James
▼
Posts: 381
Threads: 32
Joined: Mar 2006
I am using physical Saturn instructions only. The only exception is BUSCC NIBHEX 33 (or something like that) so I can use all 80 display rows for LCD printer emulation on HP-49G+. This worked very well.
But, not all of the emulated standard Saturn instructions are working exactly as in real Saturn CPU. Code which worked for years on HP-48GX, HP-49G (and Emu48, for that matter) suddenly didn't work with HP-49G+ anymore so many incompatibilities exist. For example, CONFIG/UNCONFG are behaving differently but this is to be expected because Port1 on HP-49G+ has only one 128K page available (the second 128K page is available to ARM only). Furthermore, handling hexadecimal values in decimal mode of the CPU (SETDEC) is totally different (this was reported as being fixed lately but I haven't checked because I already made workarounds where needed).
But, the biggest problem is different keyboard/interrupt handling at the lowest level. This has also changed between ROM 1.23 and 2.0x so some routines which worked with 1.23 don't work with 2.00, at the lowest level, of course. But, if you write software with SysRPL or assembler using supported entry points only then it is very unlikely that you will have much trouble, if any.
Best regards.
▼
Posts: 709
Threads: 104
Joined: Nov 2005
Quote:
For example, CONFIG/UNCONFG are behaving differently but this is to be expected because Port1 on HP-49G+ has only one 128K page available (the second 128K page is available to ARM only).
If covering ROM is OK during the use of the emulator, is it not possible to access up to 4 pages of 128KB using Port 1 in a real GX? While not designed to do so via hardware, my understanding is that you can set the next two most significant bits by CONFIG'ing them at certain addresses (basically at the 128KB boundaries) so as to simulate bank selection. These two most significant bits correspond to the least significant bits of the bank selector in Port 2. While I have no TDS software to test this, I suspect that this was how TDS was able to get around the 128KB limit in the SX series.
In fact, I wonder if this is another security measure software developers take when developing surveying software for the HP48. By using a ROM card with more than 128KB of data (say one bank contains default settings that only get copied to HOME), bit copiers which do not account for the larger ROM size will fail in creating a backup copy.
Edited: 2 June 2006, 2:12 a.m.
▼
Posts: 381
Threads: 32
Joined: Mar 2006
Only one 128K bank from the RAM card in Slot 1 can be configured at 128K boundary. You must have a way to activate one of 4 banks from the 512K card. AFAIK, this is not possible with CONFIG. For RAM card in Slot 2 you have a bank switcher which doesn't exist for Slot 1.
This is the code for configuring (next in the device chain) 128K bank to address #40000:
...
LC(5) #C0000 * Size
CONFIG
LC(5) #40000 * Address
CONFIG
...
I don't see where would it be possible to set the next most significant bits here ...
Best regards.
▼
Posts: 709
Threads: 104
Joined: Nov 2005
A 128KB RAM chip has 17 address lines. Suppose we use the convention that A0 through A16 are these address lines. These address lines are hardwired to connector pads 3 through 20 on the card connector. Connector pads 31 and 32 are hardwired to A17 and A18; you can trace them from the PCB as they connect to two more address lines on the ROM chip. Moreover, A18 is multiplexed to also turn on and off the bankswitcher. Ignoring that for now, if one had a normal 512KB card that worked properly, there should be two pins on the RAM card that make contact with connector pads 31 and 32 (as these are responsible for bank selection).
If you stick the 512KB card into card slot one, only one bank is visible. The idea is that we can manual set address lines A17 and A18 by configuring card slot one at the 128KB boundaries. The addresses are:
HEX BIN NA18 A17 BANK #
#00000h #0 0 0 0 ... 1 0 1
#40000h #0 1 0 0 ... 1 1 2
#80000h #1 0 0 0 ... 0 0 3
#C0000h #1 1 0 0 ... 0 1 4
^ ^
| |
A18 ----+ +---- A17
(If I'm not mistaken, A18 might actually be NA18). Thus, by default, storing onto a 512KB card in card slot one in an HP48Sx actually stores it into the third bank of the 512KB card. If you move the card slot to a different address and store onto the card, you end up storing on yet a different bank. The bank correspondence might be wrong, but hopefully you get the idea. Since card slot one of an HP48GX is physically the same as card slot two of an HP48SX (and hence slot one), the same principle should apply.
I think the reason why it is always said that card slot one only handles 128KB is because the first 17 address lines are shared between all memory modules, including ROM. So if you only use a 128KB card, it will not matter what address to which you configure card slot one as the higher bits are essentially ignored by a 128KB card. Read/write operations behave as one would expect them to. However, with larger cards, you end up storing in different banks depending on where the card is configured.
You can test this out yourself. Take a 512KB card and insert it into card slot one. Configure it to, say #00000h and store something into Port 1. Now reconfigure it to say #40000h and store something different into Port 1 (you will notice that the first object stored is no longer there). Do this for the remaining two addresses. Then remove the card from card slot one and place it into card slot two. You should see the four objects you stored, one in each extended port of card slot two.
Oh, I should add that the size you use to configure should still be 128KB, i.e. #20000h (or is it #100000 - #20000h; I forget what the argument is supposed to be but the physical size should be 128KB, not 512KB).
Of course, the limit would be 512KB since using larger cards would then put you into display land. What I mean by this is that since card connector pads 33-36 are for video signals (output only?), you would really get some bad behavior if you had a 1MB card inserted into card slot one.
Edited: 2 June 2006, 3:26 a.m.
▼
Posts: 709
Threads: 104
Joined: Nov 2005
If the above did not make sense, consider the following:
Configure card slot one to #40000h. A nibble gets shifted out, so the two most significant bits correspond to A18 and A17 in hardware. Meaning, when you read or write from address #40000h, A18 is 0 and A17 is 1 during the read/write operation. With a 512KB RAM card inserted into card slot one, this is essentially the selection of one of the four banks. A 128KB card would not have any physical connections to A18 and A17, so these bits are insignificant to a 128KB card.
Posts: 381
Threads: 32
Joined: Mar 2006
Yes, this is all correct. But you cannot configure arbitrary bank to arbitrary address, true? For example, if you configure it to #00000 then (perhaps) bank 0 will be visible, but if you configure it to #40000 then bank 1 will be visible, #80000 for bank 2 and #C0000 for bank 3. You cannot configure banks 1/2/3 to #00000 in this example ... True?
▼
Posts: 709
Threads: 104
Joined: Nov 2005
Yes, that is correct. Each of the 128KB boundaries corresponds to a single, fixed bank (I'm not sure which address corresponds to which bank). So it is a very "basic" bank switcher. You select a bank by configuring the card slot to the address that would correspond the desired bank.
▼
Posts: 381
Threads: 32
Joined: Mar 2006
One more question:
What is hapenning if you configure the card to address #00000 with 512K size? What banks are visible at addresses #40000, #80000 and #C0000 in this case? I don't have 512K RAM card so I cannot test it ...
▼
Posts: 709
Threads: 104
Joined: Nov 2005
I'll have to get back to you on that. My only 512KB card is currently out on loan.
Posts: 1,041
Threads: 15
Joined: Jan 2005
Quote:
I am using physical Saturn instructions only. The only exception
is BUSCC NIBHEX 33 (or something like that) so I can use all 80
display rows for LCD printer emulation on HP-49G+. This worked
very well.
Yes, that would be 80B33, referred to as SETLNED. A list of the
new opcodes is available
here,
and some newsgroup discussion of them
here,
but as far as I know, HP has never officially released this
information; how complete and accurate it is, I don't know.
Quote:
But, not all of the emulated standard Saturn instructions are
working exactly as in real Saturn CPU.
Yes, even the old physical Saturn instructions are running on an
emulator, so may well not behave exactly the same. Which brings up
the point that as the Saturn+ processor is really an emulation,
how it behaves could change with a new (flash) "ROM" revision.
Quote:
But, the biggest problem is different keyboard/interrupt handling
at the lowest level. This has also changed between ROM 1.23 and
2.0x so some routines which worked with 1.23 don't work with 2.00,
at the lowest level, of course.
Yes, the 49g+ is rather notorious for problems with missed and/or
doubled keystrokes. I expect that the changes you find are an
attempt to correct at least some of the problems.
It seems to me that all access to hardware must go through the
Kinpo OS, so this too could change with a new ROM revision.
Quote:
But, if you write software with SysRPL or assembler using
supported entry points only then it is very unlikely that you will
have much trouble, if any.
Yes, the only new instruction that I've used is 80B821 (XM=1, or
HST=1.1 on the Saturn+, but BUSCC XM=0 on the physical Saturn),
for detecting whether the program is running on an emulated
Saturn+ or a physical Saturn. My program worked just fine on both
the 49G and the 49g+, and I can see where, with probably some
modifications, it could likely be made to work on a 48G, and maybe
even a 48S, though there's much less need for it on the 48 series.
But I haven't determined whether the UART could be treated the
same for USB communications as it can with RS-232 compatible and
IrDA communications, and I planned to write separate versions for
the 49G and 49g+. The whole project has been on hold for a long
time; I really ought to get back to it one of these days.
Regards, James
|