jmasters@fxrs.intel.com (Justin Masters) (02/07/91)
I have a Radio Shack model 4 w/ Montezuma Micro's CP/M 2.2. I bought a 2400 buad modem a few months back, and while I've endured a problem with not getting the first characters of the line, I can't stand this problem anymore. I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like that). Both worked beautifully for me when I had 1200 baud capability, but now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is it a problem of my machine waiting too long at the end of the line before continuing on to the next line? This is really annoying, and as I have wanted to get on a couple of new bulletin boards around town, I can't effectively use them, since they're menu driven, and the first 3-4 characters are lost, I can't read what character to use for a particular function. Sometimes it's intuitive, but most are not. Has anybody else had this problem? How do you solve it? Is it a BIOS zap? HELP!!!!! -- "We are greatful for the dedication of the men and women serving in the gulf and our prayers are with them. Some say they are just doing their job, but it goes beyond that. They are serving this country and us, and they are serving what we believe in." - Glenn Ballard. | jmasters@fws136.intel.com
MARC.NEWMAN@f601.n106.z1.fidonet.org (MARC NEWMAN) (02/07/91)
>I have a Radio Shack model 4 w/ Montezuma Micro's CP/M 2.2. I bought a 2400 >buad modem a few months back, and while I've endured a problem with not >getting the first characters of the line, I can't stand this problem anymore. >I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like >that). Both worked beautifully for me when I had 1200 baud capability, but >now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is >it a problem of my machine waiting too long at the end of the line before >continuing on to the next line? >This is really annoying, and as I have wanted to get on a couple of new >bulletin boards around town, I can't effectively use them, since they're menu >driven, and the first 3-4 characters are lost, I can't read what character to >use for a particular function. Sometimes it's intuitive, but most are not. > >Has anybody else had this problem? How do you solve it? Is it a BIOS zap? >HELP!!!!! I had problems when I went to 19,200 baud, so I wrote an insert for Ybbat, the Fidonet mailer, which buffers in characters into an internal queue. I can then take characters off the que. You could also use an interrupt driven system. I have a Kaypro, so I doubt my code would do you much good unless your TRS has a Z80 SIO for serial IO. If so, the file is called YBH-KAY1.ASM, and it is on C1: on my system, The Black Box, 713-480-2686, 300-19200 baud. Marc
proppi@veeble.han.de (Paul Lenz) (02/08/91)
In article <316@fxrs.intel.com> jmasters@fxrs.intel.com (Justin Masters) writes: > >I have a Radio Shack model 4 w/ Montezuma Micro's CP/M 2.2. >[...] >I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like >that). Both worked beautifully for me when I had 1200 baud capability, but >now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is >it a problem of my machine waiting too long at the end of the line before >continuing on to the next line? Yes!!! I had had the same problem. My machine scrolls only when the monitor finishes a picture and the electron ray goes to the upmost line. When my BIOS wants to scroll, it is waiting in an ENDLESS loop for a flag. I found that the vert sync signal makes an interrupt. In the interrupt subroutine this flag is set. The CPU escapes from the endless loop and does the scroll. There are two ways to fix this: 1. I copied the complete scroll routine from the BIOS into the modem program and added a SIO polling routine to the endless loop. In this routine the CPU saves the bytes coming from the modem into a special area. So when the CPU waits for the scroll, it gets every byte from the modem. After the scroll the modem program checks this special area and prints the characters. 2. After that, I finally succeeded to make my Z80 SIO working in interrupt mode. So of course the CPU gets every byte from the modem. Proppi PS: Don't mind my bad english! proppi@veeble.UUCP = Paul Lenz / Friesenstrasse 22 / D-3000 Hannover 1 !unido!horga!veeble!proppi voice: +49 511-342451 / And remember: Rock'n'Roll and CP/M never die!!
pittman@mwk.uucp (02/08/91)
In article <316@fxrs.intel.com>, jmasters@fxrs.intel.com (Justin Masters) writes: > I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like > that). Both worked beautifully for me when I had 1200 baud capability, but > now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is > it a problem of my machine waiting too long at the end of the line before > continuing on to the next line? The video driver on your machine is probably too slow in scrolling the screen up when it receives a line feed. Probably the only thing you can do is to get the remote system(s) to send you a certain number of NULL characters (ASCII 0) after each CR/LF. Most BBSs have that capability. ------------------------------------------------------------- --- Darrell Pittman pittman@mwk.uucp --- --- M. W. Kellogg Co. pittman%mwk@lobster.hou.tx.us --- --- Houston, TX (713) 753-4410 --- -------------------------------------------------------------
Murray_RJ@cc.curtin.edu.au (02/08/91)
In article <316@fxrs.intel.com>, jmasters@fxrs.intel.com (Justin Masters) writes: > > I have a Radio Shack model 4 w/ Montezuma Micro's CP/M 2.2. I bought a 2400 > buad modem a few months back, and while I've endured a problem with not > getting the first characters of the line, I can't stand this problem anymore. > > I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like > that). Both worked beautifully for me when I had 1200 baud capability, but > now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is > it a problem of my machine waiting too long at the end of the line before > continuing on to the next line? > > This is really annoying, and as I have wanted to get on a couple of new > bulletin boards around town, I can't effectively use them, since they're menu > driven, and the first 3-4 characters are lost, I can't read what character to > use for a particular function. Sometimes it's intuitive, but most are not. > If you were losing characters at the start of each line at 1200 baud, then you're going to lose twice as many at 2400. The problem is caused because the processor must scroll the screen up one line whenever it sees a line feed. If your system has a separate video controller then it doesn't usually take too long and characters are rarely lost even at high baud rates. If your main processor has to do all the work then characters will probably be lost. The original Apple IIs with 80 column cards were bad in this respect: they'd even lose about 5 characters at 300 baud. The solution depends on the BBS you're calling, as there's probably nothing you can do to fix it at your end. Most BBS programs will let you specify a number of nulls at the start of each line. Try selecting some and see if it helps. ....Ron -- =============================================================================== Internet: Murray_RJ@cc.curtin.edu.au | "You can lead a horse to ACSnet: Murray_RJ@cc.cut.oz.au | water, but if you can Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet | get him to float on his UUCP : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC | something" TCP/IP: 44.136.204.14, 44.136.204.19 | -- Murphy's Law I ===============================================================================
eichin@APOLLO.COM (Mark Eichin) (02/09/91)
>>now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is
Well, I run a custom port of TurboDOS on my Model 4P, and
using a simple CP/M style comm program (it makes the TurboDOS "call
0050h" calls instead of the BDOS ones) it has *no* problems with
newlines. (The RS232 driver in the OS is interrupt driven feeding a
128 or 256 byte (I forget which) ring buffer, which helps a bit.) It
does lose when there is a large amount of text (ie a full 24x80 screen
with mostly 60 columns per line...) but upping the buffer size would
probably solve that. (this is at 2400 baud; I've *never* had loss at
1200.)
There was a standalone comm program that used the same
driver... it would run at 19.2Kbaud without losing data! No OS
overhead at all - the disk had a bootloader which read in the terminal
program, which talked to everything directly.
There is one important trick, which I suspect MM CP/M doesn't
do. The Model 4 video controller has a register which tells it what
address (in the 2K block) should appear at the top of the screen. In
order to scroll, my driver puts blanks in the 80 characters *after*
the last line, then adds 80 to the register (24x80 = 1920, 25x80=2000,
2K = 2048, so there is room...) *poof* instant scroll (or at least,
one that requires touching 80 bytes, not 2000...)
_Mark_ <eichin@apollo.hp.com>
ps. Both the TurboDOS port and the comm program were done by myself
and Jon Luning when we worked for DOKAD Inc, a CP/M consulting firm
that I think is gone now (the president had health problems and didn't
have time to continue to run it, and the technical staff all graduated
and went off to college...) I apologize for not being able to
distribute the code; I'm certainly willing to discuss details of the
code for anyone who wants to try using the same techniques. _Mark_TAGLANCE@ucs.UWPLATT.EDU (LANCE TAGLIAPIETRA) (02/09/91)
>Darrell Pittman <pittman@mwk.uucp> writes > >In article <316@fxrs.intel.com>, jmasters@fxrs.intel.com (Justin Masters) write s: > >> I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like >> that). Both worked beautifully for me when I had 1200 baud capability, but >> now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is >> it a problem of my machine waiting too long at the end of the line before >> continuing on to the next line? > > The video driver on your machine is probably too slow in scrolling the >screen up when it receives a line feed. Probably the only thing you can do >is to get the remote system(s) to send you a certain number of NULL characters >(ASCII 0) after each CR/LF. Most BBSs have that capability. > This is exactly what is happening. The serial port is ignored when the screen is being scrolled. Fortunately there is a solution to this problem. There is an overlay for MEX version 1.14 for the TRS-80 Model 4 which is interrupt driven. The interrupt routine runs asynchronously from the modem in routine, deposting characters into a buffer. The modem in routine which MEX calls, grabs characters from the buffer. The overlay is available in the MEX area of the cp/m file section on simtel, under the filename MXO-RS32.ASM. There are earlier overlays for the model 4 available, but these do not use the model 4 interrupts. Hope this helps, Lance Tagliapietra taglance@ucs.uwplatt.edu or taglance@uwplatt.edu
john@attcan.UUCP (John Benfield) (02/14/91)
In article <7015.27b26608@cc.curtin.edu.au>, Murray_RJ@cc.curtin.edu.au writes: > In article <316@fxrs.intel.com>, jmasters@fxrs.intel.com (Justin Masters) writes: > > > > I have a Radio Shack model 4 w/ Montezuma Micro's CP/M 2.2. I bought a 2400 > > buad modem a few months back, and while I've endured a problem with not > > getting the first characters of the line, I can't stand this problem anymore. > > > > I'm using Qterm 4.2f and I've also used MEX 1.12 (or some old version like > > that). Both worked beautifully for me when I had 1200 baud capability, but > > now it seems that 2400 baud is too fast. Is this true? How do I fix it? Is > > it a problem of my machine waiting too long at the end of the line before > > continuing on to the next line? (text ommitted) > processor must scroll the screen up one line whenever it sees a line feed. If > your system has a separate video controller then it doesn't usually take too > long and characters are rarely lost even at high baud rates. If your main > processor has to do all the work then characters will probably be lost. The > original Apple IIs with 80 column cards were bad in this respect: they'd > even lose about 5 characters at 300 baud. The ModelIV does not have a dedicated video display system. This leaves 3 options. A modem with a good character buffer that captures in response to a flow control signal from the PC. (ie. drop DTR before each scroll call). 2) Line delays on the BBS. (beware of using nulls for timing loops with the ModIV. Some comm packages actually display the NULLs). 3) Cyclic (non)Scrolling. Write your term emulator to go to the top line of the screen instead of scrolling when it hits bottom. DO NOT TRY TO DO A SCREEN CLEAR WHEN YOU HOME THE CURSOR! Clear screens on the IV take 400-700ms. Enough time to lose MAJOR amounts of data. When I implemented kermit on the IV, I had to disabled the status display because it actually slowed down the system enough (doing cursor addressing) to drop characters often enough to piss me off. Cheers. ______Opinions stated are my own. Transcripts available by request______ === =--==== AT&T Canada Inc. John Benfield =----==== 3650 Victoria Park Ave. Network Support Analyst (MIS) =----==== Suite 800 ==--===== Willowdale, Ontario attmail : ~jbenfield ======= M2H-3P7 email : uunet!attcan!john === (416) 756-5221 Compu$erve: 72137,722 ____Eagles may soar, but weasels don't get sucked into jet engines._____