SD: DH85: Project Manifesto


[Prev][Next][Index][Thread]

SD: DH85: Project Manifesto



Note:  I know this is long.  Just read it all the way through anyway.
Please.

    Greetings everyone on Shell-Developers.  Isn't it a nice day?  Well,
anyway, let me get to the point.  This is concerning the new OS that is
based on the E2 and is for the TI-85 calculator, by general consensus called
Doomsday Horizons 85, or DH85/DHOS for short.  Are there any objections to
this name?
    I would like to thank everyone who wrote about this idea, in this list
and in the Assembly-85 list.  Many great ideas were gathered and polished.
Many of these ideas were for parts of the system further ahead in the road
before us, such as the GUI shell, etc.  They were all good ideas.  I also
appreciate the optimism generated by (almost) everyone discussing the topic.
It is wonderful to see that it has such support and it brings hope.  Since I
originally brought up the idea, i feel sort of responsible for it in a way,
although by now it certainly belongs to many other contributors as well.  As
the originator, however, I would like to appologize to everyone on the
Assembly-85 list who was offended by the high traffic on the list lately.  I
also would like to apologize to Bryan Rabeler, who told us long ago to come
to the Shell-Developers list, but whom we did not listen too for a long
time.
    Recently, Greg Sharp sent a message to this and the A85 list to tell all
interested in working on the OS to contact him.  This was a success, and
many people have contacted him.  I encourage all others to also help us work
on the OS and contact him at BSharp81@aol.com to join us.  This doesnt mean
only those of you who have programming experience, but also those who have
ideas to help use even in the development work.  The list of
people who have so far contacted him and are willing to help are as follows:
Jonathan Kaus, Josh Morris, Greg Sharp, Matt Cooper, Mathew Bledso, Randy
Frank, David Whittaker, Pat Gray, and Mikel Blanchard.  Again, I encourage
anyone who is even slightly interested to join us and help make this great
thing happen.
    I have posted some information concerning the OS's internal operation
and design and continue to post more information at that site as I think of
new ideas and write more information.  This website is at:
www.angelfire.com/wi/dh85/  Please visit there for more information on the
OS so you can familiarize yourself with the material.  I have just posted
some more diagrams and explainations there, so keep coming back every day as
I usually add something daily.  A few questions concerning the OS circle
diagram and explaination have (hopefully) been answered by a new, deeper
explaination of it at that site.  Check the news section.  It is also
obtainable at this link:  www.angelfire.com/wi/dh85/Osdescri.txt  I also
have included the text in this document for any web-impaired readers.  I
will be writing more information to expand on that which is currently
outlined at my web site, and releasing it there, so please stop by often.
       This, however, is not the official Doomsday Horizons 85 webpage,
which has not been yet released to the public.  It soon will be, I hope, and
then the diagrams and texts on the angelfire page will be moved there as
well.  There are currently some people working on the official web page,
currently in the design phase, (as far as I know).  They will release the
site's location when they are ready for us to see it. =)  The people who are
working on it that I know of are Pat Gray, Matt Cooper, and Mathew Bledso.
There may some others, but I do not know them at this time. (If you have not
already, please email BSharp81@aol.com so you can be put on the active
list.)
    Our objective for this project is to create an operating system for the
TI-85 calculator that allows the calculator to be a small computer system.
The calculator RAM is to be used as a place to store the programs and data
being currently used, when a program is finished, it is erased from the RAM.
The recently released Expander II (EII), with plans and information at
www.flash.net/~bryanr/eii/ is to be used as the 'hard drive' so to speak,
although excessive writes to the drive should not be done very often.  This
hard drive will contain the programs and initial data to be used.  It can
have huge programs that are segmented into small pieces to be loaded to the
calculator RAM to be executed seperately.  Another facet of this technology
is the use of DLLs, or Dynamic Link Libraries.  These are libraries of code
on the E2 that are loaded into a small piece of RAM and executed from there.
The advantages to these are that a library inplace for one program can be
used by the other simultaneously and without reloading and relocating the
library.
     A third and amazing facet for the E2 technology is the module port that
is included with the E2.  this port can be controlled by the calculator and
thence can give us enhanced communications wiht other devices, or several
devices at the same time. We can hook up an i2c mbus network and another
calculator at the same time.
    These things would make a large OS string on the calculator, if it were
all present before it was run.. But this is not the case.  The only things
that will be on the calculator prior to the execution of the OS. is the
bootstrap loader, whcih loads the rest of the OS onto the calc.  this
maximizes the space on your calculator so that you can have many other TI-OS
variables on it.  Also,  the OS will support Usgard/ZShell programs also, by
going through the program and relocating the calls that it used to make into
calls that the new OS has.  It also modifes the programs so that they don't
use the VAR functions, but let the OS emulate it for them in the following
way:  The program requests to see a TI-OS var.  The Shell alloctes space for
the variable in the RAM and copies the variable over to there.  Then the
program uses that allocated space as the variable.  When done, the program
exits and leaves the variable in its copied RAM   position.  On exit, the OS
remembers this and so copies the modified variable back into its former
position, resizing, Deleting, and creating new variables then.  This
prevents all the problems associated with deletion and resizing of
variables.  Once the programs have been modified, they are rewritten to the
E2 as modified, so that next time they do not need to be modified again.
Hopefully, however, authors of previously games and utilities will rewrite
them to take advantage of the new OS instead of the old ones.  Eventually
perhaps we can remvoe the modifiying code altogether, although with the
entire e2 of space, it is not a major priority. =)
    As soon as possible we should begin programming the operating system to
