Visit Atarimax Store


Free-Net Logo
The Atari SIG Historical Archive
Created and hosted by: atarimax.com
[ HOME | GO ATARI | 8-BIT | ST/TT | PORTFOLIO | LYNX | JAGUAR | LIBRARY ]


Article #615 (635 is last):
From: Michael Current 
Newsgroups: freenet.sci.comp.atari.news
Subject: Project: PHOENIX notes
Posted-By: xx004 (Atari SIG)
Date: Sun Feb 21 22:54:47 1999

From: "morloc" 
Date: Wed, 3 Feb 1999 00:33:50 -0500

Project: PHOENIX



Development by: Timothy B. Kline

Logical development: S.T.I.P. (ST.andard I.nterface P.rotocol) modules

Product Design: Cartidge (256K ROM/128K RAM/dual chipset) (estimation)

Programming Language: 6502 Assembly

Supports: TCP, PPP, HTML (text-based)

Machine Requirements: Atari 800/XL/XE, modem

Optional Components: Disk Drive(floppy/hard),printer,mouse/joystick



Introduction: This is a very generalized overlay of the PHOENIX project that
I am presenting to the Atari public from the outset to get feedback. This is
also a rough draft of the project and will likely become more refined as
PHOENIX is developed. Feedback and questions are welcome, as I am new at
some of this and will likely have many mistakes, including in my logic. Let
PHOENIX be an Atari Users PUBLIC-INPUT project since you are the ones that
will be using it.

Modules:

Modules marked with (*) are required to remain in MAIN memory and cannot be
banked!

Modules marked with (+) are cleared from memory after they operate.

1. TCPIP*

A. Provides the tcp/ip stack for user.

2. DIALUP (+)

A. Handles connecting to ISP for user, including login procedures. Used only
to connect to ISP. All other matters are handled by TCPIP module.

B. Memory freed up by KERNEL after successful connection. Reconnection
requires that module be reloaded to run.

3. KERNEL*

A. Browser kernel (OS).

B. Handles com port activity, calls appropriate modules for action after
INIT.

C. Maintains HTML buffer for HTML-IN modules.

D. Frees up memory used by INIT module, DIALUP (after connection returns
"success"), DISPSETUP.

E. Monitors user's inputs via joystick/keyboard/mouse.

4. HMTL-IN

  1.. HTML interpreter (similar to BASIC interpreter which dismisses w/error
any HTML code not supported (HTML 3 so far?)
B. Read in HTML from kernel HTML buffer

C. Convert to PHOENIX' display S.T.I.P. format

D. Send converted code to HTML-OUT S.T.I.P. module for displaying

5. HTML-OUT

A. Receive converted code from HTML-IN module

B. Display page, setup any pop-up boxes containing links on page

1) Determines if display is hi or lo res and formats accordingly

6. DISPSET (+)

A. Initializes custom display according to user's selection (hi/lo res)

7. INIT (+)

A. Runs setup routines, reads in from disk any user preferences/settings

B. Sets variables, checks machine's capabilities (RAM, XL/XE?, etc.)

C. Initializes KERNEL and passes control to KERNEL

8. BUFFER*

A. Stores HTML code for processing

9. POPUP

  1.. Provides a pop-up menuing system for user to access certain features
such
  as page links of a web page.

  B. Provides a simple help system to user as an "online" guide.

  2.. Provides a means to input manually a URL address, in conjunction with
the input box of the web browser.
  3.. Provides user with a list of available "favorites" from disk file and
ability to select one.
10. HTMLED

A. A simple text-based HTML editor for editing HTML files

Notes:

1. S.T.I.P.

  1.. S.T.I.P. is designed for modular use to allow for maximum
expandability of PHOENIX and to allow for optimal trapping of errors.
  2.. Each module interfaces with the KERNEL by using the KERNEL's unique
program STACK. The KERNEL module simply initializes appropriate modules.
Each module MUST PERFORM A SINGLE FUNCTION, and may access the following
permanent modules: STACK, BUFFER, TCPIP.
  1.. C. Additional modules can be interfaced into PHOENIX simply by
injecting itself into the STACK's command table or by the designer providing
a new COMMAND module for PHOENIX which includes his/her module's
call-command.
This gives PHOENIX unlimited potential for all its users and a standardized
means of expandability. Modules can be set up to run from any available disk
drive (floppy, hard, or RAM).

2. BUFFER

  1.. Simply put, this is where all html that is received from the web goes.
Now, because there is only so much memory available on the Atari 8bit, this
is done in the following fashion:
1) html code is received

2) after each "complete" html segment, it is buffered and HTMLIN module is
summoned by KERNEL, which processes the code and passes the processed code
onto HTMLOUT for display.


example: KERNEL receives an html segment from web page and buffers it thus:


Received:

text

KERNEL's action:

Upon receiving the closure html code "", KERNEL considers this a
complete instruction and sends it on to HTMLIN for processing. If there had
been no "" signifying closure, KERNEL would have come to another html
code and dismissed the beginning "" command altogether.

Fortunately, most html editors on the market will check for errors in html
code, so this is unlikely to happen.


This is similar to how BASIC interprets your typing in a command (such as
SETCOLOR) and then reacts. Simple, right? Thus the COMMAND module's
importance comes to light. Want a new feature? Add a command to the COMMAND
table and KERNEL will call it up when it's needed. HTML definitions are
located in the COMMAND module in such a way as to cause HTMLIN to react in
an Atari-friendly fashion, and HTMLOUT, too.

Now you may ask, what about web pages that contain straight text, such as a
textfile, or text that may be found without html tags? Does that, then, just
become ignored? No. The KERNEL is designed to recognize that sometimes this
is the case and will respond thus:

