2023-01-15 00:10:00 <KipIngram   > You know, I need to be careful not to do too much thinking about a touch screen calculator built with that 800x480 display based on looking at my phone.
2023-01-15 00:10:10 <KipIngram   > My phone is 1920x1080.
2023-01-15 00:10:18 <KipIngram   > It's NOT going to look the same.  :-)
2023-01-15 00:19:17 <decay       > it really isn't.
2023-01-15 00:23:44 <KipIngram   > You know, one shortcoming of that "MP29" calculator in the video today - the one with the homebrew clear plastic keys - was that prior to hitting a shift key, you don't see the shifted functions anywhere.
2023-01-15 00:24:07 <KipIngram   > All he had was the label on his keys.  Shift key would change them to the new function, but you have to remember which shift key to hit.
2023-01-15 00:24:30 <KipIngram   > Whereas on most calculators it's all color-code printed on the calculator, so the calculator itself serves as a "cheat sheet."
2023-01-15 00:24:38 <KipIngram   > Seems to me like a hybrid approach would be best.
2023-01-15 00:25:09 <KipIngram   > yes, print all the functions so they're visible all the time, but then still when you hit a shift key change the image on the KEY ITSELF to the now-selected function.
2023-01-15 00:25:28 <KipIngram   > but in between the keys you'd still have that color-coded cheat sheet.
2023-01-15 00:31:51 <KipIngram   > Ok, so I took a screen shot of the calculator screen on my phone and transferred it to my computer.  I opened it in Gimp and scaled it from 1920x1080 down to 800x450.
2023-01-15 00:32:00 <KipIngram   > Exported that as highest quality jpeg.
2023-01-15 00:32:29 <KipIngram   > Then re-opened it, and scaled it back up to a size that matches the physical dimensions of that screen on my notebook screen.
2023-01-15 00:32:43 <KipIngram   > Now that should show me what it would look like on the 800x480 screen, right?
2023-01-15 00:32:55 <KipIngram   > Once I save it as the small jpg, I've lost the higher quality information.
2023-01-15 00:33:17 <KipIngram   > It still looks fine.
2023-01-15 00:34:10 <KipIngram   > Here it is:
2023-01-15 00:34:12 <KipIngram   > https://imgur.com/a/CiVdwb8
2023-01-15 00:34:39 <KipIngram   > I can see the difference.
2023-01-15 00:36:48 <KipIngram   > I added the 1920x1080 version to the same link.
2023-01-15 00:38:47 <KipIngram   > Hmmm.   Gimp says the 800x450 image is 3.4 MB.  But 800x450 is 360,000, and 24 bits per pixel makes it 1.08 MB.  Why's the file so much bigger than that?
2023-01-15 00:44:30 <KipIngram   > Some of those keys have six functions.  You've got a bare function, f, g, and h shift functions, and for some keys the CPX key functions as a shift key as well, and then there's an alpha mode function.
2023-01-15 00:45:22 <KipIngram   > Some keys only have five, though.
2023-01-15 00:50:21 <KipIngram   > That would just be hard to remember without some kind of visual cue.
2023-01-15 00:51:01 <KipIngram   > Not impossible, but it would take some work to get it down, and even then you'd have an error rate, so you'd have regular "oopsies."
2023-01-15 01:12:16 <KipIngram   > So that 16 MB flash would need to hold all of the graphics resources required, and the rest of the space could serve as "calculator mass storage."  My gut feel is that just a few MB should be plenty for the graphs; I'd expect 12MB-ish to be left for user storage.
2023-01-15 01:17:17 <KipIngram   > You know, seems like a nice feature would be able to be able to touch the display area and drag down, and have it open like a window and let you look at more of the stack.
2023-01-15 01:17:34 <KipIngram   > That would be "view only" - as soon as you let go it would pop back to the normal state.
2023-01-15 01:17:46 <KipIngram   > It would be a handy way to refresh your memory about what you had on the stack.
2023-01-15 01:18:18 <KipIngram   > Also, the WP34S lets you select 4-deep or 8-deep stack under the mode options.
2023-01-15 01:18:21 <KipIngram   > I like that.
2023-01-15 01:18:53 <KipIngram   > Very occasionally you write a program that capitalizes on the top stack register being "sticky" (keeps its value when the stack pops).
2023-01-15 01:19:19 <KipIngram   > But usually eight would be better than four - just one less thing to worry about.
2023-01-15 01:29:56 <KipIngram   > Oh, that display unit I linked earlier can detect touch events even when it's in sleep mode.  So you can wake it up that way if you want to.
2023-01-15 01:30:10 <KipIngram   > I'm sure sometimes you'd want to not do that, but a lot of the time it would be handy.
2023-01-15 01:36:07 <KipIngram   > That "pull down" of the display region would work for viewing programs on-calculator too; would let you see a lot more lines.
2023-01-15 01:37:25 <KipIngram   > Also, on this emulator if you touch a non-key region of the screen you can drag all over the place without it doing anything.
2023-01-15 01:37:56 <KipIngram   > That's kind of nice - it offers the possibility of being able to use grafitti type input of text in alpha mode.
2023-01-15 01:39:39 <KipIngram   > And you'd definitely want it to be able to "commandeer" parts of the screen for displaying graphs and stuff, and you'd want to be able to gesture on the graph to zoom, pan, and so on.
2023-01-15 02:28:46 <dave0       > KipIngram: i keep thinking of ways to do my forth dictionary differently... right now the dictionary is literally a stack of pointers to code, and each piece of code (machine code or forth definitions) has it's name and immediate flag before it in memory
2023-01-15 02:30:14 <dave0       > KipIngram: but i could make each dictionary entry with a pointer to code (machine code or forth) and a counted string for the name ... and just make a stack of variable-sized entries
2023-01-15 02:33:02 <dave0       > KipIngram:   : print-entry cell+ count type ;     : next-entry cell+ count + aligned ;    : words dictionary @ REPEAT dup dictionary-end < WHILE dup print-word next-entry AGAIN drop ;
2023-01-15 02:34:47 <dave0       > KipIngram: the dictionary would be    [ cell pointer-to-code-#1 ] [ counted string name-#1 ] [ cell pointer-to-code-#2 ] [ counted string name-#2 ] [ cell pointer-to-code-#3 ] [ counted string name-#3 ] ...
2023-01-15 02:35:01 <dave0       > KipIngram: the dictionary would be not a linked list, but a stack
2023-01-15 02:36:18 <dave0       > i could pack the immediate flag into the counted string length
2023-01-15 02:37:05 <dave0       > or have a separate field for flags
2023-01-15 02:38:14 <dave0       > but i would need to code it!
2023-01-15 02:38:23 <KipIngram   > Yeah, there are all kinds of ways to lay that stuff out.
2023-01-15 02:38:54 <KipIngram   > The very early Forths had the name stuff, a pointer to a code "handler" (which was actual real machine code) and then  "whatever data made that word."
2023-01-15 02:39:17 <KipIngram   > If it was a Forth definition, it would be a list of addresses there, and the handler took care of nesting from the higher list to the lower list.
2023-01-15 02:39:40 <dave0       > ah so a name would be near the machine code?
2023-01-15 02:39:42 <KipIngram   > If it's a variable, then there's just a cell there for the storage, and the "handler" just pushes the address of that cell to the stack.
2023-01-15 02:40:16 <KipIngram   > No, the machine code might be far away - the name would have a field that points to it.  That field is called the CFA.  Well, the address of that field is the CFA.  The field is the code field.
2023-01-15 02:40:18 <dave0       > right now my names are near the machine code, and the dictionary is just a list of cells that points to the start of the machine code
2023-01-15 02:40:25 <dave0       > aaah
2023-01-15 02:40:27 <dave0       > ok
2023-01-15 02:40:43 <dave0       > KipIngram: did fig-forth do it like you describe?
2023-01-15 02:40:45 <KipIngram   > In my system the data part is also pointed to instead of being right there.
2023-01-15 02:41:00 <KipIngram   > So I have name into (with a link for the linked list) and then a pair of pointers.
2023-01-15 02:41:23 <KipIngram   > Code pointer and a data pointer, which traditionally is called the parameter field.
2023-01-15 02:41:33 <dave0       > KipIngram: my main difference is i removed the link list
2023-01-15 02:41:47 <KipIngram   > Yes.  Linked list is just "a way" of doing it.
2023-01-15 02:41:55 <dave0       > KipIngram: instead of following links, i make the dictionary a vector
2023-01-15 02:41:56 <KipIngram   > I don't think it makes it "not Forth" just by changing that.
2023-01-15 02:42:09 <KipIngram   > Normally in Forth it is important to be able to tell the order the words were defined in, though.
2023-01-15 02:42:19 <dave0       > KipIngram: i know you once mentioned to be that it could be a patricia tree
2023-01-15 02:42:25 <KipIngram   > But it only matters if you re-define a word; you want to use the newest definition.
2023-01-15 02:42:38 <dave0       > KipIngram: you can make the dictionary a stack
2023-01-15 02:42:50 <KipIngram   > I think GForth has a linked list, but they mainly use a hash to find words.
2023-01-15 02:43:02 <dave0       > hash tables are not my favorite
2023-01-15 02:43:21 <KipIngram   > I've thought that a good way to use huge RAM space would be to have a linked list but build a hash table on the fly.
2023-01-15 02:43:30 <KipIngram   > You'd only use the linked list the first time you looked up each word.
2023-01-15 02:43:37 <KipIngram   > After that the hash table would take you to it.
2023-01-15 02:43:40 <dave0       > ahh
2023-01-15 02:43:47 <dave0       > i know that... that's dynamic programming
2023-01-15 02:43:49 <KipIngram   > And when you quite you'd just abandon the hash table and build it again next time.
2023-01-15 02:43:55 <KipIngram   > quit
2023-01-15 02:43:58 <dave0       > you cache the pointer
2023-01-15 02:44:15 <KipIngram   > Yeah.  Very inefficient use of RAM, but if you've got it and aren't using otherwise, why not?
2023-01-15 02:44:35 <KipIngram   > Thing is though that you'd have to be compiling a HUGE program for the linked list being slower to matter.
2023-01-15 02:44:52 <KipIngram   > I've never "waited" for a Forth compile in my whole life.
2023-01-15 02:44:59 <KipIngram   > Maybe it mattered more 30-40 years ago.
2023-01-15 02:45:10 <KipIngram   > When machines were slower.
2023-01-15 02:45:18 <dave0       > KipIngram: my forth that runs in real-mode is very slow !
2023-01-15 02:45:29 <KipIngram   > Chuck seemed to go through a phase during which he was almost obsessed with compile speed.
2023-01-15 02:45:31 <dave0       > KipIngram: i run it in dosbox .. the program is a .com file
2023-01-15 02:45:38 <KipIngram   > I figure there must have been a reason.
2023-01-15 02:45:49 <KipIngram   > 
ACTION liked .com files.

2023-01-15 02:45:53 <KipIngram   > Nice and simple.
2023-01-15 02:45:58 <dave0       > yes!
2023-01-15 02:46:03 <dave0       > it couldn't be simpler!
2023-01-15 02:46:17 <dave0       > load a blob of code into ram and jump to it
2023-01-15 02:47:26 <dave0       > it's humid here
2023-01-15 02:47:50 <dave0       > it's gonna be another hot & sticky night in my town 'wollongong'
2023-01-15 02:48:52 <dave0       > KipIngram: for me to change the layout of the dictionary i will have to not only rewrite FIND but i have to change the interface for IMMEDIATE words
2023-01-15 02:49:46 <dave0       > KipIngram: right now i have   IMMEDIATE?   which takes an xt and returns a flag true if it is an immediate word or flag false if not
2023-01-15 02:50:07 <dave0       > KipIngram: but that relys on the immediate flag being near the machine code
2023-01-15 02:51:33 <dave0       > but a different layout means moving the immediate flag into the dictionary
2023-01-15 02:51:55 <dave0       > i have to think more
2023-01-15 02:52:03 <KipIngram   > Yeah.  I changed my header layout at once point, based on a suggestion here.
2023-01-15 02:52:07 <KipIngram   > It took a few hours.
2023-01-15 02:52:28 <KipIngram   > Ideally you have a handful of words that navigate you around, and always use them.
2023-01-15 02:52:35 <KipIngram   > It's hard not to miss a few places, though.
2023-01-15 02:52:43 <dave0       > i find it harder to modify my existing code than write it from scratch.. i'm always worried i will miss a spot.. right
2023-01-15 02:53:00 <KipIngram   > Fortunately the actual construction of the headers was easy to change - I use macros for that, and just had to diddle them slightly.
2023-01-15 02:53:09 <KipIngram   > It was the runtime stuff that took a few hours.
2023-01-15 02:53:15 <dave0       > KipIngram: do you have a "backwards link" from your definition to it's dictionary entry?
2023-01-15 02:53:33 <KipIngram   > Anyway, the suggestion was to move the name itself to the tail end of the header, and that makes sense, since it's the only variable-size part.
2023-01-15 02:53:43 <KipIngram   > No.
2023-01-15 02:54:00 <KipIngram   > If I need to go that way I have to search the list until I find one that points to me.
2023-01-15 02:54:11 <dave0       > ah yes
2023-01-15 02:54:20 <KipIngram   > A major goal of mine was to have adjacent Forth definitions be contingous uninterrupted code.
2023-01-15 02:54:21 <dave0       > i've read it's a tradeoff
2023-01-15 02:54:26 <dave0       > KipIngram: nice
2023-01-15 02:54:32 <KipIngram   > So that a definition without a ; will just run through into the next one.
2023-01-15 02:54:46 <KipIngram   > It's all one long stream of code, with the headers just pointing in in various places.
2023-01-15 02:55:13 <dave0       > yep that's how i was gonna do it
2023-01-15 02:55:26 <dave0       > but not your idea of having multiple entry points
2023-01-15 02:55:40 <dave0       > that's a bit too magic for me :-p
2023-01-15 02:55:58 <KipIngram   > I actually think it might be slightly better to move the CFA and PFA fields away from the names, and have a brand new pointer from the name to them.
2023-01-15 02:56:11 <dave0       > i like the idea of having all the headers in one place, not scattered throughout the definitions
2023-01-15 02:56:15 <KipIngram   > That way you wouldn't need the name region at all at run-time, and you could excise it in an embedded application.
2023-01-15 02:56:23 <dave0       > KipIngram: yes!
2023-01-15 02:56:35 <KipIngram   > But that complicates memory management a little - you need a "new region."
2023-01-15 02:56:36 <dave0       > KipIngram: someone here used the word "decapitate"
2023-01-15 02:56:41 <KipIngram   > Yeah.
2023-01-15 02:57:00 <KipIngram   > I used to chat with a guy in another channel who was BIG time into tiny decapitated apps.
2023-01-15 02:57:12 <KipIngram   > With tiny little <$1 processors.
2023-01-15 02:57:21 <dave0       > oh cool
2023-01-15 02:57:55 <KipIngram   > When I found out here about mecrisp across, I sent info on that to him - it seems like something he'd be very interested in.
2023-01-15 02:58:25 <KipIngram   > I've been thinking today about Forth systems that are more "event oriented."
2023-01-15 02:58:31 <KipIngram   > All this calculator thinking.
2023-01-15 02:58:38 <dave0       > my FIND is written in forth and for my real mode forth it's slow .. but for the native NetBSD forth it was unnoticable
2023-01-15 02:58:39 <KipIngram   > Calculator key presses are "events."
2023-01-15 02:58:57 <KipIngram   > It seems like the right structure for a calculator.
2023-01-15 02:59:21 <dave0       > are you talking about interrupts? or an event loop?
2023-01-15 02:59:23 <KipIngram   > Once you had the framework all set up, it would just be a matter of writing a word for each event and plugging them into a big table.
2023-01-15 02:59:35 <KipIngram   > Or however you decided to represent that - "register" them.
2023-01-15 03:00:07 <KipIngram   > You could use a regular dictionary if you wanted to - just let hte word name be the key scan code.
2023-01-15 03:00:25 <dave0       > aha that's forth'y
2023-01-15 03:00:46 <KipIngram   > You'd want a symbolic name somewhere, though, but that's not how you'd be receiving the words from the input.
2023-01-15 03:01:01 <KipIngram   > That would just be something you printed when someone entered a keystroke into a program.
2023-01-15 03:01:23 <KipIngram   > Though if you wanted to import a program from a PC it might come in that way, using ASCII names.
2023-01-15 03:01:28 <KipIngram   > So I guess you'd want both.
2023-01-15 03:01:32 <KipIngram   > Key codes and names.
2023-01-15 03:01:44 <KipIngram   > Be able to search the dictionary using either one.
2023-01-15 03:02:11 <KipIngram   > Hmmm.
2023-01-15 03:02:18 <KipIngram   > that actually works really cleanly.
2023-01-15 03:03:11 <KipIngram   > I imagine most calculators look up the names as they run the programs; I wonder if any of them actually COMPILE those programs in any way.
2023-01-15 03:03:19 <KipIngram   > It would be a lot faster if you did.
2023-01-15 03:04:02 <KipIngram   > I think I'd compile them, and then decompile them for display in the program editor.
2023-01-15 03:04:25 <KipIngram   > My Forth variant is already really close to being completely decompilable without any ambiguity.
2023-01-15 03:04:39 <KipIngram   > Since i don't have the usual control structures that are hard to recover from the compiled code.
2023-01-15 03:05:55 <KipIngram   > I do use the same jump for tail optimization (which should decompile to ; ) that I use for "me" words.  But I could have separate words for those.  They'd "do" the same thing, but they'd decompile differently.
2023-01-15 03:07:55 <KipIngram   > In a system like that only the words that actually corresponded to keys would have non-null keycode fields.
2023-01-15 03:08:15 <KipIngram   > So only three dozen ish or so.
2023-01-15 03:09:01 <KipIngram   > Anything else would show up in a program as a call.  In HP calculators those would be XEQ's.
2023-01-15 03:10:08 <KipIngram   > But I think if it was an XEQ of an alphanumeric routine you wouldn't really need the XEQ.  Just put the name.
2023-01-15 03:10:11 <KipIngram   > Like in Forth.
2023-01-15 03:10:33 <KipIngram   > But these calculators also let you execute "local" labels like XEQ A and XEQ 01 and so on.
2023-01-15 03:10:42 <KipIngram   > You might need an explicit XEQ indication for those.
2023-01-15 03:11:29 <KipIngram   > In HP calculators programs are separated in program memory by END statements.
2023-01-15 03:11:53 <KipIngram   > Local labels are searched for only within the region between the two END statements that you happen to be "in" right now.
2023-01-15 03:12:11 <KipIngram   > Whereas global labels are searched more like Forth.
2023-01-15 03:12:41 <KipIngram   > It would be easy to build that structure into a Forth; you'd just have a way of putting "END" markers in the dictionary.
2023-01-15 03:13:28 <KipIngram   > It's an idea Forth doesn't have: a "convention" for categorizing names as either local or global.
2023-01-15 03:14:50 <KipIngram   > It's usually pretty simple: a handful of letters (like A-D on the WP34S) are local.  Two-digit numeric labels are local.
2023-01-15 03:14:55 <KipIngram   > Everything else is global.
2023-01-15 03:15:16 <KipIngram   > And A-D correspond to hotkeys; they're labeled.  The first four keys of the top row.
2023-01-15 03:15:30 <KipIngram   > If you hit one of those keys and that label exists in the current program, it executes it.
2023-01-15 03:16:02 <KipIngram   > And you can hit XEQ and then any key - it takes the row and column numbers of that key and makes a local label from them.  If that label exists in the current program, it executes it.
2023-01-15 03:16:22 <KipIngram   > So you can get two-keystroke redefinition of any key on the keyboard as a custom function.
2023-01-15 03:16:35 <KipIngram   > Just by "going to" the name of that program section, you can re-define the entire keyboard.
2023-01-15 03:16:38 <KipIngram   > It's a neat idea.
2023-01-15 03:17:29 <KipIngram   > Oh, another thing you could do on a touch screen calculator that's an improvement over keyboard calculators is when you open function catalogs.
2023-01-15 03:17:58 <KipIngram   > On the physical key units that shows the current item of that catalog in the display, and you have up and down arrow keys to scroll around.
2023-01-15 03:18:05 <KipIngram   > XEQ on the one you want executes it.
2023-01-15 03:18:29 <KipIngram   > But on a touch screen unit executing the catalog name could pop open a scrollable menu that filled the screen from top to bottom.
2023-01-15 03:18:44 <KipIngram   > You could just roll it up and down by sliding your finger, and tap the function you wanted.
2023-01-15 03:19:17 <KipIngram   > It's a whole different model.  You lose the tactile feedback of keys, but you gain a lot of possibilities.
2023-01-15 03:19:33 <KipIngram   > And I haven't really seen that explotied.
2023-01-15 03:19:37 <KipIngram   > exploited
2023-01-15 03:19:48 <KipIngram   > Probably because I've only really played with EMULATORS.
2023-01-15 03:20:04 <KipIngram   > Which try to work as much like the real calc they're targeting as possible.
2023-01-15 03:20:36 <KipIngram   > In a Forth based model, a "catalog" would be a vocabulary.
2023-01-15 03:21:26 <KipIngram   > I've also never seen hierarchical catalogs, and that would be easy to implement too.
2023-01-15 03:21:39 <KipIngram   > Because a vocabulary could certainly contain vocabulary names.
2023-01-15 03:21:52 <KipIngram   > That would just pop a side menu open, and let you scroll in it.
2023-01-15 03:22:59 <KipIngram   > You could also let what program you've selected completely control how the keys are labeled in the various shift modes.
2023-01-15 03:23:19 <KipIngram   > You really could just completely customize the thing for various applications.
2023-01-15 03:23:52 <KipIngram   > Maybe most of the time you'd only vary certain keys.  The top row, the top two rows, whatever.
2023-01-15 03:23:59 <KipIngram   > But the possibility of total redefinition would be there.
2023-01-15 03:24:21 <KipIngram   > I mean, you're probably not going to redefine your numbers.
2023-01-15 03:24:57 <KipIngram   > but wouldn't it be nice if when you put the calculator in hex mode the A-F keys appeared as a nice contiguous continuation of the number keys, rather than jumping up to the top row of the keyboard?
2023-01-15 03:25:15 <KipIngram   > After all, if you're working in hex you're probably not going to be doing sin, cos, tan, and so on.
2023-01-15 03:28:09 <KipIngram   > This WP34S has 37 keys.  Three of those are modifier keys, and don't have any shifted functions.  So 34 modifiable keys.  A key can have up to six functions in some cases, so that's 204 functions available from the keyboard.
2023-01-15 03:28:29 <KipIngram   > If you were on a 32-bit architecture, you've got four-byte addresses.
2023-01-15 03:28:35 <KipIngram   > So that's 816 bytes.
2023-01-15 03:28:53 <KipIngram   > So a <1kB table could specify a total keyboard functioality.
2023-01-15 03:29:31 <KipIngram   > You could have a bunch of such tables in the thing that you could switch in if you wanted to.  Just set a pointer to the table and you've customized the keyboard.
2023-01-15 03:30:47 <KipIngram   > One key is a modifiable key with serveral functions, but it's "unmodified" function is that of a modifier.  That doesn't present any particular problem in this picture I'm putting together.
2023-01-15 03:32:23 <KipIngram   > Oh, by the way, in the WP34S if you enter something like 3 . 4 . 7 (those are keys), it will display 3 4/7.
2023-01-15 03:32:56 <KipIngram   > And it shows it to you that way, but if you then add a regular decimal number to it it switches back to decimal display.
2023-01-15 03:33:03 <KipIngram   > The / is hidious visually.
2023-01-15 03:33:10 <KipIngram   > Just a limitation of the display.
2023-01-15 03:33:49 <KipIngram   > Oh, no, it actually stays in fraction mode.
2023-01-15 03:34:34 <KipIngram   > It lights up a little annunciator over on the right, either = or GT or LT (I think they should have used > and <) to indicate how the displayed fraction corresponds to the ACTUAL number it's got in X.
2023-01-15 03:35:52 <KipIngram   > Anyway, neat feature.  Who remembers what all the "sevenths" are?  That's just a lot faster to be able to enter it as a fraction.
2023-01-15 04:29:14 <KipIngram   > I think such a Forth based calculatore also needs to have the "typed entity" capability I've talked about sometimes.  You should be able to have any mathematical quantity on the stack.  Real numbers, coomplex, vectors quatrnions, matrices, higher order tensors, etc.  Finite field integers, and so on.  Maybe even a representation of an algebraic express, for CAS type stuff.
2023-01-15 13:53:15 <MrMobius    > KipIngram: have you checked out the HP Prime and its touch screen?
2023-01-15 14:28:53 <KipIngram   > Not yet - I've seen numerous references to it the last couple of days and mean to, though.  So far I'm just having my own thoughts (which is something I enjoy).  :-)
2023-01-15 14:29:16 <MrMobius    > Right :)
2023-01-15 14:29:19 <KipIngram   > It won't surprise me at all to find out that every single thing I suggested last night is already out there somewhere.
2023-01-15 14:29:40 <KipIngram   > I mean, in a lot of ways it's all just kind of common sense stuff.
2023-01-15 14:29:45 <KipIngram   > Fairly obvious.
2023-01-15 15:02:58 <KipIngram   > I think the holy grail here will be a future color e-ink display that's responsive enough to allow the sort of real-time updates that we need for an application like this.
2023-01-15 15:03:52 <KipIngram   > Doesn't even have to be full 24-bit RGB; just a reasonable 16-color palette could accomplish a lot for an application like this.
2023-01-15 15:04:13 <KipIngram   > So long as they're the right ones.
2023-01-15 15:05:00 <KipIngram   > That display I was looking at yesterday is probably a power hog.  I didn't see any power info on it anywhere.
2023-01-15 15:05:18 <thrig       > if you have to ask...
2023-01-15 15:05:28 <KipIngram   > I perused the data sheet for it's GPU; it looks quite capable.
2023-01-15 15:05:31 <KipIngram   > Exactly...
2023-01-15 15:06:34 <KipIngram   > It gives you full access to the graphics RAM, but it also lets you create data structures that reference graphics elements, which it will pull from the flash and make use of to generate the screen data.
2023-01-15 15:07:07 <KipIngram   > Those can be points, lines, rectangles, bitmaps, that kind of thing.  And it's got various sorts of texturing and shading capability.
2023-01-15 15:07:22 <KipIngram   > It's real target market is the creation of human-machine interfaces.
2023-01-15 15:07:34 <KipIngram   > Which I guess is exactly what a calculator screen is.
2023-01-15 15:07:50 <KipIngram   > Calculator front panel, that is.
2023-01-15 15:08:58 <KipIngram   > The WP34S has these extensive catalogs.  Like the "PROB" catalog has dozens of standard probability distributions canned in it.
2023-01-15 15:09:10 <KipIngram   > But it offers no provision for ADDING new items to a catalog.
2023-01-15 15:09:17 <KipIngram   > That would be a nice thing to be able to do.
2023-01-15 15:09:40 <KipIngram   > I mean, all you need is a name and an algorithm for computing it.
2023-01-15 15:10:25 <KipIngram   > Of course, the kind of system I'm envisioning makes the source code accessible to me, and you could certainly add new items to those catalogs by modifying the source.
2023-01-15 15:10:52 <KipIngram   > I just want that to be something you can do using the calculator's own interface, and Forth ideas make that feasible.
2023-01-15 15:11:49 <KipIngram   > My model of Forth is already something that's damn close to fitting into a "one word per line" calculator program type structure.
2023-01-15 15:12:19 <KipIngram   > Though with a better display I'm not sure that's the best way to display it.
2023-01-15 15:12:31 <KipIngram   > It might be better to have it look on-calculator a lot like it looks on-computer.
2023-01-15 15:12:50 <KipIngram   > You could still edit it by words instead of by characters.
2023-01-15 15:13:01 <KipIngram   > The scroll keys would just scroll you through words, instead of through items in a list.
2023-01-15 15:13:14 <KipIngram   > Delete key would delete that word, and you could insert a different one, etc.
2023-01-15 15:14:04 <KipIngram   > So I'm thinking of something that's kind of a "hybrid" between the pure Forth experience and the pure calculator experience.
2023-01-15 18:36:59 <Zarutian_iPad> : LERP ( a b t -- v ) >R 2DUP SWAP - 100* R> * 100/ NIP + ; \ should work, t is 0 to 100 inclusive btw
2023-01-15 18:39:39 <Zarutian_iPad> 
ACTION watching https://www.youtube.com/watch?v=NzjF1pdlK7Y

