This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - timwessman
76
« on: September 25, 2013, 03:08:31 pm »
Another thing was, how the heck are you supposed to take a derivative? Whatever way it was coded is definitely not intuitive.
You've lost me on this one. There are 3 quite easy ways. Press CAS to switch to symbolic mode, open the template, select the d<box>/d<box> template, type it in. Or else type diff(func, var), or just sin(x)' Are you in the HOME screen? If so, you are probably using X which is a predefined real number, instead of 'x' which would be a symbolic object with no definition. In home d(sin(X),X=<num>) would let you do a numerical at a specific point. Oh, and last edit... did you try selecting the "differentiate" from the CAS->calculus and clicking the HELP key. That would pop up more info.
77
« on: September 24, 2013, 11:08:12 am »
Another bug. This time, it's with units. I think the image says it all:
Yes, that is something that I'm not a fan of either. There is a very good technical reason at a low level for it, and the only way to get around it is kind of a hack. Still, I've logged it. Or maybe those 'plot view' and 'split view' menus could be sub-menus. I don't know, you're the HP official here Tim.
The key really is for user created views, and saved "special" views instead of the main 7. However, I do see the confusion. Perhaps sticking them into a submenu and leave the top level ones that are accessable with a single keypress could aleviate that some. In actual use, those special views get used primarily as a quick way to autoscale, or set a specific graph setting in most cases. Thank you everyone for comments/changes sent along. I've logged these for review.
78
« on: September 22, 2013, 03:30:53 pm »
After trying to type the following integral in, I got the weirdest, most undescriptive error that I've ever seen on a calculator. Trying to copy/paste yielded the same result, yet retyping the function gave the correct result.
Just a note on this one, it is a result of the "d(x)" having the integral included inside the variable declaration like d(x+int...). Definitely a problem with not showing the user clearly that you are still inside the variable declaration there.
79
« on: September 22, 2013, 03:19:38 pm »
I've reported both problems to HP-France, but I don't know if they did translate and forward them.
Definitely never made it to me... As a general comment here, thanks for the details on things. As I suspected, the vast majority of the comments revolve around the CAS. I always monitor and collect issues/comments and get that into our systems to make sure they are addressed in some fashion. When you find a spelling/grammatical issue with the built in help, please email me and I'll be sure it gets resolved in the next revision. Remember, there is 5MB(!) of compressed built in help on the system. Thus there is lots of chances to miss things. Any help here is greatly appreciated. If you've never had to proofread a large collection of information multiple times, it is nearly impossible to understand how the brain fills in and filters things to make them "right" in your brain. :-)
80
« on: September 21, 2013, 05:45:31 pm »
Also is the calc really sold with OS 0.025.5106? A version number under 1.0.0 often means it's a beta... 
Nope. That is a common convention, but really has nothing to do with the state of things. That whole menu is for factory use and they control numbers and versions there. I honestly have no idea what they really are using there or what it is supposed to mean. I suspect it has something to do with bootloader stuff. some features feel incomplete
Examples please?
81
« on: September 19, 2013, 02:56:33 pm »
Tim Wessman hardly ever post on Omni anymore for unknown reasons.
Just nothing to say really. I would assume that fact that the calcs were not available and in people's greedy little palms was the reason for lack of interest. Tim has to try to avoid participating to HP hacking discussions, since he is working for HP. Bingo. I think most people who have an HP Prime are on HP Museum forums it seems. It's hard to attract HP fans on a TI forum when there is an established HP-only board around, same problem we had with Casio people. Certain people might see TI boards as the "enemy" or something.
Then they have some maturity problem.
On the contrary, the average age of the posters at hpmuseum is probably up in the ~50 year range or higher.  Games, hacking, quotes at the bottom of posts, animated avatars, etc just is not much interest to a large chucnk of people in that range. Seeing such just makes them think "kids, get off my lawn"... :-P I am certain a large majority see someone posting "cute" little simple programs that don't really do much doesn't interest a majority of the readers/posters. Also note that that group is more about the OLD calculators, the historical interest items and less about modern units (hence the name "hp museum". They don't even really talk much about anything newer. Then again, there are a large numbers of others there that are interested in such but just don't have anything to contribute in their opinions. Every time someone has posted a "this is the HP museum forum, don't waste my time with Prime" type message, they have been inundated with others telling them to shut up and that, yes, there is interest. Also, you need to remember that a LARGE chunk of people who are regulars at the hpmuseum forum are WAY beyond talking about "hacking" software. They have long ago moved into the "create calculators from scratch" phase. Were you aware of the wp34s which is a complete from scratch calculator based on a repurposed HP-20/30b? http://commerce.hpcalc.org/34s.php Or how about the user that created a USB connection for said calculator complete with rechargeable li-ion battery that mounts inside the unit? Or the user who created from scratch a brand new replacement board for the HP-41, including every flash module ever sold for it, extensions to the built in system, full compatibility with all HP-IL modules, and so on... http://systemyde.com/hp41/index.html? Then you have the team that recreated a mini HP11,12,15,16C calculators and sells them? http://www.swissmicros.com/ The team that is making a complete from scratch hardware calculator to rival anything HP or TI ever made (of the classical style)? To many folks like this, hacking software to make games, or even just programming on modern units isn't all that exciting. I do think the people that complained about the wiki were a bit silly. However, easiest way to show them wrong is to simply make it better. Everyone will know which is the real resource... thanks to the (ab)use of the standard HID class, no additional driver is required. Abuse? In what way?
82
« on: August 22, 2013, 02:48:29 pm »
Nah not the shiny colors, but the overal feel of the UI makes it oldskool.
You mean it isn't a desktop application packaged onto a calculator (nspire)?
83
« on: August 21, 2013, 12:26:55 pm »
Is this really what I am thinking? 
No. That is just what the ODM calls the main OS. How do you run the BXCBOOT0 bootloader? Judging from the text found in BXCBOOT0.DAT the calculator checks for an SD card. Could this mean the bootloader can load an operating system from an SD card?
Nope. Nearly all RTOS systems are rather generic and start life provided by the chip manufacturer. They generally contain example code for anything supported from the chip. Usually it isn't complete and only does very basic things - and in many cases doesn't even work for some of the "features"- and usually requires quite a bit of modification before it does anything useful. It is extremely common to find some leftover stuff that less qualified devs just leave in place to avoid extra work needed to strip it out (because they just don't understand it...). I would be very surprised if any of that type of stuff proves useful for you. TW
84
« on: August 20, 2013, 01:33:41 pm »
Question: What kind of data is stored into RAM? When a program is executed, for example, is it copied to a certain RAM area, forcing a size per program limit? Are programs always stored in RAM then backed up in Flash when the calc is turned OFF (to prevent them from being lost on a reset)? How large are each GROB memory areas? It is actually quite interesting/different to see people who have never experienced "HP" calculators discovering the programming philosophy differences. There have never been arbitrary limits or things put in place to try and restrict what you can do in HP graphers. In fact, in quite a few ways the new programming in Prime is much more restrictive then anything found on HP graphers to date. Basically, none of these questions are things I've even thought about or seen posted in HP centered forums. I guess I'll have to adjust my thinking some. RAM only contains things as/when they are loaded. Program execution can be done from anywhere provided there is enough memory to run. No limits I am aware of. In fact, I honestly have no idea how large of a program you'd have to create before any sort of issues would start happening. If you run out of memory (say, by creating an 11MB lists and trying to multiply it by itself), the calculator will reboot. There is no clean low memory cleanup yet unfortunately. Not really a real problem, but bothers me from a technical perspective. The 10 predefined grob variables are just pointers. No limit on size. Also, any variables in a program can be any type. You are not restricted to the base 10. The only unique one is G0 which is basically just the main screen pointer. There might be some size limits leftover from the 39gII that we forgot to remove (for example, on the 39gII lists were limited to 999 or 10000 chars per note or something), but they are not intentional. Programs consist of 3 parts. You have a header area that contains information about exported variables/programs (so the system knows how to recognize them, and number of arguments for example), a compiled bytecode area, and the source. On poweroff, the source is saved to flash if it has been modified. The bytecode is discarded. Early in the development it was kept across power cycles, but there is basically no reason to do so since the parsing/compiling is so fast you could never notice a difference as an end user.
85
« on: August 20, 2013, 12:50:07 pm »
(the calc simulator software is more annoying to work with - we/I'm not sure exactly when it decides to save stuff...) On exit. Everything is only saved when either more memory is needed (and then it will write out loaded objects), or on power down. Loading is also delayed until needed. Some of the mysterious bits you have trouble interpreting are flags indicating status, location in memory, or similar.
86
« on: August 16, 2013, 05:44:03 am »
That actually is more of a marketing activity and not really a testing type activity. Anyone complaining/worrying about stability before the final version that arrives with the calculator is just unfamiliar with the way things work. In fact, debugging in the ROM wasn't turned off until recently. Generally, when active development for the first version of a software product is happening, anything prior to the first release are development builds or marketing samples. Usually the ROM builds run through a quick automated test to ensure they don't immediately crash with basic operations, and are supposedly sent to a selected set of people who know how to update the units and are aware of the possibility of large issues in order to give feedback on specific things. However, sometimes those units end up in the hands of people who don't receive the update information, fail to update, choose not to or really never should have received them in the first place. After a first release of a product things are much more stable and any sort of evaluation versions that go out are much, much more thoroughly tested because there is actually a stable location on which everything else is built upon. Rest assured, the shipping firmware is very stable. Perfect? No. That is essentially impossible. I am sure there will be bugs found as all software of any marginal complexity will have them, but it is a very good product. We already heard of blue screens on the HP Prime Smiley Basically, what that shows is a dump of all the ARM registers. Allows you to track down where it crashed. If I remember my computing history, blue screens were used for error/crashes long before windows, but microsoft definitely made them famous. I think the DVT is more like a prototype with the pre-release version software. So hopping HP can do better on the production version. Datamath actually has a very relevant writeup that explains it quite well ( http://www.datamath.org/Story/Phoenix.htm). EVT, DVT, and PVT are standard terms in product design. It is very common to have multiple stages of them as well. For example, an EVT unit might have the near final shape, but the plastic molds don't have texturing, there are missing components, etc. It usually is at this stage that they begin testing EMI. DVT is usually the stage where the unit basically looks final and complete. This is when the final testings/certifications are usually done. PVT is for final checks to make sure the production lines are working properly and consistently. Usually, little is done here - however sometimes issues can be discovered and need resolving.
87
« on: August 13, 2013, 06:49:26 pm »
Here's another one. Supports direct editing and transparency color flagging. Also will load from source.
With regards to size, you really don't have to worry about it much. There are 256mb of flash so there is lots of space... I don't think you'd start running into issues till your program files are several mb or more.
That being said, there is a PNG library in the calculator which is used for screen shot compression internally for wireless classroom monitoring. I suspect at some point we'll expose that for use directly.
Also, it would be helpful to collect a list of improvements/changes to be passed along to us. One that came into my mind was a GSCROLL or something that would do internal scrolling on the grobs. Would probably come in handy. :-)
88
« on: August 12, 2013, 05:53:15 pm »
By the way, is there any image<>hex converter that supports A1R5G5B5 format or something that can convert JPEG/BMP/GIF to exactly that image format?
No, don't have anything for that. Sorry. (might tweak one and post it later though). It is a very basic encoding scheme though. Basically, all that is happening is that you convert a #FF value into a linearly scaled #1F value. Here is a C macro that shows how this is done internally. #define RGBToColor(R,G,B) (((R>>3)<<10)+((G>>3)<<5)+((B>>3))) // transforms 0-255 RGB into color The 16 bit is just a flag that signifies transparency. Note that the DIMGROB command just takes the information in order. So if you want to make a 6x3 grob, The first 4 16 bit groups come out of the first hex numb, the next hex num takes the first 2 and then the last 2 are the start of the second line and so on... { |#64bits, #(upper32)||(lower32), #64bits|,|#64bits,#(upper32bits)|(unused) }. Each line in the 6 width takes the first 6 16 bit groups it finds. Each "line" of the grob is defined between the paired | |. Remember that all hex numbers, regardless of sign/unsigned/bits is internally 64 bits of data.
89
« on: August 12, 2013, 03:09:42 am »
Hello,
The code I'd posted previously (the little sprite command), shows how to load colors to a grob, and how to scale it.
EXPORT Sprite()
BEGIN
DIMGROB_P(G2,4,4,{ #7C0003E0001F0000:64, #0, #0, #7C0003E0001F0000:64 });
BLIT_P(G0,20,20,100,100,G2,RGB(0,0,0));
WAIT(3);
END;
Note that scaling is only a pixel by pixel things. It doesn't not interpolate. Also note that you can specify different source regions from the grob. This means you could have a larger grob containing a tileset, and blit in from a specific location.
90
« on: August 09, 2013, 03:53:35 pm »
Anyway, my parents won't let me buy any new calcs with my own money, so if/when they'll let me, it's going to be a tough choice as to which calc I should buy.
Well, you should tell them my story. :-) I was known in high school as the calculator guy. I was the one sitting there writing programs and knew everything about them. Even though I hated TI calcs with a passion and only was an HP only guy, the teachers still came to me with questions on things. I wrote some comparison documents, and some other things. In school, I started a business with a land surveyor using the 50g as the main cpu/internal guts. I did all the software on it. ( http://stakemill.wordpress.com/2008/02/05/precision-survey-solutions-dc50-data-collectors/). We did a few business plan competitions. Took home money from several of them including Fortune Small Business ( http://marriottschool.byu.edu/cet/news/article?id=307, http://money.cnn.com/magazines/fsb/fsb_archive/2006/11/01/8391418/), and Rice University. Did that for about 2 years or so until HP hired me in the calc group. Been here almost 5 years now. Also, I met my wife due to one of those comparison documents I mentioned. Her dad was looking for a calculator for his daughter who was starting engineering courses. Her dad and I kept in touch, and later on I met her and we now have 2 kids. :-) Learning programming on memory restricted, slower devices gives you an amazing capability and flexibility missing from many professional software developers. You gain an understanding of how and why things work in a way many new developers never get. Granted, if you do nothing but web stuff it may not be incredibly useful, but in my time here at HP I've definitely seen how that start I had has made me much more flexible and able to jump in on all types of tasks and be productive much quicker even in areas I've not had experience with before. TW
|
Show Posts