|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        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        1024 512 320 256 128 64 BANK        7 6 5 4 3 2 1 [Bank 0 = 0, Bank 8=255] STATUS2        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        CMDSTACK2        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!