Hoppi 1.3.2 Release

[pdo]

Hi all,

For anyone that's interested, I've just uploaded Hoppi 1.3.2 to cloudycat.com. This is a bug-fix release that fixes a problem with using semicolons in file names. Click on http://bitbucket.org/cloudycat/hoppi/downloads for a direct link to the download page.

Hoppi is an application for MacOS that allows easy Kermit communication with HP48/49/50-series calculators.

Note that, although it was my intention to allow any legal MacOS file name characters, there is a problem with backslash (\) characters that is hard to overcome. Since part of the problem is with auto-translating to/from the HP48's Transfer app (which assumes DOS syntax, using backslashes for directory separation), I've decided just to accept this limitation and suggest you do not use backslashes in file and folder names -- Hoppi shouldn't crash (if it does it's a bug), but it may well mangle the names in ways that are difficult to predict/control.

That said, I haven't actually tested against all possible characters, but at least the built-in hp<->unicode character translation gives it a bit of a workout.

All feedback appreciated,
Paul

[JDW]

(07-16-2016 06:37 PM)pdo Wrote:  Hoppi is an application for MacOS that allows easy Kermit communication with HP48/49/50-series calculators.

Paul, is there a reason you chose KERMIT instead of XMODEM in Hoppi?

[pdo]

(07-16-2016 09:43 PM)JDW Wrote:  Paul, is there a reason you chose KERMIT instead of XMODEM in Hoppi?

Well, I wanted something where the user interaction was driven from the calculator, and offered the potential to go beyond simple file/variable transfer. Since Kermit offers lots of features for remote command/script invocation and messaging, and RPL has built-in commands for Kermit packet generation, I thought Kermit would be a better fit.

My original plan was to implement enough of the Kermit protocol to work with the built-in "Transfer" app of the 48/49/50-series calculators, then to consider extending the functionality to other areas. So imagine my disappointment when I found that that app was apparently buggy on the 49G+, the only RPL calculator that I had at the time :-(

However, I then obtained a 48GX and found that "Transfer" works as expected, so I carried on :-)