If information continues to be received from a website, but without any html
tags, then it is fed into BUFFER until it becomes full, and then HTMLIN is
flagged to dispose of the BUFFER, treating it as raw text, and it will
certainly display it as raw text, too! The BUFFER is then cleared and ready
to go again. This process continues until an html tag is found or until the
web page finishes loading. Again, though, most people will add a
 tag to their html, so this will work in an html setting. In
the case of a raw textfile, the end will be reached and that is, as they
say, that. Flagging HTMLIN to act on the buffer as raw text is the ultimate
failsafe that you won't miss any information of a web page that is
text-based. However, there is no java support, midi support, etc. in PHOENIX
unless someone figures out how to write the S.T.I.P. module for it. Sorry!

3) process returns to step 1.

3. STACK

  1.. This is a unique system that will provide a means to access various
features of PHOENIX.
  2.. It provides numerous factors such as FLAGS, online condition
(connected/offline), and more.
C. It is designed thus:


1) STATUS TABLE:

STATUS1 [64] [32] [16] [08] [04] [02] [01]

               F    E    D    C    B    A

A- CONNECT ONLINE=255 OFFLINE=0

B- DISPLAY HIGH=255 LOW=0

C- MACHINE XE=255 XL=0

D- CART YES=255 NO=0

E- MODIFIED YES=255 NO=0

F- PATCHING YES=255 NO=0

RAM [64] [32] [16] [08] [04] [02] [01]

         1024  512  320  256  128   64

BANK [64] [32] [16] [08] [04] [02] [01]

       7    6    5    4    3    2    1

[Bank 0 = 0, Bank 8=255]

STATUS2 [64] [32] [16] [08] [04] [02] [01]

          G    F    E    D    C    B    A

A- BUFFER FULL=255 EMPTY=0

B- CONVERT HTMLIN=255 HTMLOUT=0

C- BUFCOMMAND TAG=255 RAW=0


2) COMMAND STACK:

CMDSTACK1 [64] [32] [16] [08] [04] [02] [01]



CMDSTACK2 [64] [32] [16] [08] [04] [02] [01]



4. COMMAND

  1.. This works in conjunction with the KERNEL module in that it will
verify that what is in the BUFFER is html code. It examines the buffer's
start for an html tag, compares it against its command table and if it
doesn't find a match, sets the COMMAND flag to RAW and returns control to
KERNEL.
  If it matches the html tag with a command, it sends it to HTMLIN for
processing, along with setting the CMDSTACK byte to its necessary flags for
HTMLIN.

  2.. Can be modified by enduser or developer to incorporate additional
support, such as music support, or to add additional modules such as
ftp/email. Table for COMMAND is loaded during INIT from either the cartridge
or a diskfile. If PHOENIX is the cartridge version, the user must have set
the flag in his SETTINGS panel to have PHOENIX recognize that the COMMAND
table needs to be patched with add-on commands. The appropriate format for
patching is as follows (text-only!):
  Format for a new COMMAND to be added into table:

  128,command-name,command-module-name,0,255

  The "128" tells INIT that this is an incoming COMMAND patch.

  The "0" designates the end of the patch.

  The "255" signifies end of patching sequence, EOF. If there are more
COMMANDS to be patched, then there would be another "128," after the "0,"
until done, and then the "255."

  3.. There is no check to assure that the original COMMANDS are not
overwritten! However, the flag for MODIFIED is set to high when the COMMAND
table is patched, so if PHOENIX starts behaving erratically, check the
MODIFIED bit to see if the COMMAND table was modified. If it was, and you
want to determine if the patch is at fault, simply set the flag in your
SETUP to disallow patching of the COMMAND table and restart PHOENIX.
  If the problem stops, then you've discovered the culprit!

  4.. Again, this is a wonderful provision of expandability provided to the
enduser. By adding a command for KERNEL to access, you can add power to your
web browser! Your add-in patch can direct HTMLIN to act in certain ways in
response to the code it may have otherwise discarded or shown as raw text,
as an example. You could re-direct it to a file on your floppy drive (if you
have enough room!) or to a hard disk, even. The possibilities are there, if
you have the imagination and motivation to do it. I've made the S.T.I.P.
simple enough that you should have little trouble customizing your own copy
of PHOENIX or making your add-in patches available on the internet for
others to use. The only draw back is that you must use 6502 ML to write the
module. If you don't know ML, there may still be a pseudo-compiler available
at one of the Atari archives that takes BASIC and converts it into ML (I
used to use one from Analog Magazine years ago!) if you want to write it in
BASIC instead.
-------------------------------------------------------

Again, this is nothing more than my initial notes. Some things will change
as the design becomes more firm.

Essentially, PHOENIX will serve as a means for the Atari 8bit user to
connect to the WWW, using what I am calling a "in progress" interpreter.
Simply put: it will act like BASIC's intepreter does, only you aren't typing
in the html it is acting upon (like someone typing in the BASIC program for
you).

The S.T.I.P. concept should allow for a centralized KERNEL and companion
modules and yet allow for either customization or additional components. The
trick will be how to add in new commands in a cartridge setting.

Having established REGISTERS for PHOENIX and aspiring programmers should
ease things, too, since various values and settings will be accessible via a
table of bytes (with flagged bits as the means of discernment, rather than
wasting entire bytes for a particular value).

Conserving memory is vital in the Atari. PHOENIX is being built specifically
to utilize not only VBLANK processing, but memory bank switching, too! Add
to that that my current scenario is to have the browser burned into a 256K
rom cartridge (banked memory), and looking into how 128K of RAM can
accompany that for high-speed writes for caching. and this should be a
decent little web browser for the Atari 8bit!

The credit list will be intact as well, for all those who have been such a
tremendous help with this thus far!







Visit Atarimax Store