22149853@WSUVM1.BITNET (Duane Wessels) (06/15/88)
I just got my old ][e updated to an enhanced ][e. The reason was so
that I wouldn't lose characters when the screen had to scroll. That
works fine, now. What doesn't work, is my printer.
I've had my Epson MX-100 connected for years without any problems.
Now, I get
0408- A0 A0 A0 A0 A0 A0 A0 A0
or something like it inserted every five lines. I know that its not
because of any of the other cards in my slots. I am assuming that
it is because my Tymac interface card is somehow incompatible. It
was made in 1982, and I have no manual for it.
What I would like to know is:
1) Has anyone else had this problem?
2) Is Tymac still around?
3) Does anyone have a used parallel printer interface that
is known to work on an enhanced ][e and with an Epson
that they would be willing to sell or trade?
--- D. Wessels (22149853@WSUVM1)
Acknowledge-To: <22149853@WSUVM1>elliott@glacier.steinmetz (06/15/88)
In article <8806132225.aa05060@SMOKE.BRL.ARPA> 22149853@WSUVM1.BITNET (Duane Wessels) writes: > I just got my old ][e updated to an enhanced ][e. The reason was so >that I wouldn't lose characters when the screen had to scroll. That seems a very strange reason to get enhanced... No decent terminal program would lose characters while scrolling! . . . . . . ... . . . . . . . . . . ... . . Jim Elliott / ...!seismo!uunet!steinmetz!crd!elliott / "Don't look, son, it's / Jim_Elliott%mts@itsgw.rpi.edu [school] a secular humanist!" / (or) elliott@ge-crd.arpa [work] . . . . . . ... . . . . . . . . . . ... . .
22149853@WSUVM1.BITNET (Duane Wessels) (06/19/88)
Jim Elliot (steinmetz!glacier!elliott@itsgw.rpi.edu) writes: > >In article <8806132225.aa05060@SMOKE.BRL.ARPA> 22149853@WSUVM1.BITNET (Duane > Wessels) writes: >> I just got my old ][e updated to an enhanced ][e. The reason was so >>that I wouldn't lose characters when the screen had to scroll. > >That seems a very strange reason to get enhanced... No decent terminal >program would lose characters while scrolling! Thats what I thought! Unfortunately, its not up to the termial program. I tried several and they all had that problem. The problem was definately in the ROMS that I had. As near as I can tell, whenever a the first character of a new line was sent to the screen, the ROMS said "geez, I have to scroll the screen now!" While the CPU was busy doing that, any incoming data was simply lost. I always managed to get the first character of a new line, and miss the next 4 or 5. --- D. Wessels (22149853@WSUVM1) Acknowledge-To: <22149853@WSUVM1>
McAllister@DOCKMASTER.ARPA (06/20/88)
I had my ][e enhanced and indeed had the same experience with a TYMAC parallel interface card. I purchased a buffered printer interface card from ORANGE MICRO (Grappler) and am very pleased with it. The manual from TYMAC would not be very helpful since it is a small pamphlet with some programming tips. The incompatibility appears to be because of stricter adherence to standard I/O protocols in the enhanced version which TYMAC ignored. In the meantime, while you are deciding what to do about your printer card, you can write a software driver to read status at location $C1C1 and output data at $C090. I wrote a short routine and switched it in using P A$NNNN. McAllister at Dockmaster.Arpa
elliott@glacier.steinmetz (06/20/88)
In article <8806191034.aa04168@SMOKE.BRL.ARPA> 22149853@WSUVM1.BITNET (Duane Wessels) writes: >>> I just got my old ][e updated to an enhanced ][e. The reason was so >>>that I wouldn't lose characters when the screen had to scroll. >> >>That seems a very strange reason to get enhanced... No decent terminal >>program would lose characters while scrolling! > > Thats what I thought! Unfortunately, its not up to the termial program. >I tried several and they all had that problem. The problem was definately >in the ROMS that I had. As near as I can tell, whenever a the first character >of a new line was sent to the screen, the ROMS said "geez, I have to scroll >the screen now!" While the CPU was busy doing that, any incoming data was >simply lost. I always managed to get the first character of a new line, and >miss the next 4 or 5. While it is true that the firmware (ROM) scroll routines are slow, ugly and inefficient, and any program silly enough to use them for Screen I/O while doing non-interrupt-driven I/O on a serial port will lose characters during scrolling, my statement is still true: No decent terminal program loses characters during scrolling. There are two ways to solve the problem: The first is to include better screen I/O code in the program, which is faster and also polls the card frequently, so that even when scrolling, incoming characters are buffered. Totally ignoring the ROM screen I/O code is actually a good idea. The second option is to write an interrupt handler and turn on interrupts in the serial card. This way, whenever a character comes in over the serial port, NO MATTER WHAT ELSE MAY BE HAPPENING, it will be buffered by the interrupt handler, to be processed later. (Actually, if you are going to be doing disk I/O you have to be even more careful. But that is a whole other story). Any responsible terminal program MUST do one of these two things if it is to be useful at 2400 baud (probably even lower baud rates) on a //e. I've written two terminal programs which work perfectly fine at 19,200 baud on an unenhanced //e, so I feel qualified to make the above statements. The second program is now documented, and as soon as I add //gs support, I will be making it available as ShareWare (probably later this week). . . . . . . ... . . . . . . . . . . ... . . Jim Elliott / ...!seismo!uunet!steinmetz!crd!elliott / "Don't look, son, it's / Jim_Elliott%mts@itsgw.rpi.edu [school] a secular humanist!" / (or) elliott@ge-crd.arpa [work] . . . . . . ... . . . . . . . . . . ... . .
McAllister@DOCKMASTER.ARPA (06/21/88)
From: Richard K. McAllister ARPA: McAllister at DOCKMASTER.ARPA A correction to my message concerning TYMAC printer cards in response to D. Wessels. The last line of: > In the meantime, while you are deciding what to do >about your printer card, you can write a software driver to read status >at location $C1C1 and output data at $C090. I wrote a short routine and >switched it in using P A$NNNN. Should have been: switched it in using P A$NNNN
kamath@reed.UUCP (Sean Kamath) (06/22/88)
In article <11295@steinmetz.ge.com> elliott@glacier.steinmetz.ge.com () writes: >While it is true that the firmware (ROM) scroll routines are slow, >ugly and inefficient, and any program silly enough to use them for >Screen I/O while doing non-interrupt-driven I/O on a serial port will >lose characters during scrolling, my statement is still true: No >decent terminal program loses characters during scrolling. > . . . >The second option is to write an interrupt handler and turn on >interrupts in the serial card. This way, whenever a character comes in >over the serial port, NO MATTER WHAT ELSE MAY BE HAPPENING, it will be >buffered by the interrupt handler, to be processed later. (Actually, >if you are going to be doing disk I/O you have to be even more >careful. But that is a whole other story). I was under the impression that the real *problem* with the old ROM's were that it turned off interrupts during that long scroll period. Remember, if you SEI, it doesn't matter what's going on, no interrupt will take place. Unfortunately, the ROM hardcopy that came with the original //e tech ref manual is misplaces, since it is not part of the tech ref itself. Since all the new tech refs are for the enhanced //e, looking at them won't help. > Jim Elliott / ...!seismo!uunet!steinmetz!crd!elliott Sean Kamath PS DAMN Inews, I HATE IT! I DON'T WANT TO WASTE MY TIME WITH IT! (sory folks.) -- UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@PSUVAX1.BITNET ARPA: reed!kamath@PSUVAX1.CS.PSU.EDU US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!)
elliott@madison.steinmetz (06/22/88)
In article <9646@reed.UUCP> kamath@reed.UUCP (Sean Kamath) writes: >I was under the impression that the real *problem* with the old ROM's were >that it turned off interrupts during that long scroll period. Remember, if >you SEI, it doesn't matter what's going on, no interrupt will take place. Yup. I stand corrected. It's been so long since I used the wretched firmware screen routines that I have forgotten all their deficiencies. So, my second proposed solution will not work, and the only way to not lose characters is to write your own screen code. Which is a fun and useful exercise in itself, but not for everyone I suppose. . . . . . . ... . . . . . . . . . . ... . . Jim Elliott / ...!seismo!uunet!steinmetz!crd!elliott / "Don't look, son, it's / Jim_Elliott%mts@itsgw.rpi.edu [school] a secular humanist!" / (or) elliott@ge-crd.arpa [work] . . . . . . ... . . . . . . . . . . ... . .
blume@netmbx.UUCP (Heiko Blume) (06/24/88)
In article <11295@steinmetz.ge.com> elliott@glacier.steinmetz.ge.com () writes: > >I've written two terminal programs which work perfectly fine at 19,200 well, since i have this hst modem i have tested around a bit: even with transwarp and accessing the serial card at full speed, no prgm as yet was able do keep up with continous at$ - menues at 19200 bps from the modem. the prgms buffer, but of course you can send the next cmd to the modem while the prgm is still putting out to screen, which causes the buffer to overflow sooner or l8er... till now z-link did best, unfortunately i dont have TIC. anyway i'd be glad to see a prgm that keeps up with that speed ! -- Heiko Blume # DOMAIN: blume@netmbx.UUCP { BITNET: ( mixed } Seekorso 29 # BANG : ..!{backbone}!netmbx!blume D-1000 Berlin 22, West-Germany # Phone : (+49 30) 365 55 71 or ... 365 75 01 Telex : 183008 intro d # Fax : (+49 30) 882 50 65
nakada@husc8.HARVARD.EDU (Paul Nakada) (06/25/88)
In article <1971@netmbx.UUCP> blume@netmbx.UUCP (Heiko Blume) writes: :In article <11295@steinmetz.ge.com> elliott@glacier.steinmetz.ge.com () writes: :> :>I've written two terminal programs which work perfectly fine at 19,200 : :well, since i have this hst modem i have tested around a bit: :even with transwarp and accessing the serial card at full speed, :no prgm as yet was able do keep up with continous at$ - menues :at 19200 bps from the modem. the prgms buffer, but of course you can send :the next cmd to the modem while the prgm is still putting out to screen, :which causes the buffer to overflow sooner or l8er... :till now z-link did best, unfortunately i dont have TIC. :anyway i'd be glad to see a prgm that keeps up with that speed ! :-- :Heiko Blume # DOMAIN: blume@netmbx.UUCP { BITNET: ( mixed } i've tested 3 programs at 19.2 and only zlink can handle it. TIC and Proterm both choke on ttransfers to and from a mac with a direct serial connection at 19.2 ... it probably has something to do with the wa interrupts are handled... do the authors wish to elaborate on the interrupt handling routines? are they the standard Prodos interrupt i/o handlers? -paul -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Paul Nakada '89 #8-) nakada@husc4.harvard.edu Harvard College nakada@husc4.bitnet Cambridge, MA {ihnp4!think, seismo, rutgers}!harvard!husc4!nakada _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_