Since then I have also obtained a 49G and a 50G, but found them also to be buggy :-(

So to cope with the bugginess I started writing my own Hoppi RPL library for the 49/50-series calculators, which is a bit rough'n'ready and still a work-in-progress, but gets the job done at the moment. I have plans for further development, but finding the time to do stuff is always a challenge.

Details on all this are included in the Hoppi Help pages, also supplied as PDFs in the download, and online at Hoppi Help.

Paul

[JDW]

Thank you for the detailed information, Paul!

James

[JDW]

Paul,

I installed the highly praised HP48 backup software BKUP46 to my 48GX today and then proceeded to press the BKUP key on the calc to backup to my iMac with Hoppi 1.3.2 open and ready. (I had no cards in the 48GX, and only a few libraries in the calc's port 0 RAM.) BKUP46 backed up one 52410 byte file named "HPAUG15.BAK" to my iMac just fine, and then it proceeded to download something else separately (which seems odd, since I think it should backup everything into one file). But before it finished, I saw an error on the calc and on Hoppi. And in addition to the "HPAUG15.BAK" file was a second file named "L1303.0" -- whatever that is. Anyway, both errors vanished before I could write them down, and then a subsequent error in Hoppi as follows:



It was after that last error message that I I clicked on the View menu in Hoppi and opened both the Packet Logger and the Message Logger, but both were blank. What would have cleared both logs?

I then clicked the Reset button in Hoppi, deleted both files ("HPAUG15.BAK" & "L1303.0") from my iMac, and pressed the BKUP menu key again on my Calc. It started backing up to "L1303.0" for some reason, and after a few packets finished it created a second "HPAUG15.BAK" file and proceeded to transfer 830 packets (52397 bytes) when Hoppi gave me an "unsupported command" error, followed by the second error shown in my screenshot above.

This second time I tried the backup, I had both the Packet Logger and Message Logger windows open during the backup, and this time Packet Logger retained all the information, while Message Logger was still blank. But when I then closed the Packet Logger window and reopened it, it was blank. Is that right? Am I supposed to keep both windows open and then never close them in order to see the logs, otherwise the log data will be deleted?

Please note that I have transferred many games and libraries from my iMac to my 48GX via Hoppi 1.3.2 over the past week, and this is the first problem. So I guess it's just a bad piece of software (despite all the praise I've read given to BKUP46) rather than a problem with Hoppi.

Thanks.

[pdo]

(08-15-2016 06:25 AM)JDW Wrote:  I then clicked the Reset button in Hoppi, deleted both files ("HPAUG15.BAK" & "L1303.0") from my iMac, and pressed the BKUP menu key again on my Calc. It started backing up to "L1303.0" for some reason, and after a few packets finished it created a second "HPAUG15.BAK" file and proceeded to transfer 830 packets (52397 bytes) when Hoppi gave me an "unsupported command" error, followed by the second error shown in my screenshot above.

Hmm, looks like BKUP46 is issuing some Kermit command packet that Hoppi doesn't support. If you look at the last few packets in the packet logger you might be able to see what command Hoppi is objecting to, but I admit that would require some Kermit knowledge.

When I have some time I'll look into this myself too.

Quote:This second time I tried the backup, I had both the Packet Logger and Message Logger windows open during the backup, and this time Packet Logger retained all the information, while Message Logger was still blank. But when I then closed the Packet Logger window and reopened it, it was blank. Is that right? Am I supposed to keep both windows open and then never close them in order to see the logs, otherwise the log data will be deleted?

Yes, for good or bad, that is the expected behaviour: packets/messages are only logged when their respective windows are open. Maybe I should revisit this decision.

Paul

[JDW]

Paul,

Thank you for your reply.

If I send you the log, up to the point when the error occurs, would that help you find the problem?

You may also want to consider adding Hoppi here, to give it more exposure:
http://www.hpcalc.org/hp48/pc/link/

You can use this submission form:
http://www.hpcalc.org/contribute.pup

James

[pdo]

(08-15-2016 01:21 PM)JDW Wrote:  If I send you the log, up to the point when the error occurs, would that help you find the problem?

No need, I've just downloaded BKUP46 and recreated the problem myself. It seems that BKUP46 sends an F generic command (in a G packet), which just means "Finish", and to which no response is necessary. Unfortunately I haven't implemented this in Hoppi, so it sends an "unsupported command" message back to the calculator causing the transfer to fail :-(

However, the good news is that the fix for this is almost trivial :-) I've tested it just now and the backup transfer works okay.

My only problem is that I'm wondering if there are any other features missing that BKUP46 relies on -- looks like quite a sophisticated program, with which I am completely unfamiliar. I think I need to fiddle around a bit with BKUP46 and do a bit more testing before releasing a new version of Hoppi.

Quote:You may also want to consider adding Hoppi here, to give it more exposure:
http://www.hpcalc.org/hp48/pc/link/

You can use this submission form:
http://www.hpcalc.org/contribute.pup

Yes, I really should get around to that sometime :-)

Paul

[pdo]

(08-15-2016 06:58 PM)pdo Wrote:  I think I need to fiddle around a bit with BKUP46 and do a bit more testing before releasing a new version of Hoppi.

Well, I created a multi-part backup with a library in port 0, then restored it as per the documentation, and all went well. So I've created a new release (1.3.3) in the usual place at http://bitbucket.org/cloudycat/hoppi/downloads.

What I should really do at some point is go through all the Kermit generic commands and implement them (at least those that make sense for Hoppi).

Anyway, thanks for reporting the problem James. Let me know if you find anything else...

Paul

[JDW]

Paul,

Thank you for the Hoppi 1.3.3 update!

I did a backup using BKUP46 today and it worked without error. Not sure why it still creates a separate file called L1696.0, in addition to the *.BAK file, but it does. I guess that is a BKUP46 issue rather than a Hoppi issue.

But after I finished the backup, I used ALLMEM to check memory. ALLMEM tells me 10265.5 bytes are used. The *.BAK file on my iMac is 4478 bytes, and the L1696.0 file (whatever the heck that is), is 1388 bytes. I performed the BKUP46 with the CONFIG set to backup Port 0 (which I assume is a required CONFIG change needed to backup everything on the 48GX). Even so, it still backed up less data than ALLMEM reports.