encompass these needs.  Our immediate goals are the support of the e2 and
the basics of this oeprating system.  Eventually, complete support and many
functions will be available.  Eventually we will release many libraries
containing additional functions which we create for the operating system.  A
GUI Shell has been suggested and is a wonderful idea.  That will be another
thing which will eventually be accomplished.
    And, as a final note, several times it has been suggested that choose a
'leader' for this project.  I don't think we should choose one person to
lead this project as that could lead to corruption.  However, we do need
something to lead the project along.  Perhaps a committee would be a better
idea.  A managable but large enough number, such as 5 or so, would be a good
size i think.  We need people on this commitee who have shown leadership in
this project so far and who can keep it moving.  We also should have at
least one representative from the Web site committee in this leading
committee.  Since Pat Gray is the leader of the web site group, perhaps this
would be a perfect candidate for at least one seat in our little congress.
Greg Sharp has also shown a lot of initiative in getting things organized by
having people email him who are interested.  Does anyone else have any
nominations for this committee? anyone agree with me or disagree?  We should
get everyone's input and then decide.

Thank you for you time.  I know this email was long and problably boring.
Please respond with your comments and ideas.  This message will also be
posted as a text directly on the web page that I have posted on, as stated
above.  Remember, I have included a copy of the text that explains the OS
System Drivers in further detail, so please read and examine this file as
well.

Good bye for now,
--Jonathan Kaus
IRC: Jedsmeny
ICQ: 15873088 (Jedsmeny)
email: kaus@cybrzn.com




	This document is an additional explaination of the circle diagram i 
posted.  It goes further into depth about each system driver portion and 
parts of the Kernal.  I hope it answers some of your questions.  If you have
 any comments or ideas, please send them to me as soon as possible at 
kaus@cybrzn.com  
	Thank you,
	Jonathan Kaus

	The OS, as stated before, may be broken down into parts, each part
 doing its job and interacting with other parts to create an efficient and
modular program design.  These parts I like to call System Drivers, because
 each part 'drives' a part of the main 'system' (the calculator and e2, along 
with other devices.)

	The first Driver is the one that is common in current assembly 
programs.  It is the Physical Input/Ouput System Driver (PIO).  It is the
 functions that both write to the TI-85's screen and get input from its keyboard.
  Usgard (and ZShell) have functions like  GETKEY  and CLRSCR and 
D_ZM_STR.  These functions are part of the old ROM based PIO system,
 although it was not called that.  That was pretty much the extent of the system. 
 Only a few of the functions discussed further in this document were supported 
by even Usgard, and even some of those were hard to do.  
	The PIO for the new, DH85, OS will have its equivalents of the above 
functions, along with the rest supported by ZShell and Usgard.  It will also 
have some more as standard, such as a line input routine.  But, they will have
 more standardized names for the programmers to use so that they are more 
similar to other programming languages and platforms.  Many of the functions
 will be using the original ROM calls, although redirected through the OS like 
the other shells did.  Some new ones will be barnd new and coded into the OS
 itself.

	The second System Driver to be talked about is the RAM Input/Ouput 
System Driver (RIO).  Its functions are used to manage the RAM on the TI-85.
  It is in charge of all the Arena setups (blocks of memory in ram).  It has 
functions to allocate and deallocate RAM amounts for different purposes and 
put data into them.  It can copy the arenas to each other, or parts of them.
It relocates the code in the program arenas to run correctly at there current 
positions.  This driver also takes care of modifying the ZShell/Usgard programs
 to be usable by the new OS.  It also calls programs at arenas and calls library 
functions.  It modifies the Usgard programs that use VAR functions to be emulated
 in an arena, so we dont have to face the problems associated with deletion and 
resizing variables.  It has a small TSR section that every so often rearanges the
 arenas that can be moved  so that they are more efficient.  This can also be forced.

	Another important System Driver is the Communications Input/Ouput System
 Driver (CIO).  This driver allows the OS to exist, because this is what communicates
 directly with the E2.  It also communicates with any connected networks or additional
 calculators.  It has a TSR section that automatically recieves data and handles requests
 for data.  It has control over the E2's module port for Enhanced Communications.  With 
lib support, it can allow for functions like: Send packet on network, recieve packet on 
network.  We could have an ethernet style network  that sends out packets and have 
TSR's on the connected calcs pick up the packet, check it for data sent to its calc, and
 send it along if not.

	The fourth System Driver is the File Input/Ouput System Driver (FIO).  This driver
 is the intermediate between the CIO and the RIO.  It takes the data from the E2 and gets 
it ready to be sent into an arena in RAM.  Or, the other way around, or even directs the 
sending to other devices or networks.

I hope this document has cleared up some more of everyone's questions, and... dare i
 hope...  Gives you some ideas and insights.