[Color Computer] Re:[coco] www on coco

[Tad Burnett]

Can you find an ISP that will talk to you using the slow baud and packet 
size...
Are you willing to pay long distance charges
 to reach it...

How about the idea of using a PC at your location to serve as a link between
a DSL internet and a CoCo ..
PC could also be used as a mass storage device to connect to a plane Jane
CoCo through the tape drive port...

Instead of hard ware changes to the CoCo that only a few would try
software could be written and shared by many....
Tad

L. Curtis Boyle wrote:

>On Wed, 08 Nov 2006 21:55:11 -0600, George's Coco Address  
><yahoo at dvdplayersonly.com> wrote:
>
>  
>
>>Frank(and all),
>>
>>  My desire for sending and receiving email from a coco outweighs the  
>>need
>>for a laptop. It's a passion.
>>
>>  Meanwhile, I refuse to believe that a coco "Can't" do email on the
>>internet. No one has ever explained exactly why it can't, other than
>>something about "stacks" requiring too much memory.
>>  Since the internet and TCP/IP works on packets, what's the big deal? We
>>just use a hard drive/floppy/ramdisk to make memory. The "internet" will
>>wait for the next packet or a request for a packet and process it  
>>normally.
>> I'm ignorant in this part, but logic tells me that packets are packets  
>>and
>>a coco can send and receive packets.
>>
>> Packets are sent to the intended modern PC at a rate that the modems can
>>handle. If a coco is on a slow modem(9600), then the IP can provide for  
>>that
>>and wait for the next request for a packet.
>>
>>  I am constantly sending and receiving large files between my coco and  
>>this
>>PC at 9600 baud using Xmodem and Ymodem, depending on the file types.   
>>These
>>machines do it flawlessly and I can't see the problem. They use PACKETS!.
>>
>> If anyone can explain exactly why a coco can't do this email thing then,
>>possibly, I will understand. Simply claiming it can't is not good enough.
>>
>>  Please..... I'm not angry. I just want the TRUTH!
>>
>>  Since I started work at my new job at a machine shop, I've discovered  
>>that
>>they LOVE me because I am catching on and today, I actually wrote a  
>>program
>>to build a part.  I only made a few mistakes and my mentor showed me  
>>what I
>>did.
>> He  indicated that he was impressed that I did so well.
>>
>> So why can't I get a handle as to why a coco can't do eMail?
>>
>> "If you think you can't then, you can't. If you didn't know you can't  
>>then,
>>you can"  ME!
>>
>>BTW. .
>>
>> CNC machines are really COOL!!!!  Gene Heskett was right. Modern  
>>software
>>and hardware is where it's at. If I needed to make a few hundred parts,  
>>then
>>this is the way.
>> However, I do "One Off" parts at home, so my coco is the way to go with
>>CNC. I can wait(and watch) until the product is done. My little  
>>dohicky(CNC
>>center) is good to .0005/inch. Good enough for me..... as long as I can
>>figure the math.
>>    
>>
>
>     I had started expermenting with this right before I lost all free time  
>in my life (sigh).... and it IS possible. You _have_ to have fairly large  
>storage (I would say a hard drive is pretty well required... not even a  
>1.5MB RAM drive would cut it for certain websites), but you can negotiate  
>packet size with the provider that you are logging in through (whether you  
>use SLIP or PPP is immaterial), and you would have to write the TCP/IP  
>driver either 1) as an actual OS-9 driver that passes along which packet #  
>it has received to the calling program, and let it sort them out (you  
>won't receive them in order), or 2) as part of the  
>browser/email/newsreader program itself, which can then sort the packets  
>out itself to begin with. One could even do some of the graphics (the  
>additions I did to the 6309 version of VIEW, including GIF animation, were  
>part of this experiment). I also did experiments on increasing modem  
>speeds, and had some quite encouraging results. A few things to do there:  
>1) use a large buffer serial driver (like SACIA/DACIA), 2) change SCF to  
>be able to block read from the driver, like it block writes to GRFDRV (I  
>had a scheme cooked up with 2 mode bit flags that would have to be present  
>in both the driver and the descriptor to enable read and write buffering;  
>if either was not set, it would go back to the single character driven  
>mode it uses now, but if both had the bit set, it would allow up to 32  
>chars at a time in a single transfer; this would allow one to mix  
>buffered/unbuffered drivers, not crash if you mismatched a descriptor and  
>driver, and allow specialized drivers that have buffering for only one of  
>read/write to work as well), 3) change the program doing the reading to  
>use the GetStat call to see if data is on the port, and depending on baud  
>rate, wait for a small, set amount of time or a certain buffer size (the  
>GetStat call also returns how many characters are waiting in the buffer to  
>be read) before reading a whole chunk at a time. This last portion I  
>actually had some test code done (without the buffered SCF), and I could  
>_easily_ keep up with 9600 baud even with hardware text screen updates,  
>and just about with 19200. With a buffered SCF, I am confident one could  
>keep up pretty well. Then, it's just interpreting the HTML code after you  
>receive all of the packets, put them all in order on the hard drive, and  
>figure out what to divide into what files (html, images, etc.) One would  
>pre-render graphics, and possibly convert the raw HTML code, into more  
>Coco native formats to get the speed up when going through a web page.  
>This is the other reason one would need a hard drive... this would take a  
>lot of space. At the very least one would need a large, no-halt drive  
>system (the No-Can2 and up boards with 8 MB of RAM could be used, and  
>maybe 800 or 1.44MB floppy, but no-halt is pretty well mandatory unless  
>you want to view pages offline).
>     I did have a bare start on SLIP (PPP is much more complicated, and at  
>the time I was just experimenting), but didn't get very far on that part  
>of the project. I did get the PLAY command to handle many more sound  
>formats, including a few from the web, and was optomizing VIEW for speed  
>and handling more versions of GIF. I didn't/don't understand enough about  
>how JPG works to figure out how to do that, which has become much more  
>prevalent since then. I was also planning on adding more stuff to  
>Windint/Grfdrv, including insert/delete column, and different font sizes  
>(beyond the 8x8 and 6x8 we have now) into a new, 16K version of GRFDRV),  
>but never got that far (I did bugfix Alan's last additions/optomizations,  
>and added the filled circle/ellipse commands from the level 2 upgrade). I  
>was going to add variable height fonts first, as that would be the  
>easiest, and also allow more text on a screen (a 5 pixel high font could  
>fit 40 rows on a 200 line screen, although you wouldn't have descenders at  
>that point).
>     I have actually been cleaning up the computer room recently, and have  
>found a lot of my "planned for the future" notes (including adding Setstat  
>calls for stereo sound, screensavers, etc.) that I would be happy to pass  
>along to anybody on the current Nitros9 development team if they want to  
>try implementing them. Enough code has changed since I worked on it that  
>it would take me awhile to catch up, and I simply don't have the time  
>anymore to dedicate to such large projects.
>
>  
>