To see what would happen, I pressed BKUP a second time on the calc. It started to backup but then stopped with an error saying it could not overwrite an existing filename. Hoppi reported the same. So I am not sure if "filename overwrite" is simply not supported by the BKUP46 program on the calc or if Hoppi doesn't support it. That's why I mention it here.

Another thing I noticed is that now I am seeing a number one "1" at the very top of the LCD, almost in the middle horizontally, but perhaps a tad shifted to the left. Do you know what that "1" means? (I/O transfer error?) I am not able to clear it using ON-C. Do you know how to clear it?

The next thing I did was to install something big into System RAM, so as to have a bigger backup to test Hoppi 1.3.2. So I used Hoppi to install ALG48.LIB (50k), INT.LIB (7k), LONG.LIB (6k), SPECFUN.LIB (6k) and AKEYS (325 bytes). I then performed a backup (without specifying any port in the {} brackets of BKUP46) into a different directory on my iMac. Hoppi backed up to a single *.BAK file that was 23847 bytes. ALLMEM says I have 97005.5 bytes stored. So I tried it again...

I deleted the *.BAK file but kept the same directory in Hoppi. I then press CNFG in BKUP and pressed the PORT menukey and set it to { 0 }, which should make BKUP backup everything, including all my libraries (which are all stored in System RAM). I then started the backup. Once again, it started saving *.0 files for some reason. I guess the zero "0" filename extension means those are "libraries" stored in Port 0? Anyway, it saved the following, from top to bottom in that order:

L1696.0 (1388 bytes)
L909.0 (50204 bytes)
L913.0 (6544 bytes)
L912.0 (6039 bytes)
L911.0 (5852 bytes)
HPAUG17.BAK (23977 bytes)
[6 files totalling 94004 bytes]

94004 bytes doesn't match 97005.5 bytes reported by ALLMEM, but when I use ALLMEM now, it reports 97138.5 bytes used. So who knows how to interpret this! I guess it's close enough.

To further test Hoppi and to test a RESTORE (which I've never done before on an 48GX, since I am still new to the 48GX), with the calc ON, I pressed ON-A-F and then NO to wipe out everything. And to my delight, that wicked "1" atop my LCD is now gone too. Yipee!

The BKUP46 documentation (section 8, No.3 of BKUP_DOC.TXT) says I need to use I/O to transfer the *.BAK file from my computer (via Hoppi) to my 48GX, which I did. No errors from Hoppi. I then pressed the VAR button and then pressed the softkey associated with the name of the variable for my *.BAK file, which put "Backup HOMEDIR" on the stack. I then typed RESTORE and pressed ENTER. After a couple seconds it finished and I see the names I had before in VAR, but LIBRARY is still empty. So I then followed Section-8, No.5 of the BKUP46 instructions which says to type the name of my *.BAK file and put that name on the stack, which I did. I then pressed the VAR key, then entered the BKUP directory, then pressed the softkey for RESTO. That made the calc start receiving L911.0 and the rest of the *.0 library files. I then turned the calc OFF then back ON, then did an ON-C warmstart, then returned to the BKUP directory so I could press STK to restore the stack. Everything seems to be working. There were no errors from Hoppi. ALLMEM reports 97090.5 bytes used.

Thanks again, Paul.

[rprosperi]

(08-17-2016 02:49 AM)JDW Wrote:  Another thing I noticed is that now I am seeing a number one "1" at the very top of the LCD, almost in the middle horizontally, but perhaps a tad shifted to the left. Do you know what that "1" means? (I/O transfer error?) I am not able to clear it using ON-C. Do you know how to clear it?

The "1" you see is just showing that User Flag 1 has been set. You can clear it by doing "1 CF". This is likely some sort of status indication from your backup program, but I'm not familiar with that program.

The L1696.0 file made by the backup program is almost certainly a library (number 1696) which the backup program somehow can't work with so it likely makes a separate copy. Wild speculation: Perhaps the backup program uses this library and it can't store it since it is in use. To see what libraries are installed use [LS] [2] [LIBS] to see a list of the installed libraries with name, number and port.

[pdo]

(08-17-2016 02:06 PM)rprosperi Wrote:  The L1696.0 file made by the backup program is almost certainly a library (number 1696) which the backup program somehow can't work with so it likely makes a separate copy.

From my brief usage of BKUP46 I can say that L1696.0 is the name it gives to the file that is a backup copy of library 1696 in port 0. It backs up all port objects separately to the main HOME directory. Then restoration is a 2-step process: first restore the HOME backup in the normal way with the RESTORE command, then issue the BKUP46 RESTO command which goes and retrieves all the library files and puts the recovered objects in the appropriate ports.

Paul

[pdo]

(08-17-2016 02:49 AM)JDW Wrote:  To see what would happen, I pressed BKUP a second time on the calc. It started to backup but then stopped with an error saying it could not overwrite an existing filename. Hoppi reported the same. So I am not sure if "filename overwrite" is simply not supported by the BKUP46 program on the calc or if Hoppi doesn't support it.

There is a checkbox in the Hoppi main window labelled "Allow Overwrite". This must be checked for Hoppi to allow files to be overwritten. Hopefully you didn't have it checked and Hoppi did the right thing, otherwise it's a bug :-)

