Threaded Mode | Linear Mode

Claudio L. · 09-09-2015, 01:22 PM

(09-09-2015 02:39 AM)Han Wrote: Here were the exact steps I took to get mine to work:

It seems from the various posts here the only thing needed is to restart from a true power off state. Removing a battery makes it work. Do it twice if the first time doesn't do it.

(09-09-2015 02:39 AM)Han Wrote: With the USB cable plugged in, one cannot turn the calculator off. It immediately turns back on.

Also without the cable.

(09-09-2015 02:39 AM)Han Wrote: The variable keys should not activate the actual variables unless the VARS menu is visible. Right now, pressing APPS will recall the first variable even when the VARS menu is not visible.

The normal key function (APPS, MODE, etc) was moved to a long press.
I thought of hiding the vars menu as something temporary. However, I like your idea of going back to normal press when the menu is not visible. Showing VARS in the dark menu seems like a step backwards to me but it makes hiding vars more permanent. I'll probably implement it soon as it gives a retro-UI mode that many people will find comfortable.

(09-09-2015 02:39 AM)Han Wrote: I like the font, except that 'w' and 'm' are one pixel wider than the rest.

The fonts are variable width for a reason. Those letters look better when wider. Almost every font has wider m and w. Same as i l and t being narrower. Numbers are all the same width so digits can align well in columns.
All fonts were artfully crafted by our friend Helix, and I want to take this opportunity to say they look great, and to give him due credit for an excellent job.

Han · (This post was last modified: 09-09-2015 02:29 PM by Han.)

For the cursor, I recommend using the alpha indicator with different blinking patterns to indicate the alpha mode. When uppercase alpha mode is on, then the alpha indicator is permanently on. In lower case mode, have it blink. For the cursor itself (in the command line) a solid black box for insert mode and an empty box (just black border) for overwrite mode.

While the current cursor is informative, it makes the command line hard to read because I keep seeing an extra letter (the cursor) which throws me off when quickly glancing at the screen. I think the alpha annunciator's different behaviors would alleviate this problem.

I also think that long and short pressing the alpha key should activate lower and upper case (as an optional setting) in place of pressing alpha multiple times. I am sure some users prefer to quickly tap alpha several times to get the appropriate alpha mode. Me, I prefer a short alpha press to always enforce upper case and long press alpha to always turn on lower case. The current setup stores the previous alpha mode and I find myself hitting alpha 1 to many times when trying to switch cases.

For left and right shift, they should blink when using a long-press so that we can also have long-press shifts. This gives users a visual cue to differentiate between short and long shifts.

EDIT: The fonts do look really nice. I suppose I have gotten used to fonts that have letters being all of the same dimensions. Do you suppose fonts will be user-configurable?

Han · (This post was last modified: 09-09-2015 04:22 PM by Han.)

Here's another idea for the menu system. I'll refer to the "black" menu as the main menu and the "light grey" menu as the secondary menu.

There should be two modes for menus: mode 1 uses only the main menu and behaves like the old HP48 series; mode 2 uses both main and secondary menus.

Mode 1: When using a short-press for any key that brings up a menu (including softkeys and VAR), then the main menu is updated. However, a long press would activate the menu as a secondary menu and turns on mode 2. The NXT key shifts pages, and PREV shifts in the opposite direction.

Mode 2: Long-presses for menu keys will deactivate mode 2 and revert to mode 1. Since there are two menu levels, we have to be able to navigate each separately. My proposal is that short-pressing (including short left/right shifted versions) the APPS-through-NXT key will be the equivalent of the normal menu key behavior for F1 through F6. Since the NXT key is now a (secondary) menu key, I propose that holding NXT and using the arrow keys navigates the menus. Holding NXT and pressing left/right would scroll the main menu, whereas holding NXT and pressing up/down would scroll the secondary menu (either by 3 or by 6) since these menus span two rows.

In essence, NXT becomes a shift key for menus, to be used in conjunction with the arrow keys.

As examples for mode 2:

Long pressing APPS will activate whatever softkey corresponding to apps and deactivate the secondary menu, and the secondary menu replaces the main menu. The same goes for MODE, TOOL, VAR. The exception would be NXT since that has a different role and STO as I think long-press STO should behave like normal STO.

