Tiny Remote Control for DOS

[ibmapc]

...Here's a link to Mike Cs effort for those interested http://www.vintage-computer.com/vcf...9-new-FAST-DOS-VNC-like-remote-control-server...

I got Mike C's remote Host running on my XT and his Client running on my Dell NetBook with Win 7. It works fairly well with the expected performance issues, ie Video lag, slow host response. But I don't know if one can expect more from a 16 bit processor choked by an 8 bit buss and a 10 base T Lan card. It's fun to play with but not very practical.

Still talking with Josh via E-mail, Trying to get Tiny working. Will update if anything changes.

Greg

 

[mbbrutman]

You raise an interesting question - performance ...

To send an 80x25 text screen to a remote machine requires 4KB. To do that 15 times per second requires 60KB/sec.

*Any* older 8088 class machine with an Ethernet card can do that (and more), but assumes that it is doing nothing but blasting packets out as quickly as possible. I've gotten over 100KB/sec on a NEC V20 equipped PCjr, and that was using TCP/IP which is a heavy protocol. UDP is much less stringent, and UDP without checksums is about as fast as it gets. (On a local network you don't need the checksum - the Ethernet CRC will protect you from corruption.)

You need to leave time for the actual programs that are supposed to be running. I think that in 80x25 mode you have more than enough CPU cycles to make it usable. At worst case you have to drop to 10 frames per second.

Graphics is a much different story. A CGA display in graphics mode needs 4x the bandwidth. Using a paint program across the network might be frustrating. ;-0



Mike

 

[jonnymacuser]

For an alternative approach to remotely control a DOS computer you might as well look at the RMENU package available here: http://www.bttr-software.de/products/jhoffmann/. It operates differently and certainly has advantages and disadvantages compared to TINY but isn't that the fun with free software that you can freely try various ideas to see which one you like best?

Great stuff! RMENU is pretty easy to setup as a telnet server on a 5150, you just need to have a WATTCP.CFG file, the RMENU package, and load up your packet driver on at least DOS 3.3.




The configuration options seem to be a pretty complicated though, and I find myself intensely studying the manual just to figure it out


.... And I just crashed it ... and I'm at work..., nowhere near my 5150.

 

[Caluser2000]

Keep at it. It's cool folk have put the time and effort to produce these programs.

Received a copy of PcAnywhere complete with bright yellow null-modem cable last week. It includes the dos/win3 versions. I'm going to give that a shot. Ok it's old, "booo hiss" a commercial product and doesn't do tcp/ip but I'm curious to see how well it works

 

[MikeS]

Keep at it. It's cool folk have put the time and effort to produce these programs.

Received a copy of PcAnywhere complete with bright yellow null-modem cable last week. It includes the dos/win3 versions. I'm going to give that a shot. Ok it's old, "booo hiss" a commercial product and doesn't do tcp/ip but I'm curious to see how well it works

Odd; the yellow cables were usually parallel-link cables...

What version is it? The old DOS versions could only do Serial, NetBIOS, Netware IPX or Banyan, but the later Windows versions could certainly do TCP/IP over the Internet.

 

[Ole Juul]

. . . you just need to have a WATTCP.CFG file, the RMENU package, and load up your packet driver on at least DOS 3.3.

Actually it's not a package. It's a single executable - although it does need a configuration file.

Odd; the yellow cables were usually parallel-link cables...

Was this some kind of standard, or a particular manufacturer? I've got one of those which I collected for it's coolness, but wasn't sure about it's wiring.

 

[MikeS]

Originally Posted by MikeS:
Odd; the yellow cables were usually parallel-link cables...

Was this some kind of standard, or a particular manufacturer? I've got one of those which I collected for it's coolness, but wasn't sure about it's wiring.

The official Laplink package included a yellow parallel DB25P<>DB25P cable and a blue doubleheaded DE9S/DB25S<>DB25S/DE9S cable; no idea whether anyone else made equivalent cables in those colours, but there are certainly all sorts of compatible cables in grey/beige, both parallel and serial.

If your yellow cable is 25-pin male to male then it probably is a parallel Laplink-type cable; you can check the connections, they're in the Interlnk help file as well as on the 'web.

 

[Caluser2000]

Odd; the yellow cables were usually parallel-link cables...

You are quite correct it is a parrallel cable, which is better still. Didn't remove it from the cable from the box as I was just interested in getting a look at the dos pdf on cd, which is what I was really interested in anyway and what I was refering to re no TCP/IP support. It's Version 8.0 so has win3/NT4/win9x software with it. I've got a beige 2 headed serial null-modem cable and parallel laplink cable.