Otherwise, glad to see things are working for you.

Paul

[JDW]

(08-17-2016 06:11 PM)pdo Wrote:  ... Hoppi main window labelled "Allow Overwrite". This must be checked for Hoppi to allow files to be overwritten. Hopefully you didn't have it checked and Hoppi did the right thing, otherwise it's a bug :-)

You're right. I didn't have that checkmarked in Hoppi.

Thank you for the helpful advice, Bob & Paul!

[JDW]

Paul,

It's been a while since I launched the Hoppi 1.3.3 app on my iMac. I am now running MacOS Sierra and I get an error when trying to launch:



The round, green Hoppi icon just jumps endlessly in the Dock.

This is true regardless of whether I have my 48GX connected to the iMac or not. I also downloaded the 1.3.3 Intel DMG just now and tried launching it from the disk image, but I get the same dialog as you see in my screen shot above.

Any thoughts?

Thanks,

James Wages

P.S. I just got home from work and tried it on my home iMac, also running Sierra. Same problem. Hoppi worked fine on this iMac at home prior to the Sierra update, so it's pretty clear there's some kind of OS conflict.

[pdo]

(12-07-2016 12:35 AM)JDW Wrote:  I am now running MacOS Sierra and I get an error when trying to launch:

Oh no, that's disappointing! Unfortunately I don't have access to macOS Sierra (my mac mini is too old), so this is going to be difficult to figure out.

However, one aspect of Hoppi that irked me the last time I worked on it was that I couldn't build a functioning app with the latest release of Clozure CL (1.11), only with the previous (1.10) release. The problem I had was something to do with startup (I can't remember the details now), but I'm wondering if it could be related in some way.

So my plan right now is to get Hoppi working with Clozure CL 1.11 on El Capitan, then see if it fixes your Sierra problem.

Paul

[JDW]

(12-07-2016 02:08 PM)pdo Wrote:  So my plan right now is to get Hoppi working with Clozure CL 1.11 on El Capitan, then see if it fixes your Sierra problem.

Thanks, Paul. Hopefully that will bring clozure to this problem! :-)

--James W.

[pdo]

(12-07-2016 02:08 PM)pdo Wrote:  So my plan right now is to get Hoppi working with Clozure CL 1.11 on El Capitan, then see if it fixes your Sierra problem.

Hi James,

I've uploaded a new version of Hoppi built with CCL 1.11, the file's called Hoppi-1.3.4-rc1.dmg at http://bitbucket.org/cloudycat/hoppi/downloads

Works fine on El Capitan, please let me know if it works for you on Sierra.

Thanks,
Paul

[JDW]

Paul,

Although I don't have my 48GX here at the office, I downloaded and launched Hoppi 1.3.4-rc1 with success this time under Sierra! So it would appear you gave it the Midas Touch!

I will try some file transfers later tonight and report back here if there are any problems. But based on what I see, it looks like it should work just fine.

Many thanks and best wishes!

James W.

[pdo]

(12-12-2016 12:05 AM)JDW Wrote:  But based on what I see, it looks like it should work just fine.

Excellent news! I'll prepare a proper release in the next day or so -- updating the documentation and tagging the repository.

Thanks for your help in reporting and testing this,
Paul