rrwood@lotus.waterloo.edu (Roy Wood) (10/02/89)
In a recent posting, someone mentioned using their 8-bit for telecommunications,and expressed an ardent wish for an eighty-column, software-driven display module. I too would like to have an eighty-column communications program that works with an SX212 modem. Does anyone know of such an animal? I must also profess my ignorance in regard to "Bobterm." I assume it is a communications package of some sort, but I've never come across it. (The nice men in the white coats don't let us out too often. :-) ) Can anyone enlighten me on either of these points? R. Wood - rrwood@rose.waterloo.edu
w-darekm@microsoft.UUCP (Darek Mihocka) (10/03/89)
Somebody was just asking about what Bobterm is. It is a public domain telecommications program by Bob Puff, the same guy who wrote ARC, DiskComm, MyDOS 4.5, and other 8-bit disk utilities. For an 8-bit terminal program it's quite powerful, supporting all baud rates up to 19.2 kilobaud. And it can still scroll the screen at that speed! It has the usual set of features like macros, type ahead buffer, xmodem/ymodem/quickb protocols, disk operations, and a capture buffer. I don't know if it supports 80 columns. Probably not. You should contact Bob either on Compuserve or GEnie, or call him at the ACORN BBS in Rochester, NY. - Darek
clf3678@ultb.UUCP (C.L. Freemesser) (10/03/89)
In article <7938@microsoft.UUCP> w-darekm@microsoft.UUCP (Darek Mihocka) writes: >Somebody was just asking about what Bobterm is. It is a public domain >telecommications program by Bob Puff, the same guy who wrote ARC, DiskComm, >MyDOS 4.5, and other 8-bit disk utilities. For an 8-bit terminal program it's >quite powerful, supporting all baud rates up to 19.2 kilobaud. And it can still >scroll the screen at that speed! It has the usual set of features like macros, >type ahead buffer, xmodem/ymodem/quickb protocols, disk operations, and >a capture buffer. I don't know if it supports 80 columns. Probably not. >You should contact Bob either on Compuserve or GEnie, or call him at the >ACORN BBS in Rochester, NY. > >- Darek As SysOp of the ACORN BBS, I guess it falls on me to leave you the number: The ACORN BBS (not it's real name, but it does well here) 300/1200 baud 24 hours a day, 7 days a week, 365.25 days a year 14 message bases 11 file areas 40 megs online And that number: (716) 436-3078 Chris Freemesser, Rochester Institute of Technology | What I like : BITNET: %clf3678@RITVAX GEnie: C.FREEMESSER | 1) My Atari ST USENET: Just reply and hope it gets through | 2) My '77 Mercury Call the ACORN BBS (716)436-3078, 300/1200 baud | 3) Coke Classic
Chris_F_Chiesa@cup.portal.com (12/29/90)
1) What's the most likely reason that a single-sided, single-density, Atari-DOS-2.0S-format autoboot diskette, which works on several dif- ferent Atari 1050 drives, would NOT work on a SS/SD Percom AT88 drive? The Percom makes valiant but unsuccessful attempts to read the disk, whereas the 1050's boot right into the software. I expect you to say that the most likely culprit is "head alignment in the Percom," but YOU tell ME. 2) Lately I have been experiencing "disappearance" of all peripheral devices beyond the first one (D1:) on my SIO daisy-chain. D2:, for example, will start its motor in response to a DIR D2: command from SDX, but no directory (or any other disk-read) data ever reaches the computer. After a while I get only "device not present" and "device NAK" statuses no matter what operation I attempt. The problem goes away if I reseat the SIO cable coming OUT of D1:, but occurs regardless of actual cable swapping. I hypothesize that it is the SIO _CONNECTOR ITSELF_ on D1: that is the culprit. Can someone tell me if I've overlooked something, or whether I seem to be on the right track? Thanks for any and all responses; hope you all had a good holiday and everything! Chris Chiesa Chris_F_Chiesa@cup.portal.com
parsons@matt.ksu.ksu.edu (Scott S Parish) (12/29/90)
Chris_F_Chiesa@cup.portal.com writes: >1) What's the most likely reason that a single-sided, single-density, > Atari-DOS-2.0S-format autoboot diskette, which works on several dif- > ferent Atari 1050 drives, would NOT work on a SS/SD Percom AT88 drive? My guess is the RPM's. Either too fast or too slow. But hey, what do I know, it's just a guess. >2) Lately I have been experiencing "disappearance" of all peripheral You are on your own here. >Chris Chiesa > Chris_F_Chiesa@cup.portal.com --Scott Parish parsons@matt.ksu.ksu.edu
Ordania-DM@cup.portal.com (Charles K Hughes) (12/29/90)
Chris asks about 1050 vs Percom autobooting and about SIO problems... The Percom (to my knowledge) does not work with "Enhanced" density disks. These are the disks that hold 128k (1000+ sectors) instead of the 90K of single density. I know you said the disk was single density, but you might want to check again to make absolutely sure. The easiest way to check is to use a disk editor program and try to read/write sector 721 - don't just look at the DOS structure on the disk, this isn't reliable. If the disk absolutely, positively is single density, then my next guess is that you are using a commercial software disk of some kind that has a nasty form of copy protection on it. The Percom does not act exactly like a 1050, 810, or XF551 and might fail copy protection checks. SIO problems are a bitch. If swapping cables doesn't have any effect, swap positions of the SIO units. So, connect computer to D2: to D1: to (something else) and test the something else. If the something else fails then the SIO connector is indeed at fault. To find out which connector is at fault just swap the incoming SIO cable on D1: to the outgoing SIO connector on D1:. If D1: fails, then the incoming SIO connector is bad, if it doesn't fail AND the something else does fail, then the outgoing connector is bad OR both connectors are bad. In some Atari peripherals the SIO connectors were only soldered in and not screwed down. Check inside the drive, and if this is the case, replace both SIO connectors just to be on the safe side. Charles_K_Hughes@cup.portal.com
zielke@unssun.nevada.edu (John R. Zielke) (12/29/90)
Organization: University of Nevada-Reno Keywords:drives, indus, atari, good luck! Concerning your first question, I use to own an Indus GT it had the same type of problem at times. What it was (an some else eluded to this) that certian software was written to use the speed/timing hole(oops atari never used this) and other sector read techniques that did not always work on all drives. I had a original copy of Rescue of Fractalas and it didnt work on my indus but a friend brought over the same program but the copy protection was broken on it, and guess what... IT WORKED! probably didnt suprise ya. No easy solutions on this one, get a different drive I guess. john zielke
cummins@d.cs.okstate.edu (John Cummins) (12/30/90)
About the disappering devices after D1: We had a pin break off in a SIO cable. I guess if we had pressed it (the cable) into the drive the broken pin's stubbs may have made contact and worked for a bit... Could be a bad connection from the connector to the board also... (in the disk drive...) john cummins cummins@d.cs.okstate.edu (not an 8-bitter at present...)
Chris_F_Chiesa@cup.portal.com (01/04/91)
Thanks to all who've responded to my disk problems, both here and in e-mail. Haven't had time to follow up on any of the suggestions yet, but I sure have a healthy list of possibilities! BTW, several people have suggested copy-protection on the boot disk; I guess I neglected to mention that I made this one MYSELF, from scratch. Just DOS 2.0 and my own AUTORUN.SYS file. Chris Chris_F_Chiesa@cup.portal.com