New firmware for the Swissmicros DM15L
|
09-21-2024, 11:11 PM
(This post was last modified: 09-21-2024 11:53 PM by Helix.)
Post: #48
|
|||
|
|||
RE: New firmware for the Swissmicros DM15L
(09-21-2024 01:32 AM)jebedeo Wrote: 2. ->H, ->HMS, FRAC bugs should be fixed. That time conversion is pesky man! Took me way too long to figure it out. Please stress test it again, especially with large numbers as there are some type casts in my code that might cause trouble there. 4.1 → H.MS gives 4.056 instead of 4.06 I also notice that the full precision is not used for time conversions, only about 10 digits. I don’t think it’s a problem, but this should be specified in a future documentation. Quote:3. The calculator is now set to turn off after 10 minutes of inactivity. Too little? Too much? Perfect! Quote:4. Try those benchmarks again, the old version of the firmware was running at 12MHz, now it's at 48MHz. This change was immediately noticeable to me: I had to change the battery. But it was depleted. Quote:5. About program editing. There is a "go to line" function, it's available if you long-press GTO while in program mode. Again, it seemed to me more intuitive than GTO CHS nnn but I am open to changing it if people have strong preferences, it probably could be accessed both ways too. Also, should that function be available also while not editing a program? Another feature is that you can clear program memory completely if you long-press f (CLEAR) PROGRAM. Also, long-press for SST and g BST let's you scroll through instruction at different speeds, pretty cool I didn’t know the long-press GTO. It works nicely, as the long-press SST/BST. I don’t use my DM-15, and I haven't even read the entire HP 15C manual! But I think that for debugging, in some cases it could be useful to jump to a specific line number in Run mode, without having to enter program mode to type this command. For clearing the entire program memory, I’ve found that the f prefix is not necessary: a long press on R↓ has the same effect Quote:6. If you start at the top of the program memory the instruction is added above the first instruction, however there is a bug: after that the behavior goes back to inserting instruction under the current line by default. I need to do some more work there. Ideally I am trying to replicate the HP42 behavior but that might be too involved, so I might tie the behavior to the last pressed step function: if you last pressed g BST you will insert new instruction above current line, if you pressed SST the new instruction will be placed below the current line. How does that sound? The current solution is not satisfying, as it’s impossible to insert an instruction between the first and the second line. The other proposed solution seems complicated to me, as one has to remember if the last movement was SST or BST. That sounds confusing. I don’t know how to solve this problem, but I note that the HP solution is very good: the step 000 is a convenient way to go to the very beginning of the program memory. Also, keying BST from that step jumps directly to the last instruction in program memory. Currently there is no easy way to do that, apart from leaving permanently a dumb label at the end of the programs, or doing a long-press SST. Jean-Charles |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)