In the HP48 series, one could use softkeys, or one could opt to use the graphical interface. On the HP49/50 series, the graphical interfaces usually required long-presses. For example, the 2D/3D graphing UI was accessible via holding left shift and pressing F4. I think all these should be collectively grouped into APPS and accessed by the APPS key. There should be a setting for GUI vs softkey interface like on the HP50G. With the GUI enabled, the APPS key would behave mostly like it currently does in the HP ROM. With softkeys enabled, then APPS would bring up a menu for the apps in the same manner as, say, the left-shifted version of the apps in the HP48 series. (For example, press left-shift plot). The menu is display, and the screen should show a description of each menu item much like pressing right-shift down on the HP48 series while the libraries menu is loaded.

EDIT: For the "grey" menus, I propose a light grey rectangular border in place of full grey background for the soft keys. Then you won't have to deal with contrast, since it should show up as extremely sharp.

Claudio L. · 09-09-2015, 07:51 PM

(09-09-2015 02:24 PM)Han Wrote: While the current cursor is informative, it makes the command line hard to read because I keep seeing an extra letter (the cursor) which throws me off when quickly glancing at the screen. I think the alpha annunciator's different behaviors would alleviate this problem.

Lately I don't even see the cursor anymore. Give it some time first before passing judgement and calling it a problem. It will take time for you to adjust to the new keys, menus, the alpha mode, etc. If after some time you still believe it's a problem then we'll come up with improvements together.

(09-09-2015 02:24 PM)Han Wrote: I also think that long and short pressing the alpha key should activate lower and upper case (as an optional setting) in place of pressing alpha multiple times.

I originally had something similar, but long press to deactivate alpha instead of a double tap. When you get used to the keyboard, it's too long to wait for the long press. Double tap is way faster so I decided that long press is only for functions that are rarely used.
The shift keys don't have long press. If the user wants to do shift hold and takes too long to find the other key the long press would kick in inadvertently, so it would put pressure on the user to find the key quickly.
Then we would have short shift with short key, long shift with short key, short shift with long key, long shift with long key. I. Think it's too many shift planes, very confusing. Right now a shift is a shift, then the key can be short or long.

(09-09-2015 02:24 PM)Han Wrote: EDIT: The fonts do look really nice. I suppose I have gotten used to fonts that have letters being all of the same dimensions. Do you suppose fonts will be user-configurable?

Yes. Fonts are RPL objects, and I have a converter from BMP format to the proper one, so you can edit fonts with your favorite graphics editor in the PC. For now there's no way to change them but there will be eventually.

Claudio L. · 09-09-2015, 08:49 PM

(09-09-2015 04:17 PM)Han Wrote: There should be two modes for menus: mode 1 uses only the main menu and behaves like the old HP48 series; mode 2 uses both main and secondary menus.

While I think it's doable, there are a few problems.
RPL commands like TMENU would become incompatible, because they need to know if the menu will show on dark or gray areas. Hence my proposal was only VARS on the gray. The rest goes always to menu 1. Also one menu would have 5 keys and the other 6 because NXT is not available. This makes again the page number change in TMENU. So if one menu has 5 Soft keys, the other one should too, therefore it's simpler to have a NXT soft key and lose one space than a dedicated NXT key with some complex interaction to handle 2 menus at once.

(09-09-2015 02:24 PM)Han Wrote: In essence, NXT becomes a shift key for menus, to be used in conjunction with the arrow keys.

The keyboard driver doesn't allow other keys to act like shifts.

(09-09-2015 02:24 PM)Han Wrote: should be a setting for GUI vs softkey interface like on the HP50G.

I don't think the dual interface on the 50g was a good thing, so my vote goes for not trying to replicate it.

(09-09-2015 02:24 PM)Han Wrote: EDIT: For the "grey" menus, I propose a light grey rectangular border in place of full grey background for the soft keys. Then you won't have to deal with contrast, since it should show up as extremely sharp.

Yes the background should be white, gray edges sounds good.

Helix · 09-09-2015, 11:22 PM

(09-09-2015 02:39 AM)Han Wrote: I like the font, except that 'w' and 'm' are one pixel wider than the rest.

I've made another font with more compact characters. When the tool to make one's own font will be available, it will be possible to try other variants, and of course to make changes if some letters look ugly.
There is also a more compact 6 pixel font that was intended for the menus, but Claudio chose another font for this demo version.

