Features

[Darth Android]

please visit http://nwps.ws/~dragonfire/forums/index.ph...st=0&#entry2017 and tell me and the rest of the dev team what you want to see in DragonOS.

PS: There's an admin posistion open if any one wants it.

[Toksyuryel]

[Darth Android]

um... it was a contest at my site....and teh contest closed due to lack of interest...

[Toksyuryel]

Oh...

[Darth Android]

UPDATE!

YAYS:
got most of the file structure design is done, still have a few things that need work

easy linking

NEW:
i plan for DOS to be command line, based for the most part off of *nix
users will download a gui to the calc that will hook into the the shell and takeover after installation (this allows for not only the user to change the gui, but it allows DOS to get on the net faster)

Link port(s) will be commanded via "drivers" for the different protocols, escpecially since teh 84+'s usb port will allow (with a simple adapter of course) a host of devices to connect. simply plug in the device, select a driver, and then the device should work.

lock status: programs can be "locked" (no read/write) or "read-only" (just what it says, read but no write). a program like a text editor will not be able to remove these flags, they will have to be removed by teh user via command line or via the gui (the gui will be the only program that can change these flags)

Dont want to search through the VAT or directory structure? simply send a command to the shell and read the output buffer to preform operations and commands (ex. for a game , search for level files with "LS *.LVL" or "LS GAMENAME.*"

keep in mind that this is designed to be a gaming platform, not a math platform (ironic, isnt it?). dont worry, it'll do calculations and y= graphing, but if you really need much more, TI has made a wonder operating system called TI-OS

[Adm.Wiggin]

Oh man, so pumped, and can't wait

[Darth Android]

well then, as one of teh official programmers, would you like to start helping me and iambi out, as soon iambi will be unable to help for a long time (hurricane francis is due to hit tomorrow)?

[tweekers]

this will be so dang cool

[Adm.Wiggin]

Just tell me what to do, Darth, and I want to help... Just make sure it's within my abilities . IRC, or MSN me (MSN, more often, I am on [Yoda style! ])

[Toksyuryel]

WOW! This looks so amazing. I'm expecially interested in that GUI thing you mentioned. Any chance there will be a GUI editor for people who haven't found the time yet to learn ASM? (me >.<) I've still got those concept PICs I drew, and I'd love to see them used in a GUI for DragonOS 8)

BTW, are you on IRC right now? I'd like to get on and chat while I can, been so long man

[Darth Android]

well, i need rom call routines. i also found a way to make rom calls MUCH, MUCH faster. however, you must do more on your (the programmer's) part if you switch pages in and out of the $4000-$7FFF address range.
in short, i did away with teh rst 28h / .dw xxxx and replaced it with a call xxxx

call is 17 t states

the rst 28h would have to do the following:
save hl and other vars used to the stack
manipulate sp to find the return address
return address->some register
go to the return address and find the lut address specified for the requested rom call (the .dw xxxx part)
move it to a register
restore sp
move teh lut offset to a reg that is rarely used (IY?)

adm., right now i need a routine that displays 768 bytes at screen_data and copies it to the lcd - use a bit cpuspeed,(IY + hardware) to check for fast mode on a 83+se and delay appropriately: 1 (nz) is fast mode, 0 (z) is regular mode. note that this will always be 0 on a 83+

for anyone else that wants to help:
let me know before you start a routine - if i have 3 of 1 routine and none of another, then 2 ppl didnt help the project too much. here are some other routines i need made. note that you can check hardware version with a bit se,(IY + hardware) - 1/nz is 83+se. 0/z is 83+:

link send routine - sends byte in register a over link port in standard tiso protocol. returns nz if successful, z if send failed

link get routine - get a byte over the link port in standard tios protocol. a = returned byte and z is failed, nz if sucessfull. will be called in an interrupt routine upon link activity detection

8*8 unaligned OR sprite routine -
hl = start of 8 bytes that is the sprite
d is xcoord
e is y coord
needs to clip and must be super fast. size is no object
if bit buffer,(IY+display) = 0 then it needs to write directly to the screen. else it needs to write to teh 768 bytes at screen_data
author also needs to provide a XOR and AND version as well

line routine -
when a is:
1 - draws a line from b,c to d,e
2 - clears a line from b,c to d,e
3 - xors a line from b,c to d,e

note to anyone working on these routines -
write just like you would for tios
if you must use saferam, use saferam_1. try to use the stack when ever possible
use as few bcalls as possible. try to stick to simple math ones like _HTimesL and _DivHLbyA

[sgm]

[Darth Android]

i may use some of the routines. but not without credit where credit is due.
i would also like to inform people that there are several polls at my site reguarding DragonOS to get community input.

[Adm.Wiggin]