mail editor

I wonder if anyone tried to write a subject under isdos? Or adapt
existing trdosnye? After all, for example, it is quite possible to adapt the same
ZED.
Good bye.

03 May 01 23:07, Sergey Krinitsin wrote to All:

SK> I wonder if anyone tried to write a subject under isdos? Or
SK> adapt existing trdos? After all, for example, it is quite possible to adapt the same ZED
SK>.

I watched its raw versions - it’s very difficult. Mainly due to the fact that everything
will not
fit in memory.

SK>> ZED
SK>> it is quite possible to adapt.
KF> I watched his raw materials

Do you have his raw materials? Can you share?

KF> - it’s very difficult. Mainly due to
KF> the fact that everything will not fit in the memory
KF>.

At least - chic without any problems. Just reduce the cache.
There are problems with the classic. If the channel descriptors were moved higher, then it would be possible for
this version.

Good bye.

SK> Do you have any sources of it? Can you share?

Take it from the author’s website.

KF>> - it’s very difficult. Mainly due to the fact that everything will not fit in the memory
KF>>.
SK> At the very least, chic without any problems. Just reduce the cache.

If you reduce the cache, it will slow down more than the original
(without cache) tr-dos version.

SK> There are problems with the classic.

Problems with the “chik” on Scorpios and not only.

SK> If the channel descriptors were moved higher, then
SK> for this version is possible.

Yes, this can be solved more easily - switch to another bank there and that's all.
But simply compiling this ZED with another compiler is also a whole problem!
Look for yourself and you will understand. It is necessary to tear out the entire assembler from there and redo
again.
And then it turns out that, as always, everything there was tied to tr-dos and...

KF> Yes, this can be solved easier - switch the jar there to another
KF> and that’s it.

IS-DOS clssic does not fit into the jar. Descriptors and residents will be
overlaid with overlays.

KF> But simply compiling this ZED with another compiler is also a whole
KF> problem!
KF> Look for yourself and you will understand. It is necessary to tear out the entire assembler from there
KF> and redo it again.
KF> And then it turns out that, as always, everything was tied to tr-dos
KF> and...

I only looked at the compiled one. There really are a lot of calls to
trdos... But in any case, porting is faster than writing from scratch...

Good bye.

KF> Get it from the author’s website.
url plz. And a couple of mirrors, in case he went down as always.

I think, unfortunately, you are right about the editor for is-dos. It will slow down terribly... but you can still try.

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

SZ> url plz. And a couple of mirrors, in case he went down as always
SZ>.
SZ> Unfortunately, I think you are right about the editor for is-dos.
SZ> It will slow down
SZ> terribly...

Hm... Depending on what you compare with... When working with a ramdisk or a screw it will be
faster than in TR-DOS with a floppy disk...
Especially if through restarts $dread and $write. After all, ZED still has its own
text buffer.

SZ> but you can still try.

Imho, it’s even necessary ;)

Good bye.

ZXNet: 500:8462/1 ~/ <~ http://zs80.chat.ru/
Fido: 2:5057/21.93 /_ _> ftp://zx-museum.org.ru/zs/

SK> I don’t have an Internet :(

And there’s no PC with an Internet nearby either?

Put it in netmail?

SK> IS-DOS clssic doesn’t fit into the jar. Descriptors and residents will
SK> be covered by overlays.

There are iS-DOS versions of Chick and Shit... ;-(

SK> I I only looked at the compiled version. There really are a lot of calls to trdos by
SK>... But in any case, porting is faster than writing from
SK> from scratch...

If you port it, it's tied to trdos to hell - you'll be tortured.