[A83] Re: Ms-dos and file function (half of it OT)
[Prev][Next][Index][Thread]
[A83] Re: Ms-dos and file function (half of it OT)
At 19:12 2001-03-05, Henk wrote:
>Well, I think this part of your reply is about the "program-pointers" mail?
No.
>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
No, I have only been talking about ms-dos, an off topic guy.
You can't run anything "under" X-windows, X-windows only handles output and
input to programs. (and not much of it, only keyboard and mousemovements
and moseklicks, and keeping track of squares on the screen to draw in)
(Xwindows is a windowing standard for unix-type os:es if you didn't know)
>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-".
I'm quite sure he mentioned cp/m because he wanted to be original and
mention another compact os to use.
> > 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...
I fail to see the connection between this comment and what I said (that you
even qoute)
I talked about whole OS:es since someone talked about linux on the calc,
and someone then replied with ms-dos beeing a compact os, wich I
interpreted as he wanted ms-dos on the calc.
I think we can leave the above behind now? :)
It isn't really important...
>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.
I still don't see the use of a read function (that would then just copy
data from one place in mem to another)
why not design your program in another way, without the file-abstraction,
and just use the data directly?
dereference a pointer to the variable, and then you have your datablock
there, ready to use.
ok, easier to not change the way you think, but it feels a bit of a waste
of memory to copy data when it's not needed.
the "files" on a calc is nothing like a file on a PC. (since it isn't on
disk, but completly in ram and can be accessed as such)
better support of writeing to variables and changeing the size of them
could be nice though. (havn't done that though, so I really don't know, but
I have gotten the impression that it can be a bit messy)
aww.. ok, a read could be nice, but I think it would come with a large
warning label, so it isn't misused by novices who doesn't know better. But
maybe badly coded programs are better then none....
Should only be used to read some pointertables or something in the
beginning and not the actual data. (if it's not just small amounts ofcourse...)
whatever, I regret I was drawn into this discussion, it started out mostly
because I was bored and wanted to write some off topic things, and here I
am, discussing on topic.. bummer :)
>PS: If I'm finished with my code I'll send it to you... (If you like)
No need, I don't have any calc to run it on.
>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)
I havn't said anything about that.
And ofcourse it is better to have the changes centralized if they are needed.
///Olle
References: