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

[L. Curtis Boyle]

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.

-- 
L. Curtis Boyle