Did the later releases of pcAnywhere have all the earlier versions on them?

 

[MikeS]

Did the later releases of pcAnywhere have all the earlier versions on them?

This is Symantec; what do you think? The various versions (and there were quite a few) are also not always compatible with each other, needless to say.

Yeah, the DOS (version 5.0?) manual is from the Norton days and is excellent reading, all 356 pages of it.

BTW, presumably Ole was asking whether the yellow colour was a standard, but the parallel link is a network standard: PLIP, similar to SLIP but (you guessed it) parallel instead of serial.

 

[Mike Chambers]

edit: posted in wrong thread

 

[wiwa64]

Great stuff! RMENU is pretty easy to setup as a telnet server on a 5150, you just need to have a WATTCP.CFG file, the RMENU package, and load up your packet driver on at least DOS 3.3.

The configuration options seem to be a pretty complicated though, and I find myself intensely studying the manual just to figure it out

Is it really that complicated? The manual is supposed to tell you all the necessary details and there also is an example configuration file.

If all that doesn't help you, just ask.

 

[Trixter]

To send an 80x25 text screen to a remote machine requires 4KB. To do that 15 times per second requires 60KB/sec.

*Any* older 8088 class machine with an Ethernet card can do that (and more), but assumes that it is doing nothing but blasting packets out as quickly as possible. I've gotten over 100KB/sec on a NEC V20 equipped PCjr, and that was using TCP/IP which is a heavy protocol. UDP is much less stringent, and UDP without checksums is about as fast as it gets. (On a local network you don't need the checksum - the Ethernet CRC will protect you from corruption.)

You need to leave time for the actual programs that are supposed to be running. I think that in 80x25 mode you have more than enough CPU cycles to make it usable. At worst case you have to drop to 10 frames per second.

Graphics is a much different story. A CGA display in graphics mode needs 4x the bandwidth. Using a paint program across the network might be frustrating. ;-0

I think this can be taken even further. If I were extending this, I'd hook the keyboard, mouse, and video BIOS/interrupts, and only transmit when either were called. That way the host program can run full speed unless something NEEDS to get sent over. For programs that also just update without user interaction, I would send 1400 (or whatever the MTU is) bytes hooking INT 08. Yes, it would take a few ticks to get the entire screen updated, but having the screen update in "slices" gives the user immediate feedback.

This would result in really swift updates that hardly affect the speed of the host program. Sending 4K 10 or 15 times a second surely would (on 808x-class machines).

 

[Mike Chambers]

I think this can be taken even further. If I were extending this, I'd hook the keyboard, mouse, and video BIOS/interrupts, and only transmit when either were called. That way the host program can run full speed unless something NEEDS to get sent over. For programs that also just update without user interaction, I would send 1400 (or whatever the MTU is) bytes hooking INT 08. Yes, it would take a few ticks to get the entire screen updated, but having the screen update in "slices" gives the user immediate feedback.

This would result in really swift updates that hardly affect the speed of the host program. Sending 4K 10 or 15 times a second surely would (on 808x-class machines).

that's an interesting method. that could be added to my program. instead of sending an update on every clock tick though, it just sends the screen when the client requests it. i thought that would keep it simple to modify the refresh rate from the client-side depending on what kind of machine the server is running on. i've found 4 to 8 updates per second on an 8088 keeps things reasonably quick.

http://rubbermallet.org/remoter-source-code.zip

 

[wiwa64]

I'd hook the keyboard, mouse, and video BIOS/interrupts, and only transmit when either were called.

This will fail if a program writes directly to the screen buffer without any user interaction which is not uncommon under DOS. Imagine a TSR that constantly displays the current time in some part of the screen. Such a program is very likely to write directly to the screen buffer both for efficiency reasons and to avoid reentrancy problems when calling BIOS.

But if you can afford another 4K of RAM, you could simply keep a copy of your last screen content, compare the current screen buffer against this copy and send only those lines that have actually changed. If you cannot afford that much memory, you could make use of the fact, that the MDA adapter actually has room for a total of eight screen pages, which are rarely used.

If you dislike such kinds of "dirty tricks" you could calculate a checksum for each line and just store that sum instead of the entire line. This way you only need 25 words of storage. This checksum has to be designed carefully, just summing up the characters on the screen would not be sufficient as it misses changes where just the position of characters within the line changes but not the characters themselves. Imagine e.g. an editor window where some space characters are inserted and the rest of the line just shifts to the right.

In any case it might be useful to make a full screen update every ten to sixteen times just be be sure.

 

[Ole Juul]

. . . you could make use of the fact, that the MDA adapter actually has room for a total of eight screen pages, which are rarely used.

