Missing characters on throughput
Ditto to what was said earlier about the quality of the code.  I've been writing code for a terminal emulator on a 16 bit computer.

How the incoming stream is buffered as well as how large the buffer is, impacts whether you drop characters as well as whether the terminal emulator is also buffering the screen in the CPU.  All this also impacts how the screen is scrolled as well.

Examples, I have a BBS.  There is one point where I select to search for new files and it scans over 200 areas.  That command results in over 20K of data being sent to the terminal emulator with my buffer wrapping around on itself.  My buffer is about 9K.  

Not knowing your terminal emulator, if you have a buffer that is less than 1K, you could easily be losing character(s) during a scroll.  And, if the terminal emulator has to read video memory of say something like 23x80 lines to scroll up one line before rewriting that back out, that is a lot of CPU time.  Whereas, if there is a screen buffer maintained so you only write out the 23x80 lines rather than have to read, you have cut video access in half.  Now, if your video processor has the ability to do a hardware level screen scroll in the mode you are in, that is super fast.

There are other tricks as well if your CPU has internal RAM sufficient enough to load code into that section of memory for your code that needs to run at maximum speed.

And, as mentioned, ANSI takes up a lot of time as well versus just pure text display.

There are lots of tricks and nuances between various terminal emulators / telnet clients.

I've got code running on a 12 MHz TMS9995 system at 38.4K with ANSI (not color) while another developer has it running at 38.4K with ANSI color.

It all depends upon the code and something as simple as whether the software is even testing if the buffer wraps on itself.

If you want to do some testing, go to 9640news.ddns.net:9640 .  It's a Mystic BBS on a Windows 64 system.  See if you get overruns, etc.


Users browsing this thread: 1 Guest(s)