A379 > Does anyone know of any effort to make symbolic / heavy duty math > apps like ALG48, ERABLE, CAS, etc. for the PalmOS? The current PalmOS handhelds don't have the memory or CPU power to do a really decent job at CAS. If you really need CAS, you should really stick with one of: * The HP48/49. * A laptop (running Maxima -- see http://maxima.sourceforge.net/). * An iPaq. Bernard Parisse is supposedly working on a nice CAS-like program for this -- search the archives for more info. * A Sharp Zaurus (runs java/linux, and so a non-graphical Maxima does run on it). -- Darryl Okahata darrylo@soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. I don't know if you'd describe DERIVE (for DOS) as a CAS, but it even works on an HP-95LX;-) Raymond Darryl Okahata schrieb im Newsbeitrag > Does anyone know of any effort to make symbolic / heavy duty math > apps like ALG48, ERABLE, CAS, etc. for the PalmOS? > The current PalmOS handhelds don't have the memory or CPU power to > do a really decent job at CAS. If you really need CAS, you should > really stick with one of: > * The HP48/49. > * A laptop (running Maxima -- see http://maxima.sourceforge.net/). > * An iPaq. Bernard Parisse is supposedly working on a nice CAS-like > program for this -- search the archives for more info. > * A Sharp Zaurus (runs java/linux, and so a non-graphical Maxima does > run on it). > -- > Darryl Okahata > darrylo@soco.agilent.com > DISCLAIMER: this message is the author's personal opinion and does not > constitute the support, opinion, or policy of Agilent Technologies, or > of the little green men that have been following him all day. I've got a HP48GX with memory card 1Mb and some programs, writtem by me, in how can i store them in memory card? Vittorio use port numbers from 2 to 9 as tags for the name << I'm a >> :2:PIG STO 'PIG' 2 ->TAG is another way to create a tagged name you can also EVAL programs using the wildcard tag. Naturally one could use the direct port tag << New program FOR a :2:PIG NEXT >> and...read the manuals... > I've got a HP48GX with memory card 1Mb and some programs, writtem by me, > how can i store them in memory card? > Vittorio > I on the hunt for a HP 41 CV or CX, but can someone tell me the market > prices for such a device? In Europe or USA? > BR > Matti, Sweden One good place for buying no longer made HP Calculators (such as the HP 41C/CV/CX) is International Calculator in Florida, USA. Their website is www.internationalcalculator.com. I bought a working HP 48SX from them (as well as no longer made HP calculator cases). I Don O'Rourke does not like being called through the toll free number given on the website. A toll call from Sweden to Florida would be very expensive. Heck, the source for Emu48 is available--I was seriously considering porting it to PalmOS until I discovered that PalmOS doesn't expose multithreading support to application programmers. Plus, I have no $$ and all this Cygwin/PilRC/gcc baloney is gunking up my gaming rig. There IS a CE version, but the source is not available (?). Probably VERY easy to convert the Win32 Emu48 code to WinCE. As a side note, I was thinking of porting Emu48 to Java just for kicks... > X > I think that we're familiar enough with ON& A&F, B, C, D, E, F, -, and > +, but what about ON&CursorUp? That sends something from the serial > port. You can capture it with HyperTerminal if you're curious. It seems > to depend on what the speed parameter in IOPAR is set to (perhaps other > things as well?). Does anyone know what that's all about? > How about: a screen dump to your PC? Yes, now that you mention it, I should've known that; I did try it out a few times with HPComm, but haven't had any real need for it. I did think of the PRLCD command, but it didn't look like what the 48 series transmits for that, and it wasn't obvious (to me) what printer a PRLCD on the 49G would be formatted for. Ok, the printer for this hidden key is a PC program. I wonder whether there's a hidden key combination for LCD-> on the 49G, one that could be executed from any environment and regardless of whether or not the calculator is in user keys mode. -- James > I think that packing would be a better way to describe it than either > defragmentation or garbage collection. My understanding is that the > calculator alway puts any new object into a single block of memory. When > it uses memory, it marks the object as referenced, and adds another > reference mark for each additional pointer to the same object, and of > course removes a reference mark each time a pointer to the object is > removed. > Well, the HP48/49 do it a bit differently. > All objects are always allocated in a continuous block of memory (called > TEMPOB), below (i.e. at lower addresses than) the RPL return stack. All > free memory lies between the return and data stack. (Note that we're > grow towards this free memory: The return stack grows upwards and the > data stack downwards. > That way, the HP avoids fragmenting memory. If it runs out of free space > to allocate more objects (or return/data stack elements, since each of > these pointers takes up 5 nibbles too), it starts the garbage > collection. This uses a marker field present in every temporary object > to mark all those object which are still referenced. After having run > through all possible locations for object pointers (the return and data > are not needed any more. Now there's where I find the garbage collection terminology perhaps a bit misleading. What in the world does it mean to remove an object from TEMPOB? I rather doubt that the system would bother to change the bits in memory to any particular pattern, and surely it wouldn't bother to move the unreferenced objects to somewhere else. I think that it's rather a matter of marking the memory that they occupy as available to be overwritten or perhaps of not marking it as not available to be overwritten, or unallocated versus allocated. But isn't the object still there until it's overwritten? It seems to me that it's the referenced objects that are being collected into a contiguous block, not the garbage objects that are being collected for disposal. But the term garbage collection is probably too traditional to be replaced by something less colourful like memory packing. > To keep the allocated objects in a continuous block, it must move all > objects after the removed one to lower memory addresses so as to fill > the gap. During SysRPL execution this is never a problem, since the GC > routine updates all pointers to their new locations, but in ML it can > be, because e.g. the hardware return stack (RSTK) is never updated. This tells me that using ML, you can recover some memory without actually doing a garbage collection? This is a bit deeper into the internals than I've ever cared to think about. I was thinking in terms of what happens in UserRPL. Of course, if you choose to bypass the system and do things your own way, you have to take care of certain things yourself. But it brings up a very good point; not only does an object have to be moved in memory, but any pointers to its old address have to be changed to its new address. I wonder whether this requires yet another scan of all the pointers to find any that pointed to the old address each time that an object is moved. > Note that the marker nibble is always zero outside GC. I do not know > whether the GC routine initializes it to zero before it scans through > the object pointers, but the memory allocation routine CREATETEMP does. So the objects in TEMPOB are never actually marked as referenced until the GC routine looks at the pointers in the system and marks any object pointed to as being referenced? Is the marker nibble changed for every additional pointer to a particular object that's found? > A common UserRPL method of forcing a garbage collection is to execute > MEM DROP. MEM forces a garbage collection so that it can simply > calculate the size of that one block of memory rather than calculate and > add up the sizes of all the unreferenced objects plus the unused memory. > There may be other UserRPL operations that force a garbage collection; I > don't know. > Actually the free memory is never known exactly except after a GC - > since virtually no other routines make a difference between referenced > and unreferenced objects. (I know of only one other routine which does: > INTEMNOTREF?) Yes. I suppose that, in principle, it would be possible to find the sizes of all of the unreferenced objects in TEMPOB, but that would mean doing a good bit of the GC routine, so the calculator just does the entire GC when it needs to know the amount of memory that could be made available. But what I was really referring to was whether any other UserRPL operations force a GC. I suppose that 0 PVARS may, or FREE or MERGE might force one. > Note that, as a general rule, the more you have on the stack, the longer > it takes to do a garbage collection, and I've noticed that garbage > collection seems to be especially slow when the stack has a lot of > pointers to list elements (and I suppose elements of other composites > and maybe arrays). > This (I guess) happens because to find the TEMPOB marker which a pointer > on the stack references it must skip (via SKIPOB) objects until it > reaches the end of the TEMPOB object (in this case the whole composite), > where the marker is stored. So if you have a pointer to the first object > of a list, the GC routine must skip all the rest of it until it finally > reaches the end. Am I correct in thinking that there's only one marker for the composite, not one for each element? > Note that true arrays (DOARRY) can only exist as a whole; if you extract > elements from them, the element will be copied to a new TEMPOB object. Ok, I can see why. The type and body of each element aren't contiguous in the array, so it would be a bit difficult to meaningfully have a single pointer to an element of the array, short of making an entirely new object of the element. And indeed, a GC with a array of reals exploded onto the stack seems to be just as fast as having the reals on the stack by putting them there with a FOR loop. > However the 49 matrices (DOMATRIX) are very much like lists of lists. Do you mean the type 29 symbolic matrices? But I note that with the elements from type 29 matrices on the stack, garbage collection isn't especially slow, so I suppose that these elements are in TEMPOB as new objects too. So it seems to be only composites that cause the drastic slowdown of GC, not arrays of any kind. > I hope that these explanations clear things up instead of making them > more obscure =) On the whole, they do, although they also raise additional questions in my mind. Certainly it shows us that GC can involve quite a lot of activity. I suppose that it *might* be possible to speed up garbage collection, but quite possibly at the expense of slowing down everything else. Someone much more knowledgeable than me can consider that question. -- James Ok, here goes the second part... > To keep the allocated objects in a continuous block, it must move all > objects after the removed one to lower memory addresses so as to fill > the gap. During SysRPL execution this is never a problem, since the GC > routine updates all pointers to their new locations, but in ML it can > be, because e.g. the hardware return stack (RSTK) is never updated. > This tells me that using ML, you can recover some memory without > actually doing a garbage collection? This is a bit deeper into the > internals than I've ever cared to think about. You can indeed recover memory if you happen to *know* that a TEMPOB zone is not referenced any more - ML programs can quite easily delete TEMPOB zones with the entry MOVERSD. > But it brings up a very good point; not only does an object have to be > moved in memory, but any pointers to its old address have to be changed > to its new address. I wonder whether this requires yet another scan of > all the pointers to find any that pointed to the old address each time > that an object is moved. There are even dedicated entry points for this (I faintly remember something about PTRADJUST2), since not only the GC routines need to update pointers: The MOVERSD (mentioned above) and MOVERSU entries must also keep them up to date, and there's even a memory swapping procedure called BLKSWAP+ which automatically handles the pointer business for the caller. > So the objects in TEMPOB are never actually marked as referenced until > the GC routine looks at the pointers in the system and marks any object > pointed to as being referenced? Is the marker nibble changed for every > additional pointer to a particular object that's found? I can only guess here, but I think it's not. As soon as the GC routine finds the end of a TEMPOB zone, it probably just puts a referenced value there, maybe 1 or F. Incrementing it would not make any sense, since after 16 pointers to that zone you'd have a 0 (zero) again, which seems to stand for unreferenced. > But what I was really referring to was whether any other UserRPL > operations force a GC. I suppose that 0 PVARS may, or FREE or MERGE > might force one. You are right, PVARS does, for any valid argument (i.e. 0, 1 or 2). Neither FREE nor MERGE do anything on the HP49, and I do not have a 48, so I cannot have a look there. A lot of ML programs which do not know in advance how many memory they might need also force one: MASD is a good example. > Am I correct in thinking that there's only one marker for the composite, > not one for each element? Yes. In fact there's exactly one marker in the whole zone, at the very end, as I explained in my other post. > However the 49 matrices (DOMATRIX) are very much like lists of lists. > Do you mean the type 29 symbolic matrices? Yes. > But I note that with the elements from type 29 matrices on the stack, > garbage collection isn't especially slow, so I suppose that these > elements are in TEMPOB as new objects too. I have just checked, at least GET does not make new objects. > So it seems to be only composites that cause the drastic slowdown of GC, > not arrays of any kind. Well, the terminology here is a bit difficult, since these type 29 matrices *are* technically the same as lists of lists, except that they have a different prologue. Maybe there is some side effect of a matrix command which decreases the slowdown a bit. > On the whole, they do, although they also raise additional questions in > my mind. > Certainly it shows us that GC can involve quite a lot of activity. Unfortunately - or luckily, you might say - this is entirely hidden from the (user and, to a large extent, system) RPL programmer. In the world of ML things are more hairy, but in turn the pieces of the jigsaw start to fit =) > I suppose that it *might* be possible to speed up garbage collection, > but quite possibly at the expense of slowing down everything else. > Someone much more knowledgeable than me can consider that question. algorithm, which unfortunately needs some extra memory and thus possibly breaks certain ML programs: ond.com ond.com Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > algorithm, which unfortunately needs some extra memory and thus possibly > breaks certain ML programs: ond.com ond.com > Yes indeed, that slipped my mind. I hope that he makes enough advance > information available so that updated ML programs can be ready. I hope > that it would be possible to have the updated ML programs work with both > the new and the current GC routine. than once all the objects previously allocated during the GC, it's much more optimized than that The way my new GC works is subdiving the Temporary Object area into 256 small module using a hash table, that's where extra memory is required Then I re-organize the tempob for the time of the GC in order to be able to save the size of the allocated object before it. That way the size of the allocated memory will be stored both at the end and at the beginning of the reserver memory: In the current GC process the TEMPOB memory is organized like this: | flag1_inused? (1n) | object1 (n nibbles) | size allocated area1 (5n) | flag2_inused? | object2 | size allocated 2 | etc.. It will then become: size allocated (18bits) | flag1_inused (1 bit) | size object (18 bits) | object 1.. | size object (18 bits) | On an HP39/49/40 you can't allocate more than 256KB of memory, so 18 bits is sufficient for the size field. As you can see I'm missing some bits to record all the data. For that I use the prologue inside the object itself: it is easily possible to have the prologue on 7 bits only (instead of 20 bits) as there are less than 128 type of objects on the HP49. Using 7 bits to encore the prologue will free 13 bits, which is JUST what I need. And that's it I can have all the information I need to have a fast GC... The most tricky part in the actual GC, is from an address in the stack, where the flag (stating that this object is in used or not) is located. The way it currently works is like this: -Get the address from the stack (or whatever) -Check if this pointer refers to a TEMPOB object -If it does, it will skip forward all the objects it can find until it finds the area where the size is saved. The may take a long time especially if you have an exploded list on the stack. Internally the memory could be something like: { obj1 obj2 obj3 ... objn } | size (5n) Let say on the stack you will find a pointer to obj2, to find the size field, you will have to jump obj3, then obj4 .. objn If your list was over 1000 elements exploded on the stack, you will have to perform 499500 SKIPOB (the sub-routine to calculate the size of an object). As you can see it can gt very slow very quickly. Another problem with the current algorithm is that you can't have a pointer on the stack referring to a non-composite object. Let say you had a string in TEMPOB, with a pointer referencing this string right in the middle. The OS has currently no way in skipping the object, from its middle to find the size field. For example, if you try the following: donwload an object to the HP49 so you know it will contain the famous header HPHP48 The usual trick is to simply perform a ->H 26 + H-> NEWOB on it. But remove the NEWOB and do instead: ->H 26 + H-> MEM DROP Make sure that the object is only referenced on the stack, and is not save in any variables (otherwise the object will not be in TEMPOB).. What do you get after the GC on the stack? garbage/junk. In fact, you may even get a memory clear. This limitation of how the GC works prevents any fix for the famous problem: if you run a program from port2 in ML, and this program allocate memory, it will crash. The main reason is that you can't from the Return Stack address skip the Code object to its end. But let's keep going into how the GC works: -If the object is found in memory, tag it to say it is used. -Keep repeating all the previous operations until you've parsed all the different stacks and reserved memory -Now you can delete all the objects that are not marked as being used.. My new GC works differently. When you want to mark an object to be in used, you first locate using the hash table where is the sub-area containing it. without any problem, I'll put it at the beginning of TEMPOB ! (will be a bit slower though). So far I was using one of the screen, but this is not too good as if somebody was using this memory, a GC would have corrupted it. My different trials show that this new GC is not much faster on an average basis that the old one. But if you have a 1000 objects list exploded on the stack, now the GC is almost instantaneous. While the previous version may take a long time. Try this: 1 1000 FOR I I NEXT 1000 ->LIST DUP LIST-> You should now have on the stack a list of 1000 elements, then 1000 integers (all sub-element of the list). Then type MEM and see how long it takes. I'v just done it on mine and it's been over 3 minutes so far With the new GC it takes 2.3s > I suspect that the current GC routine is mostly or entirely legacy > code from the very early days of RPL. When there was very little (by > wouldn't have been so much to do for each GC, the GC would have to be > done using as little additional memory as possible, and the ROM code for > the GC would need to be as small as possible. With the relatively large > and the 49G, the compromises made back then may very well not be optimal > today. The current GC is a great piece of software, very fast. As I said before I tried several times to rewrite it without any luck. It was always smaller than the existing one... I hope that all of this made sense to you. It's a bit complicated. not done :) (over 5 minutes now) I will not attend the HPPC september conference - because I'm no longer a member ;-) Now, for the new gc: Do I understand correctly that you have to move the objects in order to create the 'new' TEMPOB layout? What a pity that TEMPOB is not organized as follows: .. .. That way, locating the slot within which (not necessarily 'to which') a particular stack pointer pointed could be determined with a dichotomic search.. and the amount of space used is exactly the same. Too bad that reorganizing it this way for a gc looks too time-consuming. newsgroups after the demise of dejanews. every post. The amount of spam I receive is rising exponentially. A+, Werner > I will not attend the HPPC september conference - because I'm no > longer > a member ;-) I'm not a member either, don't see why I wouldn't be able to participate to this conference.. > Now, for the new gc: > Do I understand correctly that you have to move the objects in order > to create > the 'new' TEMPOB layout? What a pity that TEMPOB is not organized as > follows: I will not move the objects but will play around them.. > .. > .. > That way, locating the slot within which (not necessarily 'to which') > a particular stack pointer pointed could be determined with a > dichotomic search.. and the amount of space used is exactly the same. > Too bad that reorganizing it this way for a gc looks too > time-consuming. I thought about totally re-organizing the tempob area, but it would surely break some ML programs, and would also break some existing code that I couldn't think about. I can't really re-organize the memory as you describe during a GC< a it would eat some more memory > every post. Thread are organized by the most recent posts, while Outlook express will not. For example, for answering this post, I must go far back into the history. > I'm not a member either, don't see why I wouldn't be able to participate to > this conference.. Indeed. I thought it was 'members only' - the fact that *you* can go does not mean mere mortals can. But we already have a holiday planned for the weekend of the 21st.. > Now, for the new gc: > Do I understand correctly that you have to move the objects in order > to create > the 'new' TEMPOB layout? What a pity that TEMPOB is not organized as > follows: > I will not move the objects but will play around them.. But, the original tempob format is: where in-use flag is one nibble, and the prologue is 5 nibbles, for a total of 24 bits. After the change, it looks like: where is 1 bit in length, is 18 bits and the short prologue needs 7 bits. that's 26 bits preceding the object body? Werner Huysegoms > Indeed. I thought it was 'members only' - the fact that *you* can go does > not mean mere mortals can. But we already have a holiday planned for > the weekend of the 21st.. You put too much importance on me ! I honnestly would like to see more people at these conference, otherwise it tends to be somehow ... boring... Especially if it's only talking about HP41 like I've seen sometimes :) How can you plan holidays so far in advance! > But, the original tempob format is: > > where in-use flag is one nibble, and the prologue is 5 nibbles, for a total > of 24 bits. > After the change, it looks like: > > where is 1 bit in length, is 18 bits and the short prologue > needs 7 bits. that's 26 bits preceding the object body? Well, I thought I had explained it in my first post. The way the actual memory is as you mentionned: but if you also include the size of the *previous* object, then you will have: that's: 20 + 4 + 20 = 44 bits when all you need is: 18 + 1 + 18 + 7 = 44bits it fits ! Sure, you have the issue for the *first* object in TEMPOB, but in the HP49, the first object is always the same (Virtual Stack), so it's easy to work around it... Just got back from a two-week holiday in La Douce France, so maybe I'm not thinking clearly yet ;-) > Another problem with the current algorithm is that you can't have a pointer > on the stack referring to a non-composite object. > Let say you had a string in TEMPOB, with a pointer referencing this string > right in the middle. > The OS has currently no way in skipping the object, from its middle to find > the size field. > For example, if you try the following: donwload an object to the HP49 so you > know it will contain the famous header HPHP48 > The usual trick is to simply perform a ->H 26 + H-> NEWOB on it. > But remove the NEWOB and do instead: > ->H 26 + H-> MEM DROP ->A 16 + A-> ( ;-)) ) A pointer on the stack may point to any object within a TEMPOB slot as long as skipping the object (and the ones following it) will eventually lead to the end of the slot. But I guess you meant: DOSTR nnnnn x ob y if the stack pointer points to ob, and y is not 'skippable', a gc will crash, as is the case (about half of the time) with these HPHP48 strings, since there may be a dummy nibble following ob. > This limitation of how the GC works prevents any fix for the famous problem: > if you run a program from port2 in ML, and this program allocate memory, it > will crash. > The main reason is that you can't from the Return Stack address skip the > Code object to its end. Not if you do it 'my way', blatantly stolen from Mika's code (as with may things) A+, Werner > Just got back from a two-week holiday in La Douce France, so maybe I'm > not thinking clearly yet ;-) So obviously you enjoyed it :) > Not if you do it 'my way', blatantly stolen from Mika's code (as with > may things) Yes, there are some ways, but it involves integrating SysRPL code.. Not very obvious. There are some things the user/programmer shouldn't worry about. How is the GC working is one of them.. Will I see you in London ? my comparisons HP vs TI www.geocities.com/jaimezacalcs/hp-versus-ti.htm Jaime fernando meza meza X > algorithm, which unfortunately needs some extra memory and thus possibly > breaks certain ML programs: ond.com ond.com THE reason for a 1.19-7 upgrade. I would even suggest that HP should release it as Commercial OS 2.00 !!! > Now there's where I find the garbage collection terminology perhaps a > bit misleading. What in the world does it mean to remove an object > from TEMPOB? I rather doubt that the system would bother to change the > bits in memory to any particular pattern, and surely it wouldn't bother > to move the unreferenced objects to somewhere else. Well, it does not actually move them somewhere else - it *deletes* them (maybe remove was not a clever choice). Memory looks like this: | ... | TEMPOB -> +-------------------+ | Temporary objects | TEMPTOP -> +-------------------+ | Return stack | RSKTOP -> +-------------------+ | ##### free ###### | DSKTOP -> +-------------------+ | Data stack | EDITLINE -> +-------------------+ | ... | (Note that the zone between TEMPOB and TEMPTOP is usually also called TEMPOB.) What I meant with all objects are always allocated in a continuous block of memory is this: The *only* free memory *always* lies between RSKTOP and DSKTOP. If an object zone O of size S is not referenced any more, the GC routine takes these steps: - First, all objects from O to RSKTOP (except O itself) and the whole return stack are moved S+6 nibbles towards TEMPOB (to lower addresses). - Second, all references to the moved objects are updated (by subtracting S+6 from them). Note that there cannot be any references to the return stack. Allocating a new object zone of size T is a bit easier because of that last Note: The return stack is moved T+6 nibbles towards DSKTOP, thus creating room for the new zone just under the return stack. Okay, now the explanation where the 6 comes from and why lists cannot be deleted as long as there are any references to it: An object zone in TEMPOB looks like this: | ... | +----------------------------+ 5 | Previous object's length | +----------------------------+ 1 | Previous object's marker | | RPL object | +----------------------------+ 5 | Length | +----------------------------+ 1 | Marker | | Next object | +----------------------------+ | ... | The length is a bit special: It is actually the object's length plus 6. Another way to look at it is that it is a backwards offset to the previous object's length. As you can see there is only one marker for the whole object zone; if the RPL object inside is a list which has any of its elements referenced, the zone will be marked referenced and cannot be deleted. > I think that it's > rather a matter of marking the memory that they occupy as available to > be overwritten or perhaps of not marking it as not available to be > overwritten, or unallocated versus allocated. But isn't the object > still there until it's overwritten? It seems to me that it's the > referenced objects that are being collected into a contiguous block, not > the garbage objects that are being collected for disposal. As far as I understand, this is how garbage collection works in languages like C. However RPL has the advance that it keeps all pointers to objects in a few known places like the return and data stack, allowing it to move object zones as long as it updates all references. Unfortunately I've run out of time; I will (try to) answer the rest of your questions this evening. Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > X > Note that true arrays (DOARRY) can only exist as a whole; if you extract > elements from them, the element will be copied to a new TEMPOB object. > However the 49 matrices (DOMATRIX) are very much like lists of lists. > To make it more clear: > true arrays: 48-style all numeric (real/complex) arrays > the 49 matrices: Symbolic Matrices or any matrix > have any single element as either a symbolic, like 'X+1', Y, etc > OR integer, like 1768 , eg. a number without a decimal point. Hmm.... I would think that Thomas meant arrays such as are used for some of the message tables. That is, the elements can be of any type, but they all have to be the same type, because the type is only included in the array once, not with each element. I'm under the impression that the real/complex arrays are special cases of arrays. -- James X > Hmm.... I would think that Thomas meant arrays such as are used for some > of the message tables. That is, the elements can be of any type, but > they all have to be the same type, because the type is only included in > the array once, not with each element. I'm under the impression that the > real/complex arrays are special cases of arrays. X But...then the length would have to be the same, too ?! Right ???!!!! >> the array once, not with each element. I'm under the impression that the >> real/complex arrays are special cases of arrays. >But...then the length would have to be the same, too ?! >Right ???!!!! According to the Introduction to Saturn Assembly Language by FH Gilbert and Eric Rechlin, Page 95 an array is: Prologue 029E8 (5 Nibbles) Kind of Element (5 Nibbles) Number of dimensions (5 Nibbles) Dimension 1 (5 Nibbles) . . . Dimension N (5 Nibbles) . . . The array can contain any number of elements that are of the same type. It seems that any type of object is valid inside the array, including and array of strings. The only issue is that all elements must be of the same type. The bare HP48 can only display one or two dimensional arrays of reals, or I think the only special case for reals or imaginaries is that the HP48 has the capability to display and edit these arrays built in. Hope this helps. If I am wrong, please correct me. Bill alternate E-dress wtstorey@ieee.org.no.spam.please (Use the obvious) > X > Hmm.... I would think that Thomas meant arrays such as are used for some > of the message tables. That is, the elements can be of any type, but > they all have to be the same type, because the type is only included in > the array once, not with each element. I'm under the impression that the > real/complex arrays are special cases of arrays. > X > But...then the length would have to be the same, too ?! > Right ???!!!! Good question. I don't know for sure how it determines where one element of an array ends and the next begins. I got my information from RPLMAN.DOC, which doesn't seem to spell out that minor detail. For fixed-length element types, it could be computed easily enough. I suppose that for variable-length element types, the length fields or ending delimiters would be included as part of the element bodies. I have found that the message tables are arrays of strings, or, in many cases, linked arrays of strings, and these strings are certainly not the same length. Certainly the elements of the array all have to be of the same type, and I get the impression that the type is only in the array once, not with each element. Perhaps I'm mistaken. -- James > X > Hmm.... I would think that Thomas meant arrays such as are used for some > of the message tables. That is, the elements can be of any type, but > they all have to be the same type, because the type is only included in > the array once, not with each element. I'm under the impression that the > real/complex arrays are special cases of arrays. Yes, exactly. > But...then the length would have to be the same, too ?! > Right ???!!!! No. I shall explain the way the HP stores a string first. For a more detailed reference of all data types, see Introduction to Saturn Assembly Language, available on hpcalc: HTML: http://www.hpcalc.org/details.php?id=1695 PDF: http://www.hpcalc.org/details.php?id=1693 PS: http://www.hpcalc.org/details.php?id=1694 A string looks like this: +---------------------+ 5 | DOCSTR | +---------------------+ 5 | Length | +---------------------+ | Data... | +---------------------+ So, the first five nibbles are the object prologue. Every object has a prologue, which denotes its type; for strings it is #02A2Ch. Then follows the length field, which includes itself, but not the prologue. Another way to look at it would be that it is an offset to the end of the object. And at last you have the string data, (Length-5) nibbles. Note that this must not necessarily be an even number, though UserRPL does not let you create such strings. Lets have a look at the true arrays now, as I called them. +----------------------+ 5 | DOARRY | +----------------------+ 5 | Length | +----------------------+ 5 | Prologue of objects | +----------------------+ 5 | Number of dimensions | +----------------------+ | Dimension sizes | +----------------------+ +----------------------+ The beginning is almost the same: A prologue, #029E8h for arrays, and the length, which again includes itself, but not the prologue. Next you have the prologue of the included objects. The advance of this is that these five nibbles do not need to be repeated for every object in the array; the disadvance is that all objects must have the same prologue, and thus the same type. Then you have the number of dimensions, followed by that many 5-nibble dimensions sizes, and lastly the contents. Apparently for two-dimensional arrays the first dimension size is the number of rows, and the second the number of columns; the content is then stored row-wise from left to right. An example with strings of different lengths: ARRY [ World! ] @ ASM ->H (Note that MASD can create arrays of strings, at least with ROM 1.19-6!) This gives you a string with a lot of hex digits (57 to be exact). Below they are listed, with some line breaks and comments. Mind that the Saturn chip reverses the nibble order in memory, so e.g. 1 in a 5-nibble field looks like 10000. It's in a way little-endian like the x86, but nibble-based instead of byte-based. 8E920 The prologue: #029E8h 43000 The length: #34h or #52d C2A20 The prologue of the included objects: #02A2C 10000 One dimension 20000 Two rows 11000 Length of World!: #11h = #17d 75F627C64612 Characters World! Ok, enough of this =) Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman I seem to have lost the website for this emulator - it would emulate either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. Does anyone have the URL for this? TIA, Pad http://ftp.mindspring.com/~hildinger/Power48/ Of course a Palm can do everthing an HP can, and more... > I seem to have lost the website for this emulator - it would emulate > either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. > Does anyone have the URL for this? TIA, Pad > I seem to have lost the website for this emulator - it would emulate > either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. > Does anyone have the URL for this? TIA, Pad Knowing that the Sony Clie is runnin PalmOS, I doubt you will ever see an HP48 emulator on such machine. would it be possible using the ROM of the 49 having an emulator running on the X25? Martin >>I seem to have lost the website for this emulator - it would emulate >>either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. >>Does anyone have the URL for this? TIA, Pad > Knowing that the Sony Clie is runnin PalmOS, I doubt you will ever see an > HP48 emulator on such machine. > would it be possible using the ROM of the 49 having an emulator running > on the X25? > Martin On the X25 you have the CPU power to handle such task. However, there's no X or FLTK running there... So the first thing you will have to do is port it to the X25. There s a good HP49 emulator for unix made by Ivan Bertolotti I have a few applications that I would like to see on a cheap PDA device like the X25, I guess I will have to get my hand dirty again and do the porting myself but didn't HP pull the plug on the X25 ? you also have the sharp zaurus as option :) it uses QT. > would it be possible using the ROM of the 49 having an emulator running > on the X25? > Martin > On the X25 you have the CPU power to handle such task. > However, there's no X or FLTK running there... So the first thing you will > have to do is port it to the X25. > There s a good HP49 emulator for unix made by Ivan Bertolotti > I have a few applications that I would like to see on a cheap PDA device > like the X25, I guess I will have to get my hand dirty again and do the > porting myself sorry about this dumb question, but what is X and FLTK? Martin >>would it be possible using the ROM of the 49 having an emulator running >>on the X25? >>Martin > On the X25 you have the CPU power to handle such task. > However, there's no X or FLTK running there... So the first thing you will > have to do is port it to the X25. > There s a good HP49 emulator for unix made by Ivan Bertolotti > I have a few applications that I would like to see on a cheap PDA device > like the X25, I guess I will have to get my hand dirty again and do the > porting myself To know what X is, you could go to http://www.x.org and read: The X Protocol was developed in the mid 1980's amid the need to provide a network transparent graphical user interface primarily for the UNIX operating system. X provides for the display and management of graphical information, much in the same manner as Microsoft's Windows and IBM's Presentation Manager. For FLTK, you could go to http://www.fltk.org and read: FLTK (pronounced fulltick) is a LGPL'd C++ graphical user interface toolkit for X (UNIX¬), MacOS¬, and Microsoft¬ Windows¬, and supports 3D graphics with OpenGL¬. It is currently maintained by a small group of developers across the world with a central repository on Source Forge. In JX25 the User Interface its done with Chai-LX, I think. But, at least it has a linux kernel, so using the right driver it could be possible to run X and a Window Manager like Matchbox: http://handhelds.org/~mallum/matchbox/ Probably you could see some nice ports before the end of September for Jornada X25 units.. J.Manrique Club de Usuarios de Gijon #1077 HPCC Member http://www.asturlinux.org/~jsmanrique > sorry about this dumb question, but what is X and FLTK? > Martin > > >>would it be possible using the ROM of the 49 having an emulator running >>on the X25? >>Martin >> > > On the X25 you have the CPU power to handle such task. > However, there's no X or FLTK running there... So the first thing you will > have to do is port it to the X25. > > There s a good HP49 emulator for unix made by Ivan Bertolotti > > I have a few applications that I would like to see on a cheap PDA device > like the X25, I guess I will have to get my hand dirty again and do the > porting myself > > > > > > Your HP48 emu program looks great (too bad my palm isn't fast enough). Since HP is getting out of calculators, have you thought about trying to port some of the most useful HP48 software (erable, ALG48, CAS...) directly to PalmOS? I think that software to duplicate the functionality of an HP, but used the (great) Palm interface instead of the (clumsy) HP48 interface is the biggest thing lacking in the handheld market right now. There are some decent calculators and spreadsheets, but no hard-core symbolic math packages out there. Just my 2cents, good luck... > sorry about this dumb question, but what is X and FLTK? > Martin > > >>would it be possible using the ROM of the 49 having an emulator running >>on the X25? >>Martin >> > > On the X25 you have the CPU power to handle such task. > However, there's no X or FLTK running there... So the first thing you will > have to do is port it to the X25. > > There s a good HP49 emulator for unix made by Ivan Bertolotti > > I have a few applications that I would like to see on a cheap PDA device > like the X25, I guess I will have to get my hand dirty again and do the > porting myself > > > > > > > How about getting the emulation to support the HP49 then you will have the (quick flexible) interfacace of the 49 rather than the (complex slow) Palm/math package interface. For day to day calcs and solving familiar problems I prefer the HP49 over a graphical maths package. Problem setup and the mouse interface tends to slow things down. I'll jump to a PC maths package if I need to study a problem or if the number crunching is just to much for the 49. Nowdays I'm also finding more of my data is coming from the PC so I'll often manipulate the data on the PC. Stephen N > Your HP48 emu program looks great (too bad my palm isn't fast enough). > Since HP is getting out of calculators, have you thought about trying > to port some of the most useful HP48 software (erable, ALG48, CAS...) > directly to PalmOS? > I think that software to duplicate the functionality of an HP, but used > the (great) Palm interface instead of the (clumsy) HP48 interface is > the biggest thing lacking in the handheld market right now. There are > some decent calculators and spreadsheets, but no hard-core symbolic > math packages out there. Just my 2cents, good luck... > sorry about this dumb question, but what is X and FLTK? > Martin > > >>would it be possible using the ROM of the 49 having an emulator running >>on the X25? >>Martin >> > > On the X25 you have the CPU power to handle such task. > However, there's no X or FLTK running there... So the first thing you will > have to do is port it to the X25. > > There s a good HP49 emulator for unix made by Ivan Bertolotti > > I have a few applications that I would like to see on a cheap PDA device > like the X25, I guess I will have to get my hand dirty again and do the > porting myself > > > > > > > > I seem to have lost the website for this emulator - it would emulate > either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. > Does anyone have the URL for this? TIA, Pad You are probably referring to http://one-two-three-four-five.com/palm/tofu.html. This isn't an emulator (or even a simulator as advertized), it's just an HP48 keyboard on a rather low-feature RPN calculator. > Knowing that the Sony Clie is runnin PalmOS, I doubt you will ever see an > HP48 emulator on such machine. Agreed, unfortunately, because of 2 main things: 1) The 68K-derived CPU doesn't have the raw speed needed. Featurewise, however, it is pretty good (remember those 68xxx v. 80x86 debates 20+ years ago?) 2) The PalmOS programming model is severely limiting. This is probably the biggest impedance. I have no idea if PalmOS 5 will rectify the programming model issues. They probably will, but I haven't seen anything yet about a new native SDK. The ARM core it uses will certainly have the speed and capability. After all, Emu48 on WinCE (oops -- PocketPC) devices reportedly performs reasonably well. Old apps will run (mostly) unchanged on PalmOS 5, i.e. they will be emulated. This will be like when Apple introduced their PowerMac line. I've toyed with the idea of porting Emu48 to PalmOS, but don't think it would be practical, at least not with PalmOS <=4.1. At a blue-sky guess it would probably be 10x slower than an HP48. After all, anything is possible given sufficient time and resources. However, I don't have the time, let alone justification, to do that. - Paul Goertz > > I seem to have lost the website for this emulator - it would emulate > either the HP48G or HP48SX as I recall, using the hi-res Sony PDAs. > Does anyone have the URL for this? TIA, Pad > You are probably referring to > http://one-two-three-four-five.com/palm/tofu.html. This isn't an > emulator (or even a simulator as advertized), it's just an HP48 > keyboard on a rather low-feature RPN calculator. > Knowing that the Sony Clie is runnin PalmOS, I doubt you will ever see an > HP48 emulator on such machine. > > Agreed, unfortunately, because of 2 main things: > 1) The 68K-derived CPU doesn't have the raw speed needed. Featurewise, > however, it is pretty good (remember those 68xxx v. 80x86 debates 20+ > years ago?) > 2) The PalmOS programming model is severely limiting. This is probably > the biggest impedance. > I have no idea if PalmOS 5 will rectify the programming model issues. > They probably will, but I haven't seen anything yet about a new native > SDK. The ARM core it uses will certainly have the speed and > capability. After all, Emu48 on WinCE (oops -- PocketPC) devices > reportedly performs reasonably well. Old apps will run (mostly) > unchanged on PalmOS 5, i.e. they will be emulated. This will be like > when Apple introduced their PowerMac line. > I've toyed with the idea of porting Emu48 to PalmOS, but don't think > it would be practical, at least not with PalmOS <=4.1. At a blue-sky > guess it would probably be 10x slower than an HP48. After all, > anything is possible given sufficient time and resources. However, I > don't have the time, let alone justification, to do that. > - Paul Goertz Pad, The website you're looking for is http://www.mindspring.com/~hildinger/Power48/. I'm afraid you're wrong. As the website above shows I have built an HP48 emulator for the Sony NR70 series running PalmOS 4.1. Paul, I'm the author of the HP48SX/GX emulator referenced in the above website. The emulator at the current beta level only runs on a Sony NR70 clie, which has a Motorola DragonBall SuperVZ CPU running at 66MHz, and uses PalmOS 4.1. I wanted to respond to a few of your points... First with regard to speed, with the 66MHz processor I've achieved an emulation speed of approximately 80% of the actual hardware for the 48SX and 40% for the 48GX. I hope to optimize the code further and increase the speed a few points, but in general I'm happy with the speed I've obtained and find the emulator quite usable at those speeds. In reeality, the biggest bottleneck is the fact that the basic data unit of the HP48 is a nibble, and the fact that the registers are loaded in reverse order. As soon as there is ARM hardware available, I expect the emulator to stomp the real thing in terms of performance. Unfortunately, as you surmise, PalmOS 5 doesn't really alter the programming model in any way. They (Palm) have, however, allowed an opening in the model and allowed to developers to write what are called Armlets, or natively compiled ARM functions that can be called from regular 68K code. Since the entire core of my emulator is written as a single function, the speed increase should be dramatic when recompiled as an armlet. > Paul, > I'm the author of the HP48SX/GX emulator referenced in the above > website. The emulator at the current beta level only runs on a Sony > NR70 clie, which has a Motorola DragonBall SuperVZ CPU running at > 66MHz, and uses PalmOS 4.1. > I wanted to respond to a few of your points... > First with regard to speed, with the 66MHz processor I've achieved an > emulation speed of approximately 80% of the actual hardware for the > 48SX and 40% for the 48GX. I hope to optimize the code further and > increase the speed a few points, but in general I'm happy with the > speed I've obtained and find the emulator quite usable at those > speeds. In reeality, the biggest bottleneck is the fact that the basic > data unit of the HP48 is a nibble, and the fact that the registers are > loaded in reverse order. As soon as there is ARM hardware available, I > expect the emulator to stomp the real thing in terms of performance. > Unfortunately, as you surmise, PalmOS 5 doesn't really alter the > programming model in any way. They (Palm) have, however, allowed an > opening in the model and allowed to developers to write what are > called Armlets, or natively compiled ARM functions that can be called > from regular 68K code. Since the entire core of my emulator is written > as a single function, the speed increase should be dramatic when > recompiled as an armlet. > probably would achieve the same speed with PalmOS 3.5, 3.0, or > lower... > Anyway, just FYI.... > developer, Power48 > power48support@mindspring.com I am absolutely delighted to have been proved wrong! I was unaware that model's CPU was 66MHz. Just to save face, when I scale that performance to the speed of my Palm Vx (22-24MHz?), I get 14%. I don't suppose you'd consider supporting more pedestrian Palms? I have actually been sketching out a 160x160 bitmap, but haven't yet done the KML script. I've dispensed with the digit and function keys, and would map the hard buttons to arrow, on and enter keys. The resulting screen has buttons of the approximate size of Russ Webbs RPN. You'd have to resort to using grafitti for much of the input, but then I always use the PC keyboard with Emu48 and only rarely use the mouse. -- Paul Goertz By checkerboard I mean individual pixels alternate between off and on in both directions. I came up with a few ways but was wondering if there was any kind of trick that would let me do it quicker. I guess doing it once then storing the LCD in a GROB would be the fastest but that would also waist a lot of space so lets say no GROBs allowed. -- john R. Latala jrlatala@golden.net here's the shortest version I made in the mid 90ies: **************************************************************************** * CODE GOSBVL =SAVPTR GOSBVL =D0->Row1 C=0 A LCHEX 37 D=C A LCHEX 5555555555555555 A=C W A=A+A W CBarLp DAT0=C W D0=D0+ 16 DAT0=C W D0=D0+ 16 DAT0=C B D0=D0+ 2 ACEX W ** Prepare for shifted checkers line D=D-1 A GONC CBarLp GOVLNG =GETPTRLOOP ENDCODE **************************************************************************** * It's 45.5 bytes in size. Of course in HP SASM syntax;-) Raymond schrieb im Newsbeitrag > By checkerboard I mean individual pixels alternate between off and on in > both directions. I came up with a few ways but was wondering if there was > any kind of trick that would let me do it quicker. I guess doing it once > then storing the LCD in a GROB would be the fastest but that would also > waist a lot of space so lets say no GROBs allowed. > -- > john R. Latala > jrlatala@golden.net > here's the shortest version I made in the mid 90ies: Combining yours with a Good Idea (tm) in mine one gets CODE SAVE GOSBVL D0->Row1 LC(2) 63 D=C.A LC 555555555555555 A=C.W A+A.W { DAT0=C.W D0+16 DAT0=C.W D0+16 DAT0=C.B D0+2 ACEX.W D-1.B UPNC } LOADRPL ENDCODE 45 bytes, #DDA9h Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman Nice work, Thomas, Raymond, Jonathan! Could you kindly comment you programs and resend them so that we all could learn from them. Veli-Pekka Nousiainen schreef: > Nice work, Thomas, Raymond, Jonathan! I agree but I've managed to shave off 2.5 bytes (#F1EFh 34 bytes) > Could you kindly comment you programs > and resend them so that we all could learn from them. There are some comments but I doubt if you can learn from it CODE SAVE % save RPL pointers SCREEN % point D0 to screen LA 3F % #3F = 63 counter for lines LC 55 % bit pattern 01010101 { C=-C-1 B % logical NEG { DAT0=C B % write byte to screen D0+2 % point to next position P+1 % P is one 4 bits wide UPNC % so do it 16 times } DAT0=C B % write last byte to D0+2 % complete 34 nibble line A-1 B % loop 64 times UPNC } LOADRPL % get RPL pointers and return ENDCODE -- This message was written with 100% recycled electrons Pivo another variation of the checkers, not the binary;-) , also readable for SASM users: CODE GOSBVL =SAVPTR GOSBVL =D0->Row1 LCHEX 37 * Row count A=C A LCHEX 55 * Pattern CBarLp DAT0=C B D0=D0+ 2 P=P+1 GONC CBarLp * On exit; P=0 DAT0=C B D0=D0+ 2 C=-C-1 A * Switch pattern A=A-1 B GONC CBarLp GOVLNG =GETPTRLOOP ENDCODE 33Bytes Chk:#D2B1h Raymond Peter Geelhoed schrieb im > Veli-Pekka Nousiainen schreef: > Nice work, Thomas, Raymond, Jonathan! > I agree but I've managed to shave off 2.5 bytes > (#F1EFh 34 bytes) > Could you kindly comment you programs > and resend them so that we all could learn from them. > There are some comments but I doubt if you can learn from it > CODE > SAVE % save RPL pointers > SCREEN % point D0 to screen > LA 3F % #3F = 63 counter for lines > LC 55 % bit pattern 01010101 > { C=-C-1 B % logical NEG > { DAT0=C B % write byte to screen > D0+2 % point to next position > P+1 % P is one 4 bits wide > UPNC % so do it 16 times > } > DAT0=C B % write last byte to > D0+2 % complete 34 nibble line > A-1 B % loop 64 times > UPNC > LOADRPL % get RPL pointers and return > ENDCODE > -- > This message was written with 100% recycled electrons > Pivo For real bit freaks we could also make it 33.5 bytes #B095h CODE SAVE % save RPL pointers SCREEN % point D0 to screen LC 3F % #3F = 63 counter for lines A=C A % LC is 3 nibbles smaller than LA LC 55 % bit pattern 01010101 { C=-C-1 B % logical NEG { DAT0=C B % write byte to screen D0+2 % point to next position P+1 % P is one 4 bits wide UPNC % so do it 16 times } DAT0=C B % write last byte to D0+2 % complete 34 nibble line A-1 B % loop 64 times UPNC } LOADRPL % get RPL pointers and return ENDCODE -- This message was written with 100% recycled electrons Pivo > For real bit freaks we could also make it 33.5 bytes #B095h Or 33 (#4CF1h): CODE SAVE SCREEN LC 3F A=C.A LC 55 { C=-C-1.A % Note that .A is one nibble shorter { DAT0=C.B D0+2 P+1 UPNC } DAT0=C.B D0+2 A-1.B UPNC } LOADRPL ENDCODE This is fun =) Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > ?ABIT=0.6 UP I can't believe I didn't think of this. I was looking for a smaller counter for a while. Originally it was asked to have a fast way of doing it. so I've made a version with very few cycles. it's a *bit* larger at 1116.5 bytes buy it also 65 times faster so by the standard minichallenge rule time*bytes it is better :-) CODE CD0EX RSTK=C D0= 00120 GOSUBL DATA NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 NIBHEX AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5555555555555555555555555555555555 *DATA C=RSTK ?CBIT=0 0 -> ODD C+1 A *ODD DAT0=C A C=RSTK D0=C A=DAT0 A D0+5 PC=(A) ENDCODE @ -- This message was written with 100% recycled electrons Pivo > so I've made a version with very few cycles. > it's a *bit* larger at 1116.5 bytes buy it also 65 times faster > so by the standard minichallenge rule time*bytes it is better :-) Yes, but it wouldn't follow the classic minichallenge rules: That is, do not leave the calculator in a *wierd* state. Now, the guy will be stuck with a chessboard on his screen. Which can be corrupted easily. Let say you save your program in a variable. Run it. now save something else in VAR< you got an even wierder screen. If you run the program directly after you've compiled it and do MEM DROP, it will also give interesting result. What kind of solution is that ??? > so by the standard minichallenge rule time*bytes it is better :-) > Yes, but it wouldn't follow the classic minichallenge rules: > That is, do not leave the calculator in a *wierd* state. > Now, the guy will be stuck with a chessboard on his screen. > Which can be corrupted easily. > Let say you save your program in a variable. Run it. now save something else > in VAR< you got an even wierder screen. The chessboard remains on my 49 > If you run the program directly after you've compiled it and do MEM DROP, it > will also give interesting result. It is still there, but to satisfy your needs we can just save the pointer to the screen first the problem is that it is so fast that you do not see the chessboard anymore CODE LC 806DA CD0EX RSTK=C C=DAT0 A RSTK=C D0= 00120 GOSUBL DATA % % chessboard *DATA C=RSTK ?CBIT=0 0 -> ODD C+1 A *ODD DAT0=C A C=RSTK C+10 A C+10 A DAT0=C A C=RSTK D0=C A=DAT0 A D0+5 PC=(A) ENDCODE @ -- This message was written with 100% recycled electrons Pivo On Mon, 12 Aug 2002 10:14:21 +0200, Peter Geelhoed >> ?ABIT=0.6 UP >I can't believe I didn't think of this. I was looking for a smaller counter for a while. I guess I have an excuse for doing something as stupid as an explicit test for the parity of the row counter. ;) >Originally it was asked to have a fast way of doing it. >so I've made a version with very few cycles. >it's a *bit* larger at 1116.5 bytes buy it also 65 times faster hehe. Talk about brute force. ;) >so by the standard minichallenge rule time*bytes it is better :-) Well, in that case I think Raymond Hellstern's version modified by Thomas Rast would be the winner. But I think the size challenge is more interesting since even the slowest version is almost beyond human perception in terms of even noticing that it had run. ;) ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. On Mon, 12 Aug 2002 08:18:12 -0500, Jonathan Busby >>so by the standard minichallenge rule time*bytes it is better :-) >Well, in that case I think Raymond Hellstern's version modified by >Thomas Rast would be the winner. Well, I take that back. If you're getting a time only 65 times faster then I think it's due to the fact that your version is so fast that it's beyond TEVAL's timing resolution. ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. > [..] > This is fun =) It would be more fun (at least for me) if you used SASM or JAZZ syntax;-) Raymond I even forgot the rules for the D0[+-] instructions, this fixes it. ---8<------------------------------------------ #!/usr/bin/perl -w use strict; my @instr = split /s+|[%;].*n/, (join , <>); my $i = shift @instr; my $f = (A|B|P|X|XS|W|WP|S); my $r = ([ABCD]); my $lnum = 0; my (@begin, @end); sub label { sprintf L%04x, $lnum++; } sub openblock { my ($b, $e) = (label (), label ()); push @begin, $b; push @end, $e; ($b, $e); } # MASD abbreviations # each line must have a t in front to distinguish it from a label! my %abbrev = ( SAVE => tGOSBVL =SAVPTRn, LOAD => tGOSBVL =GETPTRn, LOADRPL => tGOSBVL =GETPTRLOOPn, RPL => tA=DAT0tAntD0=D0+t5ntPC=(A)n, LOOP => tA=DAT0tAntD0=D0+t5ntPC=(A)n, SCREEN => tGOSBVL =D0->Row1n, MENU => tGOSBVL =D0->Sft1n, INTOFF2 => tGOSBVL =DisableIntrn, INTON2 => tGOSBVL =AllowIntrn, ERROR_C => tGOSBVL =ErrjmpCn, A=IN2 => tGOSBVL =AINRTNn, C=IN2 => tGOSBVL =CINRTNn, OUT=C=IN => tGOSBVL =OUTCINRTNn, RES.STR => tGOSBVL =MAKE$Nn, RES.ROOM => tGOSBVL =GETTEMPn, SHRINK$ => tGOSBVL =Shrink$n, COPY<- => tGOSBVL =MOVEDOWNn, COPYDN => tGOSBVL =MOVEDOWNn, COPY-> => tGOSBVL =MOVEUPn, COPYUP => tGOSBVL =MOVEUPn, DISP => tGOSBVL =DBUGn, DISPKEY => tGOSBVL =DBUG.KEYn, SRKLST => tGOSBVL =Shrink$Listn, ZEROMEM => tGOSBVL =WIPEOUTn, MULT.A => tGOSBVL =MULTBACn, MULT => tGOSBVL =MPYn, DIV.A => tGOSBVL =IntDivn, BEEP => tGOSBVL =makebeepn ); # Instructions without field argument # Note that the 1's are dummies and not used my %passthru = ( ASLC => 1, ASRC => 1, BSLC => 1, BSRC => 1, CSLC => 1, CSRC => 1, DSLC => 1, DSRC => 1, A=IN => 1, C=IN => 1, PC=A => 1, PC=C => 1, PC=(A) => 1, PC=(C) => 1, D0=A => 1, D0=C => 1, D0=AS => 1, D0=CS => 1, AD0EX => 1, CD0EX => 1, AD0XS => 1, CD0XS => 1, CLRST => 1, C=ST => 1, ST=C => 1, CSTEX => 1, OUT=C => 1, OUT=CS => 1, UNCNFG => 1, CONFIG => 1, RESET => 1, C=ID => 1, BUSCB => 1, BUSCC => 1, BUSCD => 1, SREQ? => 1, SHUTDN => 1, INTOFF => 1, INTON => 1, RSI => 1, SETHEX => 1, SETDEC => 1, RTN => 1, RTNSXM => 1, RTNSC => 1, RTNCC => 1, RTNC => 1, RTNNC => 1, P+1 => 1, P-1 => 1, C+P+1 => 1, C=RSTK => 1, RSTK=C => 1 ); # Instructions which invariably require a single argument my %onearg = ( GOC => 1, GONC => 1, GOTO => 1, GOLONG => 1, GOVLNG => 1, GOSUB => 1, GOSUBL => 1, GOSBVL => 1, D0=(2) => 1, D0=(4) => 1, D0=(5) => 1, D1=(2) => 1, D1=(4) => 1, D1=(5) => 1 ); # Inverted tests # keys are regexps, values must eval() to the substitution string my %testinv = ( ?$r=$r.$f => q{?$1#$2.$3}, ?$r#$r.$f => q{?$1=$2.$3}, ?$r=0.$f => q{?$1#0.$2}, ?$r#0.$f => q{?$1=0.$2}, ?$r>$r.$f => q{?$1<=$2.$3}, ?$r<=$r.$f => q{?$1>$2.$3}, ?$r<$r.$f => q{?$1>=$2.$3}, ?$r>=$r.$f => q{?$1<$2.$3}, ?ST=0.(d+) => q{?ST=1.$1}, ?ST=1.(d+) => q{?ST=0.$1}, ?[AC]BIT=0.(d+) => q{?$1BIT=1.$2}, ?[AC]BIT=1.(d+) => q{?$1BIT=0.$2}, ?P=(d+) => q{?P#$1}, ?P#(d+) => q{?P=$1} ); # Skip and Skip-Else instructions and the jump they translate to my %skips = ( SKIP => GOTO, SKIPL => GOTOL, SKIPC => GOC, SKC => GOC, SKIPNC => GONC, SKNC => GONC, SKUB => GOSUB, SKUBL => GOSUBL ); my %skelse = ( SKELSE => GOTO, SKLSE => GOTO, SKEC => GOC, SKENC => GONC ); # Translators for UP UPC UPNC (only the C NC part) my %jumpcond = ( => GOTO, C => GOC, NC => GONC ); while (defined $i) { if ($i =~ /CODE/) { print STDERR Warning: RPL mode not supported (yet?)n; } elsif ($i =~ /*(.*)/) { print $1n; } elsif (exists $abbrev{$i}) { print $abbrev{$i}; } elsif (exists $passthru{$i}) { print t$in; } elsif (exists $skips{$i}) { my ($b, $e) = openblock; print t, $skips{$i}, t$en$bn; } elsif ($i eq }) { my $e1 = pop @end; pop @begin; print $e1n; if (@instr and exists $skelse{$instr[0]}) { my $i = shift @instr; my ($b2, $e2) = openblock; print t, $skelse{$i}, t$e2n$b2n; } } elsif ($i eq {) { my ($b, $e) = openblock; print $bn; } elsif ($i =~ /^P=(d+)?$/) { if (/^P=(d+)$/) { print t$1t$2n; } else { $i .= shift @instr; next; } } elsif ($i =~ /UP(N?C)?(d*)/) { my $n = $2; $n = 1 unless $n; print t, $jumpcond{$1}, t, $begin[@begin - $n], n; } elsif ($i =~ /EXIT(N?C)?(d*)/) { my $n = $2; $n = 1 unless $n; print t, $jumpcond{$1}, t, $end[@end - $n], n; } elsif ($i =~ /^?/) { if ($i !~ /./ and $i ne ?SB=0 and $i ne ?MP=0 and $i ne ?XM=0 and $i ne ?SR=0) { $i .= . . shift @instr; } my $t = shift @instr; if ($t eq { or $t eq SKIPYES) { my ($b, $e) = openblock; print t$intGOYESt$en$bn; } elsif ($t eq ->) { $t = shift @instr; if ($t eq {) { my ($b, $e) = openblock; for (keys %testinv) { if ($i =~ /$_/) { $i = eval $testinv{$_}; last; } } $i =~ s/./t/; print t$intGOYESt$en$bn; } else { $i =~ s/./t/; print t$intGOYESt$tn; } } elsif ($t =~ /UP(d*)/) { $i =~ s/./t/; my $n = $1; $n = 1 unless $n; print t$intGOYESt, $begin[@begin - $n], n; } elsif ($t =~ /EXIT(d*)/) { $i =~ s/./t/; my $n = $1; $n = 1 unless $n; print t$intGOYESt, $end[@end - $n], n; } } elsif ($i =~ /D[01][+-]/) { $i .= shift @instr unless $i =~ /D[01][+-].+/; $i =~ /(D[01])([+-])(.*)/; print t$1=$1$2t$3n; } elsif ($i !~ /./) { $i .= . . shift @instr; next; } elsif ($i =~ /([^.]+).(.*)/ and exists $onearg{$1}) { print t$1t$2n; } elsif ($i =~ / $r ([+-]) (d+) . $f /ox) { if ($3 == 1) { print t$1=$1$2$3t$4n; } else { print t$1=$1$2CONt$4,$3n; } } elsif ($i =~ / $r = $r - $r . $f /ox) { print t$1=$2-$3t$4n; } elsif ($i =~ / $r ([+&!-]) $r . $f /ox) { print t$1=$1$2$3t$4n; } elsif ($i =~ / $r = ( (?:-1)? -) $r . $f /ox) { print t$1=$2$3t$4n; } elsif ($i =~ / ( L[AC] (d+) ) . (.*) /ox) { print t$1t$2n; } elsif ($i =~ / ( L[AC] ) . (.*) /ox) { print t$1HEXt$2n; } elsif ($i =~ / ( D[01]= ) . ([0-9A-F]+) /ox) { print t$1( . length ($2) . )t#$2n; } elsif ($i =~ / (.*) . $f /ox) { print t$1t$2n; } elsif ($i =~ / G (OIN)? ([245]) . (.*) /ox) { print tREL($2)t$3n; } $i = shift @instr; } ---8<------------------------------------------ -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > It would be more fun (at least for me) if you used SASM or JAZZ syntax;-) --8<------------------------------------------------ #!/usr/bin/perl -w use strict; my @instr = split /s+|[%;].*n/, (join , <>); my $i = shift @instr; my $f = (A|B|P|X|XS|W|WP|S); my $r = ([ABCD]); my $lnum = 0; my (@begin, @end); sub label { sprintf L%04x, $lnum++; } sub openblock { my ($b, $e) = (label (), label ()); push @begin, $b; push @end, $e; ($b, $e); } # MASD abbreviations # each line must have a t in front to distinguish it from a label! my %abbrev = ( SAVE => tGOSBVL =SAVPTRn, LOAD => tGOSBVL =GETPTRn, LOADRPL => tGOSBVL =GETPTRLOOPn, RPL => tA=DAT0tAntD0=D0+t5ntPC=(A)n, LOOP => tA=DAT0tAntD0=D0+t5ntPC=(A)n, SCREEN => tGOSBVL =D0->Row1n, MENU => tGOSBVL =D0->Sft1n, INTOFF2 => tGOSBVL =DisableIntrn, INTON2 => tGOSBVL =AllowIntrn, ERROR_C => tGOSBVL =ErrjmpCn, A=IN2 => tGOSBVL =AINRTNn, C=IN2 => tGOSBVL =CINRTNn, OUT=C=IN => tGOSBVL =OUTCINRTNn, RES.STR => tGOSBVL =MAKE$Nn, RES.ROOM => tGOSBVL =GETTEMPn, SHRINK$ => tGOSBVL =Shrink$n, COPY<- => tGOSBVL =MOVEDOWNn, COPYDN => tGOSBVL =MOVEDOWNn, COPY-> => tGOSBVL =MOVEUPn, COPYUP => tGOSBVL =MOVEUPn, DISP => tGOSBVL =DBUGn, DISPKEY => tGOSBVL =DBUG.KEYn, SRKLST => tGOSBVL =Shrink$Listn, ZEROMEM => tGOSBVL =WIPEOUTn, MULT.A => tGOSBVL =MULTBACn, MULT => tGOSBVL =MPYn, DIV.A => tGOSBVL =IntDivn, BEEP => tGOSBVL =makebeepn ); # Instructions without field argument # Note that the 1's are dummies and not used my %passthru = ( ASLC => 1, ASRC => 1, BSLC => 1, BSRC => 1, CSLC => 1, CSRC => 1, DSLC => 1, DSRC => 1, A=IN => 1, C=IN => 1, PC=A => 1, PC=C => 1, PC=(A) => 1, PC=(C) => 1, D0=A => 1, D0=C => 1, D0=AS => 1, D0=CS => 1, AD0EX => 1, CD0EX => 1, AD0XS => 1, CD0XS => 1, CLRST => 1, C=ST => 1, ST=C => 1, CSTEX => 1, OUT=C => 1, OUT=CS => 1, UNCNFG => 1, CONFIG => 1, RESET => 1, C=ID => 1, BUSCB => 1, BUSCC => 1, BUSCD => 1, SREQ? => 1, SHUTDN => 1, INTOFF => 1, INTON => 1, RSI => 1, SETHEX => 1, SETDEC => 1, RTN => 1, RTNSXM => 1, RTNSC => 1, RTNCC => 1, RTNC => 1, RTNNC => 1, P+1 => 1, P-1 => 1, C+P+1 => 1, C=RSTK => 1, RSTK=C => 1 ); # Instructions which invariably require a single argument my %onearg = ( GOC => 1, GONC => 1, GOTO => 1, GOLONG => 1, GOVLNG => 1, GOSUB => 1, GOSUBL => 1, GOSBVL => 1, D0=(2) => 1, D0=(4) => 1, D0=(5) => 1, D1=(2) => 1, D1=(4) => 1, D1=(5) => 1 ); # Inverted tests # keys are regexps, values must eval() to the substitution string my %testinv = ( ?$r=$r.$f => q{?$1#$2.$3}, ?$r#$r.$f => q{?$1=$2.$3}, ?$r=0.$f => q{?$1#0.$2}, ?$r#0.$f => q{?$1=0.$2}, ?$r>$r.$f => q{?$1<=$2.$3}, ?$r<=$r.$f => q{?$1>$2.$3}, ?$r<$r.$f => q{?$1>=$2.$3}, ?$r>=$r.$f => q{?$1<$2.$3}, ?ST=0.(d+) => q{?ST=1.$1}, ?ST=1.(d+) => q{?ST=0.$1}, ?[AC]BIT=0.(d+) => q{?$1BIT=1.$2}, ?[AC]BIT=1.(d+) => q{?$1BIT=0.$2}, ?P=(d+) => q{?P#$1}, ?P#(d+) => q{?P=$1} ); # Skip and Skip-Else instructions and the jump they translate to my %skips = ( SKIP => GOTO, SKIPL => GOTOL, SKIPC => GOC, SKC => GOC, SKIPNC => GONC, SKNC => GONC, SKUB => GOSUB, SKUBL => GOSUBL ); my %skelse = ( SKELSE => GOTO, SKLSE => GOTO, SKEC => GOC, SKENC => GONC ); # Translators for UP UPC UPNC (only the C NC part) my %jumpcond = ( => GOTO, C => GOC, NC => GONC ); while (defined $i) { if ($i =~ /CODE/) { print STDERR Warning: RPL mode not supported (yet?)n; } elsif ($i =~ /*(.*)/) { print $1n; } elsif (exists $abbrev{$i}) { print $abbrev{$i}; } elsif (exists $passthru{$i}) { print t$in; } elsif (exists $skips{$i}) { my ($b, $e) = openblock; print t, $skips{$i}, t$en$bn; } elsif ($i eq }) { my $e1 = pop @end; pop @begin; print $e1n; if (@instr and exists $skelse{$instr[0]}) { my $i = shift @instr; my ($b2, $e2) = openblock; print t, $skelse{$i}, t$e2n$b2n; } } elsif ($i eq {) { my ($b, $e) = openblock; print $bn; } elsif ($i =~ /^P=(d+)?$/) { if (/^P=(d+)$/) { print t$1t$2n; } else { $i .= shift @instr; next; } } elsif ($i =~ /UP(N?C)?(d*)/) { my $n = $2; $n = 1 unless $n; print t, $jumpcond{$1}, t, $begin[@begin - $n], n; } elsif ($i =~ /EXIT(N?C)?(d*)/) { my $n = $2; $n = 1 unless $n; print t, $jumpcond{$1}, t, $end[@end - $n], n; } elsif ($i =~ /^?/) { if ($i !~ /./ and $i ne ?SB=0 and $i ne ?MP=0 and $i ne ?XM=0 and $i ne ?SR=0) { $i .= . . shift @instr; } my $t = shift @instr; if ($t eq { or $t eq SKIPYES) { my ($b, $e) = openblock; print t$intGOYESt$en$bn; } elsif ($t eq ->) { $t = shift @instr; if ($t eq {) { my ($b, $e) = openblock; for (keys %testinv) { if ($i =~ /$_/) { $i = eval $testinv{$_}; last; } } $i =~ s/./t/; print t$intGOYESt$en$bn; } else { $i =~ s/./t/; print t$intGOYESt$tn; } } elsif ($t =~ /UP(d*)/) { $i =~ s/./t/; my $n = $1; $n = 1 unless $n; print t$intGOYESt, $begin[@begin - $n], n; } elsif ($t =~ /EXIT(d*)/) { $i =~ s/./t/; my $n = $1; $n = 1 unless $n; print t$intGOYESt, $end[@end - $n], n; } } elsif ($i !~ /./) { $i .= . . shift @instr; next; } elsif ($i =~ /([^.]+).(.*)/ and exists $onearg{$1}) { print t$1t$2n; } elsif ($i =~ / $r ([+-]) (d+) . $f /ox) { if ($3 == 1) { print t$1=$1$2$3t$4n; } else { print t$1=$1$2CONt$4,$3n; } } elsif ($i =~ / $r = $r - $r . $f /ox) { print t$1=$2-$3t$4n; } elsif ($i =~ / $r ([+&!-]) $r . $f /ox) { print t$1=$1$2$3t$4n; } elsif ($i =~ / $r = ( (?:-1)? -) $r . $f /ox) { print t$1=$2$3t$4n; } elsif ($i =~ / ( L[AC] (d+) ) . (.*) /ox) { print t$1t$2n; } elsif ($i =~ / ( L[AC] ) . (.*) /ox) { print t$1HEXt$2n; } elsif ($i =~ / ( D[01]= ) . ([0-9A-F]+) /ox) { print t$1( . length ($2) . )t#$2n; } elsif ($i =~ / (.*) . $f /ox) { print t$1t$2n; } elsif ($i =~ / G (OIN)? ([245]) . (.*) /ox) { print tREL($2)t$3n; } $i = shift @instr; } --8<------------------------------------------------ Notes: - Input comes from <>, i.e. the files given on the command line or, if none, stdin. Output goes to stdout. - RPL mode is not supported: CODE and ENDCODE spit out a warning (to stderr), all other RPL stuff will cause it to do unpredictable things. - Some of the less used features of MASD are not supported either. - Expressions are not translated, as this would (probably) require a full-blown parser. - Generally, it relies on your program being correct. Weird things may happen if it's not. - Your program should not contain any labels of the form Lxxxx, where each x is a hex digit. The labels generated for MASD skips and blocks look like this. If you already have a few thousand lines of code and desperately waited for this program, change the sprintf line near the top. - Comments are silently dropped. Well, it doesn't get more readable anyway, you should keep the original version for that. - The code may look a bit ugly. In fact, it is. This program is in the public domain. Do whatever you want with it. If you become a millionaire through the use of this script, don't credit me, I won't take the blame anyway. Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman On Sat, 10 Aug 2002 23:54:53 +0200, Thomas Rast >> here's the shortest version I made in the mid 90ies: >Combining yours with a Good Idea (tm) in mine one gets >45 bytes, #DDA9h If you're optimizing for size we can get to even smaller byte counts by using a different method : ( HPTOOLS/Jazz syntax ) CODE GOSBVL =SAVPTR GOSBVL =D0->Row1 A=0 A -- LC(2) 33 B=C A LC(1) #A ?ABIT=0 0 GOYES + C=-C-1 A + - DAT0=C P D0=D0+ 1 B=B-1 B GONC - A=A+1 A ?ABIT=0 6 GOYES -- GOVLNG =GETPTRLOOP ENDCODE This one is 36.5 bytes with checksum # DC1h (48G) . ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. Your code variation is even two CPU cycles faster per loop;-) D=D-1 A 7 cycles D=D-1 B 5 cycles Raymond Thomas Rast schrieb im Newsbeitrag > here's the shortest version I made in the mid 90ies: > Combining yours with a Good Idea (tm) in mine one gets > CODE > SAVE GOSBVL D0->Row1 > LC(2) 63 D=C.A > LC 555555555555555 > A=C.W A+A.W > DAT0=C.W D0+16 > DAT0=C.W D0+16 > DAT0=C.B D0+2 > ACEX.W > D-1.B UPNC > LOADRPL > ENDCODE > 45 bytes, #DDA9h > Thomas > -- > Thomas Rast > If you cannot convince them, confuse them. > -- Harry S. Truman > Your code variation is even two CPU cycles faster per loop;-) > D=D-1 A 7 cycles > D=D-1 B 5 cycles I've noticed that processor cycles are not everything. Consider the difference between the R0=C.A and R0=C.W opcodes: The former is 6 nibbles long and takes 14 cycles, while the latter is 3 nibbles long and takes 20.5 cycles (according to Introduction to Saturn Assembly Language). So choosing one of the two - at least where both are possible - seems to be a question of space or speed. However the additional memory reads needed to fetch the longer one (R0=C.A) mostly undo the speed advance. This can be seen quite easily: Short form: CODE C=0.A C-1.A { R0=C.W C-1.A UPNC } RPL ENDCODE 16 bytes, #2270h, TEVAL: 15.22 seconds Long form: CODE C=0.A C-1.A { R0=C.A C-1.A UPNC } RPL ENDCODE 17.5 bytes, #1978h, TEVAL: 14.90 seconds So the difference in execution time for one single instruction is 0.32 seconds divided by #FFFFFh: 3.05E-7 seconds. While the expected difference is 6.5 cycles divided by 4MHz: 1.63E-6 seconds, more than five times as much. Note that the last number is even an underestimate, since the Saturn runs either at 3.75 or 3.95 MHz. Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > By checkerboard I mean individual pixels alternate between off and on in > both directions. I came up with a few ways but was wondering if there was > any kind of trick that would let me do it quicker. I guess doing it once > then storing the LCD in a GROB would be the fastest but that would also > waist a lot of space so lets say no GROBs allowed. How about (in MASD syntax) CODE SAVE GOSBVL D0->Row1 LC(2) 63 B=C.A % Loop counter LC 5555555555555555 % Pattern (16 digits) { DAT0=C.W D0+16 % Write a display line DAT0=C.W D0+16 DAT0=C.B D0+2 CSRB.W % Alternate pattern P=C.0 C=P.15 % Copy leftmost nibble B-1.B UPNC % Decrement counter } P=0 LOADRPL ENDCODE 47 bytes, CRC #E27Fh TEVAL: 0.0313 seconds If you want the top left pixel to be white instead of black, change the pattern to all A's instead of 5's. HTH Thomas -- Thomas Rast If you cannot convince them, confuse them. -- Harry S. Truman > By checkerboard I mean individual pixels alternate between off and on in > both directions. I came up with a few ways but was wondering if there was > any kind of trick that would let me do it quicker. I guess doing it once > then storing the LCD in a GROB would be the fastest but that would also > waist a lot of space so lets say no GROBs allowed. Try the following program. It is a lot faster than any pixel-by-pixel program I have seen, and works on an HP48 or HP49: << 0. 130. XRNG 0. 63. YRNG ERASE { #0 #0 } PVIEW 0. 63. FOR Y 0. Y R->C 130. Y R->C LINE 2 STEP 0. 130. FOR X X 0. R->C X 63. R->C TLINE 2 STEP 7 FREEZE >> >> By checkerboard I mean individual pixels alternate between off and on in >> both directions. I came up with a few ways but was wondering if there was >> any kind of trick that would let me do it quicker. I guess doing it once >> then storing the LCD in a GROB would be the fastest but that would also >> waist a lot of space so lets say no GROBs allowed. >Try the following program. It is a lot faster than any >pixel-by-pixel program I have seen, and works on an HP48 or HP49: ><< 0. 130. XRNG 0. 63. YRNG ERASE { #0 #0 } PVIEW > 0. 63. FOR Y 0. Y R->C 130. Y R->C LINE 2 STEP > 0. 130. FOR X X 0. R->C X 63. R->C TLINE 2 STEP > 7 FREEZE > You'll also find working in direct screen coordinates is faster than going through the HP's scaling functions. Something like: << #131d #64d BLANK PICT STO 0 64 FOR y #0d y R->B 2 ->LIST #130d y R->B 2 ->LIST LINE 2 STEP o 130 FOR x x R->B #0d 2 ->LIST x R->B #63d R->B 2 ->LIST TLINE 2 STEP 7 FREEZE On my GX your original program ran in about fourteen seconds whereas the above one runs in about ten. -- john R. Latala jrlatala@golden.net >> By checkerboard I mean individual pixels alternate between off and on in >> both directions. I came up with a few ways but was wondering if there was >> any kind of trick that would let me do it quicker. I guess doing it once >> then storing the LCD in a GROB would be the fastest but that would also >> waist a lot of space so lets say no GROBs allowed. >Try the following program. It is a lot faster than any >pixel-by-pixel program I have seen, and works on an HP48 or HP49: ><< 0. 130. XRNG 0. 63. YRNG ERASE { #0 #0 } PVIEW > 0. 63. FOR Y 0. Y R->C 130. Y R->C LINE 2 STEP > 0. 130. FOR X X 0. R->C X 63. R->C TLINE 2 STEP > 7 FREEZE > At least it's in RPL! :-) I guess I should have mentioned in my original post that I wasd looking for an RPL solution. I tried it and on my GX it took about 14 seconds which is slower than my RPL solution which runs in about one second (give or take). %%HP: T(3)A(D)F(.); << LCD-> SIZE BLANK PICT STO { # 0d # 0d } PVIEW { # 0d # 0d } PIXON { # 1d # 1d } PIXON PICT { # 2d # 0d } PICT { # 0d # 0d } { # 1d # 1d } SUB REPL PICT { # 4d # 0d } PICT { # 0d # 0d } { # 3d # 1d } SUB REPL PICT { # 8d # 0d } PICT { # 0d # 0d } { # 7d # 1d } SUB REPL PICT { # 16d # 0d } PICT { # 0d # 0d } { # 15d # 1d } SUB REPL PICT { # 32d # 0d } PICT { # 0d # 0d } { # 31d # 1d } SUB REPL PICT { # 64d # 0d } PICT { # 0d # 0d } { # 63d # 1d } SUB REPL PICT { # 128d # 0d } PICT { # 0d # 0d } { # 2d # 1d } SUB REPL PICT { # 0d # 2d } PICT { # 0d # 0d } { # 130d # 1d } SUB REPL PICT { # 0d # 4d } PICT { # 0d # 0d } { # 130d # 3d } SUB REPL PICT { # 0d # 8d } PICT { # 0d # 0d } { # 130d # 7d } SUB REPL PICT { # 0d # 16d } PICT { # 0d # 0d } { # 130d # 15d } SUB REPL PICT { # 0d # 32d } PICT { # 0d # 0d } { # 130d # 31d } SUB REPL 7 FREEZE >> P.S. Even though I was looking for an RPL solution it was informative looking at all the other solutions. -- john R. Latala jrlatala@golden.net well I am glad to announce that yes I had both calculators in my hands to day and I could not really tell a difference in the key the broken calc was a Chinese model and the Indonesian replacement has the good screen and I am very happy again I just finished installing the beta flash ROM and now I can begin using my new books from Gilberto Urroz which I highly recommend they are very well written. hopefully I will be answering question instead of asking so many after the 2 books ;) good night all > I purchased a hp 49g from Samson in Dec of last year. recently I went to > turn it on and to make a long story short its dead in the water so the hp > tech that I talked to recommended ups 2 day replacement as I cant wait 2 > weeks to get another calculator I have to start using it as soon as possible > for my calculus class. that part of the service was incredible great > technicians pleasant fast and all that my problem is they are replacing my > Chinese model with an Indonesian model I have hear bad things about these > calculators now I can deal with stiff keys I'm a big strong boy (loll) but > my main concern is a screen with poor visibility or that has fun colors etc. > if the Indonesian calculators are obviously inferior why is hp still selling > / sending them to nice loyal customers like me I have previously owned the > last 2 models in this series. my cal id number is id94202887 is there any > this was a little long winded but....I appreciate the help > well I am glad to announce that yes I had both calculators in my hands to > day and I could not really tell a difference in the key the broken calc was > a Chinese model and the Indonesian replacement has the good screen and I am > very happy again I just finished installing the beta flash ROM and now I can > begin using my new books from Gilberto Urroz which I highly recommend they > are very well written. hopefully I will be answering question instead of > asking so many after the 2 books ;) good night all > I purchased a hp 49g from Samson in Dec of last year. recently I went to > turn it on and to make a long story short its dead in the water so the hp > tech that I talked to recommended ups 2 day replacement as I cant wait 2 > weeks to get another calculator I have to start using it as soon as > possible > for my calculus class. that part of the service was incredible great > technicians pleasant fast and all that my problem is they are replacing my > Chinese model with an Indonesian model I have hear bad things about these > calculators now I can deal with stiff keys I'm a big strong boy (loll) but > my main concern is a screen with poor visibility or that has fun colors > etc. > if the Indonesian calculators are obviously inferior why is hp still > selling > / sending them to nice loyal customers like me I have previously owned the > last 2 models in this series. my cal id number is id94202887 is there any know > this was a little long winded but....I appreciate the help I purchased mine from amazon and it is a chinese model, I really don't have any problems with it. The buttons are a little stiff at first but with use they either become less stiff or I'm just getting used to them. I haven't had any problems with the screen...only problem I have is trivial, the calculator slide cover after being taken off and put back on so many times no longer stays on as well. Other than that, its a great calculator! > I purchased a hp 49g from Samson in Dec of last year. recently I went to > turn it on and to make a long story short its dead in the water so the hp > tech that I talked to recommended ups 2 day replacement as I cant wait 2 > weeks to get another calculator I have to start using it as soon as possible > for my calculus class. that part of the service was incredible great > technicians pleasant fast and all that my problem is they are replacing my > Chinese model with an Indonesian model I have hear bad things about these > calculators now I can deal with stiff keys I'm a big strong boy (loll) but > my main concern is a screen with poor visibility or that has fun colors etc. > if the Indonesian calculators are obviously inferior why is hp still selling > / sending them to nice loyal customers like me I have previously owned the > last 2 models in this series. my cal id number is id94202887 is there any > this was a little long winded but....I appreciate the help I purchased an HP 49G from HP Shopping and it was an Indonesian model that had a screen that scratched easily, but no rainbow effect. I called HP and they asked for the serial# off the back, and after I read it off to them, they told me it was a model that wasn't supposed to be defective. They said, the defective ones were the first runs made in Indonesia and that later ones produced there were okay. Well, after telling the man that regardless of any of that, my screen scratches by simply wiping off the dust, so they gave me an order # and address to their new service center in Tennessee and I ended up with a brand new one from China, which is perfect. Even if your new replacement model is of the bad batch, it can still be returned again until you get a good one. Oh, and HP has a service as well, where they will send you the new calc first and let you return the old one after getting your new one. >so they gave me an order # > and address to their new service center in ***Tennessee*** and I ended up > with a brand new one from China, which is perfect. Gene: What service center in TN? I live in Nashville. Anyone know where this is located? >so they gave me an order # > and address to their new service center in ***Tennessee*** and I ended up > with a brand new one from China, which is perfect. > Gene: What service center in TN? I live in Nashville. Anyone know where this > is located? It is in LaVergne Tennessee, by the way were practically neighbors, I'm from Kentucky. Try: http://www.contrib.andrew.cmu.edu/~drury/hp48gaur/ It's not the complete guide, though. Best wishes, Walter. > I'm trying to locate a copy of the hp48 Advanced User's Reference. Does > anyone know if it is available for download? Can't locate it at hpcalc.org. try www.calcpro.com $29.95 > I'm trying to locate a copy of the hp48 Advanced User's Reference. Does > anyone know if it is available for download? Can't locate it at hpcalc.org. Do somebody on the group had the idea to control the Philips Expanium 401 with hp49g? (Because there's some kind of in-cord remote attached...) Is it possible? > Using ROM 1.19-6, Calc is set to RAD and EXACT (I've also tried > different configurations that yield the same result listed below). > > I'm not sure if the ->Qpi command is working properly. > > For example 4.712 should convert to '(3*pi)/2' using the ->Qpi > command. > Instead it converts to '33/7' - the same as the ->Q command. > > Based on the '48 manual, the ->Qpi command compares the fractional > equivalent of the original number AND the fractional equivalent of the > original number divided by pi. It returns the fraction with the > smallest denominator - which should by '(3*pi)/2' and not '33/7'. > > What am I doing incorrectly? > The command ->Qpi does work correctly. It doesn't give (3*pi)/2 when > you feed it with the decimal approximation of 33/7 because 4.712 is > not the 12 digits approximation for (3*pi)/2. If you feed it with > 4.71238898038 then it will return (3*pi)/2. > Nick. you're correct in pointing out that the numeric format (and hence, the precision) determines whether the ->Qpi command functions properly or works the same as ->Q. Glenn > Using ROM 1.19-6, Calc is set to RAD and EXACT (I've also tried > different configurations that yield the same result listed below). > I'm not sure if the ->Qpi command is working properly. > For example 4.712 should convert to '(3*pi)/2' using the ->Qpi > command. > Instead it converts to '33/7' - the same as the ->Q command. The effect of the ->Qpi command (and the XQ and ->Q commands) depends on the current display settings. If you are using the STD (standard) display then you need 11 or 12 significant digit precision in the decimal representation in order to guarantee the '(3*pi)/2' result. However, using a FIX display, for example 6 FIX, and a 6 decimal place roundoff of the numerical value of '(3*pi)/2', you will find that ->Qpi will give '(3*pi)/2'. Some experimentation is necessary to determine how many significant digits are needed with the various display options to get a good conversion to rational or rational multiple of pi format. NOTE: The numeric display options are STD (standard), n FIX (fixed), n SCI (scientific), n ENG (engineering), with 0 <= n <= 11, for the number ofdecimal places to be displayed. The RND (roundoff) function takes as input a number-to-be-rounded and a roundoff code n, with -11 <= n <= 11. Negative n's round to |n| significant digits (at least 1) while non-negative n's round to n decimal places (including zero), the same as in the HP48 series. I'm looking for the unoffical manual of hp28s/c made by a french man in french language in which there it is indicated how to connect this calculator to a PC Nicolas On Sat, 10 Aug 2002 16:43:01 +0200, Nicolas >I'm looking for the unoffical manual of hp28s/c made by a french man in >french language in which there it is indicated how to connect this >calculator to a PC > Nicolas Is this what you're looking for? : http://www.courbis.com/voyage28.html ---------------------------------------------------------------------------- --- Jonathan Busby - before replying. Jonathan Busby a .8ecrit dans le message : edmelucts5gea2sfbfjjkamcoh3ohnuec5@4ax.com... > On Sat, 10 Aug 2002 16:43:01 +0200, Nicolas >I'm looking for the unoffical manual of hp28s/c made by a french man in >french language in which there it is indicated how to connect this >calculator to a PC > Nicolas > Is this what you're looking for? : > http://www.courbis.com/voyage28.html yes, thank you very much On my new HP49G I have a dark irritating shadow under every sign on the display. Though the LCD has a higher contrast it's worth readable than my old HP48G because of this shadow. I thought that HP has improved the displays. Any similar experiences? Georg. Try reducing the contrast (Press and hold 'on'; press '-' or '+') >On my new HP49G I have a dark irritating shadow under every sign on >the >display. Though the LCD has a higher contrast it's worth readable than >my old HP48G because of this shadow. I thought that HP has improved >the displays. >Any similar experiences? >Georg. > Try reducing the contrast (Press and hold 'on'; press '-' or '+') >On my new HP49G I have a dark irritating shadow under every sign on >the >display. Though the LCD has a higher contrast it's worth readable than >my old HP48G because of this shadow. I thought that HP has improved >the displays. >Any similar experiences? >Georg. Unfortunately that doesn't help much. Georg. > Try reducing the contrast (Press and hold 'on'; press '-' or '+') >On my new HP49G I have a dark irritating shadow under every sign on >the >display. Though the LCD has a higher contrast it's worth readable than >my old HP48G because of this shadow. I thought that HP has improved >the displays. >Any similar experiences? >Georg. Unfortunately that doesn't help much. Georg. Taoist writings, formatted for Scribe. The writings of Chuang Tzu http://www.windmills.freeserve.co.uk/ChuangTzu/ Yick. Asian philosophy is why the Chinese and Indians are still living in the same serfdom they've enjoyed for millennia. Rational thought produces extensible results. Tossing the ol' I Ching bones and repeating vaguely plausible aphorisms doesn't benefit anybody any more than a drag on a thai stick does. Only through progress can things improve, and progress requires systematic, methodical change for the better. Any system which does not allow for change is therefore an enemy of improvement. This includes virtually all non-western philosophy and ALL religions. This also explains why the West innovates while the pacific rim asian economies knock them off. Even the Japanese had to borrow Deming's principles to reach their current position (which is in decline due to traditional counterproductive practices, plus the goose laying the golden eggs [USA] is killing itself). > Taoist writings, formatted for Scribe. > The writings of Chuang Tzu > http://www.windmills.freeserve.co.uk/ChuangTzu/ > Yick. Asian philosophy is why the Chinese and Indians are still living in > the same serfdom they've enjoyed for millennia Still they produce your HP49 much cheaper than anywhere else so don't complain too much. What is more I doubt Taoism is really a religion and whatever it is now is far FAR FAR (in even bigger) from what it used to be. So it can evolve and you can adapt it to whatever you want which is a good thing I guess. Arnaud Quisiera que alguien me ayude, el problema es que le transferi un programa que era para HP48 a mi HP49G, y al momento de reiniciar para terminar la instalacion en el puerto 2 no entro mas, la he reseteado CAS, incluso la he dejado horas desconectada y lo mismo. Espero me puedan ayudar Mant.8en presionada la tecla [DROP] mientras la calculadora se reinicializa. Despu.8es de varios intentos seguro que puedes acceder. Ve al puerto 2 y borra la librer.92a en cuesti.97n. Por cierto, el grupo en espa.96ol para las calculadoras hp es: es.comp.sistemas.hp48 Saludos > Quisiera que alguien me ayude, el problema es que le transferi un > programa que era para HP48 a mi HP49G, y al momento de reiniciar para > terminar la instalacion en el puerto 2 no entro mas, la he reseteado > CAS, incluso la he dejado horas desconectada y lo mismo. > Espero me puedan ayudar I am a surveyor and only use my 49g for running programs I use for work. these are written in RPN and work well for what I do. Is there any need for me to update to the latest ROM? I have ROM version 1.18. I don't know where i have heard it but: Never change a running system!!! Martin > I am a surveyor and only use my 49g for running programs I use for work. > these are written in RPN and work well for what I do. Is there any need for > me to update to the latest ROM? I have ROM version 1.18. > I don't know where i have heard it but: > Never change a running system!!! That may be the case for some system. But on the HP49, it's definitely worth upgrading to the latest ROM. yes, I agree with you. Martin >>I don't know where i have heard it but: >>Never change a running system!!! > That may be the case for some system. But on the HP49, it's definitely worth > upgrading to the latest ROM. The 1.18 has more and bigger bugs than the 1.19-6 So, pick your choice...wait for a disaster or prevent it ! > I don't know where i have heard it but: > Never change a running system!!! > Martin > I am a surveyor and only use my 49g for running programs I use for work. > these are written in RPN and work well for what I do. Is there any need for > me to update to the latest ROM? I have ROM version 1.18. Ever since ROM 1.19-5 (now 1.19-6) the HP 49G OS has been perfect. That is: no major bugs and loaded with useful operations. For example I like the CAS help system very much. I recommend upgrading to the latest ROM anyway. > I am a surveyor and only use my 49g for running programs I use for work. > these are written in RPN and work well for what I do. Is there any need for > me to update to the latest ROM? I have ROM version 1.18. I have a program that gives at the end a GROB. This GROB displayed on the screen and saved in XXX variable(for other time display). I used a temporary (TEMP) variable. I am wondering if it is must using this temperary variable: . . . @ here is the GROB 'TEMP' STO << TEMP ->LCD 3 FREEZE >> 'XXX' STO XXX >> Tal Why don't you try it ! ;-) > I have a program that gives at the end a GROB. > This GROB displayed on the screen and saved in > XXX variable(for other time display). > I used a temporary (TEMP) variable. > I am wondering if it is must using this temperary > variable: > . > . > . @ here is the GROB > 'TEMP' STO > << TEMP ->LCD 3 FREEZE >> 'XXX' STO > XXX >> > Tal I have a repeatable file result that stored in xxx variable. Does anyone could help to check if this file is exist and if so the result file name will be changed and will be stored as xxx1 and so on. Tal Do you mean something like: << IF 'xxx' VTYPE -1 == THEN 'xxx' STO ELSE 0 -> k << k WHILE 'xxx SWAP + STR-> VTYPE -1 == REPEAT 'k' INCR END 'xxx k + STR-> STO >> END or, if you can give up on the initial 'xxx' and settle for 'xxx0' and with some trimming and experimenting: << -1 -> k << 0 DO DROP 'k' INCR 'xxx SWAP + STR-> DUP VTYPE -1 UNTIL # @ 'not equal' above [+/-] key END STO >> > I have a repeatable file result that stored in xxx > variable. > Does anyone could help to check if this file is > exist and if so the result file name will be changed > and will be stored as xxx1 and so on. > Tal -- Al. Andreou, ee4299 at ee.teiath.gr. | When everything else fails, http://nemesis.ee.teiath.gr/~ee4299/ | this won't work either. . . I have a repeatable file result that stored in xxx variable. Does anyone could help to check if this file is exist and if so the result file name will be changed and will be stored as xxx1 and so on. Tal > I have a repeatable file result that stored in xxx > variable. > Does anyone could help to check if this file is > exist and if so the result file name will be changed > and will be stored as xxx1 and so on. > Tal Though I don't get exactly what a repeatable file is, you can always check if a variable with a given name exists by using: VARS nameOfYourFile POS where nameOfYourFile can be 'xxx' or anything else. Nick. I have one made in 1999 (Indonesia), poor quality, but already with a black on green screen. New HP48GX seem to have the black on white (or rather grey) screen from the HP49G. Does anyone know since when the HP48GX comes with the new screen? In which country are the newest HP48GX made? Still in Indonesia? Georg. > I have one made in 1999 (Indonesia), poor quality, > True... the old Singapore units were great. I dropped mine and cracked the > screen 8..( a few years ago and now I have an older Indonesian unit, Also, > I recently picked up a new one (at a price lower than the others) with a the > back screen. >New HP48GX seem to have the black on white (or > rather grey) screen from the HP49G. > Yep. > Does anyone know since when the HP48GX comes with the new screen? > I've seen them around for sevel months -- some places that still have the > greenish-blue screens are likely sitting on older stock that hasn't been > moving very quickly. >In which country are the newest HP48GX made? Still in Indonesia? > Still Indonesia. > The new units have nomenclature printed on the keys (and usually not > straight). My newer unit is slower than the older one and the alarm/beeper > is considerably less audible. The over all quality is reduced, but so is > the price (I would have gladly paid extra for better quality and lasting > value, and enjoyed buying the products from a firm that truly believed in > customer service -- the game does not work that way anymore). > Greg I still have a one question: Is the brand new screen really better readable? On the display of the HP49g there is a much bigger shadow underneath every sign compared to the old green screen. I could get a HP48gx made in Singapore 1995 second hand with the blue on green screen. Will there be a big difference to my Indonesian one (1999) with the black on green screen? Georg. X > Is the brand new screen really better readable? On the display of the > HP49g there is a much bigger shadow underneath every sign compared to > the old green screen. > I could get a HP48gx made in Singapore 1995 second hand with the blue > on green screen. Will there be a big difference to my Indonesian one > (1999) with the black on green screen? X Are you sure your 49G is ok?! I have in front of me a 48SX (3109S00700) and a 48GX (3448S03303) plus a 49G (ID93101038) (my own, not the original though) a 49G (ID93100819) (long loan) a 49G (ID95000985) AND a 41CX (2426S42123) The best displays are 41CX (with a small shadow) and the 49G, where I can see the shadow when light comes from 45 up-front (above the calculator) AND when I look the LCD from the left side while the light is almost directly above the calculator, maybe slightly to the north the real pixels almost vanish and I can see only the shadow. BUT under normal use I never noticed that before, so I ask once again: Is your HP 49G ok? The 48SX looses contrast when tilting, but the 48GX seems to be ok. Adjusting the contrast with [ON] [ + ] / [ - ] helps somewhat. I don't know how much of this is just a viewers opinion different lightning conditions, contrast settings, etc. Comments? chao > Yes it is a bug!!! > Look at the example! Some digits are missing! Oh no, and I was thinking that the continuation character (...) was meant here. Now that I tried it myself, I see. > I never noticed this before and only God knows how many > errors I have made trusting to the fact that I will always get > to see a window-full of numbers never missing a single digit !! Exactly the same with me. So this buggy thing is not to be trusted at all? Will someone tell us *all* things that we have to worry about using the HP49G, or do we have to find each and every bug and error ourselves and one at a time? Anyway, it seems that the HP49G is just a good chance for training the detectivistic abilities. What Jedi Knights are we talking about? I feel more and more like Columbo trying to brong some light to the ingredients of this calculatory crime ;-) > AUTSCH! This is painful but nice to know that there is Yes, and what after 1.19-7? Or does someone expect to get at last a clean system with 1.19-whatsoever? Nick. P.S. Patching a patchwork gives always a new even more complicated patchwork, which at some point breaks down without any particular reason. Long live the Hewlett-Patch 49G ;-) > No, it isn't a bug and actually this very same behavior occurs when > editing any kind of object that contains lines longer than the > display. Convert your long number to a string and try to edit it. > You'll notice the same. The ellipsis ... (character 30 on the HP49G) > is a help for you, for quickly noticing that some object extends past > the right or left edge of the display. > Nick. > X > Example > 123456789012345678901234567890 > When you attempt to edit the number, in the first 'window' you see > 123456789012345678901... > pushing left shift right arrow twice gets you: > ...34567890123456789012... > and the next window: > ...4567890 etc X > Oh no, and I was thinking that the continuation character (...) was > meant here. Now that I tried it myself, I see. > I never noticed this before and only God knows how many > errors I have made trusting to the fact that I will always get > to see a window-full of numbers never missing a single digit !! > Exactly the same with me. So this buggy thing is not to be trusted at Yes, this was exactly my 1st reaction !! But now I take back some of the *bugging* here. To me, personally, ever since 1.19-5 was released there has been no big crashes, no major bugs and the overall functionality is excellent. even the smaller bugs that tend to crawl under the hood ;-) > all? Will someone tell us *all* things that we have to worry about > using the HP49G, or do we have to find each and every bug and error > ourselves and one at a time? X With the current state of the things (quite good) and remembering the fact that this is the only HP calculator with Flash ROM I wouldn't be so worried - as long as JYA kindly patches everything on request. Now we need just one more thing: Bernard to put units back into the EQW !!! Then this calculator would be perfect IMO. Veli-Pekka > With the current state of the things (quite good) and remembering > the fact that this is the only HP calculator with Flash ROM > I wouldn't be so worried - as long as JYA kindly patches everything > on request. The job is indeed good but my only concern is that we can't go on for ever asking Jean Yves to do this and that for us. When sometime in future he gets tired of doing all this work for nada, what then? Will the HP49G have reached a state with few minor bugs, or will then new hidden bugs appear? > Now we need just one more thing: > Bernard to put units back into the EQW !!! No chance, I think. To me it seems that the professor doesn't like the units to be a major part of his CAS. But then again, instead of *1_m we can do *m (having nothing stored in m) > Then this calculator would be perfect IMO. Oh no! It will not be. There are many too many things to be corrected even in the CAS. If HP had only give those guys adequate support and time! But no, HP found better to put them out. What a loss! Nick. > 123456789012345678901234567890 > Enter > When you attempt to edit the number, in the first 'window' you see > 123456789012345678901... > pushing left shift right arrow twice gets you: > ...34567890123456789012... > no matter which font or view mode or editing that I have tried, I get the > same result, loosing one number at the beginning and end of each window. Some may argue that... Page Left/Right have been put there in order to view or find text easily. If you summarize Page Left/Right to: equivalent of pressing 22 (or 33) times left/right arrow. editor is the same as the HP49) I didn't have anything to refer to. That is, the HP48 doesn't have page left/right, and I do not know any other HP48 editor displaying the ... at the edge of the page, therefore hard to compare with anything existing. So I had to make a choice. If you edit a string made of 1234567890 many times First time you edit you will see: 123456789012345678901... , the ... hiding the 2 Pressing LS Right Arrow will put the cursor on the last 1. Pressing again: will display: ..34567890123456789012... As you can see, the previous 2 is *still* in the window. So you see it twice (even if it's covered). Depending on the number of characters to display, the page scroll will always be a move of 21 characters (or 32). this is by design choice. I had intensive review of this behaviour, and have always questioned myself wether I should change the number of characters to be shifted at a time. I believe the actual choice give the best compromise between speed and how useful it is, I only use the PageScroll to quickly find text, then I use the non-shifted arrow keys. In the nearly 7 years of existence of this text editor, I never had any complains about it :) X > If you summarize Page Left/Right to: equivalent of pressing 22 (or 33) times > left/right arrow. X > Depending on the number of characters to display, the page scroll will > always be a move of 21 characters (or 32). > this is by design choice. > I had intensive review of this behaviour, and have always questioned myself > wether I should change the number of characters to be shifted at a time. I > believe the actual choice give the best compromise between speed and how > useful it is, I only use the PageScroll to quickly find text, then I use the > non-shifted arrow keys. X I still don't quite get it, sorry! Why not move 20/31 characters at a time AND at the first page 21/32 OR which I think might be even better: pad it with one |> store arrow at the beginning to equalize the length & to show that you are back at the beginning when moving to the left. The last page seems to be ok length with a space for cursor to the right. After using years (from 1973: HP-21), no - decades of HP calculatrice I have come to trust them, that is, I trust the engineers taken care of *everything* and I just use them without a care because they are Best ! This feature - cosmetic to some, thinking it only as a quickview (quite ok) - crucial to those (like me) who think it as a tool to write down long integers or hex digits - can be corrected very easily. Please?! Veli-Pekka the > editor is the same as the HP49) I didn't have anything to refer to. That is, > the HP48 doesn't have page left/right, and I do not know any other HP48 > editor displaying the ... at the edge of the page, therefore hard to compare > with anything existing. > So I had to make a choice. > I had intensive review of this behaviour, and have always questioned myself > wether I should change the number of characters to be shifted at a time. I > believe the actual choice give the best compromise between speed and how > useful it is, I only use the PageScroll to quickly find text, then I use the > non-shifted arrow keys. explain it. I can see how for page scrolling of text it is very useful. I thought the page scroll was older than that, (btw I dont have a 48... yet.) as I know that the HP 16 had a window function for long binary numbers, as going through binary numbers one by one, would be very confusing. (Which is why sane people convert them to hex :) ) However scrolling through long hex or decimal numbers can get confusing too. So currently what I do is I put page breaks after each 20 characters so I can see all the numbers on the screen at once, so I'll simply write a short program doing just that. > In the nearly 7 years of existence of this text editor, I never had any > complains about it :) lol. sorry to be the first. :) Blair. > So currently what I do is I put page breaks after each 20 characters so I > can see all the numbers on the screen at once, so I'll simply write a short > program doing just that. I suggest the following program to do just that: 256 ATTACH << ->STR 20 R~SB 100000000 R~SB #9B003 FLASHEVAL DROP 'CUT20' STO Will do just what you want to do, but very fast .. Perfect, Blair > I suggest the following program to do just that: > 256 ATTACH > << > ->STR 20 R~SB 100000000 R~SB > #9B003 FLASHEVAL DROP >> > 'CUT20' STO > Will do just what you want to do, but very fast .. what would i have to change (48SX) to make this work on an HP49G? (for external keyboard) TX Several people have mentioned the lack of support for Using the Power of Your HP-48sx from your PC in the cable/software package. In order to help bridge that gap - and mostly because I can't type long programs on the 48's keyboard - I have written a program that allows object entry from a terminal or it basically to see if I could do it. I hope that someone can get some good use out of it. Purpose: This program will allow a user to type objects on a terminal (or terminal emulator directly to the HP-48sx. Directions for use: Download the directory TERM. Setup your IOPAR variable for XON XOFF and for whatever other communication parameters you want to use. For example: for 9600 baud, no parity checking, and XON XOFF - your IOPAR variable could be { 9600 0 1 1 3 1 }. Note that the translate code, and checksum type are not used. Connect the 48sx to your terminal or PC and set up the communication parameters on both the 48 and PC. Make TERM the current directory, and execute TRM. You should see: Term Entry 1.0 on your terminal screen, as well as on the 48sx screen. Now you can type things on your terminal. Each character is sent to the 48. To tell the 48 that you are finished with the current object, type END on a line by itself. All the lines you have typed so far will be combined into an object and left on the stack. The backspace key (Control-H) will delete the last character you typed on a current line. This is the only form of editing allowed. To enter the symbols <<, >>, or -> you should type <<, >>, -> respectively. The program automatically takes care of converting the symbols. Since this program uses XMIT and SRECV for I/O, the translate code in IOPAR is not used. This means that <<, >>, and -> will be the only symbols converted. because I wanted to be able to use a typewriter keyboard to enter data into the 48. I have some ideas for enhancements such as better editing capabilities, two way data transfer, more control of the 48 from a terminal, etc. If I get the chance, I'll add some of these features. Also, and this is VERY IMPORTANT. This code expects the stack to be empty before it is run. I know this is not good calculator programming etiquette, but hey, I'll fix it in a later release. As you've probably guessed, I'm a software engineer :-) Feel free to do whatever you want to this code. Please let me know if you make any cool enhancements. The directory contains the following objects: TRM - Main entry point to this program. This saves the current flags, prints Term Entry 1.0 on the 48's display, and calls GETPROG. Flag 2 is set. Flag 2 does not mean anything. It was supposed to mean that the program should echo characters back to the terminal. The program always echos characters to the terminal, so flag 2 doesn't do anything. I should remove it, but I haven't yet. GETPROG - Get a program (or any object). This procedure opens I/O communications, clears the I/O buffer, and sends Term Entry 1.0 to the Terminal. Then it collects lines of text, until the user types END. Afterwards, it combines all the lines of text into a single object and leaves it on the stack. READLN - Reads a line of text. A line is a string of characters terminated with a carriage return. FIXLN - Convert <<, >>, -> into their 48sx representations everywhere they appear in a line. CNVR - Convert all the strings on the stack (lines) into one object. READCH - Read a single character from the terminal, and add it to the current string. If the character is a backspace, then erase one character from the string. If the character is a carriage return, then echo a carriage return, line feed sequence. DECL - Remove one character from the current line. LIN - Current line is stored here. When the line is terminated, it gets pushed as a string onto the stack. Jamie Odell MXO - Commercial Systems Division (CSY) Hewlett-Packard Co. jodell@hpda.hp.com ---------------------------------------------------------------------------- -- #FD90h 953 %%HP: T(3)A(D)F(.); DIR TRM << CLLCD Term Entry 1.0 1 DISP RCLF -> f << 2 SF @ Set terminal echo on (not used!). GETPROG f STOF >> >> GETPROG << OPENIO BUFLEN DROP SRECV DROP @ Clear the serial I/O buffer before doing anything DROP Term Entry 1.0 13 CHR + 10 CHR + XMIT @ Transmit message with CR/LF DROP DO READLN LIN @ Read in next line FIXLN @ Convert special characters to 48 characters UNTIL LIN itself 'LIN' STO END CNVRT @ Pack all lines into a single object >> READLN << DO READCH DUP @ Read characters until CR 'LIN' SWAP STO+ UNTIL 13 CHR END >> FIXLN << -> l << 1 CF @ Check for occurences of << >> -> DO l CASE l @ Loop until no more occurences are found, << POS @ converting each occurence on the way to the 48 THEN l @ representation. << POS << @ REPL @ More special characters can be added as needed. END l @ Just add a new case. >> POS @ Remember to replace the number of characters you THEN l @ remove with an identical number of characters. >> POS >> REPL END l -> POS THEN l -> POS -> REPL END 1 SF END 'l' STO UNTIL 1 FS? @ Flag 1 is a boolean used to tell us if we are done END l >> >> CNVRT << DROP DEPTH @ Drop the END string off the stack -> d << IF d 1 > @ Combine everything on the stack into one string THEN 2 d START + NEXT END OBJ-> @ Convert the string into an object >> >> READCH << DO @ Wait until the user types a key on the terminal UNTIL BUFLEN DROP 0 > END 1 SRECV @ Get one character at a time! DROP -> c << CASE c 13 @ If the character is a return then echo CR/LF THEN c 10 CHR + XMIT DROP c END c 8 @ If the character is a backspace, then erase the THEN c @ the current line. + c + XMIT DROP DECLN END c XMIT DROP c @ Otherwise, just echo the character. END >> >> DECLN << LIN 1 LIN SIZE 1 - SUB 'LIN' STO >> LIN END > what would i have to change (48SX) to make this work on an HP49G? > (for external keyboard) The big problems were that LIN is a command in the 49G, and that the 49G needs to have literal characters (not the ones that are part of a Kermit translation code) doubled up. I took the liberty of making a few other changes. It does work (except that you may find some unwanted CR characters within strings), sort of, and it's kind of cute, but terribly slow. a lot of improvements could be made, but I expect that something like this really ought to be written in SysRPL or assembly. Oh yeah, it looks like if you want a newline within a string, type it in as 010. Change all references to the calculator to read 49G. > Purpose: This program will allow a user to type objects on a terminal (or > terminal emulator directly to the HP-48sx. Well, this version needs a 49G, but slight changes would let it work on a 48. I believe that the only change needed would be to use something other than SREPL in the FIXLN program. > Directions for use: Download the directory TERM. Setup your IOPAR variable > for XON XOFF and for whatever other communication parameters you want to use. > For example: for 9600 baud, no parity checking, and XON XOFF - your IOPAR > variable could be { 9600 0 1 1 3 1 }. Note that the translate code, and > checksum type are not used. XON/XOFF doesn't work on a 49G, just don't type too fast. The buffer can hold 255 characters. > Connect the 48sx to your terminal or PC and set up the communication > parameters on both the 48 and PC. Make TERM the current directory, and execute > TRM. You should see: > Term Entry 1.0 I changed it to Term Entry JMP.1. > on your terminal screen, as well as on the 48sx screen. > Now you can type things on your terminal. Each character is sent to the 48. > To tell the 48 that you are finished with the current object, type END on a > line by itself. > All the lines you have typed so far will be combined into an object and left > on the stack. > The backspace key (Control-H) will delete the last character you typed on a > current line. This is the only form of editing allowed. > To enter the symbols <<, >>, or -> you should type <<, >>, -> > respectively. The program automatically takes care of converting the symbols. -> was translated to a right arrow followed by a space. I eliminated that space. But I left the space next to the program delimiters. > Since this program uses XMIT and SRECV for I/O, the translate code in IOPAR is > not used. This means that <<, >>, and -> will be the only symbols > converted. For the translations that I prefer, replace the FIXLN program with the following, but observe the usual dire warnings about being sure of the argument for SYSEVAL: ----------------------------------------------------------------------- %%HP: T(3)A(R)F(.); @ 49G version of FIXLN @ # A192h, 63.5 bytes << DUP IF @ Make sure we have a string. TYPE 2. =/ THEN 514. DOERR END # 2F34Dh SYSEVAL @ KINVISLF for 49G DROP >> ----------------------------------------------------------------------- Or for a 48, use this instead: ----------------------------------------------------------------------- %%HP: T(3)A(R)F(.); @ 48 series version of FIXLN. @ # E3AAh, 63.5 bytes << DUP IF @ Make sure we have a string. TYPE 2. =/ THEN 514. DOERR END #3016Bh SYSEVAL @ KINVISLF for 48 series. DROP >> ----------------------------------------------------------------------- The above will do the same translation as would be done to a Kermit ASCII transfer, and the translation mode (I prefer 3) in IOPAR is respected. The argument checking might not be really necessary, but with a rough program like this, I'd prefer to err on the side of caution. > because I wanted to be able to use a typewriter keyboard to enter data into > the 48. I have some ideas for enhancements such as better editing > capabilities, two way data transfer, more control of the 48 from a terminal, > etc. If I get the chance, I'll add some of these features. > Also, and this is VERY IMPORTANT. This code expects the stack to be empty > before it is run. I know this is not good calculator programming etiquette, > but hey, I'll fix it in a later release. As you've probably guessed, I'm a > software engineer :-) A trivial fix, no need to have an empty stack now. But note that I stashed the old stack in a local variable, which means that it will be lost if the program errors out. Change that to a global variable if the old stack contents are really important to you. > Feel free to do whatever you want to this code. Please let me know if you > make any cool enhancements. > The directory contains the following objects: > TRM - Main entry point to this program. This saves the current flags, prints > Term Entry 1.0 on the 48's display, and calls GETPROG. Flag 2 is set. Flag > 2 does not mean anything. It was supposed to mean that the program should > echo characters back to the terminal. The program always echos characters to > the terminal, so flag 2 doesn't do anything. I should remove it, but I > haven't yet. > GETPROG - Get a program (or any object). This procedure opens I/O > communications, clears the I/O buffer, and sends Term Entry 1.0 to the > Terminal. Then it collects lines of text, until the user types END. > Afterwards, it combines all the lines of text into a single object and leaves > it on the stack. > READLN - Reads a line of text. A line is a string of characters terminated > with a carriage return. > FIXLN - Convert <<, >>, -> into their 48sx representations everywhere they > appear in a line. > CNVR - Convert all the strings on the stack (lines) into one object. > READCH - Read a single character from the terminal, and add it to the current > string. If the character is a backspace, then erase one character from the > string. If the character is a carriage return, then echo a carriage return, > line feed sequence. > DECL - Remove one character from the current line. > LIN - Current line is stored here. When the line is terminated, it gets > pushed as a string onto the stack. Changed the above to CLIN to avoid conflict with 49G's LIN command. > Jamie Odell > MXO - Commercial Systems Division (CSY) > Hewlett-Packard Co. > jodell@hpda.hp.com My version follows: ----------------------------------------------------------------------- %%HP: T(3)A(R)F(.); @ Term Entry for 49G @ # 7A73h, 757. Bytes DIR TRM @ Main program. << CLLCD Term Entry JMP.1 1. DISP DEPTH ->LIST -> s @ Save the stack. << GETPROG @ Get an object from I/O. CLOSEIO s LIST-> @ Restore the old stack. 1. + ROLL @ Move new object back to level 1. >> >> GETPROG @ Gets an object from I/O. << 'CLIN' STO @ Start with current line empty. OPENIO @ Clear the I/O buffer. BUFLEN DROP SRECV DROP2 Term Entry JMP.1010013 @ Transmit message with CRLF. XMIT DROP DO READLN @ Read in next line. CLIN @ Put the line on the stack. FIXLN @ Translate characters. UNTIL CLIN @ Loop until user types END 'CLIN' STO @ Store an empty string. END CNVRT @ Pack all lines into a single object >> READLN @ Read in a line. << DO @ Read characters one at READCH DUP @ a time until CR. 'CLIN' SWAP STO+ UNTIL CLIN 2. DISP @ Display the line. END >> FIXLN @ Translate special characters. << @ Also see alternate versions above. << << SREPL DROP @ Note that SREPL is 49G only. >> >> SREPL DROP -> -> SREPL DROP >> CNVRT << DROP @ Drop the END from the stack. @ Combine the stack into one string. DEPTH -> d << IF d 1. > THEN 2. d START + NEXT END STR-> @ Convert the string to >> @ whatever object. >> READCH @ Read characters one at a time << DO @ Wait for a character. UNTIL BUFLEN DROP 0. > END 1. SRECV DROP -> c @ Get the character. << CASE THEN 013010 XMIT DROP 013 END THEN 008 008 XMIT DROP @ Erase from the terminal screen DECLN @ and the calculator. END @ Otherwise just c XMIT DROP @ transmit the character. c END >> >> DECLN @ Remove the last character << @ from the current line. CLIN 1. OVER SIZE 1. - SUB 'CLIN' STO >> CLIN @ Variable to hold current line. END ------------------------------------------------------------------------ -- James THANKs a lot ! nice, clean and useful. you should send it to HPCALC. i installed it from the PC without effort :) ________________________________________________________________________ > THANKs a lot ! > nice, clean and useful. I'm glad that you found it useful, but most of the credit goes to Jamie Odell. I just fixed up the imcompatibilities with the 49G and made what I considered to be some rather modest improvements. I felt that it left a bit to be desired, but considering that it was posted in July of 1990, well, all HP 48 programs were written by newbies at the time. But I've made more improvements, and although my new version is still rather rudimentary, I'm happy with it. > you should send it to HPCALC. Hmm, but I'd have to write documentation for it then. But the source code is heavily commented so it shouldn't be all that hard. As if hpcalc.org really needs yet another terminal program.... > i installed it from the PC without effort :) Good, I expected that it should be just a matter of cutting and pasting to its own file, and then downloading to the calculator. By the way, I looked at some of my other programs, and a much simpler method of checking that there's a valid argument for that KINVISLF SYSEVAL is to just use + just before it; if there's no argument, then the + will error out, and whatever object was available for an argument will be changed to a character string if it's not already one. -- James > what would i have to change (48SX) to make this work on an HP49G? > (for external keyboard) [program snipped] By the look of it, I don't see any reason why this program shouldn't work directly on the HP49 does LIN work the same in the HP48sx and HP49G ? > what would i have to change (48SX) to make this work on an HP49G? > (for external keyboard) > [program snipped] > By the look of it, I don't see any reason why this program shouldn't work > directly on the HP49 Running rom 1.19-6 if I input the summation notation k=0 to infinity 1/(k!) I get ? yet, according to wolfram's math website, it should output e http://mathworld.wolfram.com/e.html > Running rom 1.19-6 > if I input the summation notation k=0 to infinity 1/(k!) I get ? > yet, according to wolfram's math website, it should output e > http://mathworld.wolfram.com/e.html > Sum Calculates the value of a finite series. On the other hand, the summation of 'e^x' from x=0 to minus infinity yields '-1/(e^1-1)'. Summation works fine with infinity as limits, but only for certain summands. > Great to hear from you! How long til you're back in civilisation? TW Oh-no! I want to have yet another Assigned key, but the key that I use is full, that is, even using Wolfgang's KeyMan I managed to overload one key and several others are near to be filled, too. Therefore I suggest using a new technique in the forthcoming 1,19.7: double-shift ! What does it mean? First of all there is a change in the way that the shift keys and indicators work: You can have them both on at the same time! Canceling happens just by pressing the appropriate shift key. Holding down the second shift key would bring up the old shift&hold feature - resulting a .01 added to the keyplane. The keyplanes would be 7 for normal left&right shift and 8 for the alpha mode left&right shift. The order of left&right or right&left wouldn't matter. Comments? Veli-Pekka and finally... Veli-Pekka Nousiainen schrieb im Newsbeitrag > Oh-no! I want to have yet another Assigned key, > but the key that I use is full, that is, even using Wolfgang's > KeyMan I managed to overload one key and several others > are near to be filled, too. Do you want to have all functions on *one* key? Maybe you should define all keys around your favourite key as shift keys... > Comments? > Veli-Pekka Raymond (still not using *any* key assignments on the HP-48) After assigning my favorite TIME functions on [ 9 ] and most CONVERsions on [ 6 ] I found out that I can't have both MATRICES and STATistics on key [ 5 ] so I used [EQW] eg . MTRW for the matrix stuff. [ 1 ] has some CoMPLeX operations on it, while [ 3 ] is filled with binary operators. [SIN] [COS] [TAN] has the hyberbolics assigned, there I have free space, but relevant to assign to. [SPC] has Angle Measure and Coord. System togglers on it. I have managed to assign some easy-to-remember programs to [APPS], [VAR], [TOOLS], and [CAT] but I'm slowly running out of memory to remember these so I thought that I would use shift&hold just to show what assignments I have on that key and therefore I would be very pleased for the extra levels of 7 and 8 as previously explained, if the new key assignment system could handle it via a simple modification (including the new annuciator handling) > and finally... > Veli-Pekka Nousiainen schrieb im Newsbeitrag > Oh-no! I want to have yet another Assigned key, > but the key that I use is full, that is, even using Wolfgang's > KeyMan I managed to overload one key and several others > are near to be filled, too. > Do you want to have all functions on *one* key? > Maybe you should define all keys around your favourite key as shift keys... > Comments? > Veli-Pekka > Raymond (still not using *any* key assignments on the HP-48) > but I'm slowly running out of memory to remember these > so I thought that I would use shift&hold just to show I don't have anyway near that much key assignments butalready have problem remembering them so the way I go about it is by assigning drop down lists of commands which bring menu or other drop down lists to long held keys. This tends to produce big assignements but I put them in a library which I can store in port memeory and I believe it is good. You don't remember all your key assignements and you want some more. How will you do. Maybe you could glue two HPs back to back that would double your key assignements Arnaud The HP-41 CX had a key CAT. Maybe someone wants to write something similar. Or does Keyman from Wolfgang already have this feature? If yes, why this thread? However, I'm still wondering that one needs so many key assignments that he/she doesn't remember them. On the HP-48, I have a special CST menu with one and a half pages, and all utilities I need only a few key strokes away. On the HP-41, I had about ten key assignments. Ok, the 41 has the feature of NULLifying a key if held longer (like SpeedMiner;-) But I only made key ASNs for functions I needed very often. And believe me, I used the HP-41 very excessively. Raymond > but I'm slowly running out of memory to remember these > so I thought that I would use shift&hold just to show > I don't have anyway near that much key assignments butalready have > problem remembering them so the way I go about it is by assigning drop > down lists of commands which bring menu or other drop down lists to > long held keys. > This tends to produce big assignements but I put them in a library > which I can store in port memeory and I believe it is good. > You don't remember all your key assignements and you want some more. > How will you do. > Maybe you could glue two HPs back to back that would double your key > assignements > Arnaud > The HP-41 CX had a key CAT. So does the HP49.. And many people complain that it's a waste :) Veli-Pekka Nousiainen schrieb im Newsbeitrag > Oh-no! I want to have yet another Assigned key, > but the key that I use is full, that is, even using Wolfgang's > KeyMan I managed to overload one key and several others > are near to be filled, too. Right-Shift-Hold-Left-Shift-Hold-Alpha-Hold-Key??? ;-) No, not realy? ..Heiko A good place to buy HP Calculators (especially the HP 48GX) and accessories for them is Calcpro website www.calcpro.com. They are in Corvallis, OR, USA. I have bought several calculators (including an HP 48GX) from them and have had good dealings with its manager, Paul Nelson. Paul sells to overseas countries such as in Europe, Australia, etc. Good luck! wingman schrieb im Newsbeitrag > I want to buy a hp48gx. Does anyone know a shop in Germany where I can > get one for less than 150 Euro? Do you need the expandability of the GX? If not you will get an 48G+ for 69 Euro at www.abyte.de Holger > I had a HP49 and liked it so much that I bought a HP48. > I've never used the 49 since. > Roland I had a BMW 48G (A 48G upgraded in Germany to 256K, then loaded with metakernel and other stuff), but it was stolen between Milan and Amsterdam. So I bought a 49. It is the greatest calculator yet made. I would not go back to the 48. While the 48 keyboard is better, the 49 allows faster data entry for me (once you make a change to keytime) Since I bought it recently, I have the advantage of keyboard and screen fixes. I found the things I was expecting to hate (keyboard and screen) much less annoying than I thought. Everything else is tremendous, particular after I learned about the arrow key SWAP shortcut. People at my office say it looks much better, if that matters. If this is the end for HP calculators, they went out on a high. X > tremendous, particular after I learned about the arrow key SWAP > shortcut. People at my office say it looks much better, if that X but...it has always had that SWAP shortcut... I'm just trying it with my HP 48SX: it works! price. Hung A scanned-in copy is on a CD that you can purchase at http://www.hpmuseum.org/. For the actual book, you could check the classified ads at the same site, and there's always eBay. -- James Hung > A scanned-in copy is on a CD that you can purchase at > http://www.hpmuseum.org/. For the actual book, you could check the > classified ads at the same site, and there's always eBay. > -- > James > Does anyone know where I can get program developement for 48 series > calculators. There use to be a HP package however I have been unable to find > it. > Warren Knorr > Wknorr@aol.com Just wait for the new HP49 SDK that will be able to compile and debug HP48 code. Now writing GUI (and Input Form boxes) will be dead easy (just like on the HP49). Great tool, much more stable than the previous version.. It rocks. Should be available soon First of all I would like to thank you people here help me to understand how to transfer program into my calculator. But, I got new question arise. Well I hope everyone forget my stupid questions. 1. I copy those file into my calculator, how can I put the program into a direcry into my calculator. 2. I donwload one of this math program for DEQ, it got set, and library file, how can I get it run, cause I use soft key to push the one look call 'Diff file it didn't run. I hope someone here can help me on this. tsli http://www.hpcalc.org/install.php > First of all I would like to thank you people here help me to > understand how to transfer program into my calculator. But, I got new > question arise. Well I hope everyone forget my stupid questions. > 1. I copy those file into my calculator, how can I put the program > into a direcry into my calculator. 'My.File' DUP RCL SWAP brings the contents of 'My.File' into stack level 2 and the name in level 1, ready for STOrage. 'UTILS' CRDIR creates a directory called 'UTILS' UTILS (without the quotas) goes to that directory STO Now you can go UPDIR to PURGE the 'My.File' > 2. I donwload one of this math program for DEQ, it got set, and > library file, how can I get it run, cause I use soft key to push the > one look call 'Diff file it didn't run. If it's a library, it should be store in a port. ReCalL the library to the stack 0 STO should STOre it into the internal port 0. If you have any memory cards installed you may wish to use port 1 or port2... > I hope someone here can help me on this. > tsli Veli-Pekka my PC before downloading. I have tried to find a ROM on HPcalc.org but I cannot find anything but a 39G. Could somepone please point me in the right direction? GN > my PC before downloading. I have tried to find a ROM on HPcalc.org but I > cannot find anything but a 39G. Could somepone please point me in the right > direction? In http://www.hpcalc.org/hp49/pc/rom/ you will find the latest (1.19-6) in a 1.2MB (almost) zip file that contains the ROM for the calculator and the ROM for the emulator. -- Al. Andreou, ee4299 at ee.teiath.gr. | When everything else fails, http://nemesis.ee.teiath.gr/~ee4299/ | this won't work either. . . http://www.epita.fr/~avenar_j/hp/49.html Have you learned to use Google to search newsgroups? on > my PC before downloading. I have tried to find a ROM on HPcalc.org but I > cannot find anything but a 39G. Could somepone please point me in the right > direction? > GN Love Bytes (or sex and the single computer) They say that computers do not think like human beings. But do they _feel_ like humans? A certain computer, to which (to whom?) we have guaranteed absolute anonymity, has supplied us with this piece of computer-style erotic-gossip that is going the rounds of the sophisticated number crunchers in the web. If you have an under-age computer around, on no account let it see this - it might be totally diskusted (!) and even corrupt its little CPU forever! Micro was a real-time operator and protocol made it easy for him to inter- face with numerous input/output de- vices, even if it meant time-sharing. One evening he arrived home just as the sun was crashing, and had parked his Merced in the main drive (he had missed the serial bus that morning), when he noticed an elegant piece of liveware admiring the daisy wheels in his garden. He thought to himself, She looks user-friendly. I'll see if she'd like an update tonight. Mini was her name, and she was delightfully engineered with eyes like Ada and a Prime mainframe archi- tecture that set Micro's peripherals networking all over the place. (to be continued...) after a long unused time I wanted to reactivate my HP41C. But it does not work. When I set in the batteries, it makes strange sounds. These change when I press some keys (i.e. R/C). Pressing ON and some other keys results in a beep. The display shows nothing. Do anyone of you have an idea what could be wrong with the calc? Contacts and everything else look like new. Holger > after a long unused time I wanted to reactivate my HP41C. But it does not > work. > When I set in the batteries, it makes strange sounds. These change when I > press some keys (i.e. R/C). Pressing ON and some other keys results in a > beep. The display shows nothing. > Do anyone of you have an idea what could be wrong with the calc? Contacts > and everything else look like new. Also try the forum at http://www.hpmuseum.org/. Try a search of the forum archives before you ask. -- James James M. Prange schrieb im Newsbeitrag > Also try the forum at http://www.hpmuseum.org/. Try a search of the > forum archives before you ask. have the idea to ask in the forum. Holger It could be static that is causing the malfunction (but I strongly doubt this). Try removing the batteries and place a short circuit across the outer two contacts. Also remove all application pacs, card readers etc. I don't think that shorting these terminals will cause any damage, but if you are worried, there is a lot of info, including circuit diagrams at www.hp41.org Good luck Andre Claassens > after a long unused time I wanted to reactivate my HP41C. But it does not > work. > When I set in the batteries, it makes strange sounds. These change when I > press some keys (i.e. R/C). Pressing ON and some other keys results in a > beep. The display shows nothing. > Do anyone of you have an idea what could be wrong with the calc? Contacts > and everything else look like new. > Holger Lindi Claassens schrieb im Newsbeitrag > It could be static that is causing the malfunction (but I strongly doubt > this). Try removing the batteries and place a short circuit across the outer > two contacts. Also remove all application pacs, card readers etc. I don't > think that shorting these terminals will cause any damage, but if you are > worried, there is a lot of info, including circuit diagrams at www.hp41.org Shortcutting didn't help. But I found the service manual at that side. Maybe It will help me! Holger Working a bit with my calc I find that the SOLVE command behavior, as pointed out several times before, it a bit confusing. My current question it's on the input/output schema I'm trying to usi it from a program but I don't know what to spect as results. It's there any doc or threat that clearly explain this command's behavior? When and how it answer periodict anwers and so? My problem is that it answer periodic ones with n1, n2, ... index but I don't know how and when more over Is there any way to get the first solution? Even numericaly I was unable to get it! I needed to user MSLV! My example is EXP(18*X)+2 'X' -> SOLVE -> X=((2*i*n1+i)*PI+LN(2))/18 in exact comples mode. But if EXP(18*n1)+2 'n1' -> SOLVE -> n1=((-(i*PI)-LN(2))/(2*i*PI-18) Why that different behavior? This last one doesn't looks like a case of the first series for a natural n1 which is what I spect n1 be so Whats n1? I'm looking in all my PDFs and searchin the group but I'm still doesnt found an explanation so if it's there, please excuse me and just point me there! TIA Luis > Working a bit with my calc I find that the SOLVE command behavior, as > pointed out several times before, it a bit confusing. My current > question it's on the input/output schema I'm trying to usi it from a > program but I don't know what to spect as results. It's there any doc > or threat that clearly explain this command's behavior? When and how > it answer periodict anwers and so? > My problem is that it answer periodic ones with n1, n2, ... index but > I don't know how and when more over Is there any way to get the first > solution? Even numericaly I was unable to get it! I needed to user > MSLV! > My example is EXP(18*X)+2 'X' -> SOLVE -> X=((2*i*n1+i)*PI+LN(2))/18 > in exact comples mode. > But if EXP(18*n1)+2 'n1' -> SOLVE -> n1=((-(i*PI)-LN(2))/(2*i*PI-18) > Why that different behavior? This last one doesn't looks like a case > of the first series for a natural n1 which is what I spect n1 be so > Whats n1? > I'm looking in all my PDFs and searchin the group but I'm still doesnt > found an explanation so if it's there, please excuse me and just point > me there! > TIA > Luis n1 stands for arbitrary integer in expressions that are returned when an equation has a set of solutions that can be represented as a general solution containing such arbitrary integers. In your first example, any of the expressions ...... ((2*i*-2+i)*PI+LN(2))/18 ((2*i*-1+i)*PI+LN(2))/18 ((2*i*0+i)*PI+LN(2))/18 ((2*i*1+i)*PI+LN(2))/18 ((2*i*2+i)*PI+LN(2))/18 ...... I think the problem in the second example is that you solved for n1, exactly the same symbol that the HP49G uses itself to denote arbitrary integers in results. The general solution for EXP(18*X)+2 solved for X is: X=((2*i*n1+i)*PI+LN(2))/18 Now, you used n1 instead of X, so this expression becomes: n1=((2*i*n1+i)*PI+LN(2))/18 The HP49G solved for n1, so when you solve the latter expression for n1 you get the result n1=((-(i*PI)-LN(2))/(2*i*PI-18) Hope it helped, Nick. > Now, you used n1 instead of X, so this expression becomes: > n1=((2*i*n1+i)*PI+LN(2))/18 > The HP49G solved for n1, so when you solve the latter expression for > n1 you get the result n1=((-(i*PI)-LN(2))/(2*i*PI-18) But It gives me directly the last expresion! I didn't solve two times just one. And is ((-(i*PI)-LN(2))/(2*i*PI-18) a particular case of ((2*i*n1+i)*PI+LN(2))/18 been n1 a natual or integer? Do you know any other special use of global I should take care of? I only want to know them I like it been able to solve this periodic solutions but I need to manage this cases if I want to embbed the SOLVE command. Luis > Now, you used n1 instead of X, so this expression becomes: > n1=((2*i*n1+i)*PI+LN(2))/18 > The HP49G solved for n1, so when you solve the latter expression for > n1 you get the result n1=((-(i*PI)-LN(2))/(2*i*PI-18) > But It gives me directly the last expresion! I didn't solve two times > just one. I included the second step only for understanding. You give the HP49G an expression f(n1) and you tell it to solve for n1. The HP49G then finds an expression of the form n1=g(n1) as solution. The n1 on the left is your one, the n1 on the right is the on that the HP49G *automatically* uses in order to represent arbitrary integers in solutions. Now, it seems to notice that the expression found as solution doesn't contain your variable n1 isolated, and thus it tries to isolate it on the left hand side, which it successfully (but not correctly) does. It doesn't distinguish between your n1 and its n1. So, avoid to solve for such variables like n1, n2 and so on. Perhaps you might want to replace n1 with m1, n2 with m2 and so on before you solve. > And is ((-(i*PI)-LN(2))/(2*i*PI-18) a particular case of > ((2*i*n1+i)*PI+LN(2))/18 been n1 a natual or integer? Integer (I think). > Do you know any other special use of global I should take care of? I > only want to know them I like it been able to solve this periodic > solutions but I need to manage this cases if I want to embbed the > SOLVE command. I only know of n1, n2 and so on. Nick. > Well, not in a SysRPL program, but Veli-Pekka and I were > referring to a UserRPL program. > Me too! I'm not at all talking on SysRPL here. You will > see it from the genuine UsrRPL program below. Huh? In that program the i is clearly the loop index local > variable, not the function i for the imaginary number. James, isn't it obvious where the misunderstanding comes from? > Veli replaced my i by j. And I only stressed that one may use i > as a counter-variable in FOR...NEXT structure, even if the > arguments of a program contain the constant i somewhere else. My apologies; I misunderstood. I thought that you were saying that you could use i as both the counter-variable name and as the constant i within the same loop. I believe that Veli-Pekka and I are both well aware that you *can* use i as the counter-variable name as long as you don't intend to also use it as the constant i within the same loop, and also still use i as the constant elsewhere within the program. What might be questionable is whether it would be better to avoid making a habit of using i (or, for that matter, any other name that already has a special meaning) as the counter-variable name. The possible problems with using i for the name are: first, that it might be misapprehended as the constant i, and second, that it makes that the constant i unavailable within the loop. > All hithertoo presented UsrRPL-programs for the problem of > preference-orderings do not solve it completely, As far as I can tell, my 329 byte program solves it completely. OK, I didn't run it, sorry. A 329 bytes program for something > which can be done with 80 bytes seems to be a bit too much :-) Yes, 329 bytes is indeed a bit much, but you did mention that the level 2 argument list may be huge, and its objects huge as well, several thoused bytes each. I took your comments to mean that my program was ridiculously slow for large lists and that the program would have to be able to reorder lists with perhaps hundreds of elements in a reasonable amount of time and perhaps also to be able to handle them without needing too much memory to run in. I expect that you can do it much faster in SysRPL, but I suggest that you run your UserRPL program with a 500 element level 2 argument list and see how long it takes. For that matter, even my original 108 byte program (for which I specifically disavowed any claim to being fast) doesn't look so bad when compared to your UserRPL program for speed only. > that the programming style of all this is not yet the best. Well, programming style is a matter of opinion. What are we > looking for? Fastest? Smallest? Executes in smallest amount of > memory? Don't exaggerate! An experienced programmer like you has some > feeling on what is good UsrRPL style programming and what is not. > Please compare Nick's and Veli's (original) aproach to my completely > different approach. Clearly, I make mistakes (as does everybody) and > such a mistake was the omitting of I->R. But I would not not classify > it as a serious bug, the more the 48 has no zints. In contrast to my, > the mistake in the approach of Nick/Veli is a basic one. My assumption is that Nick's main problem was that he didn't completely understand what the program was supposed to accomplish. And yes, his local names were longer than they needed to be; I assume that he was aware of this but wanted to make it obvious what the variables were for. I guess that most of us normally leave flag -55 clear, so Veli-Pekka's use of LASTARG without the code to clear flag -55 and restore it to its original state is understandable; I expect that he was assuming that flag -55 is clear unless he's changed it within the program. But what's he doing now? Veli-Pekka, if you're reading this, please do check that your programs return the correct results before you post them. And yes, we do all make mistakes; the program that I first posted errors out when the level 1 argument is an empty list. I don't think that any of us claim to be perfect. > 1. Avoid list commands if something can easier and > more efficiently be done in a loop. Well, this one's debatable. No, it is not! Some list commands are too slow, in particular > DOLIST and DOSUBS. I had been taking your word for this, but I find it hard to imagine that the Corvallis team would've written a command that's significantly slower than a loop that accomplishes the same thing, so I decided to experiment a little with DOLIST. But note that my experimenting was of the quick and dirty variety, so the Your mileage may vary. disclaimer definitely applies here. By exploding a list onto the stack and using stack commands in a loop to manipulate the elements, I seem to be able to do it a lot faster than with DOLIST, no matter how many elements are in the list, so it seems to me that DOLIST is indeed much slower than it should be. But how many UserRPL programmers would routinely do it that way? I suppose that it would be more typical to use GET and + within a loop to build a new list; in this case I found that DOLIST still seems to be slower than using a loop for small lists, but when the list has hundreds of elements, DOLIST seems to be much faster than the loop. For small lists (20 or so elements), it isn't as if you're going to have time to get another coffee anyway, and for large lists (over 100 elements), DOLIST is significantly faster. So, while DOLIST apparently isn't as fast as it ought to be, it isn't necessarily all that bad of a choice either. > These may be useful for some small private > programs, but no professional programmer - and there a few, > at least for the 48 - would ever use them. I hope that no professional programmer would use them; if I were paying someone to write programs for HP calculators, I wouldn't expect him to be writing UserRPL programs. But for most of us, trying to write highly optimized programs is just a hobby. Ordinarily, writing a UserRPL program is merely a method of accomplishing part of our main tasks. Most of our programs won't be used all that many times, and only by the writer, so it doesn't make sense for us to put a lot of time and effort into optimizing a program that already works. Better to write a program that works the first time, or failing that, is at least easy to debug, than to spend too much time trying to write the smallest, fastest program that possibly could be written. For a challenge we should try to optimize them, but I wouldn't be program. > 2. Make clauses between IF...THEN and THEN...END as > small as possible. Best only a single command. This > also holds for other structures including IFERR... Well, I used IF m n == NOT THEN; I could've used > m n IF == NOT THEN just as well, but I really wouldn't like > m n == IF NOT THEN as well. Why not? This is as clear as your clause and saves you 5 bytes! > IMHO, it makes the clause by no means more difficult to read. > In the contrary, it emphazises what the THEN really expects. Sorry, it doesn't save any bytes. Consider the following three programs. They take two arguments from the stack and return Equal or Unequal as appropriate. The only difference is the placement of IF. << -> m n << IF m n == THEN Equal ELSE Unequal END > # F30Ah, 70 bytes << -> m n << m n IF == THEN Equal ELSE Unequal END > # 18Ch, 70 bytes << -> m n << m n == IF THEN Equal ELSE Unequal END > # 63EDh, 70 bytes As you can see, all of the above take exactly the same number of bytes. Of course, we could improve this a bit by using IFTE instead of IF...THEN...ELSE...END: << -> m n << m n == Equal Unequal IFTE > # BE56h, 62.5 bytes Actually, I wish that they'd left out the structure word IF entirely. I don't see that RPL itself has any real need for it. Clearly, what matters is what the argument for THEN evaluates to. Does it sound better to say If m and n are not equal, then.... or to say Test whether m and n are equal; if not, then....? I really can't see that it matters which way we do it in a program, so I'll continue to place my IFs wherever they seem most natural to me. > Unlike IF, the location of IFERR is significant, and having only > a single object between IFERR and THEN makes it very clear > exactly which object we're checking, and any objects to be > skipped if an error occurs are better placed after an ELSE for > clarity and bug prevention, even though it might take a few more > bytes. Unfortunately, it is not always possible to include just a single > object between IFERR and THEN. Clearly, for IFFERR 0 WAIT THEN ... > to be trapped of more or less the same kind, it is more economical > to trap them in a single composed object. This is, what the basic > POLs (Parametrized Outer Loops) generally do. I'll take your word for it; I wouldn't recognize a POL if I saw one, and I don't know what their purpose is, but I can see that sometimes it might make sense to say if there's any error in any of this, then tell the user to try again. > I chose to copy and paste my program to the newsgroup exactly as > uploaded from the calculator to avoid any typing errors and make > it easy for anyone to download. As for figuring out how it > works, I left that as an exercise for the reader. Yes, this is what I generally estimate in your postings - and your > perfect style in comments and critics. > I would be happy if I'd > know English better to state things more clearly :-) You don't do so badly; I often have to deal with people who speak English as their *only* language, but don't express themselves as clearly as you do. -- James X > OK, I didn't run it, sorry. A 329 bytes program for something > which can be done with 80 bytes seems to be a bit too much :-) Yes, 329 bytes is indeed a bit much, but you did mention that > the level 2 argument list may be huge, and its objects huge as X > but I suggest that you run your UserRPL program with a 500 > element level 2 argument list and see how long it takes. X Werner Hyusecom with an explaining example > My assumption is that Nick's main problem was that he didn't > completely understand what the program was supposed to > accomplish. And yes, his local names were longer than they > needed to be; I assume that he was aware of this but wanted to > make it obvious what the variables were for. X > it within the program. But what's he doing now? Veli-Pekka, if > you're reading this, please do check that your programs return > the correct results before you post them. I thought that the program was for re-ordering the VAR or the Lib menu Then the user picks different numbers, but they always for a list consisting of a sequence 1..k (not in that order) so I didn't care about inputs like { 4 2 1 } where the 3 was missing > And yes, we do all make mistakes; the program that I first > posted errors out when the level 1 argument is an empty list. I > don't think that any of us claim to be perfect. X > when the list has hundreds of elements, DOLIST seems to be much > faster than the loop. For small lists (20 or so elements), it > isn't as if you're going to have time to get another coffee > anyway, and for large lists (over 100 elements), DOLIST is > significantly faster. X HERE IT IS ! DOLIST is faster than a loop with big lists !!! This I was suspecting all the time!! > I would be happy if I'd > know English better to state things more clearly :-) You don't do so badly; I often have to deal with people who > speak English as their *only* language, but don't express > themselves as clearly as you do. X I wish I could write/read & understand English better Veli-Pekka PS: No wander I'm still not a member of the Jedi-Council I should have seen my errors revealed in the future ;-) > ... > To say the truth, your programs do not completely meet all > my conditions. I said that the level 2 list can be a list > of *any* HP49-objects, I did not restrict to lists whose > objects can always be edited and recompiled with ENTER. > ... > Unless I'm mistaken, Nick and VP's programs also generally fail > in the case of repeated objects in the level-2 list (unless all > the repeated objects are referenced in the level-1 list). > For example: > { A B A } > { 2 1 } > gives { B A } instead of the correct { B A A }. Yep! Building a list with the rest of the elements doesn't work in such cases. It would be better to examine which positions weren't used and get the elements corresponding to these positions after the first portion of the list has been built. greetings, Nick. > A small modification to Nick's prog: > << SWAP -> o ... > The UsrRPL programs proposed so far do their job, though > slowly if the big Level 2 list has a large size. By the > way, if you process your 137.5 bytes program with ->XU > (Extended UsrRPL) from OT49, the resulting program has > no delimiters but has only 120 bytes and runs faster. How much faster does it get? > It > is what I call an Extended UsrRPL program. It does the > same and is completely readable with the VIEW command. In > particular, you see the single quoter in it (the one which > by the RPL-author was probably designated for some later > expansion of UsrRPL). The program can also be edited, but > not be recompiled with ENTER since the UsrRPL-compiler is, > unfortunately, too week (with OT49 one can do it :-) solving problems that I encounter each and every day. And learn in addition yet another program and yet another language. And all this keeping my bosses happy with my work so that I can earn for living. Second choise, I use what is available, write some programs and use the HP49G for my work. > To say the truth, your programs do not completely meet all > my conditions. I said that the level 2 list can be a list > of *any* HP49-objects, I did not restrict to lists whose > objects can always be edited and recompiled with ENTER. Any HP49G objects are for me most of the time the objects that the system provides directly to the user. > command line. That yields the list of all attached libs, > together with their numbers on the stack. Now, these numbers > are so-called bints (numbers being processed particularly > fast on the 48/49 because there are only 2^20 = 1,048,575 > such beasts, just enough to span the memory space of 48). I do the same by issuing the command LIBS, and save myself from having to dive in the inner world of the HP49G. Or should I also examine Mathematica down to the very elementary processes that enable me to formulate questions and get solutions in a more convenient way? Do we have to examine each program we use that way? Then good luck, we are never going to use anything if we do so, because then we buy expensives things not as helpers, but only to study them themselves. > Your program yields something wrong in this case. Hmm, not if I don't care about FPTR and the rest of the inner world. Nick. > One can still use OT49 and ->XU > AND > Nick could do some testing with ALL the versions > including the old ones (not invented by Rautenberg) > maybe even including one with + changed to AUGMENT > to see which is the fastest. Mama mia! You don't expect me to type SysRPL and also time it, do you? You do? Oh man, you just destroyed my vacation ;-) Nick. No, I don't....forget about it. We will soon meet Yoda - I mean - Jonathan Busby, who will show how to make it fast in UserRPL, too. One can still use OT49 and ->XU > AND > Nick could do some testing with ALL the versions > including the old ones (not invented by Rautenberg) > maybe even including one with + changed to AUGMENT > to see which is the fastest. Mama mia! You don't expect me to type SysRPL and also time it, do you? > You do? Oh man, you just destroyed my vacation ;-) > Nick. LOL! I guess that's why Trabakoulas thinks of selling the sheep starting a horse farm! ;-) Nick. P.S.: Be careful with wishes, they may come true ;-) > Veli-Pekka Nousiainen > PS: [HUMOR] > Look, mine is smaller is something I never dreamed of saying to any > man > until I started programming the HP calculators > also some men buy often new mobile phones and says the same quoted > thing. > A story (pick up a good and a bad politician from your own country) > In the sauna one member of the parliament seem the have a bigger...member > The others asked what happened and he answered: > I was walking down the beach when I saw a bird trapped in a bush > I helped it free and it turned into an elf and said to me: > Because of your kindness I grant you one wish. > Well, I saw a horse on the nearby field and said I'd like to same kind of > genital > as that horse has and bingo! I got this! > Immediately after the sauna, Mr. Vaerynen went to the beach looking for > trapped > birds, but not a thing, not the second day wither, but on the third day, or > rather at > the evening he finally got a glimpse on a squirrel that was trapped and > released it. > Poof! It turned into an elf. The elf promised one wish and in a hurry he > said: > I'd like to same kind of genital as that horse at the field has and bingo! > That guy never showed up in the sauna ever again and one day one of his > mates > asked about that and he told his story and the friend asked why not then > show it > around at the sauna. He replied that the horse was SHE !! > (Another possible ending would be a horse with the genitals removed > but I don't know that word in English) > Anyway: I'm going to release the Love Bytes story again in this newsgroup. > Stay tuned! Word for horse that has been castrated is Gelding. Keep up the good work. ed > that the programming style of all this is not yet the best. Well, programming style is a matter of opinion. What are we > looking for? Fastest? Smallest? Executes in smallest amount of > memory? Don't exaggerate! An experienced programmer like you has some > feeling on what is good UsrRPL style programming and what is not. > Please compare Nick's and Veli's (original) aproach to my completely > different approach. Clearly, I make mistakes (as does everybody) and > such a mistake was the omitting of I->R. But I would not not classify > it as a serious bug, the more the 48 has no zints. In contrast to my, > the mistake in the approach of Nick/Veli is a basic one. > Yes, this is what I generally estimate in your postings - and your > perfect style in comments and critics. I would be happy if I'd > know English better to state things more clearly :-) > I think that the basic one is more of about English/problem understanding > OR can you explain more clearly what was the basic mistake of Nick/Veli Without an example like this: > { A B C D E } > { 3 2 1 } > << program { C B A D E } > It's very hard to understand what the program does. > 2) > Isn't it not the _speed_ on big lists what we are looking for now? Veli-Pekka Nousiainen > PS: [HUMOR] > Look, mine is smaller is something I never dreamed of saying to any > man > until I started programming the HP calculators > also some men buy often new mobile phones and says the same quoted > thing. A story (pick up a good and a bad politician from your own country) > In the sauna one member of the parliament seem the have a bigger...member > The others asked what happened and he answered: > I was walking down the beach when I saw a bird trapped in a bush > I helped it free and it turned into an elf and said to me: > Because of your kindness I grant you one wish. > Well, I saw a horse on the nearby field and said I'd like to same kind of > genital > as that horse has and bingo! I got this! > Immediately after the sauna, Mr. Vaerynen went to the beach looking for > trapped > birds, but not a thing, not the second day wither, but on the third day, or > rather at > the evening he finally got a glimpse on a squirrel that was trapped and > released it. > Poof! It turned into an elf. The elf promised one wish and in a hurry he > said: > I'd like to same kind of genital as that horse at the field has and bingo! > That guy never showed up in the sauna ever again and one day one of his > mates > asked about that and he told his story and the friend asked why not then > show it > around at the sauna. He replied that the horse was SHE !! > (Another possible ending would be a horse with the genitals removed > but I don't know that word in English) Anyway: I'm going to release the Love Bytes story again in this newsgroup. > Stay tuned! > The following seems to be the ultimate and fastest > 49-UsrRPL-program for our problem: > << > I->R 1. PICK3 SIZE > FOR i i DUP2 POS NOT { SWAP OVER + SWAP } IFT > PICK3 PICK3 ROT GET GET UNROT > NEXT DROP SIZE ->LIST > 81.5 bytes, CRC 8B40h. << I->R 1. PICK3 SIZE FOR i i DUP2 IF POS THEN DROP ELSE + END DUP2 i GET GET UNROT NEXT DROP SIZE ->LIST 76.0 bytes #2466h Werner > << > I->R 1. PICK3 SIZE > FOR i i DUP2 > IF POS THEN DROP ELSE + END > DUP2 i GET GET UNROT > NEXT DROP SIZE ->LIST > It is a paradigm on what I mean by good style UsrRPL programming. Below another stright-forward SysRPL program (less fast than Jonathan's). Level 1 argument is a list of valid bints. Very likely that Werner finds a smaller one, and if not smaller, at least a much faster one :-) :: OVER LENCOMP #1+_ONE_DO INDEX@ OVER matchob? NOT_IT >TCOMP 2DUP INDEX@ NTHCOMPDROP NTHCOMPDROP UNROT LOOP DROP LENCOMP P{}N ; @ 47.5 bytes, CRC 1557h The following seems to be the ultimate and fastest > 49-UsrRPL-program for our problem: << > I->R 1. PICK3 SIZE > FOR i i DUP2 POS NOT { SWAP OVER + SWAP } IFT > PICK3 PICK3 ROT GET GET UNROT > NEXT DROP SIZE ->LIST > 81.5 bytes, CRC 8B40h. << > I->R 1. PICK3 SIZE > FOR i > i DUP2 > IF POS THEN DROP ELSE + END > DUP2 i GET GET UNROT > NEXT > DROP SIZE ->LIST > 76.0 bytes #2466h Werner Which can be immediately trimmed down with << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: DROP :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST BYTES => # B203h 75.5 The WH solution has the same length than my << I->R 1. PICK3 SIZE FOR j DUP2 j POS DUP IF NOT THEN DROP j END GET UNROT NEXT DROP SIZE ->LIST BYTES => # 125Ah 76. BUT This can trimmed down to << I->R 1. PICK3 SIZE FOR j DUP2 j POS DUP NOT { DROP j } IFT GET UNROT NEXT DROP SIZE ->LIST BYTES => # AF91h 71. AND Remember: I have a solution, which is in length << not yet revealed > BYTES => # 33f1h 69.5 Now, tease you little gray cells and make even. I DARE YOU TO BEAT THIS ONE !! PS: Love Bytes in another thread, very soon... PPS: I thought that what Wofgang wanted was speed regrading huge input lists?! Maybe Nick could do some testing on speed on 10, 100, 1000, 10000 items lists. the order list could be 10%, 50%, 100% on the items list. So only a few different program versions with 12 inputs > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. Werner > ... > This can trimmed down to > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. > ... > I DARE YOU TO BEAT THIS ONE !! Short wrong answers don't count!! Sorry for being a pest, but I think I keyed this in right (got right bytes, #AF91h), but I'm getting wrong output on tests. Tom AUUUURRRGGGHH! Can you please give me the examples that works on the correct programs and fail with this one. Please... > ... > This can trimmed down to > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. > ... > I DARE YOU TO BEAT THIS ONE !! Short wrong answers don't count!! Sorry for being a pest, but I think I keyed this in right (got > right bytes, #AF91h), but I'm getting wrong output on tests. > Tom { 1 2 3 4 5 } { 4 } should give { 4 1 2 3 5 } but your last version gives { 1 2 3 1 5 } unless I made an error. Maybe Nick can verify in his spare time :-) Tom > AUUUURRRGGGHH! > Can you please give me the examples > that works on the correct programs > and fail with this one. > Please... > ... > This can trimmed down to > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. So the last one working by me is: << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: DROP :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST BYTES => # B203h 75.5 Veli-Pekka > { 1 2 3 4 5 } > { 4 } should give { 4 1 2 3 5 } but your last version gives { 1 2 3 1 5 } > unless I made an error. Maybe Nick can verify in his spare time :-) > Tom > AUUUURRRGGGHH! > Can you please give me the examples > that works on the correct programs The HP49 entry to do a warm start is 2F237 (1.19-6), equivalent to 21B4E in the HP48. It just does a GOVLNG to the ML entry Warmstart. Note that PTR 0 is _not_ the same as PTR 2F237, since the former will save a warmstart event. Just run WSLOG after PTR 0 and you will see that the 49 will report it as an 'A' event: system RPL jump to #0 (AUG, command reference, part E). [On the 48, the code number would be 3, run through address zero, as stated in the AUR's entry for WSLOG. Remember that #0 SYSEVAL does not work on the 48.] After playing with all this, my 49 crashed and Jazz got removed works flawlessly on the 49, so I guess that there was a conflict with SSTK (?). When I've got enough time, I'll port the already released HP48 library that renames built-in commands: http://www.hpcc.org/V21N3/home.html Incidentally, no one to whom I sent the library to reproduce that behaviour reported that it actually works. They all must use Jazz! Best wishes, HPCC member #1046 - -- > It's worth it ! You forgot to mention the bugs and quirks that'll never be fixed, and that there is no more official HP support, hence no more official ROMs (even though v1.18 is tremendeously buggy ). Is it me, or is the flow of new programs for the HP49G not near what it once was? It seems many have lost their interest in the '49 - even the TI camp. That's of course because there's no more inside knowledge leaking out - BP while, and posts from CdB are even rarer. > But if you buy the HP 49G > and other goodies too numerous to be all mentioned here. > (the ROM is doubled to 1024KB and it's re-flashable) > except it's Flash and thus doesn't need batteries and it's virtually > crash-proof. You also get: an exceptionally ugly case, a horrible keyboard, no IR, no expansion slots, inadequate documentation... I'd rather have no calculator at all than a 49G. -- Wayne Brown | When your tail's in a crack, you improvise fwbrown@bellsouth.net | if you're good enough. Otherwise you give | your pelt to the trapper. e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock > But if you buy the HP 49G > and other goodies too numerous to be all mentioned here. > (the ROM is doubled to 1024KB and it's re-flashable) > except it's Flash and thus doesn't need batteries and it's virtually > crash-proof. You also get: > an exceptionally ugly case, Yes, the HP 48S -series win the beauty contest. It rook me a long time to get adjusted to the Gay -series merry coloring I mean mint and lila as the function keys colors? The metallic blue on my 49G is much better although some users do complain about dark blue on light blue contrast. > a horrible keyboard, The keys don't have the tactile feel of the old keyboard, that's true. > no IR, They could have used a stripe of balck tape in tests to cover the IR instead of HP removing altogether. I'll get buy with my other learning remote and use the serial all the time. > no expansion slots, For some third party modules you're right, but as mentioned above, the HP 49G comes with 2 pre-filled slots the HP 49G is a bargain! > inadequate documentation... True - we are used to have exellent documentation. The HP 48G AUR Manual & Ren.8ee De Graeve's CAS manual are a lot of help. Add to that Urroz Vol.I & Vol.2 of Science and Engineering Mathematics with the HP 49 G does the rest of it. Remember that all the old HP 48 series stuff is here to help us to get grip of this huge 1MB worth of programs. > I'd rather have no calculator at all than a 49G. You're entitled to your choise. I see it differently. I haven't sold my HP 48GX yet. Anyone to trade in a HP 49G ?? Veli-Pekka > -- > Wayne Brown | When your tail's in a crack, you improvise > fwbrown@bellsouth.net | if you're good enough. Otherwise you give > | your pelt to the trapper. > e^(i*pi) = -1 -- Euler | -- John Myers Myers, Silverlock > But if you buy the HP 49G > and other goodies too numerous to be all mentioned here. > (the ROM is doubled to 1024KB and it's re-flashable) > except it's Flash and thus doesn't need batteries and it's virtually > crash-proof. > The version 1.19-6 has more than 300 UserRPL Commands added > There are new variables, too. Like STARTED & EXITED for EDitor, > STARTEQW for EQW, STARTUP for boot, TOFF for time off setting, > Real-time 3D plot with view angle changing in 3D plus Zoom ! > Build-in assembler/SysRPL (needs only extable.lib for entry-point names) > and...Just buy it ! > It's worth it ! I can't offered it. I'm having difficulty with the xgcc port for win95. code is simply #include int main (void) { } ERROR: unable to resolve symbol '_printf', referenced by object-file 'C:WINNTTE linkage failed due to unresolved references default installation. How do I point xgcc to what it's looking for? Executing xgcc stored (according to installation instructions) in /usr/bin results in 'file not found' message, even with explicit path. Pretty confusing with non-zero file size access mode 755. Jacek Kowalczyk > Executing xgcc stored (according to installation instructions) in /usr/bin > results in 'file not found' message, even with explicit path. Pretty > confusing with non-zero file size access mode 755. > Jacek Kowalczyk Execute head `which xgcc` | strings | head -n 2 from a prompt, and I'd imagine you'll not be able to find those items which result on your system, and that that's the cause of the file not found error. The answer would be to fetch the sources to xgcc and compile it locally, rather then trying to run the pre-made executable. Either that or fetch the compatible library stuff and install it - but the first choice might be the easier one. Glen > Execute > head `which xgcc` | strings | head -n 2 > from a prompt, and I'd imagine you'll not be able to find those items > which result on your system, and that that's the cause of the file not > found error. realized that execve() simply provided me with such a non-descriptive error message after it failed to found /lib/ld-linux.so.1 which in turn opens libc.so.5. Unexpectedly, i found GLIBC2.2.2's ld-linux.so.2 binary compatible (by symlinking it, and as far as it complained of libc5), but I won't even think of doing this trick with the very libc. > The answer would be to fetch the sources to xgcc and compile it locally, > rather then trying to run the pre-made executable. Either that or fetch > the compatible library stuff and install it - but the first choice might > be the easier one. Then, for reasons above I'll follow your advice, hoping my gcc-3.01 source distribution will match with hp48xcc needs, and I won't be forced to fetch gcc-2.72 which remembers the times of my old Commodore Amiga 500... > I'm having difficulty with the xgcc port for win95. > code is simply > #include int main (void) > ERROR: unable to resolve symbol '_printf', > referenced by object-file 'C:WINNTTE > linkage failed due to unresolved references > default installation. How do I point xgcc to what it's looking for? Simply the printf() function is not yet implemeted in the HP48 C library. (Why you don't make it?) Simply the printf() function is not yet implemeted in the HP48 C > library. (Why you don't make it?) Because I'm not that smart. I have a directory with a program (XCRUNCH) which works great. I have created the necessary vars like $CONFIG and so on and used CRLIB or the command from libman. The lib is created. Then I install the lib (and attach via a warmstart), but it will give me an error Bad Argument Type when I try to use it. If I use the command from the directory it works as expected. Any ideas? Example for use with xcrunch 3: SIN(X) 2: {4 5 6} 1: 1 and call the command XCRUNCH. This should give a list of the sine values. If you want to try this for yourself you can grab the 1KB small 49 directory file (binary) on my website: www.karpfenteich.net/xcrunch111dir.49 Peter -- Great HP48/49 links: http://www.hpcalc.org http://move.to/hpkb to find *old* postings search: For the record: Jordi pointed me to the problem that I forgot to add the hidden vars x001 and x002 to the list :-/ With that addition everything works as expected :-) Peter -- Great HP48/49 links: http://www.hpcalc.org http://move.to/hpkb to find *old* postings search: PK> I have a directory with a program (XCRUNCH) which works great. I have PK> created the necessary vars like $CONFIG and so on and used CRLIB or PK> the command from libman. PK> The lib is created. Then I install the lib (and attach via a PK> warmstart), but it will give me an error Bad Argument Type when I PK> try to use it. If I use the command from the directory it works as PK> expected. PK> Any ideas? - are you trying to run the library command inside the directory where you created the library, or higher up on the path? - Are you sure that $VISIBLE and $HIDDEN contain all the variables which are need for the execution of the program? One way to get the problem you have is this: You run a program which calls another program in the directory (with ID name in SystemRPL or just with name if in UserRPL. Then you make a library, but you forget to include ID name into $HIDDEN. WHen you then run the library command, it tries to execute ID name, does not find the variable and therefore just puts 'name' on the stack. Which may lead to problems later - if you are lucky not a crash. - Carsten > I have a directory with a program (XCRUNCH) which works great. I have > created the necessary vars like $CONFIG and so on and used CRLIB or > the command from libman. Libman does not contain a lib creator, at least not the latest version. A comforable lib creator for the beginner is D<->L from OT49 with its dialog box, so one cannot forget anything and need not to write the $-variables. AND THE MOST IMPORTANT: The normal user may add HELP to his lib commands like in CATalog, written in UsrRPL. These HELPs are seen also in one of the Libman browsers. - Wolfgang > Example for use with xcrunch 3: SIN(X) > 2: {4 5 6} > 1: 1 You can do this with my Numeric49 library on hpcalc. That's not much help for your problem, I know.... :-/ I have been looking for a leather case for the HP12 C. Chary made one a few years ago and I have been unable to locate another one. Does any one have any ideas or know how to locate one. It was a flip case with a clip that help the Calc. -- Rainey Farm Management, LLC P.O. Box 233 Paw Paw, MI 49079 (616) 655-8855 > Wall Street but its getting close. You may have already tried this but, if you > want to improve calculator speed on the 48 or any hpcalc try truncating the > number of digits with the FIX command. This will speed things up a bit > depending on the number of significant digits you want. The internal representation of floating point numbers is not affected by the display mode. Try: 2 FIX 1 3 / STD. The answer is not 0.33, and those extra digits did not magically get calculated when you changed modes. > The internal representation of floating point numbers is not affected by the > display mode. Try: 2 FIX 1 3 / STD. The answer is not 0.33, and those > extra digits did not magically get calculated when you changed modes. Allow me to mention one case (at least) that what you claim is not true. Numeric integration on all HPs that I know (have) is indeed affected by the number of decimals in the FIX command (it's in the manual too). Try it with any polynomial or tigonometric function within a range of values that is continuous and for two different FIX values, say 2 and 9 and you will see the difference. !Demeter! William Graves schrieb im Newsbeitrag > I ran across NOVAL in the 49 for the first time. > In making some INFORM code work for both the 48GX and the 49, I would like > to use NOVAL but the 48 entries/suprom files do not show NOVAL. Searching the archives for this group, I found repeated mention of NOVAL for > the 48, one posting even stated that it was a ROMPTR. (So I guess it is > different than MINUSONE). > Cannot find it in any of the hpcalc.org entry files either. Can someone give me > a. The value of NOVAL on the 48GX The value of NOVAL is simply NOVAL. This word does nothing than putting a pointer to itself on the stack. It's meaning is the same as FVAL_NULL ('MINUSONE') in SysRPL input forms. xNOVAL is the ROMPTR 0AB 05B > b. A pointer to a better entries table (mine starts with Supported ROM > Entry Points 1.104) There are chances that they simply forgot to put NOVAL into that list. Another possibility is that NOVAL isn't supported. BTW: You'll never need NOVAL when making input forms in SysRPL (see above;-) Raymond So, you are interested in electronics! This is something that is not directly relevant to the HP49G programs or documentation as you ask for in your posting. I suggest that you start with an introductory textbook on electricity and electrical networks and then move on to an introductory textbook on electonic devices (BJTs, FETs, MOSFETs etc). If you are short on cash then try some web sites. Among others the following two are practical in aspect: http://ourworld.compuserve.com/homepages/g_knott/index1.htm http://webhome.idirect.com/~jadams/electronics/ Please bear in mind that this is a huge subject and it usually takes many years of study and practice before people know what they are doing! Don't despair and keep on trying. Also, remember that the next best thing to a good textbook is your personal dedication to the subject. Good luck :-) !Demeter! BBC news announced this evening that a couple of thousand jobs are going at HP here in the UK...the beginning of the end? WigglePig > BBC news announced this evening that a couple of thousand jobs are going > at HP here in the UK...the beginning of the end? WigglePig Nope, the beginning of the end was last year, I think we're about in the middle of it now :-P I've read that ~5900 jobs will disappear in Europe, 15000 worldwide. I wish all of them good luck and a happy future, I'm confident most will find work... Have a good day, Gerald. > BBC news announced this evening that a couple of thousand jobs are going > at HP here in the UK...the beginning of the end? Probably more a planned result of the HP/Compaq merger. is there any gadget to make my 48 go wireless? http://www.newsfeed.com The #1 Newsgroup Service in the World! the HP48 uses serial communication (like a modem). there are several radios (with connectors and ready to plug into the HP48) that you could use for this purpose but they are not cheap (starting at about $100). you would need two, so again, this is not cheap :) http://jewel.morgan.edu/~rcobo/wireless/ http://membres.lycos.fr/ydesir/hp48gx/radio_e.html > is there any gadget to make my 48 go wireless? > http://www.newsfeed.com The #1 Newsgroup Service in the World! is there any gadget to make my 48 go wireless? Use the IR port :) No wires required. Bill alternate E-dress wtstorey@ieee.org.no.spam.please (Use the obvious) On my HP49G under I/O functions I noticed there is 'print display' and 'print'. What do these do? I have messed around with them but havent got them to do anything and I cant find them in the manual. > On my HP49G under I/O functions I noticed there is 'print display' and > 'print'. What do these do? I have messed around with them but havent > got them to do anything and I cant find them in the manual. They are left overs from the HP48 series which could output printing through an infra-red port that the HP49 does not have. The 49 will print through the serial port. There are a number of old programs on hpcalc that you can run on your PC to capture the output. I found that each of them had there own drawbacks and haven't really used them. I had thoughts that I could have something capturing my calcs or generating some kind of output that I could use as documentation record. The best utility actually translated the output from the HP49 onto a graphic image as it would have looked on the printer but it was limited to one graphic page. Stephen N. On my HP49G under I/O functions I noticed there is 'print display' and > 'print'. What do these do? I have messed around with them but havent > got them to do anything and I cant find them in the manual. They are left overs from the HP48 series which could output printing > through an infra-red port that the HP49 does not have. Alphabetic sort would be nice but not essential. Would it be possible to allow the arrow keys to loop back at the ends of the listing. Then you can quickly get to the end of the listing with the up arrow when your at the head of the list. Looks like I'm going to have to reset the Files key to the Wolfgang Filer. I like how it extends rather than changes how the original filer worked. Stephen N. Maybe a suggestion for a future release of a filer program. Sometimes I > wish it were possible to quickly move the selection by using an alpha > key, i.e. ALPHA-S would jump to the first object starting with an S. My > port 2 memory is getting quite a little overcrowded, having such a > feature could be nice (now, am I lazy?). Of course it would only work if > the files are sorted. Not sure if it really would be an usefull addition, just a thought. publically available. I hope I can someday add something to HPCalc as a > counter effort. Best wishes, > Walter. WR> No virtual keys. I doubt whether this would work inside a POL WR> with its own key-handler. Or does Dennis' key simulator do that? Yes, they work everywhere. WR> By the way, Flashpointer Filer_Manager has a TRUE/FALSE output, WR> not noticed in your PrgInSysRPL. OK. - Carsten convenient to detach all libs without any finger gymnastics, in > particular a corrupted one. Just press the DEL-key immediately > after you hit W. Sounds to me like an accident waiting to happen. If the only reason for having yet another way to warmstart is to make it easier to reboot without attaching any libraries, then I suggest that you just use ON-D to get to the Tests screen, and then hold down the backspace key while pressing the Q key. -- James > There is another proposal by CD, to make the keys 0, 1, 2 and . (dot) > working as direct entries to the three ports and to HOME, resp. What > do other people think on this? This works in ROM 1.19-7 In Filer1 (not Filer2), key W is now used for Warmstart. Very > convenient to detach all libs without any finger gymnastics, in > particular a corrupted one. Just press the DEL-key immediately > after you hit W. To provoke a warmstart, W executes PTR 00000, > But it works. Two keys to reboot.. That's great, it's almost better than ON-C hahaha. What is this option for? To realize Walter's proposition will take much more time. Can be > done only during summer vacation (provided it rains which is > luckily mostly the case at the Baltic Sea :-) Just admit you don't know how to do it :) > In Filer1 (not Filer2), key W is now used for Warmstart. Very > convenient to detach all libs without any finger gymnastics, in > particular a corrupted one. Just press the DEL-key immediately > after you hit W. To provoke a warmstart, W executes PTR 00000, > But it works. > Two keys to reboot.. That's great, it's almost better than ON-C hahaha. What > is this option for? It was originally thought for a smooth warmstart detaching all libs like a real warmstart with holding D. Just for eliminating corrupted libs. But nobody answered my question how to program this. > To realize Walter's proposition will take much more time. Can be > done only during summer vacation (provided it rains which is > luckily mostly the case at the Baltic Sea :-) > Just admit you don't know how to do it :) Yes, I admit that I presently don't. The information you gave in Filer.h is insufficient. I need the lams which holds the list of names (or the level of a corresponding virtual stack), the length of this list and the lam which holds the present postition. Can you tell me how to reach them? Then Walter's reasonable suggestion on adequately using alpha-shifted hard-keys could be realized in one day. If I had the complete source of your filer browser, it would be just a matter of 2 hours for me to realize everything. Does it make you happy if other people are spending there nights on hacking through the ROM to improve the interface for the normal user of your commercial product? I think I should stop doing this and spent my time more pleasant, as JHM seemingly does at present. - Wolfgang > Yes, I admit that I presently don't. The information you gave in > Filer.h is insufficient. I need the lams which holds the list of I forgot about Germans and their sense of humour. You have all the information in Filer.h It gives you the offset where the name of an object is stored, and where the location of the cursor is. What else do you need? A simple lookup in the table is all you need, then calculate what the position is. > names (or the level of a corresponding virtual stack), the length > of this list and the lam which holds the present postition. Can > you tell me how to reach them? Then Walter's reasonable suggestion the structure of the dada are described in there as well with the size of eac field. Can't do it in SysRPL, must be ML. > on adequately using alpha-shifted hard-keys could be realized in > one day. If I had the complete source of your filer browser, it > would be just a matter of 2 hours for me to realize everything. even sometimes problems to understand why I did stuff that way ! > Does it make you happy if other people are spending there nights on > hacking through the ROM to improve the interface for the normal user > of your commercial product? I think I should stop doing this and spent Well, yes it does. But probably not as much as you get fun *playing* there. I like the interface of the Filer the way it works now, and it's not purely a commercial product as it's available for free for the HP48. Maybe I can try to do a module for ROM 1.19-6 with just a new Filer, I don't think that is forbidden as I entirely own the source code. I will add such tools like jumping directly to port 0,1 or 2 or HOME from the TreeList. I don't know how I can interface the direct jump to an object based on the name as I'm currently using a lot of alpha-keys. I guess I could add a search option which allows you to enter the first letters of what you're looking for. Is that okay ? Waiting for comments here. > my time more pleasant, as JHM seemingly does at present. I doubt it has anything to do with using his freetime in a different way. > Yes, I admit that I presently don't. The information you gave in > Filer.h is insufficient. I need the lams which holds the list of > I forgot about Germans and their sense of humour. > You have all the information in Filer.h > It gives you the offset where the name of an object is stored, and where the > location of the cursor is. What else do you need? > A simple lookup in the table is all you need, then calculate what the > position is. that it may be incomplete and not contain all information you are talking about. Would it be to much trouble to sent it again, doesn't process these. - Wolfgang > that it may be incomplete and not contain all information you > are talking about. Would it be to much trouble to sent it again, I doubt Carsten would have modified this little file. In Filer.h you have an alias for each unamed local variables, and there's the description of the internal data like this: ASSEMBLEM DC _SIZE_ELEMENT 60 DC _SIZE_HEADER 27 %In HEXA ! %FLAGS :3q %FreeMem :5q %NB OBJECTS:5q %POSX :5q %POS DX :5q %SIZE TAGS :6q %NB TAGS :5q %NBTAGS dec:5q %ELEMENTS %TAG :2 %@ACCESS :5 %@OBJECT :5 %SIZE OBJ :5 %TYPE :10 %------------- % 96 CP=0 DCCP 2 _TAG DCCP 5 _@ACCESS DCCP 5 _@OBJ DCCP 5 _SIZE DCCP 10 _TYPEF DCCP 2 _ICON DCCP 0 _END.ELEMENTS Don't you have this ? > that it may be incomplete and not contain all information you > are talking about. Would it be to much trouble to sent it again, JA> I doubt Carsten would have modified this little file. Certainly not on purpose. But I was not sure if I had gotten the full file from the Usenet attachment. The information you list below is indeed in the file. Which does not mean it would be enough info for me to use it - I guess, ML people are more used to this kind of descriptions. - Carsten JA> In Filer.h you have an alias for each unamed local variables, and there's JA> the description of the internal data like this: JA> ASSEMBLEM JA> DC _SIZE_ELEMENT 60 JA> DC _SIZE_HEADER 27 %In HEXA ! JA> %FLAGS :3q JA> %FreeMem :5q JA> %NB OBJECTS:5q JA> %POSX :5q JA> %POS DX :5q JA> %SIZE TAGS :6q JA> %NB TAGS :5q JA> %NBTAGS dec:5q JA> %ELEMENTS JA> %TAG :2 JA> %@ACCESS :5 JA> %@OBJECT :5 JA> %SIZE OBJ :5 JA> %TYPE :10 JA> %------------- JA> % 96 JA> CP=0 JA> DCCP 2 _TAG JA> DCCP 5 _@ACCESS JA> DCCP 5 _@OBJ JA> DCCP 5 _SIZE JA> DCCP 10 _TYPEF JA> DCCP 2 _ICON JA> DCCP 0 _END.ELEMENTS JA> Don't you have this ? Just to reming all of you that you can post enhancement request to bugs.hpcalc.org. I always have a look at it > Just to reming all of you that you can post enhancement request to > bugs.hpcalc.org. I always have a look at it Does this imply that ROM updates are still underway (official or non-official)? I have been under the impression that the corporate mucky-mucks killed all future calculator development and are just coasting along with current production for as long as it sells and makes money with no further R&D OH. Or, why can't they just let the ROM go open source like Linix--we would still be buying their hardware and you could be selling your own enhanced version? Greg S > Does this imply that ROM updates are still underway (official or > non-official)? I have been under the impression that the corporate > mucky-mucks killed all future calculator development and are just coasting It doesn't mean that I can't keep working privately on it. Sooner or later this work will be released ! Greg S. wote: > [...] why can't they just let the ROM go open source [...] Because they have not abandoned the calculator business at all. Best wishes, HPCC member #1046 - -- > Greg S. wote: [...] why can't they just let the ROM go open source [...] Because they have not abandoned the calculator business at all. Just another question on the side: Would future, and more regular, ROM updates more likely happen if they were to come out with just an RPN version of the ROM? In other words, use the bi-lingual ROM as stock (for sales purposes), then just come out with an Algebraic one for people who just go to have it (or leave the stock one alone), and then put update effort towards robust, bullet proof and bug free RPN updates. It's just an idea--I am guessing that clipping the Algebraic mode would free up resources and streamline the ROM's configuration. Greg Just to reming all of you that you can post enhancement request to > bugs.hpcalc.org. I always have a look at it Is it safe to assume that genuinebugs (as opposed to correct behaviour that the user didn't expect) are more likely to be fixed if they're reported at http://bugs.hpcalc.org instead of only in the newsgroup? -- James about the warmstart key - it seems that it somehow messed up my calc. As I've absolutely no knowledge about the insides of the 49, I hope someone can give me some hints on solving this problem. Symptoms are: repeatedly restarting, only way to stop it is using the backspace key. I know a possible approuch would be removing the installed libraries one by one, but if there's a less rigorous way, I'd like to know. I'm quite sure these problems appeared after using the new filer1, *likely* because of the warmstart. 'Quite sure' means that I've used my calc before filer1 without any problems. Though I must admit that its a little strange that detaching the libs solves this problem. I've already cleared its memory. About my suggestion of using a flag to disable the W key, Wolfgang asked me to do a proposal on this, but frankly, I don't know what to suggest. If it was to be implemented this way, a flag not used by any other program would have to be used as it's got to be kind of 'global' flag. Only flag I've seen used so far is 5, by eql49. Maybe it isn't such a good idea on second thought. Best wishes, Walter. The port 'shortcuts' are working perfectly on my calc. Really nice! So > far I havn't found any problems. But, the warm start doesn't seem to > work. That is, it works a little too good - it keeps restarting. > I exited the loop by using the backspace key, so I guess it's got to do > something with a library I've installed. If you want, I can give you a > list with the libraries I've installed. But, to be honest, I actually think a one-key restart is a little riscy. > Problem of a warm start is that it clears the stack. Maybe it would be a > good idea to add the possibility to turn this key of by toggling a flag. > Or, to let filer run a user defined program before it does the > warmstart, so one can do some last moment life-saving tasks. Please take all your time for implementing the alpha functionality, I'm > not good in meteorology, but I guess that if you've got rain, I'm likely > to get it too... Oh well, not really, but, just take your time. > about the warmstart key - it seems that it somehow messed up my calc. The Warmstart will be eliminated. Wait a day and don't use it. There are 2 possible alternatives for replacement: (a) I unify Filer1 and Filer2 just by giving +/- and NXT the same functionality of selecting (that wouldn't cost any bytes and make things easer for as I've to care on Filer1 only). Everybody could then use his favourit key for selecting. (b) I make +/- togggle the ASCII/BIN mode for file transfer, with corresponding anouncement in the Header. At the time when I had two 49, or working both with 48 and 49, I used the filer regularly for communication between these in these 2 modes. What is the general option? Please answer here in the NG. - Wolfgang Wouldn't another option be a slightly modified version of b), using NXT for ASCII/BIN and +/- for selecting? Personally, I prefer +/- for selecting, because of consistancy as it is often used as a toggler. Besides this option c), a) would be a good alterative too, I think. Saves you some work, and for me, ASCII/BIN isn't such an important function. BTW, talking about 'consistancy' and changing keys - wouldn't it be logic to assign EDITB to ENTER instead of F1? That would be like on a PC. I hope I'm not overloading you with suggestions now... sorry if I do. Walter. PS: the endlesly rebooting probably wasn't caused by your warmstart. I didn't attach last libs I installed by a ON-C, but by using ATTACH. So, it might well be that the warmstart caused by filer was the first one in quite a long time, and that some lib doesn't like rebooting. I'm very sorry if I caused any confusion. about the warmstart key - it seems that it somehow messed up my calc. > The Warmstart will be eliminated. Wait a day and don't use it. > There are 2 possible alternatives for replacement: (a) I unify Filer1 and Filer2 just by giving +/- and NXT the > same functionality of selecting (that wouldn't cost any bytes > and make things easer for as I've to care on Filer1 only). > Everybody could then use his favourit key for selecting. (b) I make +/- togggle the ASCII/BIN mode for file transfer, > with corresponding anouncement in the Header. At the time when > I had two 49, or working both with 48 and 49, I used the filer > regularly for communication between these in these 2 modes. What is the general option? Please answer here in the NG. - Wolfgang > ... (a) would be a good alterative too, I think. I've chosen alternative (a), i.e., both NXT and +/- can be used for selecting. In the next edition after a few month, NXT will select going downward, Leftshift NXT upward. The revised Filer1, including revised text is on my site ftp://ftp.math.fu-berlin.de/pub/usr/raut/HP49/tools/ > BTW, talking about 'consistancy' and changing keys - wouldn't it be > logic to assign EDITB to ENTER instead of F1? That would be like on a > PC. I hope I'm not overloading you with suggestions now... sorry if I do. You mean on a PC, ENTER does execute editorial programs. Clearly, since ENTER executes everything. On the 49, ENTER doesn't run the editor because the latter is integrated in the OS. More precisely, it is a POL (a kind of a special environement with own key handling), accessable by special keys and by all alpha-shifted and the numeric keys. Simply read ENTER in Filer1 as Enter a directory and leave the filer. In Filer0 (builtin) the EMTER has perhaps to be read as Enter an item to the already selected ones :-) Anyway, nice to hear that JYA will integrate a direct HOME and Port- entry also in ROM 19-7. Ho does hopefully not forget that it was realized for the first time in Filer1 :-) - Wolfgang What about the Filer2 ? I like a two-paged Filer a lot. Will you still make enhancements into it? Veli-Pekka Nousiainen > ... (a) would be a good alterative too, I think. I've chosen alternative (a), i.e., both NXT and +/- can > be used for selecting. In the next edition after a few > month, NXT will select going downward, Leftshift NXT upward. > The revised Filer1, including revised text is on my site > ftp://ftp.math.fu-berlin.de/pub/usr/raut/HP49/tools/ X > Anyway, nice to hear that JYA will integrate a direct HOME > and Port- entry also in ROM 19-7. Ho does hopefully not > forget that it was realized for the first time in Filer1 :-) Not at all. Wouldn't another option be a slightly modified version of b), using NXT > for ASCII/BIN and +/- for selecting? Personally, I prefer +/- for > selecting, because of consistancy as it is often used as a toggler. consistancy? Then [NXT] should ALWAYS go to the next menu page ! > Besides this option c), a) would be a good alterative too, I think. > Saves you some work, and for me, ASCII/BIN isn't such an important function. BTW, talking about 'consistancy' and changing keys - wouldn't it be > logic to assign EDITB to ENTER instead of F1? That would be like on a > PC. I hope I'm not overloading you with suggestions now... sorry if I do. This would keep consusing me unless ALL the PC quirks could be incorporated at once. > Walter. > > (a) I unify Filer1 and Filer2 just by giving +/- and NXT the > > same functionality of selecting (that wouldn't cost any bytes > > and make things easer for as I've to care on Filer1 only). > > Everybody could then use his favourit key for selecting. Look above, Wolfgang. Consistency. NXT=next menu page > > (b) I make +/- togggle the ASCII/BIN mode for file transfer, I would rather shift [+/-] for ASCII/BIN Because I want to 'shift' a program to another calculator > > with corresponding anouncement in the Header. At the time when > > I had two 49, or working both with 48 and 49, I used the filer > > regularly for communication between these in these 2 modes. > > What is the general option? Please answer here in the NG. > > - Wolfgang about the warmstart key - it seems that it somehow messed up my calc. As X > About my suggestion of using a flag to disable the W key, Wolfgang asked X I vote for no W WarmStart I have bought one 128kb an one 1Mb cars to Klotz this week. They are really well make and they works perfectly. http://uuhome.de/oklotz/index_e.html#prices ----- Original Message ----- Are you ready for an chinese expedition, dear Marco Polo? > Buy a HP 49G and the 1MB Flash will last forever (more than your > lifespan) > expansion > port. > The other feature are too numerous to say here, but take my word for > it: > v'ger is the best programmablr calculator ever (sans the key feel) I had my chinese expedition, but i did not enjoy it too much: beside > the _horrible_ keyboard, the 49G seems to me too student-oriented, and > unfortunately i am not a student anymore. I need my HP for my job. > I don't need symbolic mathematics or the Metakernel, but i need a > really solid calculator environment (even if slow). My purpose is to > make number crunching, unit management and some user-rpl programming > to automate some calculation schemes. I use my HP also in construction > sites, so i need a robust and durable keyboard. > I got the 49G to have a backup replacement for my 11 years-old 48sx. > After two weeks of heavy using i switched back to the 48sx and went > back to the shop and asked if they could replace the 49g with a 48gx. > They were surprised, but agreed and i got a brand new Malaysian 48gx > (Black screen :-) , but painted keys :-(( ). > I need the 128 kb card only for backup purpose: i already own an > original HP 128 kb card, and my intention is to use one card for my > applications and one for backing up the main memory of the 48gx. > Consider also that i will be able to move data and application from > the SX to the GX and vice versa very easyly. > I think that the 49g is a great calculator, but unfortunately it does > not match my needs. > Bye > Marco Polo -- > Marco Polo > (red october)marko_ramius@softhome.net > Remove (red october) to E-Mail..... > --- > you could try this ... > http://www.expresspcb.com/ -- Jeffery http://woodfanclub.com No, it's not vanity, just desperation. > you could try this > ... > http://www.expresspcb.com/ I recommend http://www.olimex.com/pcb/index.html I've ordered from them and i'm very pleased. Steve Sousa > I recommend http://www.olimex.com/pcb/index.html I've ordered from them and i'm very pleased. -- Jeffery http://woodfanclub.com No, it's not vanity, just desperation. > It's a good idea to do a program about, do you have any page, source > to see how much has advanced that stuff. In my searching for utterly non-productive uses of my time I have run > into > things like Core Wars, pbots, cbots, At-Robots, etc etc. Did anyone > make > such a game for the Hp48 series? I'm not sure I'm following the question. I have the URLs of some of the sites, I don't recall if any of them had available source code, though they might. Is that what you mean? -- Jeffery http://woodfanclub.com No, it's not vanity, just desperation. > It's a good idea to do a program about, do you have any page, source > to see how much has advanced that stuff. In my searching for utterly non-productive uses of my time I have run > into > things like Core Wars, pbots, cbots, At-Robots, etc etc. Did anyone > make > such a game for the Hp48 series? > I'm not sure I'm following the question. I have the URLs of some of the sites, > I don't recall if any of them had available source code, though they might. Is > that what you mean? well, yes I mean any information would be useful. let me know German Has anyone developed a Program or Formulas that perform Earned Value Analysis calculations for Project Management? Martin B http://www.terrafirma.com.au I seem not to get the resolution in it' best way. it's always a litle more unsolved that what i want. How can i upgrade my symbolic calc??' What calculator model do you have? HP 28C, 28S, 38G, 39G, 40G, 48S/SX, 48G/G+/GX, 49G ? Can you give as an example of the derivative that doesn't work? Both in math terms, human language explanation AND the exact steps that you tried to do. Also - if you have an HP 49G - please do CASCFG before the calculations to have a clean start. Veli-Pekka > I seem not to get the resolution in it' best way. it's always a litle more > unsolved that what i want. > How can i upgrade my symbolic calc??' Does anybody knows, even a little piece of documentation on SysRPL manipulation of HP49 Integer Type (DOINT prolog) and symbolic matrices (DOMATRIX prolog) ? What about '^'- and (more specifically, i think) '^Q'- prefixed entries?. Jacek Kowalczyk JK> Does anybody knows, even a little piece of documentation on SysRPL JK> manipulation of HP49 Integer Type (DOINT prolog) and symbolic matrices JK> (DOMATRIX prolog) ? What about '^'- and (more specifically, i think) '^Q'- JK> prefixed JK> entries?. Programming in SystemRPL (by Eduardo and myself) contains at least stack diagrams for all these entries and many entries dealing with matrices and integers. Get it from hpcalc.org, or from Eduardos website. - Carsten I need a program that can find the z score given the area unde the curve for the 48sx. I don't have much memory left on it so smaller is better. Does anyone know of one? > I need a program that can find the z score given the area unde the curve for > the 48sx. I don't have much memory left on it so smaller is better. Does > anyone know of one? << -> x << << x 0 1 u UTPN - > 'u' 0 ROOT NEG 'u' PURGE > Michael -- -= Michael Hoppe , =------ I need a program that can find the z score given the area unde the curve for >the 48sx. I don't have much memory left on it so smaller is better. Does >anyone know of one? There is stat48 on www.HPCALC.ORG. You'll have to check the docs to see if it is compatible with the SX though. If not, there are probably some other statistical programs there which you can use. If all else fails, wrap a solver around UTPN. It might be the difficult way, but it should converge nicely. Sorry, I have no SX so I can't help further. Bill alternate E-dress wtstorey@ieee.org.no.spam.please (Use the obvious) be usefull to transfer data from HP48 to nokia phone, I own a Nokia 3320 with an IR port, on it you can send ringtones from the PC, unfortunelly my PC doesn`t have an IR port so I was thinking about a program you can install in the HP48 (or the PC) to be used for the PC as IR port so you can send ring tones to the Nokia phone. > be usefull to transfer data from HP48 to nokia phone, I own a Nokia > 3320 with an IR port, on it you can send ringtones from the PC, > unfortunelly my PC doesn`t have an IR port so I was thinking about a > program you can install in the HP48 (or the PC) to be used for the PC > as IR port so you can send ring tones to the Nokia phone. If you could somehow set the IR of your Nokia to serial communications, then you would be able to transfer just about anything. But is that possible? Nick. > be usefull to transfer data from HP48 to nokia phone, I own a Nokia > 3320 with an IR port, > If you could somehow set the IR of your Nokia to serial > communications, then you would be able to transfer just about > anything. But is that possible? Regardless of the way the nokia gets data, the hp could eventually be made to send the right bits, I think. But the real question is - what protocol is the nokia using? -- while E < > Regardless of the way the nokia gets data, the hp could eventually be made > to send the right bits, I think. But the real question is - what protocol > is the nokia using? IrDA I guess... at least, that is what Siemens uses. Totally unexpectedly, my curiosity defeated my lazyness and so I did some timing experiments with my (corrected) program and two programs suggested by Obi Van Veli-Pekka for preference ordering. First of all, as Tom Sears has noticed, my program wouldn't work in case the second list (that contains the ordering) has two or more duplicated elements, like for example { 2 1 2}. So here is the corrected code: << 1 << I->R > DOSUBS DEPTH -> o p d << p 1 << o SWAP GET > DOSUBS o 1 << IF p NSUB POS THEN DROP END > DOSUBS IF DEPTH d == THEN + END The two programs suggested by Veli-Pekka were: << I->R 1. PICK3 SIZE FOR j j DUP2 POS IF NOT THEN SWAP OVER + SWAP END PICK3 PICK3 ROT GET GET UNROT NEXT DROP SIZE ->LIST and << I->R 1. PICK3 SIZE FOR j DUP2 j POS DUP NOT { DROP j } IFT GET UNROT NEXT DROP SIZE ->LIST These three programs were tested as follows: A list with n random reals was created. Then a list with m positions was created. Those two lists were given as arguments to the programs which were evaluted using TEVAL. The values for n were from 10 to 100 in steps of 10, that means 10, 20,...100. The values for m were from n/10 to n in steps of n/10. That means that for n=10 m was 1,2,3..10. For n=20 m was 2,4,6..20. And so on. Then a fit was performed usinf n,m and t (time needed for the programs to finish) The following fit functions describe the performance of the three programs very well: Mine: t=.1737*n^.4579*m^(-.1061+.1484*ln(n)) has the best timings. Its fitted timing function *decreases* when m increases! Some timing values for comparison: wins. wins. wins. wins. wins. wins. wins. outperform the other two for big values n and m. Using lists of other objects instead of random reals, leaves the general pattern the same. For example when using a list of the first 10,20...50 cyclotomic polynomials and using the same position lists for each of these lists, the fitting functions look like: Mine: t=.2325*n^.3768*m^(-.1383+.1684*ln(n)) wins. wins. wins. wins. wins. wins move to After hours of experimenting with timings, there are two things to notice: In other words Obi Van Veli-Pekka will have the last word. ;-) 2) Was it really worth the time and batteries? Nick. Totally unexpectedly, my curiosity defeated my lazyness and so I did > some timing experiments with my (corrected) program and two programs > suggested by Obi Van Veli-Pekka for preference ordering. First of all, as Tom Sears has noticed, my program wouldn't work in > case the second list (that contains the ordering) has two or more > duplicated elements, like for example { 2 1 2}. So here is the > corrected code: << 1 > << I->R DOSUBS > DEPTH -> o p d > << p 1 > << o SWAP GET DOSUBS > o 1 > << IF p NSUB POS > THEN DROP > END > DOSUBS > IF DEPTH d == > THEN + > END > Ok, as far as I've tested, it does work. > The two programs suggested by Veli-Pekka were: > << I->R 1. PICK3 SIZE > FOR j j DUP2 POS > IF NOT > THEN SWAP OVER + SWAP > END PICK3 PICK3 ROT GET GET UNROT > NEXT DROP SIZE ->LIST > and << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT GET UNROT > NEXT DROP SIZE ->LIST Umm, but didn't this second one give wrong answers? He did have another run the tests on. I felt left out, so I did some testing of my own, but not as thorough as yours. Just in case I have someone's program in my calculator wrong, here are the eight programs I tested. My apologies if I mangled anyone's program or goofed up the timing. Any testing of SysRPL programs would have to be done by someone else. << I->R 1. PICK3 SIZE FOR j j DUP2 POS IF NOT THEN SWAP OVER + SWAP END PICK3 PICK3 ROT GET GET UNROT NEXT DROP SIZE ->LIST << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: DROP :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: ; :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST << 1. << I->R > DOSUBS DEPTH -> o p d << p 1. << o SWAP GET > DOSUBS o 1. << IF p NSUB POS THEN DROP END > DOSUBS IF DEPTH d == THEN + END > 'NK', # 709Dh, 158 bytes << I->R 1. PICK3 SIZE FOR i i DUP2 POS NOT { SWAP OVER + SWAP } IFT PICK3 PICK3 ROT GET GET UNROT NEXT DROP SIZE ->LIST 'WR', # 8B40h, 81.5 bytes << I->R 1. PICK3 SIZE FOR i i DUP2 IF POS THEN DROP ELSE + END DUP2 i GET GET UNROT NEXT DROP SIZE ->LIST 'WH', # 2466h, 76 bytes << I->R SWAP DUP -> o << 1. SWAP SIZE FOR n IF DUP n POS NOT THEN n + END NEXT 1. << o SWAP GET > DOLIST > 'JMP1', # 99E5h, 108 bytes << DUP SIZE IF DUP THEN SWAP I->R PICK3 SIZE -> s m p n << IF m n == NOT THEN 1. n FOR i i NEXT DUP p LIST-> DUP n + 4. + 5. PICK3 OVER + 1. - FOR j 0. OVER j PICK - UNPICK NEXT DROP DROPN ->LIST ->STR 0. SREPL DROP STR-> p SWAP + 'p' STO END p LIST-> DROP s REVLIST LIST-> DUPDUP + 2. + 2. PICK3 1. + FOR k DUP ROLL k + PICK SWAP NEXT DROP n > ->LIST OVER 2. + ROLLD DROPN ELSE DROP2 END 'JMP2', # DCCEh, 329 bytes In the tables below the level 2 argument is a list of zints from 1 through n, and the level 1 argument list is a list of zints from m decreasing through 1. That is, if n=5 and n=4, then level 2 is { 1 2 3 4 5 }, and level 1 is { 4 3 2 1 }. Times are in seconds, using << RCL TEVAL 2 RND > on the program names. n=1,m=1 NK 0.23 WR 0.14 WH 0.14 JMP1 0.20 JMP2 0.18 n=2,m=1 n=2,m=2 NK 0.27 0.29 WR 0.19 0.18 WH 0.19 0.18 JMP1 0.24 0.24 JMP2 0.33 0.20 n=5,m=1 n=5,n=3 n=5,m=4 n=5,m=5 NK 0.35 0.42 0.45 0.47 WR 0.35 0.34 0.33 0.33 WH 0.35 0.34 0.34 0.34 JMP1 0.40 0.39 0.38 0.38 JMP2 0.43 0.43 0.44 0.25 n=10,m=1 n=10,m=5 n=10,m=9 n=10,m=10 NK 0.48 0.65 0.80 0.82 WR 0.68 0.66 0.64 0.63 WH 0.67 0.66 0.65 0.65 JMP1 0.71 0.69 0.67 0.66 JMP2 0.60 0.61 0.62 0.36 n=20,m=1 n=20,m=10 n=20,m=19 n=20,m=20 NK 0.75 1.30 1.75 1.77 WR 1.62 1.57 1.51 1.50 WH 1.59 1.57 1.54 1.54 JMP1 1.58 1.54 1.48 1.47 JMP2 0.97 1.00 1.02 0.59 n=50,m=1 n=50,m=25 n=50,m=49 n=50,m=50 NK 1.58 4.40 6.21 6.22 WR 6.62 6.46 6.02 5.99 WH 6.55 6.46 6.10 6.08 JMP1 6.25 6.07 5.53 5.50 JMP2 2.24 2.21 2.29 1.34 n=100,m=1 n=100,m=50 n=100,m=99 n=100,m=100 NK 3.04 13.23 19.05 19.04 WR 22.32 21.69 19.78 19.73 WH 22.18 21.69 19.94 19.89 JMP1 20.81 20.07 17.72 17.65 JMP2 4.81 4.59 4.71 2.87 n=200,m=1 n=200,m=100 n=200,m=199 n=200,m=200 NK 6.25 44.37 66.73 66.72 WR 94.62 93.51 72.26 72.18 WH 94.32 93.52 72.58 72.50 JMP1 82.87 81.13 63.85 63.74 JMP2 11.35 10.20 10.56 6.87 notice: > In other words Obi Van Veli-Pekka will have the last word. ;-) I'll let the numbers speak for themselves. > 2) Was it really worth the time and batteries? Well, yes, I found it educational. -- James PS: I'm not sure that else anyone still cares, but I cleaned up my program a bit. It's still relatively huge, but it's smaller than it was and faster now. << I->R OVER SIZE DUP PICK3 SIZE IF == THEN DROP ELSE 1. SWAP FOR i i NEXT DUPDUP 2. + PICK LIST-> 0. OVER 3.+ PICK PICK3 + 5. + 6. 4. PICK OVER + 1. - FOR j DUP2 j PICK - UNPICK NEXT DROP2 DROPN ->LIST ->STR 0. SREPL DROP STR-> + END SWAP LIST-> 1. + ROLL LIST-> DUPDUP + SWAP DUP 4. + PICK3 4. + PICK3 OVER + 1. - FOR k k OVER PICK - PICK UNROT NEXT DROP ->LIST OVER 2. + ROLLD DROPN 'JMP3', # 6991h, 270.5 bytes Timings are by the same method as in the previous post. n=1,m=1 JMP3 0.16 n=2,m=1 n=2,m=2 JMP3 0.31 0.17 n=5,m=1 n=5,n=3 n=5,m=4 n=5,m=5 JMP3 0.41 0.42 0.42 0.24 n=10,m=1 n=10,m=5 n=10,m=9 n=10,m=10 JMP3 0.58 0.59 0.60 0.34 n=20,m=1 n=20,m=10 n=20,m=19 n=20,m=20 JMP3 0.93 0.96 0.98 0.55 n=50,m=1 n=50,m=25 n=50,m=49 n=50,m=50 JMP3 2.10 2.07 2.16 1.22 n=100,m=1 n=100,m=50 n=100,m=99 n=100,m=100 JMP3 4.34 4.12 4.27 2.43 n=200,m=1 n=200,m=100 n=200,m=199 n=200,m=200 JMP3 9.77 8.66 8.89 5.21 n=500,m=1 n=500,m=250 n=200,m=499 n=500,m=500 JMP3 31.96 24.26 24.62 15.38 n=1000,m=1 n=1000,m=500 n=1000,m=999 n=1000,m=1000 JMP3 90.8 56.49 57.53 39.02 -- James Totally unexpectedly, my curiosity defeated my lazyness and so I did > some timing experiments with my (corrected) program and two programs > suggested by Obi Van Veli-Pekka for preference ordering. First of all, as Tom Sears has noticed, my program wouldn't work in > case the second list (that contains the ordering) has two or more > duplicated elements, like for example { 2 1 2}. So here is the > corrected code: << 1 > << I->R DOSUBS > DEPTH -> o p d > << p 1 > << o SWAP GET DOSUBS > o 1 > << IF p NSUB POS > THEN DROP > END > DOSUBS > IF DEPTH d == > THEN + > END > The two programs suggested by Veli-Pekka were: > << I->R 1. PICK3 SIZE > FOR j j DUP2 POS > IF NOT > THEN SWAP OVER + SWAP > END PICK3 PICK3 ROT GET GET UNROT > NEXT DROP SIZE ->LIST > and << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT GET UNROT > NEXT DROP SIZE ->LIST ************************************************************************** BUT ************************************************************************** > { 1 2 3 4 5 } > { 4 } should give { 4 1 2 3 5 } but your last version gives { 1 2 3 1 5 } > unless I made an error. Maybe Nick can verify in his spare time :-) > Tom > AUUUURRRGGGHH! > Can you please give me the examples > that works on the correct programs > and fail with this one. > Please... > ... > This can trimmed down to > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. AND << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. Werner THOSE THAT DO WORK ARE: Wolfgang: << I->R 1. PICK3 SIZE FOR i i DUP2 POS NOT { SWAP OVER + SWAP } IFT PICK3 PICK3 ROT GET GET UNROT NEXT DROP SIZE ->LIST 81.5 bytes, CRC 8B40h. Werner: << I->R 1. PICK3 SIZE FOR i i DUP2 IF POS THEN DROP ELSE + END DUP2 i GET GET UNROT NEXT DROP SIZE ->LIST 76.0 bytes #2466h Veli-Pekka: << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: DROP :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST BYTES => # B203h 75.5 << I->R 1. PICK3 SIZE FOR j j DUP2 POS :: ; :: + IFTE DUP2 j GET GET UNROT NEXT DROP SIZE ->LIST BYTES => # B79Ah 75.5 ************************************************************************** ************************************************************************** NOW: RE-RUN YOUR TESTS, please :-) ************************************************************************** ************************************************************************** and if you want to test-drive the ultimate program (with wrong answers) here it is (the secret code finally revealed): << I->R 1. PICK3 SIZE FOR j DUP2 j POS j OVER :: SWAP IFT NIP GET UNROT NEXT DROP SIZE ->LIST BYTES => #33F1h 69.5 and one more (wrong) variation: << I->R 1. PICK3 SIZE FOR j j 3. DUPN POS ROT OVER :: SWAP IFT NIP GET UNROT NEXT DROP SIZE ->LIST BYTES => 5E8Ch 70. ************************************************************************** > These three programs were tested as follows: A list with n random reals was created. Then a list with m positions > was created. Those two lists were given as arguments to the programs > which were evaluted using TEVAL. The values for n were from 10 to 100 > in steps of 10, that means 10, 20,...100. The values for m were from > n/10 to n in steps of n/10. That means that for n=10 m was 1,2,3..10. > For n=20 m was 2,4,6..20. And so on. Then a fit was performed usinf n,m and t (time needed for the programs > to finish) The following fit functions describe the performance of the three > programs very well: > Mine: t=.1737*n^.4579*m^(-.1061+.1484*ln(n)) has the best timings. Its fitted timing function *decreases* when m > increases! Some timing values for comparison: > wins. wins. wins. wins. wins. wins. wins. outperform the other two for big values n and m. Using lists of other objects instead of random reals, leaves the > general pattern the same. For example when using a list of the first > 10,20...50 cyclotomic polynomials and using the same position lists > for each of these lists, the fitting functions look like: > Mine: t=.2325*n^.3768*m^(-.1383+.1684*ln(n)) wins. wins. wins. wins. wins. wins move to > After hours of experimenting with timings, there are two things to > notice: > In other words Obi Van Veli-Pekka will have the last word. ;-) > 2) Was it really worth the time and batteries? Yes it was > Nick. Veli-Pekka And you still haven't learnt the netiquette. I already started a thread with timings of my corrected version but then I saw that this thread was already started, so here is my code. << 1 << I->R > DOSUBS DEPTH -> o p d << p 1 << o SWAP GET > DOSUBS o 1 << IF p NSUB POS THEN DROP END > DOSUBS IF DEPTH d == THEN + END Yes I am a DOSUBS fanatic ;-) The erroneous behavior using position lists with repeated elements (like {2 1 2}) is now corrected. (Hopefully ;-)) Nick. 4MHz and doing a test with lists of 10000 elements would require more batteries than the number available at both super markets of Hergiswil. ;-) The following seems to be the ultimate and fastest > 49-UsrRPL-program for our problem: << > I->R 1. PICK3 SIZE > FOR i i DUP2 POS NOT { SWAP OVER + SWAP } IFT > PICK3 PICK3 ROT GET GET UNROT > NEXT DROP SIZE ->LIST > 81.5 bytes, CRC 8B40h. << > I->R 1. PICK3 SIZE > FOR i > i DUP2 > IF POS THEN DROP ELSE + END > DUP2 i GET GET UNROT > NEXT > DROP SIZE ->LIST > 76.0 bytes #2466h Werner > Which can be immediately trimmed down with > << > I->R 1. PICK3 SIZE > FOR j j DUP2 POS > :: DROP :: + IFTE > DUP2 j GET GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # B203h 75.5 > The WH solution has the same length than my > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP > IF NOT THEN DROP j END > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # 125Ah 76. > BUT > This can trimmed down to > << > I->R 1. PICK3 SIZE > FOR j DUP2 j POS DUP NOT > { DROP j } IFT > GET UNROT > NEXT > DROP SIZE ->LIST > BYTES => # AF91h 71. > AND > Remember: I have a solution, which is in length > << not yet revealed BYTES => # 33f1h 69.5 > Now, tease you little gray cells and make even. > I DARE YOU TO BEAT THIS ONE !! > PS: Love Bytes in another thread, very soon... > PPS: I thought that what Wofgang wanted was speed > regrading huge input lists?! Maybe Nick could do some > testing on speed on 10, 100, 1000, 10000 items lists. > the order list could be 10%, 50%, 100% on the items list. > So only a few different program versions with 12 inputs batteries than the number available at both super markets of > Hergiswil. ;-) Well, actually I run out of memory when I try. ;-) -- James Hmmm.. maybe not with LastArg, Undo, Cmd buffers off and enough free Main mem, but anyway, too much time spend UNLESS one tries with a 2,533 GHz Pentium 4 using an emulator... ;-) 4MHz and doing a test with lists of 10000 elements would require more > batteries than the number available at both super markets of > Hergiswil. ;-) Well, actually I run out of memory when I try. ;-) > -- > James faster than the loop. For small lists (20 or so elements), it > isn't as if you're going to have time to get another coffee > anyway, and for large lists (over 100 elements), DOLIST is > significantly faster. > HERE IT IS ! DOLIST is faster than a loop with big lists !!! > This I was suspecting all the time!! Whoa! I also said: By exploding a list onto the stack and using stack commands in a loop to manipulate the elements, I seem to be able to do it a lot faster than with DOLIST, no matter how many elements are in the list, so it seems to me that DOLIST is indeed much slower than it should be. It turns out that I inadvertently used zints in my program example (T1) with the DOLIST command in it, which slowed it down quite a bit. But even with reals, it's not as fast as working on the stack. Also, my testing was only with programs that worked on only one list. For different problems, you may get different results. These were meant to be very rudimentary comparisons, not definitive testing. For what it's worth, see my timings below. Of course, I wouldn't be surprised if someone else has a way to do this problem faster. Examples: << 1. << SQ 5. + > DOLIST > 'T1', # CD36h, 38 bytes << { } 1. PICK3 SIZE FOR n OVER n GET SQ 5. + + NEXT NIP > 'T2', # E106h, 54 bytes << REVLIST LIST-> 2. DUP PICK3 + 1. - FOR n n ROLL SQ 5. + SWAP NEXT ->LIST > 'T3', # DDEAh, 62 bytes << 1. OVER SIZE FOR i DUP i GET SQ 5. + SWAP NEXT SIZE ->LIST > 'T4', # BF75h, 51.5 bytes Times are in seconds, rounded to three significant digits. ??? for a time means that I didn't have the patience to run that test. Argument 'T1' 'T2' 'T3' 'T4' time time time time { 1. } .0709 .0404 .0330 .0350 { 1. 2. } .0823 .0688 .0422 .0526 { 1. ... 5.} .121 .164 .0743 .112 { 1. ... 10. } .189 .347 .133 .222 { 1. ... 20. } .321 .803 .257 .479 { 1. ... 50. } .746 2.85 .642 1.52 { 1. ... 100. } 1.52 8.54 1.33 4.15 { 1. ... 200. } 3.32 28.7 2.88 12.9 { 1. ... 500. } 10.7 263. 8.69 66.0 { 1. ... 1000. } 29.5 ??? 22.1 243. { 1. ... 2000. } 91.6 ??? 62.6 ??? -- James > Is there any way to get values from the 49 table onto the stack for > use in other calculations? > You can use the command TABVAL for functions with only one variable. > Nick. > TABVAL seems to require that you are not in the table mode and that > you have a function and a list of arguments on the stack. Exactly. > What I would like is to be in table mode with the table displayed > and extract one of the table values to be on the stack when I exit > the table. Oh, I understand. This is possible in the matrix writer, where the menu command ->STK just copies the highligted value to the stack. But in table mode, I think this is not possible. > When you are in the table mode, with the table showing on screen, > can you activate TABVAL? No, you can't. Especially if you want a particular value of your function for a certain value of the independend variable. Only solution that I can think of, is to use TPAR to construct an array of values identical to teh table and then take it in the matrix writer and do all copying to the stack from there. But then you have no ZOOM. It is a bit silly that we have 25 environments, each of them with some functions only, but not even one *complete* environment that offers *all* possibilities available on the HP49G. So one must switch between table modes, and matrix writers and back and forth, until a simple task is completed. Anyway, Virgil, I think you should search for some software that does the job right. Did you take a look at www.hpcalc.org? Nick. Anyone have an Integration table...or could point me to one? Oh, and the verkion My HP49G has been transformed into a paperweight!! Everything I do to fix the problem won't work. I need assistance big time. Here's what happened.... I recently uploaded a game library file from hpcalc.org to my HP49G. I recalled it to the stack. It didn't come with any instruction so I stored it to port 2 (that was the mistake, I think) and attached it with ON-F3. My screen went blank and the hourglass blinked at me every 2 seconds or so. It won't respond to any keystrokes, unless I press ON-F3, at which time the blinking stops and the screen remains blank. As soon as I let go of the keys, the blinking returns. I went so far as to hit the reset button in the back of the calc. Upon turning on my calc, whether I try to recover memory or not (trust me, I've tried both a dozen times), the screen goes blank and the hourglass blinks at me. I even removed the batteries for 6 hours. That didn't work either. Same thing as above. Does anyone have any ideas as to how I might be able to restore my HP49G from it's paperweight status? - Ian > My HP49G has been transformed into a paperweight!! Everything I do to fix the > problem won't work. I need assistance big time. > Here's what happened.... > I recently uploaded a game library file from hpcalc.org to my HP49G. I recalled > it to the stack. It didn't come with any instruction so I stored it to port 2 > (that was the mistake, I think) and attached it with ON-F3. My screen went > blank and the hourglass blinked at me every 2 seconds or so. Isn't this in the FAQ ? Press ON-F3 and hold the backspace key when booting. > I even removed the batteries for 6 hours. That didn't work either. Same thing > as above. Flash is non-volatile. -Ian > Does anyone have any ideas as to how I might be able to restore my HP49G from > it's paperweight status? When you do the ON-F3, press the backspace key as the calculator is warmstarting; this should prevent any libraries from attaching. The timing of pressing backspace is tricky; if you don't get it right, then try ON-F4 to get the Tests screen, hold down backspace, and press Q. Then purge the offending library. -- James Does anyone know if conversions of this type are possible on the calculator? For example 2*e^(i*(2*pi)/8*t)+2*e^(-i*(2*pi)/8*t)+4*i*e^(i*(6*pi)/8*t) -4*i*e^(-i*(6*pi)/8*t) After using multiple identities is equivalent to 4*cos((pi/4)*t)-8*sin(((6*pi)/8)*t) If this cannot be done with built in functions is there a program that can do it? ANy help would be appreciated Rick RAD R Does anyone know if conversions of this type are possible on the > calculator? For example 2*e^(i*(2*pi)/8*t)+2*e^(-i*(2*pi)/8*t)+4*i*e^(i*(6*pi)/8*t) > -4*i*e^(-i*(6*pi)/8*t) After using multiple identities is equivalent to 4*cos((pi/4)*t)-8*sin(((6*pi)/8)*t) If this cannot be done with built in functions is there a program that > can do it? ANy help would be appreciated Rick hi i would need a prog which converts bitmaps to grobs for my hp49. which is a good prog and where can i get it? greetings max >hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max ;)))) > max This is easier to access : http://www.hpcalc.org/hp48/pc/misc/xnview.zip hs%V8.175$5i5.116332@news20.bellglobal.com... hl=fr&lr=&ie=UTF-8&safe=off&selm=3B1A14AD.56473E66%40student.tn.tudelft.nl&r > num=4 > 3d283818$0$19874$91cee783@newsreader02.highway.telekom.at... > hi i would need a prog which converts bitmaps to grobs for my hp49. > which is a good prog and where can i get it? greetings > max >hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max or does anyone have a grob showing the world map? thnxs max you could try www.hpcalc.org Raymond max_kuffs schrieb im Newsbeitrag hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max or does anyone have a grob showing the world map? thnxs > max i already searched there but i didn't found one. max >you could try www.hpcalc.org Raymond max_kuffs schrieb im Newsbeitrag hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max or does anyone have a grob showing the world map? thnxs > max How did you search ? In the input field 'search hpcalc.org' simply key in the two words BITMAP GROB. Be sure you have 'HP-48' checked. not for the 49G, but you can easily load them into your 49G;-) Raymond max_kuffs schrieb im Newsbeitrag > i already searched there but i didn't found one. max >you could try www.hpcalc.org Raymond max_kuffs schrieb im Newsbeitrag hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max or does anyone have a grob showing the world map? thnxs > max > or does anyone have a grob showing the world map? http://www.hpcalc.org/details.php?id=4143 http://www.hpcalc.org/details.php?id=4142 > i already searched there but i didn't found one. max >you could try www.hpcalc.org Raymond max_kuffs schrieb im Newsbeitrag hi i would need a prog which converts bitmaps to grobs for my hp49. >which is a good prog and where can i get it? greetings >max or does anyone have a grob showing the world map? thnxs > max is there anywhere a summary of all new commands from the hp49 max > is there anywhere a summary of all new commands from the hp49 See HP49G Commands and Menu Paths in http://www.hpcalc.org/hp49/docs/misc. It is updated recently. Kenji Yokohama, Japan By error I sent a version of spanglish with bug, that makes slower, the corrected version this in my Web: www.geocities.com/deachp/deachp.html I sent the corrected 49G version to www.hpcalc.com, but still they do not update it. Soon I will have a new version (2.8?) :-) -With Predictive and nonpredictive option. ;-) Does any one know of a program that allows my HP48GX to perform functions just as the Construction master pro caluculator http://www.calculated.com/products/4060.html?construction . I know the HP48GX can surely beat this product. If any one knows of one can you please reply. Roy aka Nick nak > Does any one know of a program that allows my HP48GX to perform functions > just as the Construction master pro caluculator > http://www.calculated.com/products/4060.html?construction . I know the > HP48GX can surely beat this product. If any one knows of one can you please > reply. > Roy aka Nick nak As always, first go to www.hpcalc.org -- Eric is the man! There is a lot of great stuff there (provided that you have a serial interface kit) but I doubt that you will find a single program that will have the whole suite of features found in the Construction Master Pro thing (which looks just like a TI with a different brand name). Also, get real comfy with the 48's use of units in both calculations and conversions, and the solver and multiple equation solver (MES) -- these are a really powerful features in this type of work. You could also have a lot fun programming (in UserRPL even) a number of handy little utility programs to handle your own particular needs--there are lots of ways to skin cats and we all have our own preferences. ( The HP 48G Series Advanced User's Reference Manual is a must have, if you can get it still). Greg S ( The HP 48G Series Advanced User's Reference Manual >is a must have, if you can get it still). Greg S Yah I got one last week from CALCPRO (www.calcpro.com) $29.95 I managed to dig up a Trig Table that someone posted on this newsgroup however, I don't know how to make it more readable. When I upload the program below, it just shows up on the stack as a bunch of text and I have to hit up and view to see it. Is there a way to have it fullscreen??? %%HP: T(3)A(R)F(.); TRIG IDENTITIES sin -a = -sin a sin a = 1/csc a sin^2 a + cos^2 a = 1 sin (a+b) = sin a cos b + cos a sin b sin (a-b) = sin a cos b - cos a sin b sin (PI/2 - b) = cos b sin 2a = 2 sin a cos a sin a/2 = +/- v/((1-cos a))/2 sin^2 a = (1-cos 2a)/2 cos -a = cos a cos a = 1/sec a cos 2a = cos^2 a - sin^2 a = 2 cos^2 a - 1 = 1 - 2 sin^2 a cos (PI/2 - b) = sin b cos (a + b) = cos a cos b - sin a sin b cos (a - b) = cos a cos b + sin a sin b cos 2a = cos^2 a - sin^2 a cos a/2 = +/-v/((1-cos a)/2) cos^2 a = 1 - sin^2 a = 1 - (1-cos 2a)/2 tan a = 1/cot a tan a = sin a / cos a tan 2a = 2tan a / 1 - tan^2 a 1 + tan^2 a = sec^2 a tan a/2 = v/((1-cos a)/(1+cos a)) tan (a + b) = (tan a + tan b)/ (1-tan a * tan b) cot a = cos a / sin a cot a = 1/tan a Please, only for Sony T.V.,,,, Looked in the manual(s), both in the index and contents... Wanting to know how to program/draw graphics objects (with text), and am also want to know if they can be combined with choose boxes. MC since i upgraded to rom 1.19-6 i can't compile any code. i don't know what's wrong. even short code makes problems like: CODE GOVLNG Loop ENDCODE @ gives an error back: invalid file. after executing er one error is is unknown construction (points to code) and another: { expected. i checked my flags and the masd flag is set to asm. i am learning assembler for the hp49 so i don't know whats wrong. changed the syntax? thnxs max > CODE > GOVLNG Loop > ENDCODE > @ > i checked my flags and the masd flag is set to asm. This is exactly what is wrong. It should be set to SysRPL or change the code to > GOVLNG Loop > @ -- This message was written with 100% recycled electrons Pivo