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

[Mark Marlette]

Joel,

You seem to have an understanding of what is going on.

To make a two byte byte buffer of a RS232 pack keep up is going to  
occur is a  reach. That is why you have 16, 32, 64, etc byte buffers  
to cut down on the overhead of the OS retrieval.

Would love to be proved wrong though.

Mark
Cloud-9


Quoting Joel Ewy <jcewy at swbell.net>:

> jdaggett at gate.net wrote:
>> Curtis
>>
>> In my case I do not need the PPP layer. All I need is TCP/IP. My router and
>> firewall does PPPoE already and all I need to do is connect to the   
>> router DHCP
>> server to communicate to the internet.
>>
>> It would be prudent to allow any COCO TCP/IP stack to obtain the IP  
>>  address via
>> a DHCP server.
>>
>> james ...
> For this reason among others, any project like this should be
> modularized.  A CoCo browser should be de-coupled from the network
> component.  Whether the data comes via a TCP/IP file manager under
> (Nitr)OS-9, a Superboard, a SitePlayer Telnet, sz/rz or DriveWire via a
> helper PC proxy or slave CoCo, or arrives on floppy via sneakernet
> shouldn't make a difference to the rendering engine.  The CoCo community
> is too small and diverse to preclude anybody's contribution or
> hardware.  It should be designed transport-agnostic from the outset, and
> made in such a way that any of the above options could be used.
> Obviously some would be faster than others, and some would be easier to
> implement.  But none should be prevented design.  If you have a fast
> network connection, you should be able to use it, and at most have to
> re-write or modify a module or two.  If you have an unconnected CoCo,
> but want an off-line HTML reader, that should also be possible.  If
> somebody can figure out how to make PPP work with a stock CoCo and a
> Deluxe RS-232 Pak, that's great.  But if that's simply impossible, it
> shouldn't have to stand in the way of all the other ways web pages might
> get onto the CoCo.
> How about something like this as a basic structure:
>
> 1:  HTML rendering subroutine module.  This should start off very
> simple.  Just recognize a few basic HTML tags and convert them to
> WindInt display codes.  There's already a Basic09 program that does this
> much, I think.  Then it should learn to handle hyperlinks and inline
> images.  The latter could be handled very simplistically, with the
> presumption that the images have been pre-processed by helper modules
> and saved as down-scaled, 16-color squashed VEFs or something like that.
>
> 2:  User Interface module.  Provide user menus and tie all the other
> modules together.  Manage local caches, load and unload helper modules,
> etc.  Reads a config file to find out what kinds of helpers it has
> available and what their capabilities are.
>
> 3:  HTML pre-processor.  This divides long HTML pages up into more
> easily digestible chunks with a file size boundary -- maybe 8K.  Inserts
> a link to continuation pages.  This can run on the CoCo, on a slave
> CoCo, or on a proxy PC.  Write it in C for maximum portability.  It
> might package the HTML chunks into OS-9 data modules so they could be
> loaded and unloaded from memory as needed.  It should also strip out
> stuff like Javascript that will probably never be of any use on a CoCo.
>
> 4:  Image converter module(s).  Pre-scale images to fit a CoCo screen
> and convert to CoCo-friendly file formats.  This could start out as a
> stub that runs existing conversion utilities (NetPBM comes to mind) on a
> helper machine.  A CoCo version would have to be highly optimized
> assembly language and would optimize for speed over image quality by
> default.  The UI module should provide the user with options for
> re-displaying images of particular interest at higher quality and size.
> This code might run on emulators or FPGA Super-CoCos (CC-Five?) with
> greater speed and better graphics than a stock CoCo 3, so there should
> be a great deal of flexibility here.
>
> 5:  Network transport module.  URLs are passed to this module from the
> UI module, and are interpreted in whatever way is available.  This
> module will probably exist in various forms to handle a variety of
> network hardware.  It could connect to a unix-like helper PC over a
> serial connection, log in as a user, issue wget commands, and download
> the resulting files with sz/rz.  Or it could use a
> microcontroller/ethernet module with embedded TCP/IP stack to get
> files.  On unconnected systems it might just bring up a file browser.
> In early stages it might incorporate the functions of the HTML
> pre-processor and image converter modules, perhaps just by running
> commands on a helper proxy machine.
>
> By modularizing in this way the project becomes easier to envision,
> easier to develop, easier to collaborate on, and it will become clear
> which parts of the process the CoCo can actually do on its own.
>
> JCE
>
>
>>
>> On 9 Nov 2006 at 13:08, L. Curtis Boyle wrote:
>>
>>
>>> On Thu, 09 Nov 2006 12:21:41 -0600, Tad Burnett <tburnett at vermontel.net>
>>> wrote:
>>>
>>>
>>>> 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
>>>>
>>>>
>>>      That's not a bad idea, although I am suprised that one would need long
>>> distance to contact a modem based ISP... here in Canada, pretty well all
>>> ISP's have both (especially for rural areas, where you can't get
>>> broadband).
>>>      I know Mark's Superboard is supposed to have a TCP/IP hardware chip on
>>> it that handles the packet handling, so that would make things much easier
>>> (I believe it even includes the outside PPP layer as well), as well as
>>> some of the protocols within TCP/IP (FTP, etc.), but that would only
>>> appeal to the hardcore hackers who don't mind soldering inside of their
>>> machines (I would have to get someone to do that for me... my soldering
>>> skills suck).
>>>     The only problem with hosting on a local PC is that one would have to
>>> make it cross platform to cover all of the Coco users who also have a
>>> "main" PC... you would have to write for Windows, Linux and OS X.
>>>      The other thing is that since Contiki is on a C-64 (an inferior
>>> machine to a Coco 3), and they did it, is that there is the challenge of
>>> getting it to work on a Coco... which is the reason a lot of us did a lot
>>> of the stuff for the Coco and OS9 over the last 2 decades.
>>>
>>> --
>>> L. Curtis Boyle
>>>