Impressive work! I loved the video, definitely the MSX has much to do in Internet and in IP networks in general 
I am glad that there is now a fully featured TELNET client that allow any MSX UNIAPI compliant device to connect to BBSes at high speed and even download files
I just want to point out that using GR8NET you get the same lighting fast speed in any MSX. I made another video putting the TurboR CPU in Z80 mode before entering in the BBS and there is not noticeable speed difference with R800 mode. I checked that turbo LED remained off and that the cursor sound was loud, just in case GR8NET would decide to switch back to R800 on his own.
About the COLOR 0 issue, I remember Carlos de Santa Ana mentioning that when he was developing ANSTEL. As you said, it will behave correctly if screen background color is black before connecting. I think a dirty fix would be to store the current background color at the program begin, then switch the background to black and upon exiting return the background to the stored color.
If you need me to do something on my side of the BBS, I will be glad to help :)
Try setting the TP bit (5) in VDP register 8 to 1. If you’re lucky JANSI is already writing the correct colours to VRAM and that’s all that’s required to make the VDP not treat colour 0 as the border colour.
From Basic: VDP(9) = VDP(9) OR 32
(Basic has a +1 offset on VDP register numbers > 8.)
Thanks a milion Grauw! That does the trick!
Impressive work! I loved the video, definitely the MSX has much to do in Internet and in IP networks in general I am glad that there is now a fully featured TELNET client that allow any MSX UNIAPI compliant device to connect to BBSes at high speed and even download files
I just want to point out that using GR8NET you get the same lighting fast speed in any MSX. I made another video putting the TurboR CPU in Z80 mode before entering in the BBS and there is not noticeable speed difference with R800 mode. I checked that turbo LED remained off and that the cursor sound was loud, just in case GR8NET would decide to switch back to R800 on his own.
About the COLOR 0 issue, I remember Carlos de Santa Ana mentioning that when he was developing ANSTEL. As you said, it will behave correctly if screen background color is black before connecting. I think a dirty fix would be to store the current background color at the program begin, then switch the background to black and upon exiting return the background to the stored color.
If you need me to do something on my side of the BBS, I will be glad to help :)
Hi Karloch,
If you can enable YMODEM-G officially in SYNCHRONET options, I think that will solve one issue that is when I force YMODEM-G over YMODEM, the BBS won't wait the other end to request the next file after the last file is done and then reply with a file with no name to indicate transfer is finished. At least selecting YMODEM-G on my Syncrhonet local BBS it works like a charm when selecting in the BBS YMODEM(G) :)
Very cool!
If you can enable YMODEM-G officially in SYNCHRONET options, I think that will solve one issue that is when I force YMODEM-G over YMODEM, the BBS won't wait the other end to request the next file after the last file is done and then reply with a file with no name to indicate transfer is finished. At least selecting YMODEM-G on my Syncrhonet local BBS it works like a charm when selecting in the BBS YMODEM(G)
Ok, I already enabled the YMODEM-G protocol. Actually, it's not Synchronet the one who upload or download files, but an external program. In UNIX environments it's common to use the GNU lrzsz, that is the Synchronet default in UNIX; this one doesn't support YMODEM-G, but...
When Synchronet runs from WIN32 or DOS environments, it uses his own transfer program SEXYZ. Initally SEXYZ was not available for UNIX, but now it's there and I could enable the support for YMODEM-G. I tested it with SyncTERM and it's working like a charm.
As I can't test the client right now on my real MSX, I wanted to point something important. ANSTEL and GR8NET TELNET clients do something important: they set the MSX charset to the IBM extended ASCII. This is not needed with non-japanese MSX as they already have it.
So the big question, do the TELNET client displays extended chars correctly on japanese MSXes?
Hi Karloch,
Yes, once it detects jANSI is installed, it will change jANSI character set to the IBM one. I'll test the SEXYZ on HISPA later and let you know the results with this terminal.
P.s.: do you have the contact of ANSTEL developers? It doesn't work on UNAPI, just Internestor, but I understand it does use two "drivers" to make the ANSI rendering work (v9938 and gfx 9000) instead of using jANSI.... Perhaps they can allow me to use the drivers and share how those drivers work. 
As I can't test the client right now on my real MSX, I wanted to point something important. ANSTEL and GR8NET TELNET clients do something important: they set the MSX charset to the IBM extended ASCII. This is not needed with non-japanese MSX as they already have it.
So the big question, do the TELNET client displays extended chars correctly on japanese MSXes?
Ymodem G now works fine for a single file (before, the protocol that was YMODEM and was tricked into going to G, on a single file wouldn't wait the last request to reply that there are no more files), but stopped working with YMODEMG batch (YMODEM batch is fine) if transferring long files.
I would need to look into a Wireshark capture to confirm and can't do that right now, but I believe the issue is that as YMODEMG is streaming and has no ACK, BBS has.finished buffering data into my interface buffer and it took more than 3s to get the next file request (as MSX was getting from buffer the last remaining KB and saving to disk). Perhaps the protocol can be tuned server side to allow a larger time tolerance, curious thing is that this doesn't happen on Synchronet BBSs hosted on Windows machines (I've tried a few over the internet), perhaps it is another thing at the client side as the file transfer still has its quirks (works mostly with Wildcat and Synchronet BBSs, other BBSs like Worldgroup and Mystic it is failing mis transfer). 
Another thing, I'm not sure if it is possible, but X and Y modem are using 128 bytes blocks... The 1K version is much more efficient and I think that almost any terminal supports it nowadays.