OT: Thanks wiwa 64! That explains how my MON.COM TSR can not only switch monitors, but can save 8 screens, yet takes up less than 1K of RAM. I always wondered where those saved screens went.

 

[Trixter]

This will fail if a program writes directly to the screen buffer without any user interaction which is not uncommon under DOS. Imagine a TSR that constantly displays the current time in some part of the screen. Such a program is very likely to write directly to the screen buffer both for efficiency reasons and to avoid reentrancy problems when calling BIOS.

That's why I wrote the later bit in my last post about hooking INT 08 and updating the screen in regular slices.

But if you can afford another 4K of RAM, you could simply keep a copy of your last screen content, compare the current screen buffer against this copy and send only those lines that have actually changed. If you cannot afford that much memory, you could make use of the fact, that the MDA adapter actually has room for a total of eight screen pages, which are rarely used.

Available memory isn't the problem on 808x platforms; it's memory access time and CPU speed. Even a super-quick REP CMPS to find the first changed byte and then sending from that byte forward would take more time than simply sending data.

 

[Mike Chambers]

That's why I wrote the later bit in my last post about hooking INT 08 and updating the screen in regular slices.



Available memory isn't the problem on 808x platforms; it's memory access time and CPU speed. Even a super-quick REP CMPS to find the first changed byte and then sending from that byte forward would take more time than simply sending data.

yep, that was what i was doing at first. comparing was much, much slower than just sending the whole screen without any checks.

 

[wiwa64]

Available memory isn't the problem on 808x platforms; it's memory access time and CPU speed. Even a super-quick REP CMPS to find the first changed byte and then sending from that byte forward would take more time than simply sending data.

I must admit, i never tried my RMENU on a (true 808x) but i am still not fully convinced.

The amount of 4k data sent over ethernet has to be split into at least three packets with all the overhead of the CSMA/CD protocol. On a somewhat loaded net, would that still be faster? And how about the case that not the TELNET server, but rather the client was a 8088? Wouldn't it in that case be better if the client had only to update a few lines instead of the whole screen? Seems the problem is more complex than it appears.

 

[Mike Chambers]

I must admit, i never tried my RMENU on a (true 808x) but i am still not fully convinced.

The amount of 4k data sent over ethernet has to be split into at least three packets with all the overhead of the CSMA/CD protocol. On a somewhat loaded net, would that still be faster? And how about the case that not the TELNET server, but rather the client was a 8088? Wouldn't it in that case be better if the client had only to update a few lines instead of the whole screen? Seems the problem is more complex than it appears.

trixter is very much right. there's much more overhead in comparing lines on the screen and sending out smaller updates than there is in sending out the entire screen at once. i've tried it myself. it is several times slower.

 

[jonnymacuser]

Is it really that complicated? The manual is supposed to tell you all the necessary details and there also is an example configuration file.

If all that doesn't help you, just ask.

I guess its complicated to me when I'm trying to do this stuff at around midnight whith limited brain function left.


On the topic of the RMENU.MEN configuration file:

MORE rmenu.men Display the configuration file <--------------this works!
MORE rmenu.doc Display the program documentation <-------this works too! ( I guess you could make it display any .doc file? like a telnet "library"!)
MOREL * "*.txt" "*" Display text file from list <--------------I forget what this one does ...
SYSM dir Show the current directory <----------this shows a dir of where you place rmenu.exe, can you change dir's, i.e., "cd"?
SYSV set Show the environment <----------------also forget what this does ...
SYSI date ^m Get/Set host date <-----this is to be avoided! it makes the server hang, (until I manually enter the time/date ON the actual machine itself).
SYSI c:\command ^Cexit^M real DOS command prompt ( use EXIT to return ) <----this idea of this is AMAZING, however it crashes a lot and I can't get it to work.
SHELL "[RMENU] " emulated DOS prompt ( use EXIT to return ) <--------what's the difference between real/emulated mode?
SETL 0 TEST: €�‚ƒ„…†‡ ˆ‰Š‹Œ�Ž� �‘’“”•–— ˜™š›œ�žŸ *¡¢£¤¥¦§ ¨©ª«¬*®¯ øñýáöù <---------huh? what's this for?
ansi 0 Turn ansi mode off
ANSI 1 Turn ansi mode on
SETL 24 Client displays 24 lines
SETL 25 Client displays 25 lines
SETL 34 Client displays 34 lines


It would be great if the manual had more examples of how to operate/configure RMENU for some common use cases, i.e.:

--running a program
--downloading files
--uploading files
--re-booting into RMENU if there's a crash