[Color Computer] Re:[coco] www on coco
mark at cloud9tech.com
Fri Nov 10 16:21:54 EST 2006
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.
Quoting Joel Ewy <jcewy at swbell.net>:
> jdaggett at gate.net wrote:
>> 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
> 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.
>> 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>
>>>> Can you find an ISP that will talk to you using the slow baud and packet
>>>> 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
>>>> 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....
>>> 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
>>> 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
More information about the Coco