HP-169 Subject: conn4x syntax error list transfer to 49g+ I am trying to transfer a list with conn4x xmodem to hp49g+ from pc, it is of type: %%HP: T(3)A(R)F(.); {text1 grob w h 0x0x0x... text1 grob w h 0x0x0x... text1 grob w h 0x0x0x... } it gives syntax error with long strings (>1000 chars) either binary or text transfer. is there a limit on string length within a list ? I am sending only characters in ascii 40-126 range how to find offending character if any ? thank you === Subject: Re: conn4x syntax error list transfer to 49g+ > I am trying to transfer a list with conn4x xmodem to hp49g+ from pc, > it is of type: > %%HP: T(3)A(R)F(.); > {text1 grob w h 0x0x0x... > text1 grob w h 0x0x0x... > text1 grob w h 0x0x0x... > it gives syntax error with long strings (>1000 chars) > either binary or text transfer. Verify that it's really a problem only with long strings. Try editing a copy of the file to make each string in the list small (or entirely remove the strings), and see if that helps. With that transfer header (and file formatting), you should be doing a text transfer. Maybe check for missing (or extra) delimiters? I hope that your delimiter for a graphics object is really GROB instead of grob. Check that you really do have separators (typically, space or newline) between GROB, w, h, and the pixel data in each grob. Check that the pixel data contains only hex digits. Check that the pixel data in each grob isn't too long for the grob dimensions. The number of hex digits should be the width divided by 4, rounded up to an even integer, and that quantity multiplied by the height. I think that too few digits of pixel data will automatically be zero padded to match the dimensions, but too many digits cause a Invalid Syntax error. > is there a limit on string length within a list ? No, except for the general limit imposed by available memory. Note that for text downloads, there has to be enough memory for both the original download string and the object compiled from it. The Conn4x help file says: Memory Limitations on the Calculator (Failures to download) The calculator will need enough memory to contain the text string and the final object. A syntax error will result if the calculator runs out of memory during the download operation. In general, search the Conn4x help file. Is anything left on the stack after you try your download? > I am sending only characters in ascii 40-126 range > how to find offending character if any ? Maybe add the line: C$ $ between the %%HP: T(3)A(R)F(.); header and the rest of the body, so it becomes a string, download it, then do EDIT, edit out the delimiters at the beginning and end, and press ENTER. With any luck, the highlight from the Invalid Syntax error will be more informative. If it's a problem with not enough memory, you could try holding down leftshift while pressing MODE, then press MISC, then press STK, ARG, and CMD to disable the various last saves. Of course, it's best to re-enable them as soon as the problem is solved. Maybe move various objects out of user memory (HOME and its subdirectories and port 0) to make more memory available. In case all else fails, do you have an SD card and reader? === Subject: Re: conn4x syntax error list transfer to 49g+ I was getting syntax errors due to excessive file length, seems to me empirically that about 125kb of pc text is the limit for a list of strings and grobs, which translates to a compiled list of about half that (1 char== nibble on hp ?) is there any way to compile a list object _outside_ the hp ? thank you M. Prange ha scritto nel messaggio > I am trying to transfer a list with conn4x xmodem to hp49g+ from pc, > it is of type: > %%HP: T(3)A(R)F(.); > {text1 grob w h 0x0x0x... > text1 grob w h 0x0x0x... > text1 grob w h 0x0x0x... > } > it gives syntax error with long strings (>1000 chars) > either binary or text transfer. > Verify that it's really a problem only with long strings. Try > editing a copy of the file to make each string in the list small > (or entirely remove the strings), and see if that helps. > With that transfer header (and file formatting), you should be > doing a text transfer. > Maybe check for missing (or extra) delimiters? > I hope that your delimiter for a graphics object is really GROB > instead of grob. Check that you really do have separators > (typically, space or newline) between GROB, w, h, and the pixel > data in each grob. Check that the pixel data contains only hex > digits. Check that the pixel data in each grob isn't too long for > the grob dimensions. The number of hex digits should be the width > divided by 4, rounded up to an even integer, and that quantity > multiplied by the height. I think that too few digits of pixel > data will automatically be zero padded to match the dimensions, > but too many digits cause a Invalid Syntax error. > is there a limit on string length within a list ? > No, except for the general limit imposed by available memory. Note > that for text downloads, there has to be enough memory for both > the original download string and the object compiled from it. The > Conn4x help file says: > Memory Limitations on the Calculator (Failures to download) > The calculator will need enough memory to contain the text > string and the final object. A syntax error will result if > the calculator runs out of memory during the download > operation. > In general, search the Conn4x help file. > Is anything left on the stack after you try your download? > I am sending only characters in ascii 40-126 range > how to find offending character if any ? > Maybe add the line: > C$ $ > between the %%HP: T(3)A(R)F(.); header and the rest of the body, > so it becomes a string, download it, then do EDIT, edit out the > delimiters at the beginning and end, and press ENTER. With any > luck, the highlight from the Invalid Syntax error will be more > informative. > If it's a problem with not enough memory, you could try holding > down leftshift while pressing MODE, then press MISC, then press > STK, ARG, and CMD to disable the various last saves. Of course, > it's best to re-enable them as soon as the problem is solved. > Maybe move various objects out of user memory (HOME and its > subdirectories and port 0) to make more memory available. > In case all else fails, do you have an SD card and reader? > thank you > You're welcome. === Subject: 48GX Repair My 48GX has been damaged :( A little aluminum LED flash light fell about 3 inches onto the display, now there is a tiny crack. The LCD display has started to bleed a little, I suspect it will keep getting worse till it is unusable. Is there any way to get a good deal on a replacement screen, or should I just get a new 48GX ebay? Other than the LCD crack the only blemish is a scratch in the paint above the screen. -- Chris W Bring Back the HP 15C http://hp15c.org Not getting the gifts you want? The Wish Zone can help. http://thewishzone.com === Subject: Re: 48GX Repair > My 48GX has been damaged :( A little aluminum LED flash light fell about > 3 inches onto the display, now there is a tiny crack. The LCD display > has started to bleed a little, I suspect it will keep getting worse till > it is unusable. Is there any way to get a good deal on a replacement > screen, or should I just get a new 48GX ebay? Other than the LCD crack > the only blemish is a scratch in the paint above the screen. Go here, they fix all kinds of HP calculators http://www.fixthatcalc.com/ Craig === Subject: Re: HP49G+ informations > Well, I would knowit someone here is a little bit interrested by what I'm > doing, because I have no answers but a hundred visits. I think it is > spambots... :(( > well, i'll continue updating my page. Hope it's useful... Yes we are listening! Keep going! Great work! === Subject: Russia transverse mercator parameters Hi Can anyone tell me the transverse mercator parameters for Russia. I am using the Pulkovo 1942, Russia datum (ellipsoid Krassovsky). What I need are the following: scalefactor longitude of central meridian latitude of projection origin false easting false northing Thanx === Subject: Russia transverse mercator parameters Hi Can anyone tell me the transverse mercator parameters for Russia. I am using the Pulkovo 1942, Russia datum (ellipsoid Krassovsky). What I need are the following: scalefactor longitude of central meridian latitude of projection origin false easting false northing Thanx === Subject: Re: Russia transverse mercator parameters First off: Why comp.sys.hp48? Which zone? I found about 30 for Russia using Pulkovo datum and Krassovsky ellipsoid, each having 2 variations using Gauss-Kruger base projection. > Can anyone tell me the transverse mercator parameters for Russia. I am > using the Pulkovo 1942, Russia datum (ellipsoid Krassovsky). What I > need are the following: > scalefactor most likely 1 > longitude of central meridian depends on zone > latitude of projection origin my hunch is that it is 0 > false easting depends on zone > false northing most likely 0 for all zones === Subject: Re: Russia transverse mercator parameters You're probably best to post this sort of request to one of the following newsgroups, (they're bound to be very helpful). While I've done some work recently with projection-conversions, it would be faster sci.geo.satellite-nav sci.geo.geology sci.geo.cartography Just some errata that comes to mind: false Northing: 0 (in Northern Hemisphere), 10000000 (in Southern Hemisphere) false Easting: 0 (in Northern Hemisphere), 500000 (in Southern Hemisphere) Central Merridian: this will be the mid-point of the Zone your point happens to be in (each zone is 6 degrees wide). Being that your in the Northern Hemisphere, the latitude origin is 0. You'll have to look up the scale factor (or ask someone else who knows off-hand what it is for your particular datum). Please do not take what I've said as entirely correct - you should double check the details I've provided, as I'm quoting from memory (particularly, I have doubts over the quoted fasle E,N I've given for the Northern Hemisphere). -- Manfred (mathmcn@hotmail.dev.null.com) ^^^^^^^^ > Hi > Can anyone tell me the transverse mercator parameters for Russia. I am > using the Pulkovo 1942, Russia datum (ellipsoid Krassovsky). What I > need are the following: > scalefactor > longitude of central meridian > latitude of projection origin > false easting > false northing > Thanx === Subject: Re: Russia transverse mercator parameters > Hi yuk@mapsuae.com, hi all: While I've > done some work recently with projection-conversions, Manfred, I am working on Land Surveyors Data Collector, and I would be very appreciative if you could contact me via my e-mail address. It sounds like I (and hopefully you) could benifit greatly from your talents. I desire to generate a table for all 50 US states to convert back and forth between Lat and Long (NAD83), and State Plane Coordinate Systems. The creation of a hp format, Geoid Model interpolation program is another item.... I was just thinking that this might be an area of expertise of yours? John Evers === Subject: Re: Russia transverse mercator parameters Hi yuk@mapsuae.com, hi all: Please see some further addenda below... > Hi yuk@mapsuae.com, hi all: > You're probably best to post this sort of request to one of the > following newsgroups, (they're bound to be very helpful). While I've > done some work recently with projection-conversions, it would be faster > below. > sci.geo.satellite-nav > sci.geo.geology > sci.geo.cartography > Just some errata that comes to mind: > false Northing: 0 (in Northern Hemisphere), 10000000 (in Southern > Hemisphere) (in meters) > false Easting: 0 (in Northern Hemisphere), 500000 (in Southern Hemisphere) (in meters) > Central Merridian: this will be the mid-point of the Zone your point > happens to be in (each zone is 6 degrees wide). Read that as 6 degrees wide at the equator > Being that your in the Northern Hemisphere, the latitude origin is 0. > You'll have to look up the scale factor (or ask someone else who knows > off-hand what it is for your particular datum). > Please do not take what I've said as entirely correct - you should > double check the details I've provided, as I'm quoting from memory > (particularly, I have doubts over the quoted fasle E,N I've given for > the Northern Hemisphere). -- Manfred (mathmcn@hotmail.dev.null.com) ^^^^^^^^ === === Subject: Re: Why the French guyz rule the HP scene? > agree inappropriate in this forum X > symbiosis. Algebra is an Arabic word. X Nuke them! === Subject: Re: Why the French guyz rule the HP scene? > France will soon have to deal with its anti-Semitism and Muslim ghettos ( a > term which comes from Venice, Italy not America), and I suspspect it will be > violent. You seem to be an educated guy. So I invite you to come to France and see those ghettos. If you ever find one, I will pay you some pretty good wine or whatever French thing you may want. Just in case you wanna know, yes we seem to have a problem with anti-semitism, but we do not practice communatirism as English and American do. I am still shocked by that French guy who came back from NY and said Yes, communatirism is the way to go. Well that is the most direct way to ghetto. And I am not the kind of guy who says French guys rule, that's just a dumb statement. Erf, I have to say HP here just to be slightly on topic. Laurent === Subject: Re: HP49G+ Dumping memory yes of course: http://lebonpoint.chez.tiscali.fr/hp49gp/ > So... would you care to share? > GP === Subject: Re: Saturn CODE > OK i got it > I understand this are like basics so... > for everyone who is just learning or (refreshing memory of Saturn assembly) > i was properly storing PTRs in my code > GOSBVL =SAVPTR > but then on finish i called > GOSBVL =GETPTR > i was wondering wy doesn't it continue RPL-ing (calc gets stuck) > then i remembered and found out about: > GOSBVL =GETPTRLOOP > which does exactly what i needed > (restores saved pointers and continues RPL :-) Get yourself a HP48GX with a 128kb memory card and install jazz :-) If you use jazz you can disassemble entries such as =GETPTR and see for yourself exactly what they do. P.S. Emu48 will do if you're poor ;-) -- Daniel === Subject: Re: Saturn CODE > What can you say about following code: > :: > #5000 Blank$ > CODE > ENDCODE I'm not an expert but i thing that CODE ENDCODE are SysRPL marks. They tell the SysRPL interpreted that there is an ml object of that size. The OS then takes the addrees of the begining of the code object, add 10 nibbles (header and size field) and pass the control to the saturn CPU (of course un the G+ it's the emulator). So it should find ml code there but in your code it has the ENDCODE which really it's a 0 size to it will find the SEMI (;) but it will interprete it as ML code so become mad. The smaller code object which doesnt crash the CALC I think will be: CODE LOOP ENDCODE Hope this helps ath: nntpswitch.com === Subject: HP wins battle but looses war So I've been following the revival of HP calculator models, since I was planning on needing one right about now. A year ago, Staples around Boston had a selection of HP Scientific calculators which I could walk in and buy. Then HP announced a new series of calculators, an upgraded 48, etc. So I go back to Staples to pick one up, or maybe even see if I can get a discounted 48, and, alas, they carry no HP calculators except for 2 financial calculators. Even the stock of Casio calculators seems to have dwindled and they seem to have some exclusive deal with TI, because that is the only brand of scientific calculator I can find. So, it seems that at least in Massachusetts, if I want an HP calculator I'm going to have to order one online. Any thoughts? Erik === Subject: Re: HP wins battle but looses war I had the same experience recently trying to buy a new HP calculator as well. It seems all the stores in Northern Virginia (Walmart, Staples, Office Depot, Sears, Circuit City, Micro-Center, K-Mart, Best Buy, Target, etc) don't really stock HP calculators anymore, especially when I was looking for the new HP-33S. The only HP calculator I located in a few of the stores was the HP-10B and the older HP-12C. I needed to buy from HP online directly for the HP-33S, or in the recent past I had some luck buying HP calculators (HP-49G, HP-49G+, HP-48GX) from Fry's electronics at www.outpost.com. >So I've been following the revival of HP calculator models, since I was >planning on needing one right about now. >A year ago, Staples around Boston had a selection of HP Scientific >calculators which I could walk in and buy. >Then HP announced a new series of calculators, an upgraded 48, etc. >So I go back to Staples to pick one up, or maybe even see if I can get a >discounted 48, and, alas, they carry no HP calculators except for 2 >financial calculators. Even the stock of Casio calculators seems to have >dwindled and they seem to have some exclusive deal with TI, because that is >the only brand of scientific calculator I can find. >So, it seems that at least in Massachusetts, if I want an HP calculator I'm >going to have to order one online. >Any thoughts? >Erik === Subject: Re: HP wins battle but looses war > So I've been following the revival of HP calculator models, since I was > planning on needing one right about now. > A year ago, Staples around Boston had a selection of HP Scientific > calculators which I could walk in and buy. > Then HP announced a new series of calculators, an upgraded 48, etc. > So I go back to Staples to pick one up, or maybe even see if I can get a > discounted 48, and, alas, they carry no HP calculators except for 2 > financial calculators. Even the stock of Casio calculators seems to have > dwindled and they seem to have some exclusive deal with TI, because that is > the only brand of scientific calculator I can find. > So, it seems that at least in Massachusetts, if I want an HP calculator I'm > going to have to order one online. > Any thoughts? > Erik Erik, Here are my thoughts. Don't begin (almost all of) your sentences with so. Learn the difference between loose and lose. Bob === Subject: Re: HP49g+ - NUM.SLV>Solve linear System - Bug or...? Exactly. This bug has to be resolved. The workaround mentioned by Pascal and others is valid but some indeep knowledge of the calc's internal behaviour is needed in orther to circumvein the bug. If the EDIT takes care of the matrix so should the CHOOSE command for NUM.SOLV. >> It's not a bug - it's more a malfunction of some synapses in the users >> brain ;-) > It is a bug alright. >> The solver is not able to convert matrices containing real and integer >> values... > It should be able to. At the very least it shouldn't result in a TTRM. > === Subject: I/O Hello ! Can't find you on IRC anymore, probably cause of that so *stupid* exam we in France call baccalaur.8eat. space ; the Samsung manual says that these registers begins at 0x40000000. ARM920T manual seems to indicate that virtual adressing (adress translation) is possible, I suppose I/O adresses to be remapped ; I did'nt have the time to read more closely, but just I see CP15 register access in the disassembled code... We only lacks these informations, isn't it ? If somebody discover something on I/O, it would be great to post ;)) ++ J.8er.8emy HERVE PS: What about bringing coffee and computer, and spending some hours reversing ? :p === Subject: Re: I/O Yups ; Was a reply for HP informations from Mwyann but didn't appear where I wanted :/ Please 'scuse :p === Subject: Re: SPLIT challenge > -to write a standard SPLIT comand Something like this?: It could be refined a bit, for example will ABCD88EFGH88IJK 8 result in ABCD EFGH IJK While ABCD88EFGH88IJK 88 of course will yield ABCD EFGH IJK Depending on application the former may be unwanted (and fortunately very easy to change). === Subject: Re: SPLIT challenge > i'll be happy to look at your work maybe something creative comes out of > this :) I have it working for the first occurrence of the findstring, but that was easy. Now comes the loop that will advance the #start and parse the searchstring again. In the first version I used stack operations, but it soon became to see what's going on. Bill