CompuServe Messages

As for CIS adding YMODEM, wouldn't it be more effective if the regular users started leaving E-mail stating that they would like YMODEM? Now, I don't know how much effort was required to get XMODEM i.e. 'pulling teeth'. But if we were to get a goodly sized flood of E-mail going, from not just AmigaForum, but all interested Forums would 'they' respond? You know, the squeaky wheel gets the grease… Bela, before I go on with this I want to say thank you for making me re-think about what I had to say about the serial port and the hardware. I WAS wrong concerning how the DMA is implemented on the Amiga, I commited the gravest of errors by assuming that the 68000 does the DMA, as most computers do, it is in fact transparent to the CPU. I delayed responding because I have been re-reading all the information I have available to me, and I conducted a few tests to try and sort out what is going on here. To your amazement, I still think that there is a potential problem. (persistent bugger, ain't I?) I also believe I'm going to get my point across a bit more coherently this time. I doubt I'm wrong this time, but I've been wrong before, and will be again, I know you or anyone else won't hesitate to point this out! <hehe!> First, I think I should volunteer a well deserved end to my previous subject title, O.K.? To begin with, I want to state that I still believe that multi-tasiking while telecommunicating with the Amiga is restricted under certain circumstances. I should have been more precise in my comments, because I never meant to say that this is a problem while transfering >blocked< data, such as when using XMODEM or any blocked protocol. I also never wanted you to think that this is a problem when >sending< data either. What I did, and still do think, is that there is a problem when receiving a continuous stream of serial data, such as capturing text. I want to clarify this point further, I'm not concerned with short streams but long ones, on the order of five or more minutes at 1200 baud, the time will decrease as the baud rate increases too. I know my reasons were not entirely correct when I first started this, but now I think I can show you where and when this problem can occur. I don't think it is as serious a problem as I originaly thought, but it is possible, if you try to do too much at once! I too thought that the amount of processor time to do serial communications was trivial, it is. The problem is that it does >all< tasks on a more or less equal basis. This is fine, as long as you empty the input buffer on a timely manner. But consider this, if the task that empties the buffer is delayed for any length of time, the buffer is going to overflow. What I'm leading to is this, I want to be able to capture large amounts of text, such as the message base of CompuServe every 3 or 4 days to save money. In that period of time the amount of messages becomes considerably large, so I'd like to be able to do other things while capturing. Unfortunately, most tasks that I want to do require disk access to some degree, and the disk is definately going to cause a problem, but not due to the reasons I previously stated. Originaly I mentioned that Starterm has problems with capturing data to the ram disk. It does, so I have been using Aterm, it works fine in that respect. But, it will lose data also if you start a task that uses the disk. You mentioned that I was being led astray because of the method that Starterm uses to put data to the screen, namely one character at a time. If, as you said, the program sent the whole buffer at once it could handle speeds up to 9600 baud. At this point I have to disagree, for one, Aterm also uses the very same method of screen output. Additionally, your going to have to do it that way because the program has to filter out XON and XOFF as well as other characters that are invalid to the system. So, if both use the same method then there must be something else because one can and one can't. I also don't agree with your remark that the Amiga can handle 9600 baud without blinking. I tried the following to get a rough idea just how fast text can be displayed, it isn't an exact test but I think it is a fair representation of the machines capabilities. I copied a text file of 100,448 bytes in size to the ram disk, it was a CIS message capture. I then used two AmigaDOS commands to output the file to the screen. I tried them in both 60 and 80 modes as set with Preferences. And I also did it after re-sizing the window to it's minHoriz/maxVert and also it's maxHoriz/minVert sizes. Curiously, there was no speed change between the 60 and 80 modes but there was a wide range between full screen and the other sizes. The two commands used were, "Type ram:test" and "Copy ram:test to *", the asterisk denotes the current window. The values I recorded were as follows, the equivalent char/sec is in parentheses. Type Copy ==================================== Full size – 3:08 (534) 2:17 (733) minH/maxV – 3:44 (448) 2:51 (587) maxH/minV – 2:18 (727) 1:27 (1154) Except for the rate of 1154, none of these approach the speed required for 9600 baud or 960 char/sec. True, 1154 >is< faster but that amounts to a display that is 4 lines deep! Sticking with the more realistic Full size figures, you are way below 960. I don't think I'd be too far off the mark by saying that Copy represents the high end of text output. Now this test was a pure data moving test, no disk access was involved and no other tasks were running. This is not the real world, so I started another CLI with the NewCLI command and issued the command "Copy df0: to df1: all". I then went back and tried the same to tests but only with the full screens. The results this time were significantly lower. Type had a cps of 381 and Copy was down to 542. The resulting figures could vary either way depending on how the files on the disk are laid out and how large they are. The point here is that disk activity slows down other tasks considerably. This is where I ran into trouble earlier on, I knew that the disk holds up other things from happening but I was incorrect in my original statements. Hopefully, the following is not far off this time. Before I said that the disk DMA will hog the bus too long for the serial port, This was totally incorrect. What I should have said is that the actual disk DMA is transparent to the CPU and that the blitter steals cycles from the CPU to encode/decode the data to/from MFM format for the disk controller. I can't say how much time the blitter takes from the CPU to do this encoding or decoding, it can't be very long, but the effects are cumulative considering there must be some CPU time devoted to this also. Since the blitter steals from the CPU, both can't do what is required simultaneously. Again, I can't say how long this is, but this time is being taken away from the tasks that are running in the system. This can't be a very long time, how much, I don't know. This all brings me to my statement that multi-tasking and telecommunicating while receiving a >continuous< stream of data is not smart to do. The above discussion only pointed out that the speed of text display is not that quick and that disk access slows down tasks that are active. I now want to point out that the terminal program is a task and in a generalized way it is moving data from point A to point B. With point A being the serial buffer, not the port, the buffer… I don't want to be misunderstood this time! <grin…!!!> Now point B can be the screen and the ram disk, both essentially are the same. We now have basically described the data path, from the buffer through the program on to the screen/ram disk. Let's now expand this, the buffer can have a finite size of 32,767 bytes, that is the maximum. At 1200 baud we have an incoming data rate of 120 cps. If we had instantaneous through-put, the buffer would never fill up. This is not the case here though, the program has to spend a finite amount of time to process the incoming data to check for certain characters such as XON and XOFF as well as characters that are not printable on the display and to filter out carriage returns to name a few. This is why terminal programs spend most of their time in small, efficient loops to minimize the neccesary overhead this processing requires so the input buffer doesn't get filled. Granted, this overhead dosn't amount to much, at most this creates a lag of one, maybe two or three characters behind the input stream. I should also point out that higher baud rates create a longer lag, since the internal data path remains constant but the external data stream has been increased in speed so, there is a net increase. This is also where I commited another error by assuming that you are familiar with the unique implementation that the Amiga uses for text display. I must digress here for a moment to explain this. Most computers use a hardware character generator that is extremely fast, usually on the order of 1,000 to 2,000 cps, even higher. The main point is that the CPU is done with the character almost immediately, this is not the case with the Amiga. It's prehistoric cousin, the Atari 800 was also created by Jay Miner (more specifically, the 3 chip hardware set that both machines have) and used a similar text display method. I have had an Atari 800 XL for almost 2 years and am quite familiar with it.(In fact, I wrote an Enhanced Ram Disk driver for the 256K expansion that last Sep. BYTE carried. the driver is in the AtariSIG of CompuServe.) In the 800 XL's case, it didn't have a blitter to assist it's diminutive 6502 in graphics and text processing. This assumption, which I deeply regret, caused you to remark about the text capabilities that this machine will >never< attain. I must explain here also, the blitter is basically a very hi-speed data mover that can also do some limited logic tasks at a bit level way faster than the 68000 could ever do. That was the basic design goal of the Amiga, to have a set of hardware "assistants" to enhance the performance of the 68000. I am considering purchsing an AMIGA. The one application that I know I would like to use the IBM PC emulator for, is a sophisticated banking packing that is also running on Apple's MAC and AppleII. The bank claims they did not produce it for the C-64, which I own, because the package would not fit. Without any details, any ideas on how succesfull I would be in running the IBM PC version?