@(A): New Addressing Modes =09
The 816 can utilize all 14 original addressing modes of the 65XX line,
and adds 10 more for a total of 24. The new addressing modes are as
follows:
* Absolute Long al
* Absolute Long Indexed al,x
* Absolute Indirect (a)
* Absolute Indexed Indirect (a,x)
* Direct Indirect Long [d]
* Direct Indirect Long Indexed [d],y
* Stack Relative d,s
* Stack Relative Indirect Indexed (d,x),y
* Relative Long rl
* Block Move xyc
Let's take each under consideration:
@(A): Absolute Long Mode, Absolute Long Indexed Mode
These modes allow a programmer to access a fully qualified memory
location without using the DBR. The benefits include pulling data from
one bank to store in another without constantly changing the DBR. The
disadvantages include the extra size of the instruction. The long forms
of these two absolute modes takes an extra byte in memory and an extra
cycle to load into the CPU. Note that only the X register is supported
as an index register for absolute long indexed mode.
@(A): Absolute Indirect Mode
This mode, denoted as (a), functions similar to (d), but does not
require the D register. The locations in bank 0 specified as the
operand in this mode are accessed, and the results form the lower 16
bits of the effective address. The PBR is prepended to this address to
form a final 24 bit address. The PBR is used since only the JMP opcode
uses this mode.
@(A): Absolute Indexed Indirect Mode
This mode, denoted as (a,x), functions similar to (d,x), but the D
register is not involved. Thus, as with the (a) mode above, these modes
are to direct modes as absolute long modes are to absolute modes.
@(A): Direct Indirect Long Mode
This mode functions similar to Direct Indirect Mode, except that in part
2, all three address bytes are pulled from memory. The DBR and PBR are
not involved, but the D register is used. If locations $10 - $12
contained $10, $11, $12, and the D register contained #08, then:
a7 08 lda [$08]
would load the accumulator with data starting at $121110. Do you see
how that works? The D register is added to $08, and the result ($10) is
accessed to fetch the 24 bit memory address, in low byte order.
@(A): Direct Indirect Long Indexed Mode
As Direct Indirect Indexed Mode extends Direct Indirect Mode, this mode
extends the above mode by adding the Y register to the effective address
pulled from bank 0. Note that even though this mode uses a fully
qualified 24 bit address (no DBR or PBR involved), it can still
increment into the next bank to access memory. Thus if we use the above
example, and Y =3D $ffff, executing:
b7 08 lda [$08],y
will fetch the accumulator starting at ($121110 + $ffff, or $131109).
@(A): Stack Relative Mode
Denoted as "d,s", this mode is completely new to 6502 programmers. It
starts off the set of modes that work with the S register (Stack
Pointer). As the Stack Pointer is now 16 bits in width, the stack can
fill all of bank 0. Although 65XX programmers have traditionally used
stack locations only for saving return addresses from JSR and interrupt
sources, the '816 allows one to store data on the stack. In this mode,
the 8 bit operand is added to the S register and normalized to 16 bits.
Memory in bank zero is accessed starting at this effective address.
Since the S register points to the next location to hold data,
executing:
a3 00 lda $00,s
would prove meaningless, unless you wanted to get the last byte pulled
off the stack. This mode allows one to access the last 255 bytes off
the stack in the order they would be pulled off.
@(A): Stack Relative Indirect Indexed Mode
By far the most complex Addressing Mode to understand in the '816, this
mode can be used to access data referenced by pointer values on the
stack. Denoted as "(d,s),y", the effective address formed by the 8 bit
operand and the S register is normalized to 16 bits and 2 bytes are
accessed. The resulting 16 bits are appended to the DBR register and
the 24 bit effective address is added to the Y register to form a final
24 bit memory address. This can be used to access data passed by
"reference" (not the value, but the pointer to the value, is stored in
the stack).
@(A): Relative Long
Only one opcode uses this addressing mode, Branch Long (BRL), and it
fulfills the desire of every 65XX programmer to have a relocatable jump
instruction. Unlike normal branches, BRL can cross page boundaries.
However, BRL is constrained to the current bank. It cannot cross banks. =
Although viewed as a disadvantage, this presents a few possibilities.
If a programmer was at $xxff00 and wanted to jump to $xx0000, he or she
can use BRL, even though the offset appears wider than $32767, the
maximum offset for BRL. In actuality, the assembler computes a branch
to the next bank, which is only 256 bytes away. The CPU negates the
bank increment, thus forcing execution to begin at the current bank.
@(A): Block Move
Along with stack relative indirect indexed mode, this mode is complex.
However, unlike its stack counterpart, this complex mode is easier to
understand. Denoted as xyc, this mode allows the programmer to quickly
move areas of memory from one bank to another. An example will prove
helpful:
a2 00 20 ldx #2000
a0 00 30 ldy $3000
a9 ff 0f lda $0fff
44 02 01 mvn $01,$02
Basically, we are moving $1000 bytes from $012000 to $123000. The X
register holds the offset into the source bank; the Y register holds the
offset into the destination bank. The accumulator holds the number of
bytes to move MINUS 1. Remember that. The opcode Move Negative (MVN)
takes the source bank and the destination bank as operands. The only
opcodes that utilize this mode are MVN and Move Positive (MVP). MVP
assumes the X and Y registers hold the top of the data areas to move,
while MVN assumes the opposite.
@(A): Hints And Tips That Will Decrease Your Stress
Writing Machine language applications on any platform is bound to create
stress in your life, but this section is presented to make the
programmer aware of some "gotchas" in the '816. Here goes.
@(A): Initialization
To switch the processor from emulation mode into native mode, perform
the XCE (eXchange Carry with Emulation) mnemonic with the carry bit
reset:
18 clc
fb xce
The next thing to do is determine the initial size of your registers.
The 816 can use any register as 8 bits or 16 bits. By default, the
registers are 8 bit, but just to make sure:
c2 30 rep #%00110000; set index and acc to 8 bit
By stuffing $30 into the processor status, we are setting both the X and
M flags to 8 bit.
At this point, it should become obvious that if the programmer wishes
to flip between 8 and 16 bit modes many times, macros need be employed
to do this quickly and painlessly.
Now, the development can begin.
@(A): Register Usage
Never underestimate the power of immediate mode to mess your program up. =
If at all possible, switch to one size of registers and stay that way.
If that can't be accomplished, thoroughly document where you changed the
size of either set of registers. Remember, the assembler cannot trace
program execution, so don't assume the assembler will fix everything up
for you. On the preliminary version of the SAS assembler, the opcodes
to instruct the assembler to alter immediate mode behavior are:
.inl ; INdex registers Long
.ins ; INdex registers Short
.acl ; ACcumulator Long
.ins ; ACcumulator Short
What happens when you change a register's size? Well, let's treat the
index registers and the accumulator separately. When changing from 8 to
16 bits, the index registers are simply extended by padding with zero.
When the index registers are changed from 16 bit to 8 bit, the high byte
of each index register is lost and forced to zero. On the other hand,
the accumulator is actually made up of two 8 bit registers. When
changing from 8 to 16 bit, the accumulator's high byte becomes the value
in the hidden B register. When moving from 16 to 8 bit, the high byte
of the accumulator is forced to zero, but the B register is left intact. =
Thus, changing from 8 to 16 bit and back to 8 bit won't affect the
accumulator, but it will force the high bytes of the index registers to
zero.
When using the MVN and MVP opcodes, the size of the index registers make
a difference. If set to 8 bits, one can only transfer memory from page
0 of any bank. However, unlike the index registers, MVN and MVP treats
the Accumulator as 16 bits wide, regardless of the state of the M flag.
Also, what length the registers are set to determines how many bytes are
pulled or pushed during register to stack operations. Remember that
when pushing from one location and pulling in another.
To execute emulation mode code in Native mode, simply set all registers
to 8 bit widths, load the D register with 0, and load the stack with
$01ff. By manipulating the DBR and PBR, you can execute up to 256
emulation mode programs, while at the same time using this method.
In the '816, there is no need to use a register to zero out memory. The
"stz" opcode can be used in the same manner as "sta" to zero out memory. =
Note that, like "sta", stz will store a single or double byte 0
depending on the state of the M flag.
Remember that, when the accumulator is set to 16 bits, the BIT
instruction no longer copies bits 6 and 7 to flags in the P register,
but bits 15 and 14.
@(A): Timing
Beware of absolute long addressing. It takes 1 more byte and 1 more
cycle to utilize. Use it sparingly.
In Native mode, there is no penalty for crossing a page in memory. This
should allow some programs to actually run faster in Native mode.
BRL can be used at any location a JMP would be used. The advantages
include self-relocatable code, but the disadvantages include an extra
cycle for execution.
By now, you have noticed that MVN and MVP provide a fast way of moving
data areas. However, they can also be used as a fast fill. Simply
store the fill pattern into the first address of the memory area, load
the X register with the start of the fill area. Load Y with the start
plus the length of the fill pattern. Load A with the size of the fill
area minus the fill pattern size minus 1. Then, do a mvn h,h, where h
is the bank you want to fill. Any size pattern can be used.
@(A): Stack Instructions
Many of the added instructions in the 65816 deal with enhanced stack
operations. In addition to the S register and accumulator pushes and
pulls, you can now programmatically push all the registers except PC
onto the stack, and pull all but the PBR and PC register off the stack.
Note that some registers have variable sizes, while others are fixed in
width. The breakdown is as follows:
Fixed at 8 bits: DBR, PBR, P
Fixed at 16 bits: D, S, PC
Variable: X, Y, A
In addition to using the stack to save and restore data and registers,
addresses can now be programmatically pushed to and pulled from the
stack. The following opcodes are available:
f4 34 21 pea $1234 ; Push Effective Address 1234 on stack
d4 21 pei ($21) ; Push Effective Indirect Address at D + $21
; on stack
62 e1 7f per DATA ; Push Effective Relative Address on stack
; when executed, the address PC + $7fe1 will
; be pushed on the stack. Useful for
; determining data area locations in
; relocatable code
@(A): Transfer and Exchange Operations
When using the accumulator as an 8 bit register, the special hidden B
register can be used as a "hidden" register. Move it into focus with
the XBA (Exchange B with A) opcode. Note that this is a swap, not a
transfer.
Transferring between same size registers in unambiguous. Transfers
between different size registers is tricky. If the accumulator is set
to 8 bits, only that much can be transferred in, but all 16 bits will be
transferred out to any 16 bit register, regardless of the state of the M
flag. If an index register is set to 8 bits, only that much will be
transferred in or out.
@(A): Addressing Modes
Beware of Direct Mode. Any address that can be represented by a single
byte will be assembled into Direct Mode. Sometimes, absolute zero page
addresses are desired. Use the "!" directive to force absolute
addressing.
Beware of Direct Mode II. Remember that zero-page is no more. If you
intend to use z-page as before, remember to set D to $0000.
@(A): Miscellaneous
This article is presented to new CMD SuperCPU programmers. Whether you
write SuperCPU applications in Emulation or Native mode, however, you
will find the following information helpful:
The SuperCPU contains a set of registers to control operation of the
unit programmatically. These new registers are located in "mirror"
locations of the VIC-II (6567/6569) IC. On a stock system, these
locations return $ff when read, and writing these locations does not
affect RAM under the "mirror" locations while I/O is switched in. These
locations are considered relatively "safe" and have been chosen to
contain these important CMD SuperCPU registers:
Location Purpose
--------- --------------------------------------------------
$D074 (1) GEOS Optimization (mirror VIC bank 2, $8000-$BFFF)
$D075 (1) VIC bank 1 Optimization (mirror $4000-$7FFF)
$D076 (1) BASIC Optimization (mirror $0400-$07FF)
$D077 (1) No Optimization (Default; mirror all memory)
$D07A (2) Software Speed Select - Turbo Off (1 MHz)
$D07B (2) Software Speed Select - Turbo On (20 MHz)
$D07E (3) Hardware Register Enable
$D07F (3) Hardware Register Disable
Notes:
(1) Write only, hardware registers must be enabled to access location.
(2) Write only, may be accessed with hardware registers enabled or
disabled, but does not over-ride hardware Speed switch.
(3) Write only.
The first 4 locations specify how much and what areas of RAM will be
synchronized between the SuperCPU and on-board RAM images.
These registers have been created using a "sandwich" method that
minimizes irregular operation due to memory fills. As such, each
register has a "shadow" that falls two bytes away from the register
itself. During a memory fill, a fill might turn off fast mode by
writing to $d07a, but any access to $d079 or $d07b will turn fast mode
back on. This would cause the machine to operate in the wrong state for
at most one instruction period. Only one address of each register is
documented, as the shadows of each register should not be used for
program development.
To utilize the above registers, the programmer need simply to write a
value into the appropriate location. In the tradition of CMD, it is not
relevant what value is stored at a location. Rather, that a memory
write occurred at that location suffices.
In addition to these outlined registers, there are additional "bit-
mapped" registers in the VIC-II register map that signal the state of
the SuperCPU hardware and software. These flags are read only when
hardware registers are disabled, and read write when the hardware
registers are enabled. More information about these flags and their
locations will be included in the SuperCPU Developer's Guide.
Programmers should use and modify these flags with extreme caution.
In addition to the above registers, there are two pages of RAM present
at $d200 and $d300 on the SuperCPU. Although this memory is present, it
is dedicated for SuperCPU use and should not be otherwise utilized.
@(A): Conclusion
Well, there you have it. I am learning something new about this CPU
every day, and some of these modes still baffle me. However, I hope
that each of you takes an interest in developing '816 applications, as
the possibilities are endless. Just when you thought you had the 65XX
line all figured out...
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
@(#)html: Using HTML on the Commodore, Part 1
by Jim Brain (brain@mail.msen.com)
Note: Due to the recent relocation of myself and my family, I am behind
on the development of the HTML viewer for the Commodore system.
Therefore, this article will not focus on the actual viewer. With the
development below 50% complete, the modules are subject to change.
Describing them now would only confuse issues.
@(A): Introduction
HTML. This simplistic acronym, unknown to most people before 1993, now
forms the heart of discussions. Its status is secured, as employers ask
how much "experience" one has with it, and resumes commonly include it.
A quick tally in any technical magazine reveals hundreds of references
to it, and trips to the bookstore yield mountains of titles referring to
it.
Most Commodore owners have a few questions about this acronym. First,
what is it? Second, why should I care about it? In this series of
articles, I will try to answer both questions to your satisfaction.
To answer the first question, let's step back to explain the World Wide
Web (WWW). This explanation is not designed to replace more thorough
treatments of the subject. In 1991, while working as a researcher at
the CERN laboratory in Switzerland, Tim Berners-Lee developed a
hypertext information retrieval system that allowed researchers at the
lab to design informative online "presentations" of their work. In each
presentation, a researcher could reference a document or presentation
located elsewhere on the lab-wide network of computers. This reference
was "live", meaning that a person could select it from the document and
immediately view the referenced document. Thus, a matrix of related
documents were created to interconnect the researchers' work.
In an effort to offer the researchers great latitude in presenting their
works while retaining some standard in layout, Berners-Lee found simple
ASCII text an inadequate presentation method. Clearly, a document
formatting procedure, or "markup language" was needed. However,
Berners-Lee found that popular document markup languages did not support
the concept of referencing, or "linking" between documents in a standard
and non-proprietary way. After looking past popular approaches like
Windows help files, troff, TeX, and Rich Text Format, Berners-Lee found
a standardized markup language that would support links and provide
flexibility in creating documents, yet retain some semblance of
commonality. The language was the Standard Generalized Markup Language
(SGML).
SGML in itself was derived from an IBM specific markup language called
Generalized Markup Language (GML). After some minor changes, the IBM
GML specification became standardized. SGML, though, represents more
than a simple formatting schema. SGML allows one to create multiple
derived markup languages off the SGML base, and a suitable program can
interpret each derived language independently. Thus, HTML functions as
a derivation of SGML.
Berners-Lee created the original specification for HTML while working on
the WWW framework. Since mid 1993, when the first graphical HTML
viewer arrived from the University of Illinois, the HTML specification
has been revised and updated at least 4 times, but remains an SGML
derived language.
@(A): The Basics of HTML
HTML, like most formatting or document markup languages, allows the
document creator to insert special labels, or "tags" into the document,
which the language processor can parse. The language processor then
converts these tags into the special formatting options they represent.
In a simplistic markup language, one might place an asterisk "*" next to
any word to be highlighted. As the "marked up" document is read and
parse by the language processor, the resulting output would highlight
each word preceded by an asterisk. The asterisk itself would be
stripped from the resulting display, as it does not form part of the
document itself. In much the same way, HTML allows creators to insert
HTML tags into the document being formatted. An HTML display system
(commonly called an HTML viewer if the document is local or an HTML
browser if the document can be accessed from a remote location) then
parses the tags and renders the presentation of the document on a
suitable display.
HTML tags come in pairs. For each "open" tag, there is a corresponding
"close" tag. All tags are simple ASCII words or letters preceded by a
less-than "<" character, and followed by a greater-than ">" character.
A simple tag is "HTML", which tells the browser that the document to
follow is marked up in HTML. This tag takes the form:
Since tags are not case sensitive, can be used as well. This tag
is the HTML open tag, and it has a corresponding close tag. In HTML, a
close tag is formed by inserting a slash "/" character after the less-
than character and before the tag name. Thus, would form the
close HTML tag.
Some tags require optional information. This information is included
after the tag name and before the greater-than character. Such tags
include IMG, which instructs the HTML display system to load and display
a graphics element at the present location. Since the location and name
of the graphics element is needed, it is included as an "attribute" in
the tag. To display a photo called jim.gif, I would include:
in my document. Notice the space between the tag name and the attribute
name. That space is necessary.
IMG does indeed have a corresponding close tag, but since IMG doesn't
turn something on that must be turned off, the closing tag is seldom
used. That forms the basis for using closing tags. Opening tags that
"turn-on" a formatting style require closing tags. For opening tags
that do not "turn-on" a formatting style, closing them off is optional.
Of course, exceptions exist, but you'll rarely go wrong marking up with
this rule in mind.
@(A): The BASIC HTML Tags
The following tags are considered basic since they implement either the
essential or often used formatting options available in HTML. Each
opening tag is listed in its HTML form, and a description of the tag is
given:
Tag Description
------------------------------------------------------------------------
begins an HTML document
specifies the heading information (title, etc.)
specifies the body of the document (information)
Inserts a paragraph.
Renders the following text in heading size X. 1 <=3D X <=3D 6.=
H1 is largest, while H6 is smallest
Line break
Specifies the title of the document
<hr> horizontal rule (line across document)
<strong> Emphasize text strongly (typically rendered as bold text)
<em> Emphasize text (typically rendered as italics)
Remember, this is but a few of the possible tags.
@(A): Creating an HTML Document
In HTML, HTML documents are referred to as "pages", and each page is
constructed as a simple ASCII or ISO 8859-1 (superset of ASCII) text
file. No preprocessing is necessary. This makes creating documents as
easy as editing a text document. HTML files are typically given the
file extension ".html", and IBM PC computers running MS-DOS typically
shorten this to ".htm" due to DOS limitations. However, the former
extension is most correct. Although fancy HTML generation applications
exist, most people on all platforms simply create pages using a text
editor. Since Commodore owners can usually find a text editor,
Commodore enthusiasts can create pages just as easily as anyone.
Additionally, the WWW and HTML encourage writers to create small pages,
and break up large documents into linked pages of smaller sizes.
Typically, HTML documents are less than 10 kilobytes in length. At that
size, even an expanded VIC-20 can create full size HTML pages.
Let's create our first document. Edit a file called template.html and
place the following text inside it:
<html>
<head>
<title>This is an HTML title
This is an example of Heading 1
This is a paragraph.
This is another paragraph.
I want you to see this next sentence. Therefore, I am strongly
emphasizing it.
Now we are back to normal.
This sentence is below the last in the source, but will appear following
it when displayed.
Notice which tags require closing. Also, notice how
and
are used in the document. Notice the two final sentences in the above
example. The sentences appear on different lines in the document, but
HTML specifies that all carriage returns will be translated into spaces. =
It further specifies that if multiple spaces exist in a file, they will
be reduced to a single space. Thus, using spaces as alignment helps
will not work in HTML. Likewise, using linefeeds and carriage returns
to specify alignment will also fail. If a new line is necessary, use
, which will leave a blank line, or
, which start a new line.
@(A): What's in it for Commodore Enthusiasts?
This is an interesting question, and I hope you agree with my answer.
Many claim that HTML is useless to the Commodore owner since the
Commodore can't display HTML. While I am not even sure that is true,
(I've heard of simple HTML viewer programs for the 128), it doesn't
matter. Commodore owners who access the Internet from a "shell" account
can access the World Wide Web via the "Lynx" text browser. Since the
WWW is constructed of HTML pages, those Commodore owners can indeed view
HTML files while online. Many Commodore enthusiasts possess useful
information. Putting that information on the Internet via HTML and WWW
makes it widely available to other Commodore and non-Commodore computer
owners. Why worry about the latter? You'd be surprised how many former
Commodore owners are coming back into the fold after viewing some
Commodore HTML pages. The information on those pages triggers fond
memories. Many fire off messages inquiring about purchasing a new or
used CBM machine after seeing these pages.
To the naysayers, I submit that there is nothing PC-centric in the HTML
standard. If an HTML viewer doesn't yet exist, it has nothing to do
with the computer system. As HTML was created to allow successful
operation over many different computer systems and graphics
capabilities, HTML encourages usage on computer systems like the
Commodore, where there are limitations in display size and resolution.
In fact, the Commodore community should embrace HTML as a markup
language, for it represents a standard way to effectively mark up
documentation for viewing on a variety of computer systems. Using HTML
opens up a whole set of possibilities for easily created, standardized
documentation publication.
Disk magazines, like _LOADSTAR_, _DRIVEN_, _VISION_, and _COMMODORE
CEE_, could produce issues that contain more layout information than now
offered. Since the viewer would now be standardized, these publications
could possibly forego the distribution of the viewer software and offer
more content in the extra space on disk. A side benefit is the ability
for Commodore users to read each issue on any platform. Possibly you'll
never need to read LOADSTAR 128 Quarterly on an IBM PC, but what about
reading it on a 64, while your sole 128 does something else? Moving to
HTML would shift a disk magazine's focus and concern from the
presentation, which would become standard, to content, which is why
Commodore owners read such magazine anyway. How many times has
otherwise great information been presented badly in a disk magazine?
Use of HTML could help alleviate that problem. Publishing a disk
magazine is time consuming because not only must editors work on the
articles themselves, they must also write the software that presents the
articles to the viewer. Using HTML and a pre-written browser would
allow editors to spend more time on laying out and editing articles.
Disk magazines aren't the only winners here. Have you ever wanted to
create a small publication? The use of HTML and a third-party HTML
viewer makes it easy for you to do so. Just like the editors of bigger
publications, HTML allows you to concentrate on presenting your
information without worrying about writing the presenter software. Now,
obviously not everyone should publish their own magazine, but how about
help files, information disks, software documentation, club newsletters,
etc.? These publications can all benefit from this technology.
These are but a few of the benefits of switching to HTML for document
layout. Other uses include upward compatible support. Using HTML
allows the Commodore 128 user to view documents created for the 64 in 80
columns by 50 rows. C128D owners can take advantage of their 64kB video
RAM even when viewing documents created on 16kB video RAM C128s.
Publishers would no longer be constrained by lowest common denominator
support. They can now include whatever they want and be assured that
the presentation will look fine on all platforms. When a user upgrades
his machine, he or she can immediate utilize those new features without
requesting a new version of the publication. Also, for software, even
though the software itself might differ by machine, the online
documentation need be written only once. As well, never forget that
marking up in HTML makes migrating your documents to the Internet and
the WWW a snap!
@(A): Creating an HTML viewer on the Commodore
Obviously, before Commodore users can reap the benefits of HTML, we must
create both a HTML generator and a viewer. The generator is easy, as
HTML is simply ASCII text files. So, we are left to design and
implement an HTML viewer. The following conditions should be met:
o ability to utilize all Commodore peripherals within reason
o ability to work on a stock machine
o ability to recognize and display valid HTML 3.0 or lower files
At first, we're going to concentrate on developing our viewer for the
Commodore 64, although we should strive to offer versions for the 128,
C65, Plus/4, C16, B series, PET, and VIC-20. I am reasonably confident
on all but the last one.
Although we intend to develop a viewer that supports the above, our
initial development will operate on a much smaller scale. The first
revision of this viewer will operate on the stock machine and will
contain support for the basic HTML tags as outlined above. Our design
will allow us to extend the capabilities to encompass our goals.
@(A): The Viewer Execution Flow
I am not very good at drawing execution flows, and the native format of
this magazine doesn't lend itself well to them, anyway. Therefore, I
will simply describe the execution flow.
The viewer will start by asking the user for a document to access. If
the file does not exist, an error is printed and the user is asked
again. If the file exists, the viewer will begin reading it. If a tag
is found, the tag should be acted upon. If text is loaded, it should be
displayed on the screen using the current markup controls unless the
control information is incomplete. In this case, the text should be
stored for later display. The file should be parsed in this way, until
the end is found. Then, the system will wait for either the user to
select a link or type in a new document to view.
Most of the time, text can be displayed as soon as it is received.
However, there are exceptions. Some tags, like the
tag, which
creates a table on the screen, require that all the data in the table be
known before the table cell information can be calculated. In cases
like these, we must store the data and wait for the
tag.