Need your opinion regarding GR8NET capabilities

Impossible for now to edit boot sequence with GR8NET :/

Hello, I have to revive the network implementation topic. Recently I found that there is already an existing one (didn't know about it as was not interested in network devices for MSX), the UNAPI one.
Developers need to have a standarized one, and if this one already exists then IMO it should be used. Can't program the same for each device.
In example, obsonet also has its own one
http://www.konamiman.com/msx/obsonet/onetm-e.txt
So which one should we use? It will not work for other devices anyway.

The solution is the UNAPI one. For GR8NET I think the best one to implement is the TCP/IP UNAPI as the hardware itself can handle the TCP/IP processing. Look at differences.
http://www.konamiman.com/msx/msx-e.html#tcpipunapi

The TCP/IP UNAPI specification is here
http://www.konamiman.com/msx/unapi/tcp-ip-unapi-10.pdf
This is, create in device BIOS entries to those function specifications. GR8NET already have very similar functions, so probably can be adapted much of them.

If wanted can also implement the Ethernet UNAPI, but is not mandatory really.
http://www.konamiman.com/msx/unapi/ethunapi11.txt

The more confusing probably could be how to implement an UNAPI specification. The manual is here
http://www.konamiman.com/msx/unapi/unapi11.txt
Basically is the same process used for any EXTBIO device to get the API info (like functions and other tables addresses), but as many devices would use the same device identifier (22h or DE = 2222h) then it uses the F847h address for device to set there data after calling EXTBIO.

The UNAPI specification also says not to use page 2, and I think GR8NET uses it. Probably this could be solved using a mapped ROM (so it can change bank on the same page) plus/or putting some helper routines in page 3 at device initalization.

I could be wrong (correct me if the case) but I think it works like that.

For a reference about how EXTBIO works, MSX-DOS2 memory mapper routines could be used as example.
http://map.grauw.nl/resources/dos2_environment.php#c5
In this case we ask for a complete table as the functions have a base address and then an offset for each one.
In the case of TCP/IP UNAPI I think we have to ask for each one we are going to use as there is no table with offsets defined in the specification.

I think everyone should help as can to achieve this as probably many doubts will arise during the TCP/IP UNAPI implementation.

+1.000, Totally agree at this point. There is no sense of having different implementations for networking functions, specially considering that we alreadt had UNAPI TCP/IP specification.

I have the Gr8Net now .
My opinion on its capabilities is that I love this cartridge device!
There is a solution to allot of things that in other cartridges are not solved that easily, for instance;
On my Sony HB-F700, the FM-PAC is not active when going into a certain mapper mode, but with a command to fake OPLL ROM into mapped RAM, CALL NETFKOPLLR, you can solve it. You can disable all sound expansion signals going into the machine, so you can mix the PSG separately by flipping a small switch.
On my Turbo-R it also works like a charm.

There are so many options, that maybe I will write a config program for it that might speed up configuring it for certain purposes.

Question, does there exist a GUI FTP program without usage of Symbos?

In order to explore its capabilities in Basic I did some small setup programs. It's not much yet, but it might become something. It's more user friendly to set stuff up while you see what happens. The strings and variables behind the call commands quite often obfuscate what really happens and a check in the manual is needed after which some puzzling is needed. But since the device can do so much, I guess it'll be quite some work and it's not going to be perfect nor complete.
I'd like it if some pro coder would start coding a complete setup tool. I'm just fooling around a bit