48Gii/49G/49G+/50G software compatibility
in [HP48]
|
From: John H Meyers on 1 Jan 2007 17:08 I suggested: > "{NOVAL" STR\-> 1 GET TYPE On Sun, 31 Dec 2006 19:43:00 -0600, James M. Prange wrote: > "NOVAL" STR\-> seems to do the same for me, > at least once I remembered to purge my global variable NOVAL. You have identified why I recommend the former; it guarantees non-evaluation of anything named NOVAL, whether a variable or a library command, say. I also recommend inserting "{" before applying STR\-> to the results of INPUT, because the results of editing can be so unpredictable and uncontrollable, including that it may contain commands (for SysRPL folks, palparse is one step better, because it avoids the automatic evaluation of STR\-> or OBJ\->) >> 11 11 SUB "5" == @ 11 DUP is 8 bytes shorter > 4 bytes shorter on a 49 series Only when compiled in Exact mode (but then execution is longer, not that it matters :) > which 48SX commands have never changed entry points An entire address region of substantial size, in lower memory, including all the prologs and many common basic functions; can be found by perusing the address-sorted lists in JKH's thorough compilation of 48 vs. 49/50 entry points: http://www.hpcalc.org/search.php?query=xref Happy New Year from http://www.mum.edu and http://www.maharishischooliowa.org
From: James M. Prange on 1 Jan 2007 22:28 James M. Prange wrote: I wrote: <snip> > I expect that I'll simply try storing a dummy object to port 1 > instead. I expect that it will take a few more bytes than the > PVARS method, but should be reasonably fast no matter what's > stored in port 1 of a 49G. Well, it seemed a good idea to me, but that doesn't work. If a name is tagged with a (valid) port number to make what I call a "port name", then the commands STO, RCL, and PURGE either succeed or error out as appropriate, so the technique of trying to store a dummy object to a port works for detecting whether a card with a particular port is installed. But if the number is higher than what I'll call the "maximum port number", then it's treated as a tagged global name, so the tag is simply stripped off for STO, RCL, and PURGE. The maximum port numbers are as follows: 48SX: 2 48GX: 33 49G: 2 49g+: 3 48gII: 0 50g: 3 For the 48S, 48G, and 48G+, I don't know whether it matches the 48SX and 48GX or it's 0. Anyway, for "pure UserRPL" methods of distinguishing between the 49G and 48gII, either 1 PVARS or forcing the default IOPAR to be created and checking the default speed works, but both have fairly serious disadvantages. One might expect that using the VERSION command and checking whether that says that it's a 49 or a 48 should work, but VERSION in ROM revision 2.09 (released for ARM-based models, not the 49G) or Bernard's current CAS release ROM seems to default to assuming that it's running on a 48gII if it determines that it's not on a 49g+ or 50g. I don't know how many others are using these ROM revisions, but I have to consider this method to be unreliable. So I'm rather at a loss for a "good" way of distinguishing the 49G and 48gII using "pure UserRPL". With SysRPL methods, one might think that IsApple_ or IsMidApple_ ought to work, but if I'm not mistaken, these weren't implemented until ROM revision 1.20 (first release for ARM-based models). In particular, with ROM 1.19-6, IsApple_ seemed to "hang" my 49G until I forced a warmstart, so this isn't acceptable unless it's already been determined the the ROM is at least 1.20. Okay, I could check whether the revision is at least 1.20, and reason that if it's not, then it can't be a 48gII. If it's 1.20 or higher, I could use then IsApple_ to distinguish the 49G. Something else that does work for me is a bit of assembly language, (well, within a SysRPL program) which works on any 49 series, and for that matter, I suppose that it would work on a 48 series too, although the following is Masd syntax: %%HP: T(3); C$ $ !NO CODE !RPL :: CODE $80B ; BUSCC opcode. NOP on 49G, but beginning of ; HST=1 1 on Apple. XM=0 ; OPCODE 821. Clears XM on 49G, but rest of ; HST=1 1 (which sets XM) on Apple. ?XM=0 ; 49G? SKIPYES ; Dummy GOYES to complete test. { ; Dummy block to skip. } ; GOVLNG ="PushT/FLoop" ; T/F based on carry. Label quoted to keep ; Masd from treating as expression. ENDCODE COERCEFLAG (Convert TRUE/FALSE to real 1/0.) ; @ Or equivalently: I wrote: <snip> > I expect that I'll simply try storing a dummy object to port 1 > instead. I expect that it will take a few more bytes than the > PVARS method, but should be reasonably fast no matter what's > stored in port 1 of a 49G. Well, it seemed a good idea to me, but that doesn't work. If a name is tagged with a (valid) port number to make what I call a "port name", then the commands STO, RCL, and PURGE either succeed or error out as appropriate, so the technique of trying to store a dummy object to a port works for detecting whether a card with a particular port is installed. But if the number is higher than what I'll call the "maximum port number", then it's treated as a tagged global name, so the tag is simply stripped off for STO, RCL, and PURGE. The maximum port numbers are as follows: 48SX: 2 48GX: 33 49G: 2 49g+: 3 48gII: 0 50g: 3 For the 48S, 48G, and 48G+, I don't know whether it matches the 48SX and 48GX or it's 0. Anyway, for "pure UserRPL" methods of distinguishing between the 49G and 48gII, either 1 PVARS or forcing the default IOPAR to be created and checking the default speed works, but both have fairly serious disadvantages. One might expect that using the VERSION command and checking whether that says that it's a 49 or a 48 should work, but VERSION in ROM revision 2.09 (released for ARM-based models, not the 49G) or Bernard's current CAS release ROM seems to default to assuming that it's running on a 48gII if it determines that it's not on a 49g+ or 50g. I don't know how many others are using these ROM revisions, but I have to consider this method to be unreliable. So I'm rather at a loss for a "good" way of distinguishing the 49G and 48gII using "pure UserRPL". With SysRPL methods, one might think that IsApple_ or IsMidApple_ ought to work, but if I'm not mistaken, these weren't implemented until ROM revision 1.20 (first release for ARM-based models). In particular, with ROM 1.19-6, IsApple_ seemed to "hang" my 49G until I forced a warmstart, so this isn't acceptable unless it's already been determined the the ROM is at least 1.20. Okay, I could check whether the revision is at least 1.20, and reason that if it's not, then it can't be a 48gII. If it's 1.20 or higher, I could use then IsApple_ to distinguish the 49G. Something else that does work for me is a bit of assembly language, (well, within a SysRPL program) which works on any 49 series, and for that matter, I suppose that it would work on a 48 series too, although the following is Masd syntax: %%HP: T(3); C$ $ !NO CODE !RPL :: CODE $80B ; BUSCC opcode. NOP on 49G, but beginning of ; HST=1 1 on Apple. XM=0 ; OPCODE 821. Clears XM on 49G, but rest of ; HST=1 1 (which sets XM) on Apple. ?XM=0 ; 49G? SKIPYES ; Dummy GOYES to complete test. { ; Dummy block to skip. } ; GOVLNG ="PushT/FLoop" ; T/F based on carry. Label quoted to keep ; Masd from treating as expression. ENDCODE COERCEFLAG (Convert TRUE/FALSE to real 1/0.) ; @ Or equivalently: %%HP: T(3); "!NO CODE !RPL :: CODE 00012 80B821831208D65253 COERCEFLAG ; @" After compiling, the above returns the real number 0 for any "Apple" (ARM-based model), or 1 for the 49G. \->H on the program object returns: "D9D20CCD207100080B821831208D65253B2062B2130" And of course H\-> (assuming that library 256 is attached) on that string returns the program object. <snip> -- Regards, James %%HP: T(3); "!NO CODE !RPL :: CODE 00012 80B821831208D65253 COERCEFLAG ; @" After compiling, the above returns the real number 0 for any "Apple" (ARM-based model), or 1 for the 49G. \->H on the program object returns: "D9D20CCD207100080B821831208D65253B2062B2130" And of course H\-> (assuming that library 256 is attached) returns the program object. <snip> -- Regards, James
From: James M. Prange on 1 Jan 2007 22:39
My apologies for the rather garbled post. Trying again: I wrote: <snip> > I expect that I'll simply try storing a dummy object to port 1 > instead. I expect that it will take a few more bytes than the > PVARS method, but should be reasonably fast no matter what's > stored in port 1 of a 49G. Well, it seemed a good idea to me, but that doesn't work. If a name is tagged with a (valid) port number to make what I call a "port name", then the commands STO, RCL, and PURGE either succeed or error out as appropriate, so the technique of trying to store a dummy object to a port works for detecting whether a card with a particular port is installed. But if the number is higher than what I'll call the "maximum port number", then it's treated as a tagged global name, so the tag is simply stripped off for STO, RCL, and PURGE. The maximum port numbers are as follows: 48SX: 2 48GX: 33 49G: 2 49g+: 3 48gII: 0 50g: 3 For the 48S, 48G, and 48G+, I don't know whether it matches the 48SX and 48GX or it's 0. Anyway, for "pure UserRPL" methods of distinguishing between the 49G and 48gII, either 1 PVARS or forcing the default IOPAR to be created and checking the default speed works, but both have fairly serious disadvantages. One might expect that using the VERSION command and checking whether that says that it's a 49 or a 48 should work, but VERSION in ROM revision 2.09 (released for ARM-based models, not the 49G) or Bernard's current CAS release ROM seems to default to assuming that it's running on a 48gII if it determines that it's not on a 49g+ or 50g. I don't know how many others are using these ROM revisions, but I have to consider this method to be unreliable. So I'm rather at a loss for a "good" way of distinguishing the 49G and 48gII using "pure UserRPL". With SysRPL methods, one might think that IsApple_ or IsMidApple_ ought to work, but if I'm not mistaken, these weren't implemented until ROM revision 1.20 (first release for ARM-based models). In particular, with ROM 1.19-6, IsApple_ seemed to "hang" my 49G until I forced a warmstart, so this isn't acceptable unless it's already been determined the the ROM is at least 1.20. Okay, I could check whether the revision is at least 1.20, and reason that if it's not, then it can't be a 48gII. If it's 1.20 or higher, I could use then IsApple_ to distinguish the 49G. Something else that does work for me is a bit of assembly language, (well, within a SysRPL program) which works on any 49 series, and for that matter, I suppose that it would work on a 48 series too, although the following is Masd syntax: %%HP: T(3); C$ $ !NO CODE !RPL :: CODE $80B ; BUSCC opcode. NOP on 49G, but beginning of ; HST=1 1 on Apple. XM=0 ; OPCODE 821. Clears XM on 49G, but rest of ; HST=1 1 (which sets XM) on Apple. ?XM=0 ; 49G? SKIPYES ; Dummy GOYES to complete test. { ; Dummy block to skip. } ; GOVLNG ="PushT/FLoop" ; T/F based on carry. Label quoted to keep ; Masd from treating as expression. ENDCODE COERCEFLAG (Convert TRUE/FALSE to real 1/0.) ; @ Or equivalently: %%HP: T(3); "!NO CODE !RPL :: CODE 00012 80B821831208D65253 COERCEFLAG ; @" After compiling, the above returns the real number 0 for any "Apple" (ARM-based model), or 1 for the 49G. \->H on the program object returns: "D9D20CCD207100080B821831208D65253B2062B2130" And of course H\-> (assuming that library 256 is attached) on that string returns the program object. <snip> -- Regards, James |