When you would like to install in a different path then the default, this is not possible using hubg. It would be useful when you choose for inStall that there is a question to which path before installing.

To be able to specify the destination directory (override the default destination in the yaml file). Example:

hub install vi a:\utils

This then should install vi in the a:\utils directory.

I tried to install the musicpac several times, and it ends in an HTTP error 400 several times. Every time I have to remove the installation and then start all over again. With a reinstall option, hub should check if the files installed are the same as on the server and then skip them.

At dos.c file in create(...) function there are jumps to open_noerror and open_error labels instead of create_noerror and create_error jumps.

It is odd that 'hub' seems to be a package managed by hub. Under what circumstances can a user interact with the 'hub' package? It seems some special protection is required.

hub upgrade hub deletes the files in the hub installation directory and then locks up.

This leaves things broken.. the hub\config directory is still there.
To recover, I went back to the 'hget' instructions for installing hub, then ran hub configure, proceeding at the warning that config already exists.

Not sure if this is only on nbasic and only on that nbasic.bin file, at least the nbasic.bin file issue is easy to reproduce if you go to msxhub website and try to download nbasic.bin individual file and inspect the downloaded file you will see the same bad contents of the file. This has been reported by a msxhub user in Brazil, since there is not a server specific git and it doesn't seem to be a package issue (the zip file download ok and files there are correct), thought about opening an Ossie here. Thanks 🙂

Line 1129 of hub.c:

created_dirs[0] = '\0';

This is clearing the created_dirs list every page interation, so, if there is dir created on page 1 and another one created on page 2 (for a package whose file list spans over 2 pages), the dir created on page 1 won't be stored, as saving the created dirs is done after all pages are processed.

My suggestion is that just moving it to line 1114, before the for loop to iterate all pages, will avoid this of occurring.

Hello!

I compiled now msxhub and got that error. I compiled it because the last release wasn't working for me.

If I access that URL from the computer I get:

The page you are looking for is no longer here, or never existed in the first place (bummer). You can try searching for what you are looking for using the form below. If that still doesn't provide the results you are looking for, you can always start over from the home page.

Did the repo changed location? Am I doing anything wrong?

Thanks!

Hi, we are unable to download the hub.com tool using hget. The MSX is connected to the net, but when using hget to download the tool, it detects a 9K file and never completes the download. You always have to cancel the operation, otherwise it never finishes.

When going to the website https://msxhub.com/start and clicking the download link. We get a file not found message.

Previous downloaded files are also not working anymore and are not downloading new packages.

I don't think this 'K' makes any sense there... when downloading AKID.COM from 'kids' package, progress shows values as: 24576K, should just be 24576 cause that's bytes, or 24K or 25K if you want to round up... since transfer blocks seem to be in 1024 byte chunks.

Or just drop the 'K'

Hi,

I've suggested an option to Konamiman HGET based on how Louthrax works with files, enhancing performance of his applications. Pre-allocation of the file greatly enhance performance in my test scenario (and I believe in most scenarios as Louthrax did this and tested on other MSX's) doubling transfer speeds with HGET, and I believe it can do the same for MSX HUB. Unfortunately at this moment I do not have a prototype / example of this change in MSX HUB, but as you say that you used Konamiman hget as a reference, perhaps my prototype of change to it might help. I've posted my suggestion, a prototype C file with changes and the possible shortcomings in:

Konamiman/MSX#4

Best regards,
Oduvaldo

[SofaROM v3.2]
https://www.louthrax.net/mgr/

Hola, la última versión de SofaRom es 3.2 .
En https://msxhub.com tenéis la 2.6-1 .

Gracias.

I use custom installation paths for the packages, but when I upgrade them, they are reverted to the default installation path.

Desired behavior would be the package manager realizes the software is installed in a custom directory and then use it for the upgrade.

Thanks for your work!