ISDOS Extender

In a chit of 15 Jan 00 Oleg Grigoriev wrote to me:

ES>> Spectrum, ISDOS potential rulez if it is improved. Everything
ES>> the rest goes to the garden.

OG> unfortunately, it is impossible to modify the isdos without losing compatibility. in
OG> at one time I very seriously studied this possibility, tinkered with it,
OG> disassembled the three lower levels of the system, and... that's it.

This is very interesting. As far as I remember, calls to the kernel in ISDOS
occur as LD C, function code; RST #10. Levels are loading set.com from
disk. In principle, this should be enough to
rewrite the system with virtually no loss of compatibility at least entirely.
Re-canvas set.com before working with TRDOS, make mandatory
system libraries from the levels (up to the firmware them in ROM), with the well-known ISDOS
limit on the number of levels up to 8. Write some addlib.com,
which can add/kill libraries without any restrictions. I
of course I could be wrong and probably not everything is so simple, because there is enough g.
there, but a path similar to the one given probably exists.

OG> only extenders are possible, such as dosx from a wild mailer - he, in fact,
OG> uses isdos only as a file system, everything else is his own.
OG> and even then he has wild limitations.

Extenders are different from extenders. I forgot about the wild mailer. I’ve been talking about wild
restrictions when writing programs under ISDOS and God forbid under
some new-guy OS here all this time. Nothing
should be screwed tightly, let this be the prerogative of offtopic.
Therefore, everything should be humane: commanders/desktops
separately, after loading - CLI, on the disk there is a text file startup
listing the loadable commanders/desktops, commands dir, erase, copy
- built-in, bootable from any disk format including ram disk
as any native programs and any TRDOS (RAM DISK for KAY by LAS
significantly simplifies this task - then it was written by him, indifferences from
its predecessor, written by the crooked Kostya), libraries,
the ability to use existing TRDOS ASM compilers for
writing for OS. In this case, the amount of memory allocated for running
the program (more precisely, +/- from the amount of space occupied by the CLI) will be determined
by the user. No switching between programs, no attempts
to organize multitasking, etc.. If you do everything correctly, then everything
else can then be added by other people in the form of libraries. That's the whole OS. Shaking up ISDOS, IMHO, is quite possible, although not exactly beautiful. What to do if it already exists? Why breed clusters
of underOS? It’s better to think point by point about how this can be done. And
improve ISDOS point by point.

OG> it’s impossible to climb the tree and not rip off your ass.

There are no impossible things. Everything is possible if there is
something else in addition to this “everything”. Where one peels off, the other will climb in without soap. And the Spectrum itself is an example of this.

Cordially yours.

15 Aug 2000 at 17:29, Eugene Sobolev ═> Oleg Grigoriev:

ES> This is very interesting. As far as I remember, calls to the kernel in ISDOS
ES> occur as LD C, function code; RST #10. Levels are loading set.com from
ES> disk. In principle, this should be enough to
ES> rewrite the system with virtually no loss of compatibility at least entirely.

it’s not that simple. you should deal with isdos. once again: it is impossible to redo it without
loss of compatibility with a pile of software.

[ WBR, Oleg. ]
[ 15:42 17 August XXXV A.S. ]

ES>> to rewrite the system with virtually no loss of compatibility at least
ES>> entirely.
OG> it’s not that simple. you should deal with isdos. once again:
OG> it is impossible to redo it without losing compatibility with a pile of software.

Maybe, maybe...
But I still don’t believe in the impossibility of bypassing its features, I just don’t have the time or desire to prove it
. So, science fiction... ;)

Cordially yours.