d-18 === Subject: Re: Wonderfull 41, 42, 71B emulators My page is active since Jan 28th and it does include a link to yours since then. I didn't mention this earlier because you'd think it was because you reply to Howard :-) However, if you notice a sudden increase in your emulators orders due to this, don't forget about me ! The hitometer was 109 hit the last time I saw. Ok, 99 out of these hits were due to myself, one from my brother, one from a cousin, three from friends... :-). (Too dumb hitometer, I have to find a better one) http://paginas.aol.com.br/gersonwbarbosa/index.html Now, seriously, after trying the 15C, the 49G and the 42S I have elected the latter as my everyday calculator, the one take to work everyday, not because it's better but because it has everything I need in the ideal form factor and size. If only it was possible to port the Voyager emulator to the 42S... Pehaps to a double speed 32K 42S... but too narrow a market for this I recognize... > BTW, you have my latest and free TI-57 emulator for HP-48/49 here: > http://retrocalculator.com/RPL/ I have it in my 49G since it became available. It would be nice I there were overlays available for your emulators, are there? Unlike the 49G, it is possible to place overlays on the 48, I am not sure whether this is possible on the 49G+ though. Gerson === Subject: Re: Wonderfull 41, 42, 71B emulators > If only it was possible to port the > Voyager emulator to the 42S... Pehaps to a double speed 32K 42S... but > too narrow a market for this I recognize... I can probably do this because they are written in machine language. The problem is how to (nicely) switch from HP-42S to the emulator (and vice versa) and how to protect the memory occupied by the emulator from being rewritten by HP-42S. Perhaps if it will be possible to make additional 64K ROM starting from #20000 and use XFCN to execute the emulator (or emulators: XFCN HP-11E for HP-11E, XFCN HP-12E for HP-12E, ...) === Subject: Re: Wonderfull 41, 42, 71B emulators Perhaps if it will be possible to make additional 64K ROM starting from > #20000 and use XFCN to execute the emulator (or emulators: XFCN HP-11E for > HP-11E, XFCN HP-12E for HP-12E, ...) I saw on your web site about incompatible opcodes on the 49g+, problem in DECIMAL mode etc... Have you checked any of the 2.01 and above ? all those problems got fixed. JY === Subject: Re: Wonderfull 41, 42, 71B emulators > Have you checked any of the 2.01 and above ? all those problems got fixed. I fixed those problems in 1.23 with a few workarounds so I don't want to change this in order to be able to run the emulators under the old OS. I checked 2.00, 2.01 ... and the only noticeable difference is that keyboard is not working on HP-42X - I had to fix this with another workaround - too many workarounds with standard Saturn machine code on HP-49G+. To be honest, I am not interested in HP-49G+ enough to dive into each new ROM version and try to find what incompatibilities are introduced this time (code which worked for years on HP-48GX and HP-49G suddenly stop working with particular ROM version for no obvious reason). === Subject: Re: Wonderfull 41, 42, 71B emulators > I fixed those problems in 1.23 with a few workarounds so I don't want to > change this in order to be able to run the emulators under the old OS. I understand > I checked 2.00, 2.01 ... and the only noticeable difference is that keyboard > is not working on HP-42X - I had to fix this with another workaround - too > many workarounds with standard Saturn machine code on HP-49G+. A pity, I'd love to check what could be wrong with the keyboard and your emulator. If the emulated saturn keyboard doesn't work with your emulator it means it wouldn't work for other software too and this should be fixed. The keyboard handling is entirely native since 2.0 , it isn't emulated anymore but the OS provides all the same APIs as the original HP49G, it keep up to date the OUT/IN register as well as the old 48/49 keyboard buffer. The only thing not emulated is the internal keystate table used internally by the interruptions to know which key was pressed previously. The reason for not emulated this is that it has changed between the 48g and the 49g and nobody should have ever used this keystate.. JY === Subject: Re: Wonderfull 41, 42, 71B emulators > The keyboard handling is entirely native since 2.0 , it isn't emulated > anymore but the OS provides all the same APIs as the original HP49G, it > keep up to date the OUT/IN register as well as the old 48/49 keyboard > buffer. I really don't know what went wrong with 2.0x but I suspect that in some cases keyboard interrupts aren't generated for some reason after waking up from the light sleep in SHUTDN instruction. It worked OK on HP-48GX, HP-49G and HP-49G+ with ROM 1.23. I tried to find the cause for this but without success :-( So, I had to make a workaround for HP-42X. Something like ... ... IFDEF HP49GP GOSUB SHUTDWN ELSE SHUTDN ENDIF ... ... IFDEF HP49GP SHUTDWN RSTK=C D1=(5) #4030F C=DAT1 1 CBIT=0 0 DAT1=C 1 SHUTDN C=DAT1 1 ?CBIT=1 0 GOYES + + C=RSTK RTNC GOVLNG #0000F ENDIF ... So, after SHUTDN, I am checking a bit which is set during the interrupt on HP-42S - if it is not set it means that interrupt hasn't been generated so I have to force a call to the interrupt handler ... it works for the usual keyboard scanning but unfortunatelly doesn't work for ON+ combinations. > If the emulated saturn keyboard doesn't work > with your emulator it means it wouldn't work for > other software too and this should be fixed. Yes, they are a good compatibility test. Please, contact me be mail so we can arrange something regarding the above subject (you can find my mail address on http://hrastprogrammer.tripod.com). === Subject: Re: Wonderfull 41, 42, 71B emulators > Perhaps if it will be possible to make additional 64K ROM starting from >> #20000 and use XFCN to execute the emulator (or emulators: XFCN HP-11E >> for >> HP-11E, XFCN HP-12E for HP-12E, ...) > I saw on your web site about incompatible opcodes on the 49g+, problem in > DECIMAL mode etc... > Have you checked any of the 2.01 and above ? all those problems got fixed. and probing ->KEYTIME and KEYTIME-> one could make the emulator keys behave better I think that perhaps - just perhaps Cyrille/HPQ could help HrastProgrammer a bit about the internals Also if (ok, BIG IF) HPQ-Hydrix would make yet another new calc maybe they could hire HrastProgrammer I think he is a good as Gerald in emulators Think about net-working sub-contraction etc just my 4 eurocents (inflation is getting worse) Fr.8fre-Pierre === Subject: Re: Wonderfull 41, 42, 71B emulators There's a survey company that has pages up describing a nifty overlay system for the 49g+ that they say they are planning to market: http://www.pssllc.com/products/overlay.php?s=2&p=3 . What they do is provide a *paper* underlay over which they place an adhesive-backed transparent mylar overlay. This pastes the paper template to the calculator. They claim you can reuse the overlay multiple times. This seems brilliant because the paper underlay would be really, really cheap to produce, compared to the same thing in mylar. I just hope this turns out not to be vapor. The same approach ought to be possible for the 48g as well. Overlays for Hrast's stuff would be great! Howard === Subject: Re: Wonderfull 41, 42, 71B emulators > There's a survey company that has pages up describing a nifty overlay > system for the 49g+ that they say they are planning to market: > http://www.pssllc.com/products/overlay.php?s=2&p=3 . > The same approach ought to be possible for the 48g as well. Overlays > for Hrast's stuff would be great! Hello Howard, ovelay stays in place. On the 48 there are six tiny slots for this. Is there something like this on the 49G+? Gerson. === Subject: Re: Wonderfull 41, 42, 71B emulators There's no picture of the overlay in action there, but there's a text description of how it's supposed to work. The idea is that it has adhesive on the side that faces the calculator. The paper underlay sticks to this, and the overlay sticks to the calculator on the portions that overlap the underlay. I can't see any reason why it wouldn't work, but I do have questions about the effectiveness of the bond versus the reusability of the system. Howard === Subject: Re: Programming questions > But it is turned off when the calculator is waiting for a key, as in the > Par Outer Loop. This is also the case for WaitForKey (which is > internally programmed with a ParOuterLoop). Yes, because the WaitForKey is a User POL. So the system does the default: Do TurnOffBusy DisplayScreen If WaitForKey Then TurnOnBusy , RunKey End While ExitCondition != 0 so again, if you want to turn the busy indicator on, simply turn it off. JY === Subject: Programming problem The problem is that the last calculation Ç 'T1*T2' ->NUM Iy= ->TAGÈ not work with the programm annunciator, but when I delete the << >> in this calculation it works, but why Here the full programm Don't be confused with the formulars. Ç CLEAR Stat.Werte I-Tr.8ager (in cm) { { Flb Flanschbreite } { Sh Stegh.9ahe } { t1 untere Flanschdicke } { t2 obere Flanschdicke } { s Stegdicke } } 2 { } { } INFORM IF THEN OBJ-> DROP Ù F H T1 T2 S Ç '(T1+T2)*F+S*H' ÙNUM Fl.8ache(cm2) ->TAG '(T2*F*T2/2+S*H*(T2+H/2)+T1*F*(T2+H+T1/2))/(F*(T1+T2)+H*S)' ÙNUM ys(cm)= ->TAG DUP -> YS Ç 'F*T2^3/12+F*T2*(YS-T2/2)^2+S*H^3/12+S*H*(YS-H/2-T2)^2+F*T1^3/12+F*T1*(T2+H- YS+T1/2)^2' 2 RND ÙNUM Iy(cm4)= ->TAG DUP -> IY Ç 'IY/YS' ->NUM Wyu(cm3)= ->TAG 'IY/(H+T1+T2-YS)' ->NUM Wyo(cm3)= ->TAG Ç 'T1*T2' ->NUM Iz= ->TAG È È È È ELSE Abbruch MSGBOX END È === Subject: Re: Programming problem The problem is that the last calculation Ç 'T1*T2' ->NUM Iy= ->TAGÈ not work with the programm annunciator, but when I delete the << >> in this calculation it works, but why using the << and >> 1) your main program is surrounded by << and >> 2a) in case you use local variables, the << is needed -> var << 2b) using algberaic/function structure the above could be -> var' 3) if you have the program delimiters without the -> var then the program is put on stack there is no need for extraprogram delimiters using EVAL will evaluate the stack << program >> H1) Hacking it's possible to remove << >> from a program using COMP-> DROP 2 - ->PRG H2) also note a list is almost like a program on stack but you can use PUT PUTI GET GETI POS SIZE SORT REPL SUB HEAD TAIL REVLIST LIST-> ->LIST OBJ-> ->ALG ->LST ->PRG COMP-> MAP AXL H3) after AXL you could also try some matrix manipulations ->ROW ROW-> ROW+ ROW- RSWP RCI RCIJ ARRY-> ->COL COL-> COL+ COL- CSWP DIAG-> ->DIAG and TRAN and ofcource vector is almost like list, but matrix is i, j indexed PUT PUTI GET GETI SIZE SUB REPL H4) algebraics algberaics are uinternally limited RPN programs you can use math, but not stack commands thus manipulating algraics is manipulating programs H5) ->STR converts your program to a string STR-> runs that program use can use any string manipulation including the new powerful SREPL Veli-Pekka PS: Read The Full Manuals === Subject: Re: Hash tables in UserRPL? Here's my very ugly and inefficient first try in User RPL. This will do to get me going in the application. I'll revisit it later to optimize for performance. This source code is copyright (C) 2006 by Howard Owen and released under the GPL V2. << DEPTH IF 2 < THEN 0 ELSE 1 END -> idx val sto << 'VALUES' IFERR RCL THEN { } SWAP STO { } END 'INDEX' IFERR RCL THEN { } SWAP STO { } END IF sto THEN idx + 'INDEX' STO val + 'VALUES' sto ELSE idx POS IF DUP THEN GET 1 ELSE DROP DROP 0 END END >> === Subject: Re: Hash tables in UserRPL? On Mon, 06 Feb 2006 11:29:21 -0600, Howard Owen posted a program which seems only to append each new index to list A, and each new value to list B, essentially just lengthening a dictionary, with elements stored in order of arrival. So where is the hashing? Real hashing usually involves something randomized on the basis of index content, and is most useful when there is unused space in a table, isn't that the case? For efficient storage and lookup without wasting any space, consider keeping the index items sorted, allowing a fairly fast subsequent binary lookup (although you'd have to accumulate a lot of data to make a UserRPL binary list search run faster than a built-in POS command). You can insert any new item into an already sorted list almost as quickly as you can do a binary lookup; see INSORT by Joe Horn on Goodies Disk 10 for a UserRPL program (all of Joe's Goodles Disks may be found at www.hpcalc.org). Another pretty efficient method for HP48/49 is to forget about lists, and instead devote a directory to the database; just store each value into an item having its index as its name; any string (limited only in length, to about 127 characters IIRC) can be made into a variable name using the HP49 S~N command or ->STR #5B15h SYSEVAL (this works on any HP48/49 ever made). If you need reverse lookups, you could use a second directory, or write a UserRPL search (easy to write, but not speedy), or devise a fast SysRPL/ML search (start with LastNonNull and use PrevNonNull to scan an entire directory very quickly). [r->] [OFF] === Subject: Re: Hash tables in UserRPL? I know this doesn't do hashing, John. It's a quick-and-very-dirty linear search lookup. I was hoping there was some preexisting hashing code I could stea^H^H^H^Hleverage off, but that apparently isn't the case. So I thought this kludge would get me through the prototyping of the main program, which is what I'm really interested in. I noticed that libraries had hash tables up front for their contents. I didn't think about directories, though. That may well be a workable compromise. I don't want to take the time to research a good hashing algorithm for my data set, but I will if I have to. The data isn't likely to grow very large, anyway. === Subject: Re: Hash tables in UserRPL? hello, how about this code: ADD @ takes a hash list on level 2 and 1 { object key } pair on level 1 << DUP 2 GET BYTES DROP #FF AND B->R 1 + PICK3 OVER GET ROT ADD + PUT >> NULLLIST @ generates an empty list << { { {} {} } } DUP + DUP + DUP + DUP + DUP + DUP + DUP + DUP + >> GET @ taks a list on level 2 and a key on level 1 << DUP BYTES DROP #FF AND B->R 1 + ROT SWAP GET OBJ-> DROP ROT POS IF DUP THEN GET 1 ELSE DROP2 0 END >> I will let you code the DELETE >I know this doesn't do hashing, John. It's a quick-and-very-dirty > linear search lookup. I was hoping there was some preexisting hashing > code I could stea^H^H^H^Hleverage off, but that apparently isn't the > case. So I thought this kludge would get me through the prototyping of > the main program, which is what I'm really interested in. > I noticed that libraries had hash tables up front for their contents. I > didn't think about directories, though. That may well be a workable > compromise. I don't want to take the time to research a good hashing > algorithm for my data set, but I will if I have to. The data isn't > likely to grow very large, anyway. === Subject: Re: Hash tables in UserRPL? BYTES, of course. (Slaps forehead.) Handy built in hash function! HASH @ Takes a string on level 1 and returns a hash between 1 and 256, inclusive << BYTES DROP #FFh AND B->R 1 + >> INS @ ADD won't parse. @ takes a hash list on level 2 and 1 { object key } pair on level 1 << DUP 2 GET HASH PICK3 OVER GET ROT ADD @ Removed an extra + here. PUT DELETE @ Takes a list on level 2 and a key on level 1. Deletes the value corresponding to key in the list. << HASH { {} {} } PUT >> Howard === Subject: Re: Hash tables in UserRPL? > Here's my very ugly and inefficient first try in User RPL. This will do > to get me going in the application. I'll revisit it later to optimize > for performance. > This source code is copyright (C) 2006 by Howard Owen and released > under the GPL V2. Nice try but the code you are using is used in many old constructions it's such a small sniplet that it can not be copyrighted Try a huge applications instead I have very old applications using the same approach I think you can find this kind of code in the old HP 28 libraries - phone number database? === Subject: Re: Hash tables in UserRPL? You seem not to understand copyright. Copyright does not cover the algorithm, or any ideas expressed in a writing. It covers the expression. In prose or poetry, that's the style or voice of the author. In software, it's also the style. So perhaps the choice of variable names, or order of the items. In other words, the way the ideas are expressed. All that means is you can't lift this code verbatim and use it in a manner contrary to the GPL. You are perfectly free to write your own code based on the ideas, or to note that the ideas were expressed similarly someplace else. But I'm perfectly free to assert a copyright on anything I write. If someone wanted to sue me, in order to succeed, they'd have to prove that the *expression* in this code is identical to that in someone else's *copyrighted* work. And for most purposes, they'd also have to prove that I knew about the earlier work and went ahead willfully violating their copyright in my work. It's easier just to ignore it, or comply with the license, no? Howard === Subject: Re: Hash tables in UserRPL? hello, however, what VPN pointed to is that this small portion of code might be seen as a derivative work from code created and copyrighted earlier by other persons, and that in this case, you should also pay attention to their copyright... it might also be that they have patents on the ideas that you are using, in which case, GPL or not, no-one can use this code without a proper licence from the patents holders. > You seem not to understand copyright. > Copyright does not cover the algorithm, or any ideas expressed in a > writing. It covers the expression. In prose or poetry, that's the > style or voice of the author. In software, it's also the style. So > perhaps the choice of variable names, or order of the items. In other > words, the way the ideas are expressed. > All that means is you can't lift this code verbatim and use it in a > manner contrary to the GPL. You are perfectly free to write your own > code based on the ideas, or to note that the ideas were expressed > similarly someplace else. But I'm perfectly free to assert a copyright > on anything I write. If someone wanted to sue me, in order to succeed, > they'd have to prove that the *expression* in this code is identical to > that in someone else's *copyrighted* work. And for most purposes, > they'd also have to prove that I knew about the earlier work and went > ahead willfully violating their copyright in my work. > It's easier just to ignore it, or comply with the license, no? > Howard === Subject: Re: Hash tables in UserRPL? With respect, that's not what he said. And yes, patents are a problem for anyone doing trivial programming and publishing the result. But among people of goodwill, and/or absent a compelling economic motive, it strikes me as easier *and* more polite to just respect the darned license! 8) Howard === Subject: Re: Broken key hinges HP 49g+, CN402122... one and two keys are wiggly, sometimes double-press === Subject: Re: Broken key hinges 1 and 2 are broken on mine. === Subject: Re: Broken key hinges ** Broken: Digit 0 Digit 1 Digit 2 Del Clear key Enter key ** A bit loose: Right Shift Function key 1 Function key 2 After your first broken key, you take more security using this device, is like: there is one broken, who cares now? === Subject: Re: Broken key hinges Did HP really redesign the keyboard? Do you have two of the earlier units? > Two units with probs in the Function keys -> couldnt be pressed down > Two units with the same probs -> '+' and 'Enter' > One unit with same probs -> '2' > One unit with broken key hinges -> 0' and ',' > Number 7 is alive !!! (One year of daily use) > CB === Subject: Re: 49G[+] Bug in ~Choose (ROMPTR B3 0) > There is another bug, but I don't know if it is related to the one you > explained, and I haven't reallay reproduced it. When using an input form > in order to display a choose list field, the items get truncated when > opening the choose list. Perhaps I'll have time to work on this bug > tomorow. More news about this one? Can you share code to reproduce it? -- Stefano Priore | Debian Sarge 3.1r0 --------------------------------+-------------------------------- Video meliora proboque, | Linux Registered User #210152 autem deteriora sequor... | Linux Registered Machine #97752 === Subject: Re: 49G[+] Bug in ~Choose (ROMPTR B3 0) Stefano Priore a Ì©crit : >> There is another bug > More news about this one? Can you share code to reproduce it? The bug is a simple one. Just create an Input Form with a choose list field. In this choose list, just put an item which string is too long (e.g. 20 chars). Provided your flag -90 is set (use mini font for choose lists), when you press [CHOOS] in order to open the choose list, strings are truncated to 15 (or 14, i can't remember) chars. Here is a proof of concept, to be compiled with MASD (with extable, of course): :: * I am using ROM 1.19-6 on HP49G 90 SetSysFlag ( Use mini font for CHOOSE lists ) * The only label of the InputForm Label: 2 32 * The only field of the InputForm 'DROPFALSE 31 30 97 9 TWELVE MINUSONE SEVENTEEN HELP { { 12345678901234567890 ZERO } } SEVENTEEN OVER CARCOMP DUP ( Reset and Init values ) * 1 1 'DROPFALSE TITLE DoInputForm * * Now, press [CHOOS] and see how the text get truncated, but shouldn't * ; @ === Subject: Re: 49G[+] Bug in ~Choose (ROMPTR B3 0) > Stefano Priore a Ì©crit : >>> There is another bug >> More news about this one? Can you share code to reproduce it? -- Stefano Priore | Debian Sarge 3.1r0 --------------------------------+-------------------------------- Video meliora proboque, | Linux Registered User #210152 autem deteriora sequor... | Linux Registered Machine #97752 === Subject: Re: Outside of calculator after a year of use > I use hardly my calculator for more than a year, about 15 months and > golden paint goes over, etc... see this photos to see how will look > your chinese calc soon: > http://erwin.ried.cl/?modo=visor&elemento=200 These photos should be sent to HP!! Along with them, should be photos of a well-used ten-year-old 48GX that, by nature of excellent manufacturing techniques and materials, show none of these problems. No other way to say it: This is shameful. Matt === Subject: Re: Outside of calculator after a year of use I bought one a week ago. So mine is still goldy. I was woundering if someone know a product to protect the painting. like a spray or something... === Subject: Re: Outside of calculator after a year of use Has anyone tried to remove all the gold paint to see how the calculator looks? It could be neat, except you'd lose all the printed functions. === Subject: Re: Outside of calculator after a year of use dfert ha escrito: > Has anyone tried to remove all the gold paint to see how the calculator > looks? It could be neat, except you'd lose all the printed functions. Mine has losed some of printed functions, by the way the keys protects the functions between themselves, but i have at least 5 breaken keys, but all still there, losen but there :S