2023-01-15 18:42:54 <Zarutian_iPad> hmm.. inverseLERP is a bit trickier
2023-01-15 18:43:09 <Zarutian_iPad> : inverse_LERP.
2023-01-15 18:47:08 <Zarutian_iPad> : inverse_LERP ( a b v -- t ) >R SWAP - R> 100* SWAP / ; \ not sure if this works
2023-01-15 18:53:43 <KipIngram   > Well, I downloaded an android emulator for the HP Prime.
2023-01-15 18:54:08 <KipIngram   > It's not very usable - apparently it insists on presenting the right aspect ratio, and it wastes more of an inch of my screen width.
2023-01-15 18:54:15 <KipIngram   > Makes the buttons impossibly crowded.
2023-01-15 18:54:27 <KipIngram   > It's also totally non-intuitive.
2023-01-15 18:54:59 <KipIngram   > 6 enter 5 + does not present 11 immediately, and I haven't figured out yet what else is required.
2023-01-15 18:56:19 <KipIngram   > So, the difficulty of using it physically is of course nothing to hold against the Prime; I'm just packing it onto too small a screen.  For it, at least.
2023-01-15 18:56:57 <KipIngram   > 6+5 Enter gives 11.  Yuck.
2023-01-15 18:57:07 <KipIngram   > Not "proper" RPN.
2023-01-15 18:57:16 <KipIngram   > In spite of having an Enter key and no = key.
2023-01-15 18:58:59 <KipIngram   > Apparently there is variation in exactly how people want their  RPN calculator to function.
2023-01-15 18:59:16 <KipIngram   > The video I linked the other day mentioned what that guy called "RPEntry."
2023-01-15 18:59:52 <KipIngram   > Essentially, if you have the result of some calculation in the X register, Enter will DUP it.  That seems universal.
2023-01-15 19:00:25 <KipIngram   > But if you type a number in, then in RPEntry enter doesn't immediately dup the x register.  It just terminates the entry of that number, and the dup happens if you then type more digits.
2023-01-15 19:00:40 <KipIngram   > So 5 6 Enter 7 8 gets you 56 78 just like you'd expect.
2023-01-15 19:01:28 <KipIngram   > But 5 6 Enter gets you 56 in X and the deeper registers don't change on Enter.  The stack lifted when you typed the 5.
2023-01-15 19:01:42 <KipIngram   > Maybe that actually is what I expect.
2023-01-15 19:02:14 <KipIngram   > I guess it is; I just wasn't thinking it through quite right.  Of course the stack lifts on the 5, and in that case you don't want Enter to lift it again.
2023-01-15 19:02:30 <KipIngram   > So I take it back - there is just one way.
2023-01-15 19:02:44 <KipIngram   > Not sure why I got my wires tangled on that.
2023-01-15 19:03:27 <KipIngram   > Anyway, I'm not feeling too horribly motivated to dig into this Prime emulator.
2023-01-15 19:12:04 <thrig       > not without a Directive to that effect
2023-01-15 19:12:50 <Zarutian_iPad> 
ACTION replicates a smelly sock and throws at thrig

2023-01-15 20:08:24 <KipIngram   > Guys, I highly recommend this WP34S emulator for Android devices.  An emulator is available for iOS, but I can't comment on its quality.  But on Android this is a great calculator app.  The one thing you have to remember (which I do consider a bit of a wart) is that you need to "turn it off" to ensure your content gets saved for re-loading later.  I'm just making a point to turn it off and re-load it after I
2023-01-15 20:08:26 <KipIngram   > enter any programming steps.
2023-01-15 20:08:46 <KipIngram   > It's really quite powerful, though, and I like it better than the HP-42S emulator I was previously using.
2023-01-15 20:09:22 <KipIngram   > And there are no ads or anything like that.  It just "does what it's supposed to do" and that's it.
2023-01-15 23:18:04 <KipIngram   > Aha - I found a bug in that emulator.
2023-01-15 23:18:31 <KipIngram   > The % and ∆% operations throw "Illegal Operation" errors.
2023-01-15 23:18:54 <KipIngram   > Probably not very commonly used functions, but they are actually printed on the keyboard.
2023-01-15 23:19:16 <KipIngram   > Bug in the emulator specifically - they work fine on the physical WP34S.