Creating a (very) Simple Telnet client

Por Piter Punk

Master (201)

Imagen del Piter Punk

16-01-2019, 01:11

At the end of 2018 I got some free time and began to thinker with my GR8NET and Obsonet cartridges. Of course one of the tests was to access HispaMSX (and other) BBS.

In MSX2 with GR8NET it's easy, CALL NETTELNET does all the job. Using MSX1 I can use the NETTERM (GR8NET) or the TCPCON (Obsonet and GR8NET), but both programs are very unsatisfatory as Telnet clients (probably because they aren't Telnet clients). To provide a client that suits my wants I changed the TCPCON to act as a "simple" Telnet client.

This client gives to the server the correct window size (columns x rows), terminal type (vt52) and answer other Telnet commands so they don't put garbage on screen. I changed the ESCape key from ESC to SELECT, because ESC is a very useful key in remote applications, and found a way to send the CTRL-C control code instead of aborting the program.

I believe this "way to send CTRL-C" is a source of problems... what I did:

1. In the DEFAB pointed routine:

CLOSE_END:
        cp      #9E                     ;Check if it is CTRL-C
        jr      nz,CLOSE_END1

        ld      a,3                     ;if it's set CTRLC var
        ld      (CTRLC),a               ;to 3;

        xor     a                       ;clear the Interrupt
        ld      (INTFLG),a              ;flag;

        pop     hl                      ;and returns
        ret

        ...from here is the same of CLOSE_END of TCPCON

2. At the beginning of keyboard scanning routine:

        ;--- Check for CTRL-C
        ld      a,(CTRLC)               ;If CTRL-C was pressed,
        cp      0                       ;CTRLC will contain 3
        jr      z,CHECK_SEL

        xor     a                       ;Clear the Interrupt Flag
        ld      (INTFLG),a

        ld      a,(CON_NUM)             ;Sends the character(s)
        ld      b,a
        ld      de,CTRLC
        ld      hl,1
        call    CMD_SEND

        xor     a                       ;Zeroes CTRLC
        ld      (CTRLC),a

        jr      END_F_KEY

It works. But I guess this is a horrible way to achieve the CTRL-C working and a bit worst... using an A1WX with Obsonet and turbo enabled, if I hit CTRL-C it starts to dump the memory contents on screen!!! Obsonet without turbo enabled work fine. GR8NET with turbo enabled works fine. But Obsoned with turbo enabled doesn't works and I can't understand what is happening.

If you want to see the program and the full code, they're available here:

STELNET alpha initial code and binary

I am still testing the software in some configurations. By now it works fine accessing a Linux machine (I did use VI text editor) and BBSs running Synchronet (didn't try others), by now I only got problems with:

  • A1WX + Obsonet + Turbo Enabled = Garbage on screen when hit CTRL-C
  • A1FM + Obsonet = Some random hangups (maybe a conflict with the built-in modem?)

By now, no problems using GR8NET but (again) MSX2 with GR8NET already have the very good NETTELNET terminal emulator to use.

If you have any better idea to handle the CTRL-C case I will be very happy to know :)

Thanks!

Login sesión o register para postear comentarios

Por Grauw

Enlighted (8015)

Imagen del Grauw

16-01-2019, 09:28

Your way of handling ctrl-c seems fine. Tho not sure what INTFLG is for.

Por Piter Punk

Master (201)

Imagen del Piter Punk

16-01-2019, 16:08

The INTFLG is a tip from FRS to prevents CTRL-C to be captured by MSX-DOS's input syscalls.

The console input routines of MSX-DOS check this flag to know if CTRL-C is pressed. The clearing in keyboard scanning routine prevents the INNOE or CONIN to enter in "Wait State" (and need to press CTRL-C again). The other clearing prevents some wrong characters to happens on screen.

Por Eugeny_Brychkov

Paragon (1074)

Imagen del Eugeny_Brychkov

29-01-2019, 15:13

Piter Punk wrote:

Using MSX1 I can use the NETTERM (GR8NET) or the TCPCON (Obsonet and GR8NET), but both programs are very unsatisfatory as Telnet clients (probably because they aren't Telnet clients).

Absolutely correct - they do not understand telnet protocol (RFC 854), they are just terminal applications.