(09-09-2015 01:22 PM)Claudio L. Wrote: The fonts are variable width for a reason. Those letters look better when wider. Almost every font has wider m and w. Same as i l and t being narrower. Numbers are all the same width so digits can align well in columns.
All fonts were artfully crafted by our friend Helix, and I want to take this opportunity to say they look great, and to give him due credit for an excellent job.

Thanks !

In fact, the digits are not always perfectly aligned, because the dot character has not the same width as the figures. Maybe this should be modified later. At least in "fix" mode, all the digits will be aligned, which is the most important for me.

(09-09-2015 08:49 PM)Claudio L. Wrote:
(09-09-2015 02:24 PM)Han Wrote: EDIT: For the "grey" menus, I propose a light grey rectangular border in place of full grey background for the soft keys. Then you won't have to deal with contrast, since it should show up as extremely sharp.
Yes the background should be white, gray edges sounds good.

I think too that black and white menus are preferable.
For the same reason, I think that the alpha and shift indicators should be dark too. We don't need to check these indicators to know that we are doing a long press…

Now my first comments on the alpha mode:
At the beginning, I was unable to use efficiently the calculator, because I can't remember if the last mode was capital letters or lower case letters. This behavior is totally counterintuitive for me. But I figured out that I could press simultaneously the alpha key and another key to enter lower case letters, so my default mode remains the capital letters. Although I would prefer the capital letter as a default mode, I can live with this configuration. The only thing I have to remember now is to double tap the alpha key to leave the alpha mode.

I have no problem with the cursors, but the modification we discussed privately could be interesting in my opinion, because in this case the letter inside the cursor would be slightly smaller than the current font, avoiding some confusion between the edited text and the cursor.

Han · 09-09-2015, 11:51 PM

(09-09-2015 08:49 PM)Claudio L. Wrote:
(09-09-2015 04:17 PM)Han Wrote: There should be two modes for menus: mode 1 uses only the main menu and behaves like the old HP48 series; mode 2 uses both main and secondary menus.

While I think it's doable, there are a few problems.
RPL commands like TMENU would become incompatible, because they need to know if the menu will show on dark or gray areas. Hence my proposal was only VARS on the gray. The rest goes always to menu 1. Also one menu would have 5 keys and the other 6 because NXT is not available. This makes again the page number change in TMENU. So if one menu has 5 Soft keys, the other one should too, therefore it's simpler to have a NXT soft key and lose one space than a dedicated NXT key with some complex interaction to handle 2 menus at once.

(09-09-2015 02:24 PM)Han Wrote: In essence, NXT becomes a shift key for menus, to be used in conjunction with the arrow keys.
The keyboard driver doesn't allow other keys to act like shifts.

I should clarify. I did not mean that NXT should be an actual shift key. However, I recall that the 48/49/50 series could detect multiple keypresses all at once. Can we not detect whether an arrow key is pressed alongside NXT? If so, then would that not be sufficient? Regarding TMENU, it should just affect the main menu. If we wish to have the secondary menu have a similar command, then perhaps TMENU2 could be implemented. As for the 5 vs 6 issue, the secondary menu would actually have 6 menu keys. Using regular key presses (including shifts) would result in the same behavior as F1-F6. It's only when those keys are long-pressed that only 3 (now realizing that slight changes are needed) of the 6 would activate the softkey and switch to mode 1. Longpress on VAR would behave as it does now (toggling off secondary menu), longpress STO is normal STO and longpress NXT would be in conjunction with the arrow keys. I do not imagine users quickly and simultaneously pressing NXT and an arrow key; but should they, then these keys would presumably be parsed in sequence. However, if NXT is held down and then an arrow-key pressed, then the menus would shift pages as described.

Quote:
(09-09-2015 02:24 PM)Han Wrote: should be a setting for GUI vs softkey interface like on the HP50G.
I don't think the dual interface on the 50g was a good thing, so my vote goes for not trying to replicate it.

Sounds good to me; I never did like the GUI interfaces.

I am slowly getting used to the current cursor, and agree that the double-tapping of alpha is much more efficient. I am sure that over time I will come to even prefer the cursor over my proposal of varied annunciator behaviors.

Claudio L. · 09-10-2015, 03:29 AM

