[A83] Re: Ms-dos (OT)


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

[A83] Re: Ms-dos (OT)




[Olle Hedman wrote]
> [Henk Poley wrote:]
> At 19:32 2001-03-04, you wrote:
> >Hmm, DOS means Disk Operating System, so it's made to operate disks.
(fixed
> >disks (aka harddrives), removable disks (aka floppy, CD-ROM, DVD, Zip,
> >Jazz) and RAM-disks (and *of coarse* network-drives))
> >MICROS~1 *made* MS-DOS for the 80x86-family of processors (actualy the
> >bought QDOS [Quick & Dirty Operating System] from a little company, when
> >they didn't made it to do it themselves in time -for IBM-). But there
are
> >many DOSes around even for the Z80, like -indeed- the CP/M, but also the
> >Z88.
> >
> >So a "100% IBM-compatible system" isn't needed to run a DOS. The
question
> >is, should we need one for the TI-83+ SE?
> 
> Heh, you can't put equalsigns all over the place like that just based on 
> part of the name.
> Kindof like saying that MS Windows and X-Windows is the same thing, just 
> because they both have "windows" in the name and (among other things) 
> handles graphical squares on the screen....

Well, I think this part of your reply is about the "program-pointers" mail?
In that mail I said about Windows: "all versions, as long you can run a DOS
program within it". This is true, if you can run a DOS program under
X-Windows you can run z80asm/z88dk in DOS-mode. (so also on a (i)Mac,
Linux, *nix, etc. If only you have a DOS-emu)

Of coarse you could better run the program in 'native' mode. But, well, I
*know* people who run a virtual-PC on their Mac, just because the emulator
they want to use only runs under MS-DOS/Win on a 80x86

> And we where talking about MS-DOS, and not just any os that handles
disks. 
> I said MS-DOS needed a ibm pc compatible machine, nothing more, nothing
less.
> MS-DOS only exists for x86. CP/M exists for z80 yes, (and for x86, and 
> probably some more)

I began about the other DOSes because of the "CP/M! CP/M! CP/M!"...
So you see, I wasn't the first one who didn't read the "MS-".

> >My answer would be that it would be nice to have some better file
routines,
> >so you can actualy "open"a file and read/write "that many" bytes from/to
> >it. And the OS would do the actual file-handling. It would then be a LOT
> >easier to make file-handling routines for a C compiler. I'm quite far
with
> >them now (Ti-83), but no, it's not "easy"...
> 
> Seems a bit overkill to implement a whole os just for that.
> Does the read and write and open routines really get that big that it is 
> motivated to implement a new OS?
> If one should write any new OS for the calc, I would say the biggest
reason 
> would be that it is a fun thing to do, not that it is really usefull...

I don't mean an extra layer around the TIOS...

> Isn't full fledged open and read and write a bit of a waste of space on a

> calc anyway, since it actually isn't on disk, but in ram (or flash), and 
> doesn't have to be moved to a buffer in ram to be read, like it has to
when 
> you have it on a disk? You can just read it in place.
> 
> ///Olle

My idea was that Ti themselves should add such routines, and, yes I know,
you would need another format of the VAT to (easely) implement
open/close/read/write routines. (yep, you could also store the pointers of
the opened files at another place, so you don't have to change the
VAT-format).

The ROM has plenty of room to store another 1-2kb of routines, ain't it?

Another thing, reading/writing would be easier, you would only need to
"remember" a filedescriptor and a pointer to the place you want the
routines to read/write from/to.

At the moment you have to save all the pointers yourself, and you need to
write a new file-handling routine for every new program. Having a built-in
TIOS function to do right that for you would be realy nice. Making games
that have external levels would be easier, making level editors for that
would be easier, making a text editor would be..., on-calc assembler...,
on-calc compiler(!),  etc. etc.

	Henk Poley


PS: If I'm finished with my code I'll send it to you... (If you like)
PPS: For each file you *only* need seven bytes:
-- 2 bytes EOF-pointer,
-- 2 bytes file-pointer/data-pointer,
-- 2 bytes "file_cursor" [points to the place where you read/write] and
-- 1 byte flags [read/write/append]
-- (add program-name here if "new VAT"}
You see: four of the bytes are (almost) the same as the file-pointer in the
VAT, and the sizebytes at the begin of the program. So it would only take 3
bytes extra per file (whoowww)





Follow-Ups: