[UNAPI] - Telnet Client

Page 2/4
1 | | 3 | 4

By karloch

Paragon (2046)

karloch's picture

10-08-2019, 22:00

Impressive work! I loved the video, definitely the MSX has much to do in Internet and in IP networks in general Smile 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 Smile

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 :)

By ducasp

Expert (86)

ducasp's picture

10-08-2019, 23:30

Grauw wrote:

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! Smile

By ducasp

Expert (86)

ducasp's picture

10-08-2019, 23:28

karloch wrote:

Impressive work! I loved the video, definitely the MSX has much to do in Internet and in IP networks in general Smile 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 Smile

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) :)

By ducasp

Expert (86)

ducasp's picture

11-08-2019, 01:31

Grauw, many thanks, again... This is the result:

https://www.youtube.com/watch?v=eyra-Ju6wvU

I've just enabled this mode (where TP is set) when cursor is disabled. jANSI uses a sprite cursor and it leaves a few black marks on the screen if sprites are enabled even if it is not moving. Perhaps it is just something in their logic, perhaps it is like that (it seems GR8NET telnet client disables the cursor when the screen background color is set to other than black per Karloch video of it), for now I'm happy with this solution. :P

By Grauw

Ascended (8200)

Grauw's picture

11-08-2019, 01:40

The TP flag affects sprites which use colour 0 as well, however you can still have transparency on them by turning the pattern bits off. So there’s not really a good reason in general why TP should be off, other than TMS9918 backwards compatibility. In this case it sounds like the sprites aren’t set up correctly, using colour 0 patterns when there is nothing to display.

By Manuel

Ascended (15539)

Manuel's picture

11-08-2019, 11:19

Very cool! Smile

By karloch

Paragon (2046)

karloch's picture

11-08-2019, 12:24

ducasp wrote:

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) Smile

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.

By karloch

Paragon (2046)

karloch's picture

11-08-2019, 12:28

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?

By ducasp

Expert (86)

ducasp's picture

11-08-2019, 12:55

karloch wrote:

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. Smile I'll test the SEXYZ on HISPA later and let you know the results with this terminal. Smile

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. Cool

By ducasp

Expert (86)

ducasp's picture

11-08-2019, 16:05

karloch wrote:

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). oO

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. Smile

Page 2/4
1 | | 3 | 4