A12 Tableaux de Chimie A different style of periodic table. You have a program that displays a grob of the periodic table (with scrolling; nice if a bit cluttered). To examine individual elements you have to run another program, give it the Column and Period of the element, and then get a little information. Here's the display for column 1, period 1: (1/1) H Hydrogene Z:1 M:1.008 There's another program, REDOX, that shows a grob of a table. I confess that my chemical knowledge (I'm in HS Chem 2) isn't enough for whatever this is. There's another program that takes input related to it, though. There are two other programs, OFF and QUIT. QUIT returns you to your previous menu and I'm totally mystified as to why OFF would be here. Lothar This is advertised as an all-SysRPL periodic table. I'm not sure what the particular benefit of that is =) Lothar shows the entire period table with a grob apparently built on-the-fly. This grob lets you see everything, but doesn't show the names of the elements. You can scroll through it (with noticeable but not horrible slowness) to see a little information about the highlighted element -- and here's a display: 1 H Hydrogen IA Non-Metal Gas This is shown to the right of the periodic table. It's all very pretty, and for the experienced not seeing all the element symbols isn't a problem. Lothar has a function to go to an element based on symbol, too. Pressing enter on an element gives you (again with a little more delay than other periodic tables) lots of information about it, apparently using the built-in SCROLL command. You can push information onto the stack, and there is a seperate program (GetP) to get information from the table without actually navigating it. Always a nice thing to have. One thing I particularly like about Lothar is that it is, at least in theory, very easily extendable. If you open the library you see that all the data is right there, the tables are simple, the grob is absent, so assumed generated. A little later I'm going to add a few (perhaps imaginary) elements to the table to test how easy this is. It is certainly a simple matter to fix or change information, or change the language used (like Hydrogene instead of Hydrogen). -- So, of all the periodic tables I've looked at so far, I like Lothar the best. It could be a little faster. It could use a molar mass calculator (there are lots of these, and most of them packaged with a specific periodic table and using that table's database), but ==== ==== Don't say bombs out because this is exactly the opposite. It prevents bombing by trapping the error condition. (Bomb would be a warm start). My HP49 just solves this fine and finds P=1E12. If you already have a variable with some value (perhaps a complex one) then this will be used to evaluate P-R^(-N), which in case it gives a ==== OK. I do everything on-calc, except occasionally print out or read on a computer some documentation. I do this for comfort and economy, since it is, for me, both difficult and time-taking to access a computer that is both connected to the internet and available for me to connect to my calculator. Most documentation I either page through briefly, or print out if it looks particularly important. This means that I sometimes don't learn some very interesting things (for instance, I just now learned how to set up doubleclick actions with Keyman, a library I've had for maybe a month now). It also means sometimes that I have great difficult with certain command-heavy libraries (like Mawk), since I don't know what a given command does, don't have an easy reference, etc. Sometimes I have (again, like Mawk) a printout of the documentation handy, but these aren't quite as portable or convenient as the calculator itself. Following this trade of thought myself, I've started writing on-line documentation, to peruse on my calculator. This is easy. First you set flag -91, then you use the matrix editor it a title string, and then make a CHOOSE out of it. Pass the result to SCROLL. Isn't that nice? It's a little tedious for libraries like Mawk, but most should be no trouble. Scan the documentation for relevant pieces of information and then find some way to format this information << Mawk commands {{ADJ NOVAL} {CPR NOVAL} ...} (Those NOVALs are me starting at the end and taking a while to work my way though. Incidentally, for Mawk commands I use MENU instead of ==== ==== ==== ==== I disagree. It would be a significant improvement to have multitasking if you pick the right scheduling algorithm. The fact of the matter is that almost any computing device you use is *doing nothing* 90% of the time because it is waiting for the slow user. Unix type multilevel feedback queue algorithms can take advantage of this and give good responsiveness even if the system is heavily loaded. This is true if you include the stipulation that it only works for assembly programs and furthermore those assembly programs must conform to a strict api. While it is *theoretically* possible to do this with RPL programs it would require a major reworking of many parts of the OS. Anything that could cause race conditions (such as the memory management system) would have to rewritten or else the scheduler would have to check if the saved PC was in a critical section of code and block any other process that tried to access it concurrently. ==== Well you certainly got my attention. :) If anyone wants to know, yes George, Pagala, and I were originally involved in a project to wright a modular/microkernel multitasking OS for the 48 (and eventually everything else since it was supposed to be modular). It was going to jump to the next level where other OS's (such as ShellOS) had left off. But, alas, the fact that the burden of writing most of the core of the OS was placed on me and the change of my ambitions really kind of killed it before it had a chance to take its first breath. Originally, I was interested in writing a totally new OS for the pure pleasure of innovation or its aesthetic value but eventually it dawned on me that this would just turn out as yet another niche system that, while elegant, would fade into oblivion because of the lack of applications and support. ( If I could name every example of this it would fill a few pages :) What I'm interested in now is improving the built in 48/49 RPL OS. Yes, although you might think the 49 OS is optimized to the limit, the core has changed very little since the 48 (even SX). There is a lot of room for improvement that could potentially result in dramatic speed increases. One example of this would be a rewrite of the garbage collector and memory management system which, contrary to popular belief, would not necessitate a total rewrite of the rest of the OS. In fact, you could maintain backward compatibility for the most part. Even more surprising is that you could accomplish this without burning a new rom chip! :D (although on the 48(GX) you would need a ram card in port 1). This is just one of the many changes that I've had in mind. I have all the information I need to implement this now although with the recent announce of the possible GPL of the 48G/49 source code it would make it that much easier. :) Now, I'm not making any promises (lest I be accused of vaporware ;) but if it advances to the point where it is presentable then we/I plan on releasing everything under GPL so that the development can advance much more rapidly. As George said if anyone is interested in helping please contact him or I. ==== On 4 Nov 2001 04:35:20 -0800, Lz8B@free.fr (Stephane Cocquereaumont) Indeed I have been contemplating this idea for quite some time. Contrary to popular belief, it is actually possible to *emulate* the whole calc on a card ( running on an SA-110 say ) and interface with the internal Yorke peripherals while keeping the Saturn in low power mode most of the time. ==== ==== Now that ACO is dead, I think it's appropriate to evaluate somehow what ACO has accomplished. Obviously, I do not intend to write a complete report - just to mention some points and, hopefully, start some constructive discussion. OK, let's start at the beginning. The following paragraph is an excerpt of the 1997 HHUC Conference Report, included in the Nov/Dec 1997 issue of Datafile, written by Wlodek Mier-Jedrzejowicz: Chris [Wallin, head of the new HP calculator operation] spoke with great enthusiasm about the past history of HP calculators, the many waves of innovation brought to calculators by them, and the occasional less successful product. [...] Calculators have been left to one side lately, and HP Australia wanted to take over, because of Australia's culture of innovation. He mentioned various technical innovations to come from Australia [...] and suggested that this gave his team in a special advantage in designing a new range of HP calculators while retaining their high quality. I think that at this point Chris lost some sympathy among some listeners - he seemed to be suggesting that the successful calculator team at Corvallis had somehow lost the ability to innovate - whereas we all know that the team has actually been the victim of changes and lack of interest by senior management. Nevertheless, his statement that HP will continue to design and produce innovative calculators earned him a cheer. Which innovations have been made? Aside from the excellent metakernel and the CAS, I'm afraid that... Flash ROM definitely couldn't be considered state of the art, and the successful HP6S is anything but innovative - Can you believe that under NORMAL light conditions one cannot see the shifted key labels on the blue model? The 39G/40G are nice rebuildings of the wonderful HP38G - a true innovative model! I think that the 30S doesn't deserve much comment, and about the new HP10BII, well, fortunately the rubber hasn't been placed on the keys! As well as Xpander, I know that there were many more projects that were cancelled for different reasons. It would be enlightening to know more about them. What went so wrong? Did you know that some members of the Corvallis team are still working on handhelds ... for TI!!!? I'm sure many of them would be delighted to make the goose fly backwards again. Like Jake and Elwood rejoining the band :-) Just my two cents. Bye. - [blah blah snipped] Unfortunately, you talk with very few element of what has been done. The fact is, very little information has been released. ACO hasn't been closed due to performance, or lack of profit. But before I go into details, let see about what HP-ACO has achieved over the past 4 years: I will not talk about consolidating distribution channels, selling HP calculator in countries where it was not available before, creating education material etc... No, just pure hardware work Let's hope I won't get into trouble for this. But I honnestly don't care anymore. In order of appearance, some of them may have been released in the same amount of time: 1)HP48G+ 2)Morgan, project cancelled never released 3)HP12C, total redesign of the internals and CPU. A huge work, shit load of money 4)HP17BII, HP19BII: Internal redisgn (due to component obsolescence) 5)Total redisgn of the IR printer due to obsolescence of components 6)HP49G 7)Firmware Datalogger (financed by HP, hardware produced by HP) 8)HP6S 9)HP39G, HP40G 10)HP10BII 11)HP30S 12)Xpander: project cancelled, one month before released as big HP bosses decided that HP would NOT go into education anymore. Xpander was not just a calculator, it was a total new concept of educational tools. Huge disappointment within ACO. Really nice device, a complete PDA for young people. Supposed to be released in two weeks time. Didn't get the chance for it. But the product is almost finished. Hopefully it will be distributed one day Other PDA: Carbine, based on the same architecture as Calypso (software, hardware) but it's a very tiny PDA, looks like a mobile phone. It's the best looking PDA I've ever seen in my life, and the screen supposed to be used was fantastic. Tiny, light, powerful, long battery life Other than these projects (all cancelled) ACO investigated how we could go into wireless, so I worked with many others for the past year on developping a GPRS/GSM/EDGE plateform, result: the world first embedded single-chip (not people were making comment on why I was the author of the port of a C The project one more time was cancelled and the prototype was working.. So the result is? Sure, few has been released. ACO's fault ? Don't think so. In this division, I've seen some of the most talented people in my life. I've worked in various companies, but I had never seen such a level of competencies. ACO was profitable, and in fact, could finance itself just with the calculators sale (and it's not a small profit, ACO by itself would be a multi-million dollars company). Why did they close down ACO then ? that's a good question. But management the week before said: we had to cut our workforce by 4%. It's more popular I guess to get rid of a small division, in a country far far away, a long time ago (oops that's Star Wars), than in the US ACO is a small division in HP organisation, and doesn't really fit into Carly's model where you have to be either first, or close second. Three words: profit, profit, profit. But don't worry, HP will continue to sell calculators. The one redesigned not so long ago. What about graphicals ? Well, there are stocks. Unfortunately, the Saturn is becoming obsolete this year, and nothing has been done to redisgn it, the bet was on Xpander. And redesigning a custom CPU cost over 1/2 million, too much in a market where short term profit is the key (even if analysis shows that big profit would have been made after one year only) As Forrest Gump would say: And that's all I have to say If now somebody ask me if I'm sad for not working for HP anymore? No, and the fact is : I'm relieved. The only problem is: it's not HP, HP is a great company with great product. Unfortunately, it's the way the world goes. Pt marketing people at the head of the most brilliant companies and see what happen: Q: What is this division doing? A: the sell the product X Q: Do they make profit ? A: Sure, they own 85% of the market Q: Are they growing over 16% to make our share-olders happy ? A: Sure they do for at least 2 years Q: What is this division doing? A: The do R&D and work on a replacement of product X. Q: Do they make profit ? A: Uh? No, it's a R&D facilities Q: Sure... So they don't make profit ? A: no Q: Well, our figures show that we could save $500 millions by reducing our workforce by 7000 people. We also need to increase our growth otherwise the share price will drop. Our CEO also needs to keep flying on his/her private plane with the private hairdresser. Let's close this department A: But what about in the future ? What will we sell? Q: Well, make sure you buy a lot of stock now, sell it next year. You won't have to work after that, so why care about the future of the company ? terms: customer orientation, which is an euphemism for shareholder orientation, shareholder meaning someone who buys some stock and wants to sell it with profit in a short time, nothing similar to the traditional long-term shareholder who had more or less relation with the company. The CEO of RedHat said it; with the .com madness, many of their shareholders only knew the NASDAQ symbol of the company; they even didn't know the complete name. Anyway, I think many companies going into this nonsense will sooner or later regret. I see that HP wants to go to a market which can offer high short-term profits (PCs) but in which you just have little possibilities of keeping some leadership. HP already abandoned instrumentation, a field in which they were one of the leaders, and with an enormous barrier for any newcomer. Moreover, I don't think there may be a drop in the demand for biomedical instrumentation. However, PCs are more powerful with time. Is there a limit? When will users get as much power as they think they need? A new PC can perform huge tasks, such as encoding a movie in DivX, etc. If the power multiplies by 10, for example, will we find tasks to keep the computer busy so that the user wants to buy another? I think there will be a limit. And if that limit is reached, PC dealers won't be able to keep that growing figures stock market analysts like. Stock-market oriented strategy is not good; look at the UMTS fiasco in Europe. European operators have paid enormous amounts in the English and German auctions for the UMTS licenses, and now they are facing financial trouble. The market is almost saturated; they will *not* find new customers. And, are existing customers willing to pay more for the most advanced technology? I don't think so. Mobile telephony is already expensive, and there are market studies showing the maximum amount of money the average european is willing to pay for telephony, digital television, etc. I guess the people responsible for the bids in the UMTS auctions had those studies in hand. However, they bidded as stupids. Why? Companies quitting the auctions saw they stock prices dropping, and nobody wants to see prices dropping. Something similar is happening in the computer industry. HP seems to want to manufacture PCs and printers, and *only* PCs and printers. PCs are a product in which you have a very small margin to innovate and keep an edge over the competition; the main argument is price, and there are many asian manufacturers selling low-quality PCs, but ==== ==== Brave words, big opera.......;-) Hmmm, excellent? Well, according to the discussions here, with so much complaining and confusing, I would say: The parts of the built-in software of the HP49G are very good, but the integration of them (as Bhuvanesh correctly says, it should be an integrated environment) in a whole is less thoughtfully implemented. Overall physical quality has declined. The keys of my HP49G start losing color. Not to speak about the quality of finger power exercises when I (try to) press the keys. Many projects? YOu mean there were more of them? I only know about the Xpander. Can you tell us about other projects that were cancelled? Really? For TI? Hey, could it be that the next super calc will come from TI? Boy, I start thinking about assimilation of myself by the dark side, which after all might also be not so dark at all, now that the Jedis are there. Who are those guys? Perhaps two Jedis of the old kind infiltrating the dark side? ;-) ==== ==== product. head What happens then you say? Then we take over. Simple as that. Those HP ==== This makes me sad -- and angry. :( IMO there's something fundamentally wrong with the present computer industry. It's know-how and creativity draining out ... ACO's demise is just another example. The big companies have been cutting down expenses on R&D for quite some time now, and those elephant mergers sailing under the flag of globalization only make everything worse. Innovate??? Nah, it's Make Money Fast, on a grand scale. Those marketdroids can only focus on their quaterly reports anyway, they have no idea what innovation means. The last century has been called the century of the scientists and engineers; now we apparently have the century of the managers. Let's see how long they can run the show. ;-) Anyway, JY, let me take the opportunity to thank you for all the good work you have done with ACO. I'm sure that with all your knowledge and ==== Hmm, for me it works quite well. Take an equation, simplify it in the EQW, copy the part you need, turn it into a function, make a graph, all with a few keystrokes. If I compare this to a PC - trying to work with both a symbolic software and a numerical package, and a visualization software can be quite a nightmare. I think that many of the problems people have with the 49G are actually due to the lack of decent bundled documentation, in particular, a tutorial on how you actually put this plethora of functions to work for concrete problems. Urroz' books can help there, but they still don't ==== ==== ==== ==== comp.sys.hp48:142725 comp.sys.hp.misc:29114 comp.sys.handhelds:80307 misc.forsale.non-computer:108843 To each his own... Ben Myers Ben Myers Spirit of Performance, Inc. 73 Westcott Road Harvard, MA 01451 tel: 978-456-3889 ==== ==== comp.sys.hp48:142765 comp.sys.hp.misc:29120 comp.sys.handhelds:80310 misc.forsale.non-computer:108853 What is so good about a calculator which only has a keybord for input? Why is it so sought after? Like a unicorn with only one testicle? ==== ==== comp.sys.hp48:142773 comp.sys.hp.misc:29122 comp.sys.handhelds:80312 ==== Where can I find the hp49 version of Statpack? /Jon site. It's particularly those bugs reported receipt, but hand, if any ==== chip on glass (cog) vitrim tm series (SEIKO) slightly larger than HP49 display 70.7x51.4x2.2 dot 240x160 5 volts .225x.225 dot size $55 add backlight = $6.88 evaluation kit available to customize application ($199) anything better out there? http://www.mouser.com/products/detail.cfm?mpart=628-G241D01R&CustRef=&source =search&CFID=12434869&CFTOKEN=93669410 http://www.mouser.com/products/detail.cfm?mpart=628-G8EVALKIT&CustRef=&sourc e=search&CFID=12434869&CFTOKEN=93669410 A while back I was looking into potential new calc displays ( looked at the one you mention ). Did a lot of searching for various LCD manufacturers but I found that the Seiko/Epson devices were among the few that had the right combination of resolution + size. Of course, many companies will manufacture custom displays but then you're talking big $$$. :) Anyway, these might be of some interest to you : http://www.eea.epson.com/EEA/LCD/publicFiles/lcdmodule_e_0109.pdf ( Beware of line break - huge link ). http://www.electroniccomponents.globalsources.com/GeneralManager?&catalog_id =2000000003868&design=clean&language=en&page=Browse&action=GetPoint&point_id = 3000000149695&prod_id=17780 Digikey also has some displays but I think the only graphic type displays ( made by Optrex ) are too large: http://info.digikey.com/T013/V5/SectO.pdf ( page 13 ) and don't forget Yahoo :) : ==== thank you for your input, i'll look them rigth away. ==== I'm looking for Sylvain Gamot's FXMIT and MIDIPLAYER packages for the gone and I couldn't find the software on hpcalc.org. Does anyone know where his page has gone, or where I can find that software? Or, better yet: Sylvain Gamot, if you read this it would be nice if you could drop ==== Bad style to follow up on one's own post, but anyway. Looks like these programs never worked, I should've done a google groups search earlier. ==== ==== BTW! 2 years ago I bought Diamond Monster sound MX300 sound card with A3D Vortex2 ==== ==== I would see the paper clip reset more like an On-C. I have never lost ==== ==== You can actually fix this problem without clearing your memory (probably too late now ;). Here is a program by Robert Tiismus that does the trick : http://www.hpcalc.org/hp48/utils/memory/p0fix.zip . ==== http://www.hpcc.org/hp39_40/lp.zip Useful links: http://www.hpcc.org/links.html#hp3940 ==== ==== HP48/49 software: We offer software packages for Mathematics, Physics, Chemistry for the HP48GX,G+ and HP49G. The software includes many programs and tools, all written in USER-RPL and thereby Very unique for commercial software you get the original code and data and are free to manipulate the programs as you want. There is an short description together with an file with examples to the programs. In any program or library there is an integrated help, which you can edit, so after getting comforted with the programs you don't need any printed handbook. Furthermore all data can be edited so they never loose there value, as for example a directory with 160 physical constants or a periodic table with 25 properties. Furthermore there are now a lot of very useful tools concerning Userkey assignments, Flags, Fonts, Libraries and a help, which can be edited, similar to CAS-Help on the about 500 non CAS commands of the HP49. The HEUSON-SOFTWARE has been developed since 1992 for the HP48SX, HP48G/G+/GX and now the HP49G. The Software on 3,5-discs is addressed to engineers, technicians, scientists and students. The programs can be transferred with the serial interface kit to the HP48G/G+/GX or HP49G. CONTENTS OF THE HP49G HEUSON-SOFTWARE MATHEMATICS: ALGEBRA : numeric, symbolic routines, rational functions. CALC1,2 : Calculus for functions of one or more variables. COMPLEX : complex numbers and functions, n.th roots, powers, residues, integrals etc. DIFFGEO : Differential geometry, Rn-curves parametric or implicite, R3-surfaces. DSTAT : descriptive statistics, frequencies, stat. parameters, concentration, indices, correlation, regression, timeseries. EQSOL : numerical solution of nonlinear systems with startvectors. FOURIER: Fourierseries. GEOMETRY : plane, solid, analytical geometry in R2 and R3. LAPLACE : Laplace transformation with some improvements and tools. LOGIC : logical propositions and tables, conjunctive, disjunctive form, nor, nand, etc. ODEQ : Several ordinary differential equations, fast input and solution, (non-) linear DEQ of n.th order, lin. systems. PDEQ : some partial differential equations of 1,2 order, fast input, characteristic system, normal form. PLOT : Directories, programs and examples to all plot types. SETS : sets, union, intersection, difference, product, graph of intervals etc. SFUNC : More than 70 special functions, equations, values, plots etc. Possibility to generate your own functions. STAT : Statistics : multiple data, combinatorics, discrete, continuous distributions, tests, fit of arbitrary functions. VECTOR : Vector algebra for vectors with variables. PHYSICS: symbol in terms to the value with units. MEASERR : Errors in measurements, mean, maximal error, 50%, 95%, 99% confidence level. MEQ : Multiple or single equations with constants, numerical solutions. PHDATA : physical data: moments of inertia, solar system data, thermoel., el.chem. potentials, Van der Waals constants. SIUNITS : SI-units and quantities, derived units, unitbase, conversion, unitvalues, number to unit in terms or lists. SMAT : Special physics matrices : Dirac, Lorentz, Spin, SU2..SU5-matrices. TENSOR : Tensor-algebra and calculus. VARIATION: Calculus of variations, Euler-Lagrange-equations, Noether current, energy CHEMISTRY: CHEQ : Chemical equations, fast view and selection, calculation of masses, molweights. COMP : Chemical compounds with 10 properties, (free) enthalpy, entropy of reactions, expandable. PTE : Periodic table with 25 elementproperties, fast access to properties of elements, expandable. PT : Periodic table of elements (6 properties), molweight, from the symbol to the data. REACTION : math. equations, Redox reactions, acid-base-reactions. UTILITIES: CALENDAR : calendar program, manage your dates with day, week and month screen. FONTS: Change, switch between, rename fonts and minifonts. HELP49: Help on all about 500 HP49 commands, except CAS-commands. List with help can be edited. HPDATA : Database program with many functions. HPTEXT : Text program, fast edit, view, format of texts. LIBRARY : Directory with tools for simplified generating of libraries. UTILS : Programming tools, memory, userkeys, flags. All Packages exist for the HP48GX/G+ as well with some variations. You are invited to visit our homepage and download an complete description of all programs and examples together with some example programs. HEUSON SOFTWARE D-87493 Lauben, Zugspitzstr. 4 ==== What kind of Integral-equation do you want to solve? Do you want to solve them symbolical or numerical? I can give you an example; maybe it fit's your needs. int(1.1,b,X*LN(X),X)=7 (int is the integration-sign on the HP49G of course) And now you want to solve for b. There are several ways to solve the equation. One way ist to integrate the term 'X*LN(X)' first. You can do this easily with the EQW or on the Stack. Example for RPN on the stack: (execute 'CASCFG' before you go ahead (You find it in the CAT-Menu)) 'X*LN(X)' 'INTVX' Example for ALG-mode: 'INTVX(X*SIN(X))' (You should get (in bot cases) '1/2*X^2*LN(X)+-1/4*X^2') You can solve this equation now with the NUM-Solver. Have a look in the user-guide. If you just want the numerical result you can do the whole thing in one step (But it takes a lot more time to solve it the following way): RPN Example: ['int(1.1,b,X*LN(X),X)=7'] ['b'] [1.2] 'MSLV' ALG-mode: MSLV('[int(1.1,b,X*LN(X),X)=7]','[a]','[1.2]') ==== ==== I have been trying to unsuccessfully display a string on the screen in ML. Firstly I tried $5x7. No go. So I have tried using MINI_DISP. The following Code causes the screen to fill with rubbish then a warm boot. Can anybody tell me why? IT is getting quite annoying that it is not working. ASSEMBLE NIBASC HPHP49-C RPL :: $ Test String CODE GOSBVL =SAVPTR * SAVE RPL Pointers A=DAT1 A * Pointer to String D1=A * Point D1 to Address D1=D1+ 5 * Skip Prologue C=DAT1 A * Read Length C=C-CON A,5 * Remove Length field from size CSRB A * Divide by two for number of char D1=D1+ 5 * Skip length field GOVLNG =MINI_DISP * Display String GOSBVL =GETPTRLOOP * Reset RPL Pointers ENDCODE ( now freeze the screen, else you won't see anything ) SetDAsTemp ; Below is the documentation for the use of MINI_DISP. As you can see my program sets the following D1 = first char of string (after skipping prolog and length D0 = Top left hand corner of screen C = Number of characters determined directly from the length field ST11 should be set to 0 as default %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % MINI_DISP: Assembly function % purpose: Display a text on a 131*x screen in mini font % at a 4 pixels alligned position % Inputs: % D0: point on the screen where you want the chrs to % be displayed % D1:point on the first chr of the string % Ca: Number of chr to display % ST11: 0/1 normal mode/video inverce mode ==== Can you make sure your entries are correctly resolved ? Also, change the GOVLNG MINI_DISP for a GOSBVL MINI_DISP, MINI_DISP is a ==== ==== I have changed the code to include the correct call to MINI_DISP but still no good. Same result, rubbish then warm boot. Am I correct in assuming that to check the entries are correctly resolved that I would be looking for errors in the SASM output file? I have also, changed the header info. and compiled under the HP48GX with the same result. Could someone possbily check the code on there calculator/ emulator and tell me if it works. If it does than it will probably indicate a problem with ROM of my calculator. ASSEMBLE NIBASC HPHP49-C RPL :: $ Test String CODE GOSBVL =SAVPTR * SAVE RPL Pointers A=DAT1 A * Pointer to String D1=A * Point D1 to Address D1=D1+ 5 * Skip Prologue C=DAT1 A * Read Length C=C-CON A,5 * Remove Length field from size CSRB A * Divide by two for number of char D1=D1+ 5 * Skip length field ==== ==== the only smaller RPN model still in production seems to be the 12C, which is 'slightly' programmable. It has 99 steps, no subroutines. Another one would be the 32SII, with 392 bytes (!) of program memory, but hurry to get a new one. The older, but not too old ones I'd recommend: 32S (w/o the II) 17B or 17BII The 17B(II) is not programmable in the traditional way. You can key in and store expressions for the solver. These expressions can even make use of the other expressions. You can do many things with this system, but for a teacher, I'd say it's not programmable. The only ones which were *really* not programmable are: 35, 45, 55, 37E, and some other of the first or second series. I'd not recommend one of the latter for daily use. Raymond ==== I bought the 32SII for my exams and it is a very, very nice little scientific calculator: four level stack and the wonderful 48 style keyboard. Although it's programmable, it doesn't have any where near the capabilities of your 49G. So unless your instructor is going to inspect it with a fine tool comb which is unlikely, you shouldn't have any problem. None of my instructors gave it a second look. It's also a calculator you will be able to use for a long time to come. I love mine. -- Isaac Tipton itipton@nothanx.slonet.org remove subdomain from address when replying ----- End Of Post ----- : : I need a second calc which must not be programmable, 'cause my 49G : won«t be allowed in my exams. Is there one with RPN from HP? It hasn`t : to be an actual calc, an old one would do it, too. : : : ==== ==== Hmm. Apparently I, also, need to start thinking before I press 'follow-up'. A *Non-programmable* calc? Wow. The only sort I know ==== ==== OK, I keep hearing about this from different people. The keys are bad; you can't see the labels; they wear out; they're hard to press. I can believe that the labels are hard to read in certain light, but this is hardly a major concern -- I don't need to look at the labels. As for the keys being hard to press... well, my HP49G is ID94701480, Made in Indonesia clear on the back. Supposedly this is one of the models with hard keys. My father used it for about a year before ==== Why would you even w-- oh. You have a HP48G? define hp code. define hp command. There are PC (and on-calc, but nevermind) development tools for ML and SysRPL -- and you can write UserRPL with any ascii editor (but why? *that* you can do fine on the calc). For UserRPL just get the HP49G debugger and restrict yourself to HP48 commands. It has a debugger in the PRG RUN menu that you can use. For ML and SysRPL... I dunno, but if you're seriously wanting to deal with those you ought to at least get a GX anyway. OK, forget ML (and probably also SysRPL). define 'ROM' flash ==== ==== I've posted my 'save' and 'load' programs before. This is just a pair of small programs that save flags and keybindings... and also Org data (see hpcalc.org, it's Organizer and works with Scribe), since that program has the temerity to save its data in the hidden directory without telling me that I might LOSE ALL MY SCHOOL << RCLF :1:bFLAGS DUP PURGE STO RCLKEYS :1:bKEYS DUP PURGE STO There, isn't that neat and repetitive? Also, I usually have only one line for the header, and don't like showing the clock all the time anyway. I used to have a program that would show a big clock, but that's expensive and usually assigned it to 74.2 -- since I never use that FINANCE thing. ==== any feedback on TINI (as platform)? (from agilent calculators thread...) they have new and more powerfull TINIs comming out ==== On Sat, 10 Nov 2001 10:57:03 -0600, Jonathan Busby byte serial internally I should say. It still has a 4-bit external ==== Like Raymond said, there is no such thing as a permanent solution. Eventually, no matter what processor you use, the gulf between its performance and the current status quo will eventually grow too wide. The key is in making sure it takes that a relatively long time to happen. For example, the 48GX was introduced in 1994 and at the time it was about 25 times slower (In terms of clock speed alone) than the high end PC processor (Pentium 100) and that was acceptable back then. Now it's about 500 (!) times slower than the current high end ( in terms of Mhz - long live Athlon! ;) - the Pentium 4. It's been 7 years and now the Saturn speed is starting to slip past the borderline of acceptability ( some might say that happened long ago ;). A redesigned saturn on an FPGA might give us a speed increase of 25-50x. So, assuming Moore's Law is correct and processor speed doubles every 18 months then we'll be in this situation again in say, 7 years :D - coincidence? ;). ( assuming of course that by then we don't have single chip massive parallelism which is a distinct possibility ;) That's enough time to satisfy me :). And I guarantee that if HP + us designed a backward compatible calc that came anywhere near to that speed increase it would pacify all of our whining and ranting ( ==== Actually, It seems I was looking at the 68000 cycle times when its external data bus is operating in 8-bit mode ;). 16-bit mode levels the playing field somewhat. Keep in mind though, that the Saturn is able to operate on any nibble aligned field in a register that starts at the least significant bit ( and some other fields. The cycle time is roughly proportional to the field's nibble length. There are exceptions for some fields ). The 68000 can only operate on the fields listed below which necessitates multiple instructions for other fields ( making it slower than the Saturn ). Also, note that I've left out 64-bit operations on the Saturn. For example, it takes 11 cycles to do a 64-bit add. Here is a sampling... Operation: Saturn Cycles: MC68000 Cycles: binary ADD 8-bit 4.0 4.0 16-bit 5.0 4.0 32-bit 7.0 8.0 bitwise OR: 8-bit 5.75 4.0 16-bit 6.75 4.0 32-bit 8.75 8.0 register to register move: 8-bit 4.0 4.0 16-bit 5.0 4.0 32-bit 7.0 4.0 shift right ( 1 bit ): 8-bit 7.0 8.0 16-bit 8.0 8.0 32-bit 10.0 10.0 HP48GX cycle counts by Mika Heiskanen and Dan Kirkland : http://www.hpcalc.org/hp48/docs/programming/cycles.zip M68000 8-16-32-Bit Microprocessors User's Manual by Motorola Corporation : http://e-www.motorola.com/brdata/PDFDB/docs/MC68000UM.pdf NOTES: (1) All cycle counts use general purpose registers only. (2) All Saturn cycle counts assume the opcode is on an even address. On the calculator there will be a higher cycle count for odd addresses but this is not due to the Saturn but to the memory controllers in the Yorke ASIC. (3) Saturn only supports single bit or four bit shifts. The MC68000 does not have this limitation. I apologize for any inaccuracies in this post. Hope this helps... ==== On Sat, 10 Nov 2001 10:57:03 -0600, Jonathan Busby Oops. This is if the 68000's external data bus is operating in 8-bit mode ;). For 16-bit mode the cycle counts would be 4 and 8 ==== On Sat, 10 Nov 2001 03:31:56 +0100, Raymond Hellstern A=A+1 A measured with CTIM of the Hack library on my 48GX-R takes around 5 cycles. Compare this with the 68000 which takes 8 cycles to do about the same thing ( via an ADDQ.W #1, D0 say ). Although on the 68000 you're limited to 8, 16, or 32 bits and the 32-bit case takes even longer ( 12 cycles ). If you increased the internal data bus of the Saturn to 16 bits then this would probably be cut in half ( as all evidence points toward the Yorke Saturn being byte serial ). ---------------------------------------------------------------------------- ------ before replying. I was just assessing the hypothetical situation in which you would it's already been ported to ARM :). Ok. I thought you were talking about *converting* all of the sources from sys-rpl/ML to C ;). I agree. Anyway, the minor changes I wanted to make were to the Saturn *architecture* not the actual Saturn as it is now. Who knows if HP was even using an HDL when they designed it. The current Saturn is a leveraged design from the Clarke, which was a leveraged design from the Lewis etc. Were HDL's even in widespread use in the mid to late 80's ? Even if they were I doubt whatever high level representation was used is amenable to the type of changes I want to make as they probably weren't thinking about the Saturn 15 years into the future ;). I wasn't saying ARM assembly is difficult ( I'm somewhat familiar with it ). I mean I used to program in x86 assembly and that is as convoluted as you can get ;). Anyhow, I was just trying to say that the ARM architecture is a whole lot more complex ( and consequently feature rich which makes it easier to deal with at the assembly level in many respects ) than the Saturn's. I meant it wouldn't be a walk in the park if we were implementing a CPU with ARM like features. :) A little self bashing is good for the health ;). Hehe. I wondered why that gate count was so high. Silly me ;). Ok. No one's planning on reimplementing the XScale on an FPGA ;). But I think the gate counts for the processors I mentioned are good estimates since they contain very little if any on board ram (besides the registers). At any rate, they certainly make putting a Saturn clone on an FPGA sound feasible. Well I don't have the prices right now for the XC2S30 but for the 100000 gate XC2S100 it costs around 10 USD in large quantities. The lower end ones are bound to cost significantly less. I know. Like previously I was just imagining the hypothetical situation in which you did have to write one from scratch. At any rate, even if you wanted to create a new compiled language a lot of the most difficult parts would have already been taken care of. This is because with GCC you can redo the front end (lexical analyzer, parser etc. which can be written with the help of lex and yacc so most of the grunt work is taken care of in those stages also ) and reuse the other more complicated parts ( optimization stages, code generation etc. ). Ok. But what I want to do wouldn't have anywhere near that much ram. It seems you want to design an engineering powerhouse or a high end workstation calculator. All I want is what we have now but better and faster in terms of hardware and software. Perhaps they'd be different enough to peacefully coexist within the market? ;) ==== I apparently read this too fast ;). Yes, it would be a matter of recompiling BUT... unless those entry points are emulated to the strictest degree it will involve major program redesign. Emulating user-rpl is the least difficult although I'm not implying it would be easy either. Now, when you enter sys-rpl land you get a lot closer to the innards of the OS and really it necessitates emulating (or in this case reimplementing - even worse ) a large portion of the higher level OS routines such as display management, libraries, directories and all the myriad of built in program helper routines. Obviously this is much more involved than the user-rpl case. For the ML case, well, really the only way you can provide true compatibility is to emulate the whole machine which really makes the former attempts at emulating the OS at a higher level pointless. A lot of ML programs delve into the depths of the system and if its behavior changed in the slightest bit it would be crash time :). Even an address change in ML can cause problems at the source level so as to make a straight recompile impossible. I mean, porting stuff from the 48 to 49 is hard enough not to mention a system that only incompletely emulates these :). Well, considering that to have full compatibility you'd have to reimplement the entire OS ( and emulate the hardware ) so as to duplicate its behavior to the satisfaction of most programs, I'd have ==== On Sun, 11 Nov 2001 00:39:56 -0600, Jonathan Busby ... Another complication (among many) would be that if you're statically compiling assembly programs into some other form, what is going to be done when the program decides to modify itself - directly or indirectly (as many do)? Clearly this is a major problem. Plain old ==== Obviously I'm having a little trouble with my usenet provider. ;) ( All the messages I sent in the last 3 days went to the bit bucket ) ---------------------------------------------------------------------------- ------ ==== Many has. We need to optimize any existing OS for the XScale, or we go the other way, implementing an OS kernel ourselves. No, that would be a bit tideous :-) I'm not sure of that either - even though it was NEC ;-) Yeah :-) True. You think? ;-) LOL :-) No? ;-) Good estimates - I agree. That's pretty cheap too - we need to get started :-) ==== But they are. We start at ML (fairly easy), then we compile each SysRPL mnemonic at ML level! Then we go by all the USerRPL words, this time at SysRPL level and ML where necessary. Pretty easy. about. We do not have to emulate the hardware anymore than taking it into ==== ==== Well, I took the cycle count information from SASM.DOC... So maybe CTIM is not exact, or not adjusted? Here's an excerpt: A=A+1 fs - Increment A --------- fs = A opcode: E4 cycles: 7 ==== On Mon, 12 Nov 2001 17:30:03 +0100, Raymond Hellstern SASM.DOC is for the SX Saturn. Dave Arnett said it was redesigned in ==== Ok. But I thought this was supposed to be a clean room implementation of RPL. If not, you'll have to license the source code from HP ( assuming it isn't GPL'd ). Unfortunately, it isn't that easy. Many ML programs access the hardware directly ( especially the display and associated registers ). Whatever you want to call it, it's still emulation. Although in this case it would be in a different form than say EMU48 since the assembly language would be pre-translated into native code. But even with full emulation, there are problems such as self modification. Really what you end up doing is implementing a full blown emulator like EMU48 even if it doesn't look like it superficially. ---------------------------------------------------------------------------- ------ ==== I don't think we'll have time for that at first. I assume it is. If not, we're FUBAR anyway. I see every ML instruction look in a global jump table where the registers, ==== ==== ==== You're welcome Veli-Pekka. Can you give us some examples of the keywords (=commands ?) that you ==== ==== Is there a way to exchange data/programs between an emulator and the real thing? Is it possible to upload files from the HP PC Kit to an emulator? find all the documentation I need. ============================================================ Paolo Cavallo I am a teacher at heart, and ==== Al d216 Tue, 13 Nov 2001 15:03:45 +0100, Paolo Cavallo Yes. Yes. Let's say you have EMU48 as your emulator (if you don't have it, go to www.hpcalc.org and search) Start EMU48, go to File/Settings menu and put the appropriate COM port in Wire field. Now you can connect your real HP with the emulated one by your PC cable. Sadly true (well, not exactly: there's a lot, but it isn't well ==== ----- Original Message ----- Well, I downloaded Emu48-1.25 and Emu48 SP 2.8. I tried many times, but everytime I got a No System message, where I'm stuck. I copied also from a Yorkem distribution the BMP image and the rom.e49 file; I also tried to rename this file to ROM.49G. Nothing. Every time the same story, I even try to load different KML script I downloaded, but the emulator seems not to see them. Can I hope in any further help? ============================================================ Paolo Cavallo I am a teacher at heart, and ==== I got it! I cracked THIS problem, so thanks again for the moment. To next time, ============================================================ Paolo Cavallo I am a teacher at heart, and ==== ==== version works quite in the same way. Emu48 has a free frontend, the view is always a bitmap controlled by a KML (Keyboard Macro Language) script file. In the KML script file other files maybe included. Finally you need a ROM image of the emulated calculator. This ROM image _must_ have a special format, the Win32 package (not the update archive) contain a program doing this. The ROM format is equal in the Mac and Win32 (and WinCE) version. All these file _must_ be in the same directory. Pierre made a file http://tardyp.free.fr/emu48fm/download/emu48files.sit containing all the needed additional files inclusive the converted ROM images. If you want to use other skins, the ones written for the Emu48 Windows version should work. But please don't ask me how the HP48 Port2 is supported, the Win32 version has a special Port2 file maker (command line tool in the official distribution, GUI version on seperate download which will replace the command line one in the next official distribution), which the Mac distribution hasn't. The Win32 file data is a file with double size of wanted port2 RAM filled with 0. The generated emulator state files aren't compatible from the Mac to the Win32 version, because Mac save the data in big endian order, where the ==== OK, I got it going. Some questions: 1) How do I paste an object on the stack? I tried but the Paste menu item is not on. 2) How do I keep the emulator on constantly since saving batteries are not ==== Wow, this group is becoming more provocative than talk radio :) I hate to chime in with a simple me too but what could I add? Naturally I was disappointed to hear about JYAs situation and the rest of ACO, but frankly I don't participate here because of who his employer is. It's because of he himself (and people like him) that I enjoy reading and posting here. And since he has made it clear that he is going to continue to be participating, I don't see much change occurring here anytime soon in comp.sys.hp48/49/40/39/whoknowswhatnext Lurkers and posters alike here find this a place to learn about the HP48, programming, calculators, and life philosophies. I can't think of any of the regular poster that I haven't enjoyed reading or corresponding with. I have no filters or kill files, although I do tend to scan very quickly over some posts :) ==== ok... makes sense, but it unfortunately yields the stupid question of the day: How is *that* done? I really hope you're not losing your patience yet! :-) ==== -- Colin Croft ==== ==== ==== This is a newbie question: Is there a way to make the values in the fields of an INFORM form to appear in small font? All the remaining text is already in font8, my default. ============================================================= Paolo Cavallo I am a teacher at heart, and ==== Al d216 Tue, 13 Nov 2001 14:52:01 +0100, Paolo Cavallo Yes, there is. But you have to learn sysRPL and play with new Inform Box Generator (command IfMain2). If you use UserRPL or sysRPL's old engine there is no easy way (or, at ==== I've written a documentation which explain what are the interrupts, how to deturn it and how to write a new manager. ==== ==== ==== ==== ==== what do you think of this keyboard lay-out: http://www.4p-online.com/4p/dat300_47_keyboard.html i would like to make one very similar (the enter key double size), but with HP48 keys (not membrane). I would like to run programs like Mathematica or Maple and ==== linking all your files together. A .LR file will be created. Make sure that all the entries are resolved, and that you are using the right address (e.g. the one for the HP49) As there's no problem with your code here, it should work fine ==== BTW you can shorten this to: GOSBVL =PopASavptr ==== worked out why it did not work. When I make the call to MINI_DISP, C [A] must contain the number of characters in the string. The problem with the code was when I divided the number by 2 The 5th nibble of C [A] was not equal to zero. for example, after the division C [A] = 8000B (No wonder it did not like this) To fix the problem it was just a matter of setting C [W] to zero CODE GOSBVL =SAVPTR * SAVE RPL Pointers A=DAT1 A * Pointer to String D1=A * Point D1 to Address D1=D1+ 5 * Skip Prologue C=0 W * Reset C C=DAT1 A * Read Length C=C-CON A,5 * Remove Length field from size CSRB A * Divide by two for number of char D1=D1+ 5 * Skip length field GOVLNG =MINI_DISP * Display String GOSBVL =GETPTRLOOP * Reset RPL Pointers ENDCODE I have since rewritten the code to include the supported entry =GetStrLen (Which eliminates most of the code) Input: D1=$ (Address of string) Output: C.A = length, D1 = body (start of characters) Code now looks like. ASSEMBLE NIBASC HPHP49-C RPL :: $ How are you going? CODE GOSBVL =PopASavptr * Pop string from Stack & Save Pointers ==== ==== ==== In general as I remember (it's been awhile since I took one) the large highly programable (IE you can use it to store pages of notes, formuals etc.) calculators and IR xfer calcs are not allowed on most standardized tests. SAT, ACT etc. Basically the only thing they want you to use the calculator for is for adding, multiplying, dividing. Which IMO is stupid because almost every math class now promotes and requires the use of the very calculators they ban. They have all kinds of silly rules, any calculator with a querty type keyboard is not allowed, if it has IR port it may be allowed if you slap duct tape over the IR window. ACT lists the Ti 89/92, HP 40/49 as flat out not allowed due to their capability to handle algebraic expressions (simplification etc.). Multiply polynomials, Factoring is also a no no for any calc on the ACT. Since from what I know the 38/39 will do those things as well I'd say they would not be allowed to either. However I'd think just about all the TI's would be to becuase I'm pretty sure they can multiply polynomials and factor. SAT's site seems to be a bit more flexible but it's hard to say how they will interpret those more general rules. Unlike ACT they don't specifically list any calcs that are not allowed just provide guidelines similar but not quite as picky as ACT's. And of course as with any set of standardized rules it probably varies some from test to test. I know ACT lists the HP48G as being okay if you cover the IR port, but I know when I tried to take my ACT with my 48GX I was flat ==== I«m German, so I don«t know about SAT or ACT. I just started studying EE and it depends highly on the 'prof' which calc is allowed. I could try to use a HP 32S in the exam (which can solve for example an quadratic equation, can't it?), but HP calcs are well known by the profs (they used them too!), so it could be a risk (i don't dare) to use one. ==== We have a simple rule: You can bring your calculator. Any, except communications equipment. We did not have as yet problems with the IR (and that's easily fixed with a duct tape sticker). The important issue is another: Your calculator may have any complexity and capability, but you mast master it! So the real rule is: No calculator manual or book. All you can use is your math formula book, like a Bronstein (or an Abramowiz, if you care to carry that around). The essential point ==== Which means that the following complaints are reproducible ;-) Take the HP41 in dimm light and compare its legibility of keys to the HP49. You'll see what I mean. But I need. I am not very good in memory games. ;-) Then you should try mine. After 5 minutes you will be the man with the smoking fingers. ;-) Or try an HP48xx to see what I mean. (Or even better an HP41 :-) ) The different people you already mentioned above. ;-) Ahaaa! That's how it is meant to be used! Glad to here that because until now I always hanged mine on a string that I have glued on the ==== ==== ==== I haven't touched one in several years... ==== I`m just starting to think about a major mode for Emacs (not 1.07 but ==== I started a major mode for *emacs. It does syntax hilite, indentation and delimiter matching but no interpretation. I was working on hooks to the GNU tools when I stopped working on it. Perhaps it would be easier to do the interpretor in Perl and provide it as a hook for the never ported to the 49 rom but maybe it is doable? Rgds, -Al -- -Al Arduengo ------------ Never mistake motion for action. -- Ernest Hemingway -- ==== Very interesting, is this for both sys and user rpl? I've been looking ==== Vous trouverez sur mon site web (http://perso.atsat.com/pigallio) les conversions que j'avais faites specialement pour la HP-Party de ce week-end : HP-Worms v1.1 pour HP39/40 et Trajectoires demo pour HP49 et HP39/40 A+ How about this? LOBAT from Joe Horn's Goodies Disk #10: %%HP: T(3)A(D)F(.); :: PTR 4544 @ AlertStatus (for GX only; use PTR 4546 for SX) #2/ @ move System Batts bit to lsb ONE #AND @ mask out the Port Batts bits UNCOERCE @ convert bint to real number ; If you don't have Jazz or don't want to compile it, you'll have to download it for yourself at hpcalc.org ==== This will only tell you whether the batteries are good, not how much ==== True. I seem to recall something about sampling this bit several times in ==== ==== ==== It does not really matter what HP does, the HP49 is outdated and slow. What the guys at ACO did was amazing, but no amount of genius can keep squeezing more performance from an outdated hardware platform. Face facts guys, it (the HP49) is not going to get better and eventually the majority of people will loose interest and move onto something better. Andre Claassens aim ;-) the (ACO) ==== And if you practice a bit more the 68K, you would know that it's possible to perform a multiply instruction on the 68K faster than the multiply opcode.. If I remember correctly (and I haven't checked for the past 8 years), MUL is 170 cycles isn't it ? ==== It doesn't really matter that the Saturn is able to perform operation on a nibble. You barely use this feature. What needs to be compared is on a common usage basis, on which case the 68K is faster, no doubt about that. The proof is with the TI89, this calculator is overall faster than the HP49, despite the fact that the TI programmer have probably spent far less time has we did to make the software efficient. Dirty code will be acceptable on ==== ==== SASM.DOC states on page 3 ff.: The Saturn CPU is proprietary CPU optimized for high-accuracy BCD math and low power consumtion. [...] There's more interesting information about the Saturn in this doc and others. ==== I believe that, however the Saturn was originally designed before the HP-71B project started, and I don't think they specifically had Forth in mind. If they did, they would have designed in the extra instructions that were later added in the processor for the HP-18C and HP-28C. The Saturn was designed to be a more powerful processor than the one used in the HP-41 and HP-1x (Voyager) family, and to be better-suited as a general-purpose processor. It was their first Von Neuman architecture for a calculator processor, in that it has a single address space for instructions and data. This is necessary, but not sufficient, to make it a suitable processor for FORTH or RPL. The main design criteria appear to be optimization for BCD arithmetic, and a low pin-count bus. The earlier calculator processors were bit-serial instead of nibble serial. This allowed a fairly low pin count for the HP-41 expansion modules, but limited the performance. A four bit bus was a good compromise at the time, still allowing for a low pin count expansion connector, but increasing the performance substantially. By the time of the HP-48, the pin count of the expansion bus became nearly irrelevant for several reasons: 1) Improvements in packaging technology for plug-in modules - high pin count fine pitch connectors ==== I don't agree. You can often speed up an algorithm by figuring out how to exploit this capability. But you don't even have to put much thought into it to get a speed up. For example if you have a quantity that you know is limited to a certain number of nibbles. It takes a lot less time to use Saturn's capabilities and perform the operations on just the nibbles you need. Faster if you mean slightly faster and sometimes slower. Most basic operations on the 68K ( bitwise, arithmetic, etc. ) aren't that much faster than on the Saturn and some are slower. Some common usage examples for the Saturn might be a 4-bit, 8-bit, 12-bit, 20-bit and 64-bit add. For these the clock cycle counts are 3.5, 4, 4.5, 4.75 and 11 respectively. For the 68K these might be an 8-bit, 16-bit and 32-bit add with respective clock cycle counts of 4, 4, and 8. Which CPU is faster based on these numbers is a matter of debate. Also, a lot of the cycles in the above mentioned instructions aren't really attributable to the Saturn core but to its ancient external data bus which it uses to communicate with the other parts of the Yorke. The core is ready for an 8-bit bus and in fact ( I think ) it uses one internally ( as cycle counts would indicate ). And this owes nothing to the fact that the TI-89 has 3 times the clock speed? You know, there is a C compiler for the 68K and modern C compilers can ==== Maybe that comment about the Saturn being faster was a little brash ( getting a little hot headed from my Saturn evangelism ;) but the fact still remains that most of the equivalent 68K instructions aren't ==== On the current 68K a 32-bit multiply instruction takes 70 cycles max. I seriously doubt it would take less in software. The multiply is microcoded and as such doesn't need to deal with instruction fetch/decode so if the software version and the hardware version are using the same method ( Which they aren't. You have many more capabilities with direct access to the ALU and registers ) the hardware version will automatically be faster. If you're using the shift-add algorithm for the software version then it will *at least* take a maximum of something like 500 cycles owing to the fact that a ==== ==== Is it 64 bit BCD ? If so, that would actually translate to about 53 bits of M68K. M68K does not support 64 bits of data except in multiplication and division commands. I don't think nibble flexibility is such an important factor. It seems very exotic feature (I might be wrong). How about moving data to and from the memory ? How about addressing modes ? I've heard, that M68K has rich set of ==== That's the idea. I don't see any software or hardware from any HP calc going in this new machine. If anything it should be a livense of Mr. Parisse' CAS ;-) We have already discussed several ways of mudularity, which means for example that we will be able to change to another display within hours. Adding RAM or changing types will be a matter of hours too. The OS has with 95% certainty been decided to be OO. We will probably make a C/C++ compiler for it too. the competence I'd love ideas, and whereever possible, I'd be glad for help. I just need to ==== Hey, I thought I was ambitious ;-) Just $100? That would be very nice! :-) A few things: * Every participant would need one of these machines (pointed out by Doug Burkett) * There may be differences of opinion as to what features to have (again, credit to Doug) * The project should not be abandoned if a few of the members leave * Good, thorough testing is an important part of software development ==== ==== Try yffiD, slow, but it works. (BTW, is there a command wichs gives the left hand side of an equation? Ex.: ['X1' 'X2' 'X3' 'X4'] SOLVE 'X4 = T' SUBST EVAL AXL {{}} SWAP + @ This could be shortened dramatically STREAM @ lhs of an equation -- I'm sure there is G SWAP = DUP AXL ['X1' 'X2' 'X3' 'T'] SOLVE EVAL 4 COL- SWAP DROP @ Grab 'T' SUBST EXPAND {{}} @ See above ... SWAP + STREAM yffiD exspect in level 1 a list of four numbers in *non-decreasing* order (which is to be inverted); it does work for some unordered list as well: 1: {0 0 4 4} Out: 1: {2 2 2 6} Repeat until level 2 contains the first fraction, then press UNDO and you'll see a list without inverse, in this case {1 1 4 2}. A good starting point are lists of the type {0 0 2^n 2^n}. It seems that it takes 3*n steps to get from the maximal inverse back to {0 0 2^n 2^n}. So ad lib. Happy yffiDing, Michael -- ==== ==== 1. Screen at last 480 x 160 with 16 levels of grey (much like Psion 5-series). 2. Fold-out configuration with QWERTY keyboard (much like Psion 5 series). 3. Proper digital, stereo sound (with a headphone socket so the thing can double up as an OGG player). recognition (experimental, of course). 5. A good CPU to deal with all this (e.g. TM 3120, the one used in web-pads). 6. An Li+ or NiMH battery and charger, with option to power from the mains (like a mobile phone) and work in the background in a low-power mode. 7. USB, RS232 (some of us are still in the dark ages), and IR ports (some of us still get kicks out of the old calculator/remote control thing). 8. Two types of RAM: system RAM (e.g. 8Mb SDRAM) and backing store (somewhat slower, but requiring less power, around 32 Mb or so). The operating system's job would be to effectively cache between these two stores, moving [RPL] objects in and out as needed. which runs an incredibly more sophisticated version of RPL. I'm thinking multitasking here and a professional CAS. The works - top quality 3D graphics, a new problem-solving approach that doesn't revolve around notebooks, plus better object-orientation (e.g. the ability to define your own classes). 10. TCP/IP networking and connectivity. ==== I don't like such a wide display - it should keep the VGA aspect ratio. I like 320x240 most. No QWERTY as standard. Why OGG? MP3 can be VBR too. Whatever - what I'll be making will not be a stereo, but a data device. It won't run WinCE either. Why both QWERTY and touch screen? You have commented on the resolution too - do you just throw something in the fire, or did you think first? No touch screen on my device. That's nice, but very expensive. I know of a processor that at equal performance cost a third and uses half the power. What about that? If you had looked at the technologies, you'd say lithium ion - no other technology. Which IR? IrDA? Have you read what have been discussed prior to your post? What would be slower than SDRAM? ==== What do you want, a calculator or a PDA? Start to add countless functions to a device... interesting operating system in Earth, and whenever they see any sort Same thing. Why not a PDA? Calculators are good because they are designed for one purpose. When you design something as a general purpose device, you have to make some design decisions that will not be good for each and all of the intended purposes of the device. Current calculators have two advantages: very low power and a user interface especially designed for that, for calculating. It is much faster for me to grab my HP from the desk and do some operations, than moving the mouse, going to the menu, selecting the calculator ==== -- Thierry Morissette Z8cI7.807$Bs1.188939@news000.worldonline.dk... too - OK. But, since the keyboard will, I hope, be at least as versatile to reassign as the 49G's, _please_ make the machine so that keyboard templates can be designed and used on it (like on the good old 41). Once again: why not HP-IL? I would be happy with, let's say 8 Mb RAM and a port for Flash ROM, any size available. Expansion ports, yes! Ë la 41, which had four of them! ==== templates The machine could have a PS/2 connector as an option. The keyboard will of course be user definable. post? Too proprietary, but it wouldn't be impossible to deliver it as an I/O option -. remember, the I/O capabilities of this device are user definable as well (even after purchase). size The base configuration may be less than 32 MB SRAM then? The OS will pretty much define the minimum Flash size. ROM! I will.