(09-09-2015 11:22 PM)Helix Wrote: Now my first comments on the alpha mode:
At the beginning, I was unable to use efficiently the calculator, because I can't remember if the last mode was capital letters or lower case letters. This behavior is totally counterintuitive for me. But I figured out that I could press simultaneously the alpha key and another key to enter lower case letters, so my default mode remains the capital letters. Although I would prefer the capital letter as a default mode, I can live with this configuration. The only thing I have to remember now is to double tap the alpha key to leave the alpha mode.

Same thing happened to me. Once I got used to it, it's quick, and capitals is always default because it remembers the last mode. Now I find myself using alpha as a shift on my other 50g with stock Rom, which I find frustrating and a couple of weeks before it was second nature.

(09-09-2015 11:22 PM)Helix Wrote: I have no problem with the cursors, but the modification we discussed privately could be interesting in my opinion, because in this case the letter inside the cursor would be slightly smaller than the current font, avoiding some confusion between the edited text and the cursor.

Yes, that will be implemented. For other readers, the glyphs of the cursor letters will be retouched to be clearer when inverted (with a black pixel all around), so they will interfere less with the text behind.
Soon I'll start work on the editor again to make it multiline and add copy/paste functionality. That's when I'm planning to change the cursors.

Claudio L. · 09-10-2015, 03:49 AM

(09-09-2015 11:51 PM)Han Wrote: I should clarify. I did not mean that NXT should be an actual shift key. However, I recall that the 48/49/50 series could detect multiple keypresses all at once. Can we not detect whether an arrow key is pressed alongside NXT? If so, then would that not be sufficient?

The keyboard driver I wrote tracks the keys, the order in which they are pressed and the time they are pressed and released, and sends messages to the application. This is done to allow for rapid typing. For example, when you type 123 you may press 1, then press 2 then release 1 then press 3 then release 2 and finally release 3. The keyboard driver analyzes all this to determine that you meant to press 123, so it filters out the multi keys. Try typing very fast and you'll see that newRPL won't miss a keystroke, ever. If we want NXT to be pressed with other keys we'd have to disable the filtering. I'd rather get perfect numbers when I type fast than the NXT functionality you described.

(09-09-2015 11:51 PM)Han Wrote: Sounds good to me; I never did like the GUI interfaces.

The only good thing about those menus was the long description vs the 5 letters in a soft key. What about a verbose mode where the same soft menus have an explanation line above? You could highlight a soft key with the cursors and a long description be shown above. The advantage is that once the user learns the explanation, using the soft menu becomes natural.

Francois Lanciault · 09-11-2015, 04:58 PM

Will download this weekend and report back. Are the flashing instructions included in the docs? The last time I flashed my 50G was a long time ago and I really don't remember how to do it.

F.

(09-04-2015 06:57 PM)Claudio L. Wrote: By an overwhelming number of requests (ok, just one but looks better that way) I've made available for download an early firmware image for the adventurous.
It can be downloaded here:

newRPL firmware demo

Everyone is invited to test-drive it and provide feedback. Being an early demo there's many things that don't work, some because they aren't implemented yet, and some because they are buggy. I'd appreciate comments on the latter case so we can start debugging this into a more polished product.

What to expect and not to expect:
* There's no menus, but most commands can be typed in alpha mode.
* The VARs menu is fully functional. It can be hidden/shown by long-pressing VAR.
* No status area yet
* Command line is not multiline yet, and there's no begin/end/cut/copy/paste. Skip word, go to the end, etc. are mostly not implemented yet.
* Keyboard is mostly functional, but there's keys not bound yet to their commands (like HOME or UPDIR, you have to type them).
* The new alpha mode will seem very strange at first, but will quickly grow on you.
* The STO/RCL function was moved to the HIST/CMD location in the keyboard due to the new VARs menu keys interfering with it. Everything else stayed where the 50g had it.
* The OFF function was moved to the battery compartment for now (pull a battery!). The OFF key performs a Warm-Start due to technical difficulties.

Feel free to explore the docs here, and the detailed status to see which commands are already implemented here.
There are a few more commands (several that deal with matrices) that were implemented but not shown in the list yet.

To install the rom, simply put it on an SD card together with a file called 'update.scp' that contains the text 'newrplfw.bin' inside (no quotes). Then do a normal ROM update and it will pick it up. Upon reset, you'll get a confirmation screen that warns you that the initial install will wipe out all RAM. This is your last warning before you lose anything that wasn't backed up.
To restore to stock firmware, just do a paperclip reset and re-flash the stock rom, but you'll have to use the 2MB special version that's in the .zip file to get Port 2 working again.

