Re: Graphical WWW Browser for 8 bit Apple II computers

[rubywand@aol.com]

In article <hochstrasse-2811961841290001@lanrower2-2.urz.unibas.ch>,
hochstrasse@ubaclu.unibas.ch (Urs Hochstrasser) writes:

>.... The data might be 8 bit (I'm not so
>sure about it before having a closer look) but the data space is probably
>bigger than 256 bytes (i.e. adressable with 8 bits), so 16 bit index
>registers or 16 bit indirect adresses might be more efficient. The 65816
>lets you do this, a 6502 not. And as someone else pointed out, management
>of 'bigger' chunks of memory on an 8 bit Apple II is a nightmare and
>reduces efficiency. On a GS you can use the memory manager, even without
>using the rest of the Toolbox.

     16-bit index registers, the capacity to directly address 16MB,
multiple stacks, and multiple "Zero pages" are big advantages of the
65C816 vs. the 65C02. Since the '816 can switch reg sizes 'on the fly',
tasks for same-speed machines will, virtually always, execute at least as
quickly on the GS as other Apple II's.

     A graphical web browser need not display the large-format pics or,
even, all of the text encountered. (We can use icons for pics and
partial-text links to scrolling windows to manage these.)  It does,
however, need good speed, lots of RAM, hard disk, and a fast modem/cable
interface.

    The hardware requirements do seem most easily met by forgetting about
8-bit II's and just moving to a GS. However, just as GS users point to the
small number of adequately enhanced 8-bit machines, 8-bit users can point
to the advantages of supporting as many Apple II's as possible.

     Besides, GS is not especially well equipped for handling a web
browser, either. The big bottlenecks are RAM and I/O speed. Even a GS
accelerated to 14MHz with 5MB RAM would find it difficult to handle 28.8kB
I/O, the processing of web inputs, and display. (Display capability is not
a major problem unless the objective is to fully display web graphics and
text. Insisting that every A2 web browser user add a SecondSight card is a
dead end. Such a requirement would, likely, kill the project.)

     While an accelerated GS might be able to run a super-res web browser,
most of the machine's resources would be tied up. The browser would be a
programming nightmare, likely to be plagued by bugs. It seems unlikely
that it would match up well against the competition on other platforms;
and, its distribution would be limited to a relatively small number of
users.

     A better approach is to identify key hardware/firmware bottlenecks
and develop a plug-in board which could go into 8-bit Apple II's as well
as GS.


Rubywand