Let's concentrate the feedback and questions on this thread.
Enjoy! (and report back!)

Han · (This post was last modified: 09-11-2015 06:34 PM by Han.)

As already mentioned in previous posts:

1. Download the firmware (presumably saved to a file named newrplfw.bin) and place it on an SD card.
2. Copy the file over to the SD card.
3. Create a text file on the SD card named update.scp and whose content is simply the file name of the firmwre: newrplfw.bin; save this file onto the SD card.
4. Turn the calculator OFF and insert the SD card containing the files newrplfw.bin and update.scp
5. While simultaneously press and hold both the [+] and [-] keys, insert a paperclip into the reset hole in the back of the calculator; press and release the paperclip. After about 2 seconds release the [+] and [-] keys to see the update screen.
6. On the calculator, select the update option, and select the option to update from the card.
7. When the update is done, you will see WAIT RESET (among other messages). At this point, remove a battery from the calculator (you can optionally remove all the batteries if you wish, but I think a single battery is enough). Then re-insert the battery(s). EDIT: If you are using an HP50G powered by the USB cable, then unplug and then re-plug the cable.
8. A menu should appear with the option to continue (F1 key).
9. If your screen appears garbled after pressing F1, simply turn if OFF (it won't actually turn off, and in fact you cannot turn the calculator off, but it will fix any garbled screen).

Francois Lanciault · 09-13-2015, 10:52 PM

Thank you very much for the detailed explanation.

New RPL firmware installation went smoothly. I got the expected message at the end : WAIT, RESET, ENTER. However, after removing the battery as explained below, I was left with a blank screen and a dead HP50G.

So I tried again, this time pressing "ENTER" instead of removing the battery, same result. In fact I tried a lot of things:

- Removing all batteries, including the button cell
- Waiting a lot of time after removing the batteries before reinstalling them
- Pressing the reset button instead of removing a battery
- RE-installing the 2.15 HP firmware before trying the newRPL installation again
- Changing the SD card
- Tried every keys, played with the contrast
- All of the above on my HP-49G+ instead of HP-50G

In all situations on both calculators I get a blank screen. Every time I re-install the HP firmware the calculators work as before.

Don't know what else to try.

François

(09-11-2015 05:43 PM)Han Wrote: As already mentioned in previous posts:

1. Download the firmware (presumably saved to a file named newrplfw.bin) and place it on an SD card.
2. Copy the file over to the SD card.
3. Create a text file on the SD card named update.scp and whose content is simply the file name of the firmwre: newrplfw.bin; save this file onto the SD card.
4. Turn the calculator OFF and insert the SD card containing the files newrplfw.bin and update.scp
5. While simultaneously press and hold both the [+] and [-] keys, insert a paperclip into the reset hole in the back of the calculator; press and release the paperclip. After about 2 seconds release the [+] and [-] keys to see the update screen.
6. On the calculator, select the update option, and select the option to update from the card.
7. When the update is done, you will see WAIT RESET (among other messages). At this point, remove a battery from the calculator (you can optionally remove all the batteries if you wish, but I think a single battery is enough). Then re-insert the battery(s). EDIT: If you are using an HP50G powered by the USB cable, then unplug and then re-plug the cable.
8. A menu should appear with the option to continue (F1 key).
9. If your screen appears garbled after pressing F1, simply turn if OFF (it won't actually turn off, and in fact you cannot turn the calculator off, but it will fix any garbled screen).

Helix · 09-14-2015, 12:19 AM

After the "WAIT, RESET or ENTER" message, did you try: ENTER, and then remove a battery and re-insert it?

Francois Lanciault · 09-14-2015, 01:16 AM

I must admit I did not tried that particular sequence...

But it did not help, still dead.

François

(09-14-2015 12:19 AM)Helix Wrote: After the "WAIT, RESET or ENTER" message, did you try: ENTER, and then remove a battery and re-insert it?

Claudio L. · (This post was last modified: 09-14-2015 01:05 PM by Claudio L..)

(09-13-2015 10:52 PM)Francois Lanciault Wrote: Don't know what else to try.

The only thing I can think of is that perhaps your firmware image is corrupted. You should try deleting it and downloading again from the link, just to make sure.

We all know there's something making it crash at first try, but everybody else was able to get it working simply by pulling a battery and giving it a second shot. The fact that 2 machines are doing the same tells me perhaps it's the firmware image that's bad.

EDIT: The best sequence I think for you would be: Flash it, and when it says "WAIT RESET", insert a paperclip in the reset hole. The screen will go blank and crash. At this point, pull one battery and put it back. It should work as it did for everybody else.

Francois Lanciault · 09-15-2015, 02:28 PM

I renamed the newrlpfw.bin on my laptop and re-downloaded it from the link above. In both cases the file length is 1364228 bytes.

I re-installed this newly downloaded firmware. At the end of the installation, the total size is reported as 0X0014D0F4.

I reset the calculator, and removed one battery. Wait 10 seconds. Put back the battery. Still dead :-(

Are these numbers ok ?

François

(09-14-2015 01:03 PM)Claudio L. Wrote: The only thing I can think of is that perhaps your firmware image is corrupted. You should try deleting it and downloading again from the link, just to make sure.

We all know there's something making it crash at first try, but everybody else was able to get it working simply by pulling a battery and giving it a second shot. The fact that 2 machines are doing the same tells me perhaps it's the firmware image that's bad.

EDIT: The best sequence I think for you would be: Flash it, and when it says "WAIT RESET", insert a paperclip in the reset hole. The screen will go blank and crash. At this point, pull one battery and put it back. It should work as it did for everybody else.

Han · 09-15-2015, 02:53 PM

This might sound silly, but was your calculator connected to any power source via usb? If so, you may need to unplug it.

As a last resort, try removing all power sources (including the backup cell battery). Turn on the calculator without batteries (to force a drain in power) and then put all the batteries back and turn it on again.

Helix · 09-15-2015, 08:53 PM

Another silly question: do you have fresh batteries?
http://www.hpcalc.org/hp49/pc/rom/

Claudio L. · 10-01-2015, 11:04 PM

A new firmware image is ready for download.
Use the same link from the first post in this thread to get it.

For EXISTING newRPL users only:
----------------- Skip this if you don't have a previous alpha version installed --------------------------
This image had some major internal reorganization to accommodate units, so your existing objects might become invalid after an update. For this reason, a complete memory wipe is recommended after installing this ROM.
To do that:
Press simultaneously On-A-C
The option in the middle is "Clear Mem". However, to avoid accidentally nuking your memory, this requires all 3 shift keys to be pressed simultaneously, so to clear your memory, do:
L Shift + R Shift + Alpha + C (or D, same thing)
You should see a message that install will wipe your memory.
New users obviously need not do this, this is only for people upgrading from the previous alpha. I believe this will be the last major reorganization, as all main object types are now implemented.
----------------- Now here's the important part -----------------------------------------------

New in this version: UNITS!

All units in the AUR are supported. Commands UBASE, UVAL and CONVERT are already implemented.

Features of newRPL's unit system:
* Completely open system, you can define any units you like (but not yet, the command to do that is not included in this version).
* User defined units are system-wide, and don't clutter your directories, so a unit and a variable of the same name will never conflict.
* Syntax 1_[m] is now accepted, is optional on normal objects, but mandatory within symbolics. Previously, typing '1_m/X+2' would include the X as part of the unit, the new syntax allows to properly define what's unit and what's variable, and also resolves conflicts: '1_[m]/m+2' will use unit 'm' and variable 'm' as completely separate things.
* Units can be applied to other objects, like vectors, matrices, etc.
* Exponents in units are fractions, not real numbers, so 1_m^(1/3) will stay 1/3, not 0.3333333.
* Operator _ applies a unit after the fact, to an object in the stack (same as ->UNIT but cleaner). << 2 _m >> will apply the 'm' unit to the number 2 that's already in the stack.
*Temperatures work as described in a recent thread.
* All unit definitions are updated as per latest CODATA recommended values, so they may differ from the values given by the HP48.
* All units are as exact as possible for the selected system precision. For example, the conversion factor between Rankine and Kelvin is 5/9 at any precision, not just a fixed-precision constant ( like 0.55555556).

I invite all testers to check this new module and report any problems. Thank you!

Han · 10-01-2015, 11:25 PM

Can't wait to try this. Quick question: does this release have a usable "OFF" command? Or will we have to remove batteries if we want to turn it off?