Hrip

23 Nov 00 02:00, Oleg Groskow wrote to All:

OG> Are there people here who wrote the subject, or who has a connection with them?
OG> There is no check for the true length of the file, and if it is false, then
OG> using the subject loses its meaning, because getting the file from archive is no longer
OG> impossible. This matter needs to be fixed. And the archiver
OG> turned out very well.

In tr-dos there should be only one length - in sectors. And it is necessary
to pack the remains of the last sector.

OG> I liked it. It's a pity that it doesn't have a mouse interface...

Is it necessary? IMHO the best interface is a file in which it is written what
operations the archiver needs to perform and another file in which it is written
what errors occurred.

KF> Is it necessary? IMHO the best interface is a file in which it is written
KF> what operations the archiver needs to perform and another file in which it will be written
KF> what errors happened.

You are probably overheated at the writing monitor! :)
Wake up, even on the PC this is only needed to work on the machine. And the best option is a
full-fledged interface at startup without parameters and work on autopilot according to
the parameters from the com. lines.

Well, that seems to be all for now. Happy!

... Exactly half a sip to nirvana... (C) Spleen

KF>> it will be written what errors happened.
SK> You probably overheated at the piss monitor! :)

It was you who overheated your bastard Windows. Whoa, this is for morons.

SK> Wake up, even on the PC this is only needed to work on the automatic machine.

Is the computer needed to work or to drag windows across the screen?
If the first, it will always be on the automatic machine. As a last resort, you can
make a shell that will be completely customizable and create this same
file with commands for the archiver.

KF> It was you who overheated your bastard Windows. Whoa, this is for morons.
Eh-uh, guys, we have to put up with it. GUI is good and SLI is also cool

Alex (Rolly aka Gluk2000)
st...@khakasnet.ru

AM> Uh-uh, guys, we have to put up. GUI is good and SLI is also great
That's it. Otherwise, let's start copying disks via copy s/copy b :)
imho, a balanced combination of the user interface and the command line seems reasonable. It’s easier to perform simple operations just by clicking on a button, for complex
it’s better to draw a script and still then click on one single button
to launch it :) well, it’s definitely necessary to keep logs. if there are a lot of errors,
you won’t have enough windows to display them...

WBR, Sergei Dubarev

KF> Do you need a computer to work or to drag windows around the screen?

If for you the interface is just dragging and dropping windows (don’t you understand the contents of the windows?), then I sincerely sympathize.

KF> If the first, it will always be on the machine. As a last resort, you can
KF> make a shell that will be completely responsive and create this same
KF> file with commands for the archiver.

Brilliant! Create a shell for writing a text file and working through ()(),
instead of just using the archiver.

about this you are of course right, but not completely
for pkunzip it is necessary for it to automatically start, unpack
and launch FTN soft and if there is an error, it remains in the shell indicating the file
where the error was...
and a file with glitches is not needed, it is not PC and disk space is not rubber.

▒▒▓▓▓ ▄▀█▀▀▀ ▓▓▓▒▒░░░ Sincerely yours, Yuri /I \
▒▓▓▓ ▐▌▀█▀ ▓▓▓▓▓▓▒▒▒░░░░ Jerri / Alien Factory \ZX/

YP> about this you are of course right, but not completely
YP> for pkunzip you need it to start automatically, unpack
YP> and run FTN soft and if there is an error, it remains in the shell indicating
YP> to the file where there was an error... and a file with glitches is not needed, this is not a PC and the space
YP> on the disk is not rubber.

Error message will take fifty bytes. I don’t understand why it is necessary for pkunzip
to freeze - so the automation will not be of any use. otherwise
it’s automatic, so you don’t have to press buttons.

SK> Brilliant! Create a shell for writing a text file
SK> and working through ()(), instead of just using the
SK> archiver.

In vain. In many ways he is right. True, the best option, IMHO, is 2 shells at once:
for automatic work: a file with commands + log, for manual work: gui + windows
with error messages.
Unfortunately, there is one small problem: HOW to let the program know in which
of the two modes it should work?

2ALL: Who has ideas for solving this problem - write.
Sincerely, Dmitriy.

YP> about this you are of course right, but not completely
YP> for pkunzip you need it to start automatically
YP>, unpack
YP> and run FTN soft and if there is an error, it remains in the shell with
YP> pointing to the file
YP> where the error was...
YP> and a file with glitches is not needed it is not PC and disk space not
YP> rubber.

No. One or two sectors will be enough for you to log, but to work in full automatic mode there should be no freezes: what is not unpacked is postponed until later for manual parsing, and the task should be completed as usual. For example:
unpacked what I could, unpacked and turned off the power. Or did he do some other thing, for example, he started calculating up to the 10e50000 sign! ;-)))

Sincerely, Dmitriy.

On Saturday December 16, 2000, 11:12,
Dmitriy Nesmachny -> Sergey Kulkov:

DN> In vain. In many ways he is right. True, the best option, IMHO, is 2
DN> shells at once: for automatic work: a file with commands + log, for manual
DN> work: user interface + windows with error messages. Unfortunately, there is one
DN> small problem: HOW to let the program know in which of the two modes it
DN> should work?

DN> 2ALL: Who has ideas for solving this problem - write.
The same as c0de busters did in insulte - through the command line tr-dos %)

WBR, Sergei Dubarev

Replying to a message of Dmitriy Nesmachny to Sergey Kulkov:

SK>> Brilliant! Create a shell for writing a text file
SK>> and working through ()(), instead of just using
SK>> archiver.

DN> In vain. In many ways he is right. True, the best option, IMHO, is immediately 2
DN> shells: for automatic work: a file with commands + log, for manual
DN> work: gyy + windows with messages about errors. Unfortunately, there is one
DN> small problem: HOW to let the program know in which of the two modes
DN> it should work?

DN> 2ALL: Who has ideas for solving this problem - write.

That's what I'm writing - you need 2 different programs. One of them is the
archiver itself,
which can take commands from a file OR FROM MEMORY (for example, through a BASIC channel)
and another program - gyps to the archiver.

[ZX]

DN> with error messages.
DN> Unfortunately, there is one small problem: HOW to let
DN> the program know in which
DN> of the two modes it should work?
as you enter it, it will work...

DN> 2ALL: Anyone who has ideas for solving this problem - write.
RUN "PROGRAM".log .file spisok

RUN "PROGRAM"

immediately after launch, look for keywords and launch one of the shells.

SD> Just like c0de busters did in insulte - through the command line tr-dos
SD> %)
What if I like to run from boot, and not from tr-dos? I think the easiest way is to
make two versions.

Bye, Sergei! Vivid^Brainwave of X-Project.
Mail me: vivi...@e-mail.ru

KF> That's what I'm writing - you need 2 different programs. One of them is actually
KF> the archiver itself, which can take commands from a file OR FROM MEMORY
KF> (for example, through the BASIC channel) and another program - gyi to
KF> archiver.

I talked with the authors on this topic immediately after a couple of days they made it. They said that this was unlikely to happen. There will also be no support for directories... That is. only TRDOS... :-(

/_Priest^Energy Minds/_
_[Team Marinka][Team Spectrum][Team FREEDOM][Team LightWave]_

... Energy Minds... Step in future...

DN>> write.
SD> Just like c0de busters did in insulte - through
SD> the command line tr-dos %)

It’s difficult to substitute and the length of the line there should be huge: if I’m not mistaken
20-30 bytes. Any other ideas?

Sincerely, Dmitriy.

YP> RUN "PROGRAM" But I have MMD4.xx and I launch everything from under it. Parameters on the command line are not provided there. What to do?
I proposed an almost ideal option, for those who missed it I’ll write again:
when starting, a file with a
defined
name is searched on the CURRENT (and not A: or any other) disk, in which it is written that unzipy is needed do. Unzip does what he
is told,
in accordance with the contents of the command file and the log file can be kept and the command
file can be deleted after it has completed. If there is no command file - let it work in interactive mode, or it would be better to have a separate shell that will generate a command file and run the command. This same shell can be
used
for other archivers.

[ZX]

Replying to a message of Alexander Shashkevich to Kirill Frolov:

AS> I talked with the authors on this topic just a couple of days after
AS> they made it. They said that this was unlikely to happen. Also
AS> there will be no support for directories... That is. ONLY TRDOS... :-(

Well i'm in her garden. I have pkzip on pc, zxzip on spec...

[ZX]

DN>> write.

KF> That's what I'm writing - you need 2 different programs. One of them
KF> is actually the archiver itself,
KF> which will be able to take commands from a file OR FROM MEMORY

DN>> write.
YP> RUN "PROGRAM".log .file spisok

YP> RUN "PROGRAM"

YP> immediately after launch, look for keywords and launch one
YP> of the shells.

Not an expert, but I read somewhere that 10-20 bytes after the com lines are rubbed
by the system, so they are lost, For this reason, to launch the
hidden part, you can write anything about CODEBUSTERS, as long as the length
matches. Hence the disadvantage: it is difficult to force 20 spaces before the command line after the file name. It doesn't roll. It's a pity, the idea was beautiful. :-(

Sincerely, Dmitriy.

And it all started on 21-Dec-00 at 10:02:32, when Dmitriy Nesmachny
talked with Sergei Dubarev about Hrip

DN>>> two modes it should work?
DN>>> 2ALL: Who has any ideas for solving this problem -
DN>>> write.
SD>> The same way as c0de busters did in insulte - through
SD>> the command line tr-dos %)
DN> It’s difficult to substitute and the length of the line there should be huge: if not
DN> I’m mistaken 20-30 bytes. Any other ideas?

And if you make a program with two files: .B for 1 sector, and actually .C - the program itself; if you run it as usual, BASIC, then there will be a gui, and if you run a code file, then autopilot.

Always yours Combin8or/PHT

▒▒▓▓▓ ▄▀█▀▀▀ ▓▓▓▒▒░░ Sincerely yours, Yuri /I \
▒▓▓▀▀ ▓▓▓▓▓▓▒▒░░░░ Jerri / Alien Factory \ZX/

SD>> tr-dos %)
AM> What if I like to run from boot, and not from tr-dos? I think the easiest way
AM> is to make two versions.
You can also do it in an offtopic way - with caps shift pressed, for example, load one,
without it - the other...

WBR, Sergei Dubarev

KF>> and one more program - gyi to the archiver.

DN> It will be difficult to figure out what is there with your hands: for each program there are 2
DN> BASIC. Not beautiful.

What is ugly? For example, PKUNZIP will be a user, and pkunzip will be an automaton.

YV> And if you make a program with two files: .B for 1 sector, and
YV> itself .C - the
YV> program itself; if you run BASIC as usual, then there will be a gui, and
YV> if you run
YV> with a code file, then autopilot.

And this is not as beautiful as a candy bar: a lot of files, it’s easier to get confused on the
working disk when you work manually. Very reminiscent of someone's idea to have 2 BASIC and one code file. One BASIC is an automatic machine, the other is a guy.

It seems to me that the most convenient thing is to mark this in some cells
before starting it on an automatic machine. Who can suggest the most optimal ones (that is, those that are most likely not to be overwritten during loading)? Maybe a second
screen? Or those three unused BASIC variables?

Regards, Dmitriy.

SD>> command line tr-dos
SD>> %)
AM> What if I like to run from boot, and not from tr-dos?
AM> I think the easiest way is to make two versions.

And keep two versions on disk? Not all of us have hard drives. You need to be able to
indicate whether to screw or not.

With respect, Dmitriy.

No, you painted the machine itself beautifully, but here’s the choice... The machine
should not be used a priori, it’s inconvenient. And the way of organizing a guy through the formation of a command file is not for Spectrum. Imagine the brakes for writing (first) and
reading (later), the space is also not rubber, and then if you already have a
command file for working on the machine, what will the guy erase it? Because how can he
pass the parameter: “use this file, not that one”?
Selecting the automatic/gui mode based on the presence/absence of a command file is nonsense
of a flu-inflamed brain ;-) look for yourself: on the working disk designed for automatic
work there is already a command file. When a program is launched from
a certain task manager (which, alas, does not yet exist), 100% needs to be launched automatically.
When I launch a program from BASIC/Commander/Boot, I 99% want a guy. How can I tell a prog what I need from it: an automatic machine or a guy? What, before starting in manual mode
will I need to erase the batch file? IMHO, the most ideal option is to save
something into memory to indicate the operation on the machine.

Sincerely, Dmitriy.

Friday December 22, 2000 at 00:57:52 Kirill Frolov told Yuri Potapov about Hrip
And then I

KF> burst in to create a batch file and run the command. This same
KF> shell can be used
KF> for other archivers.
and not only for archivers.

With best wishes, Max Shashkin aka Shaitan/Stars of Keladan.

DN>> program 2
DN>> BASIC. Not beautiful.

KF> What is ugly? For example, PKUNZIP will be a human, and pkunzip
KF> will be an automatic machine.

That's it. Extra BASIC is not rulez IMHO. It's better to have one. Plus either two
programs in monoblocks for each BASIC or one more code file. IMHO, in order not to get confused when copying, you need to be the author of such a feature! ;-)

Sincerely, Dmitriy.

And it all started on 24-Dec-00 at 10:29:40, when Dmitriy Nesmachny
was talking with Yuri Voynalovich about Hrip

[...]
DN> It seems to me that the most convenient thing: before starting on the machine in some
DN> cells
DN> this mark. Who can suggest the most optimal ones (that is, those
DN> which with
DN> are most likely not to be overwritten during loading)? Maybe
DN> second
DN> screen? Or those three unused BASIC variables?

And if you check RAMTOP, and if below, say 30000 (or if a specific
number, for example 29123), then autopilot? After all, if you start from something
(tp-dos, boot, manager), then the ramtop is always high. And then, if
you write in your program CLEAR 29123:RUN USR 15619:REM:RUN "HRIP",
then the autopilot will start, and in other cases - the GUI (and the probability
of an accidental launch in the autopilot is almost equal to 0, in contrast to
POKE).

Always yours Combin8or/PHT

24 Dec 00 10:36, Dmitriy Nesmachny wrote to Kirill Frolov:

DN> No, you painted the machine itself beautifully, but here’s the choice... The
DN> machine should not be used a priori, it’s inconvenient.

Why is this inconvenient, for example, for the user? How the program will work
is not important, these are its problems.

DN> And the way of organizing the user interface through the formation of a batch file is not for
DN> Spectrum. Imagine the brakes for writing (at first) and reading
DN> (later),

iS-DOS ?

DN> the place is also not rubber, and then if you already have a command file
DN> for working on the machine, what will the guy erase it? command file -
DN> nonsense of a brain inflamed with the flu ;-)

Exactly, you need 2 programs - gui and actually unzip. You're delusional.

DN> When I launch a program from BASIC/Commander/Boot, I 99% want
DN> Guy.

How do you find out where you're running the program from? And you
are wrong when it comes to BASIC.

DN> How can I tell a program what I need from it: an automatic machine or a gui? What,
DN> before starting it in manual mode, will I need to erase the command file?

Well, I’m writing - 2 different programs, gui and unzip.

DN> IMHO, the most ideal option is to store something in memory so that
DN> indicate the work on the machine.

Not to store, butput it in a BASIC channel, for example. To avoid
writing
into the file again,

DN> Selecting the automatic/gui mode based on the presence/absence of a command
DN> file is nonsense of a brain inflamed with the flu ;-) look for yourself: on

...
DN> the most ideal option: save something in memory so that

DN> That's it. Extra BASIC is not rulez IMHO. It's better to have one.

What's stopping him? There are hundreds of files lying around in isdos and do not interfere with anyone.

DN> Plus either two programs in monoblocks for each BASIC or another
DN> code file.

So for the slow ones I write for the third time:

FIRST BASIC (IN CAPITAL LETTERS) - GUY FOR THE USER. Does not
contain unpacking functions.

second BASIC (small letters) - AUTOMATIC FOR COMPUTER. It only knows how to
unpack.

DN> IMHO, in order not to get confused when copying such a feature
DN> the author needs to be! ;-)
DN> + Origin: #21004011014001FF2AEDB0C9 ;-) (2:5020/2065.609)

Also a cool hacker, don’t you like to read documents?

DN>> I want
DN>> guya.

KF> How do you find out where you are running the program from? And counting

Damn!!!! This is what I need!!! ;-)))

KF> BASIC you
KF> are wrong.

Why? The machine launches a special program: task manager. Everything else is launched by the gui, including BASIC.

[]

DN>> mark this in some cells. Who can
DN>> suggest the most optimal ones (that is, those
DN>> that are most likely not to be overwritten
DN>> when loading)? Maybe a second screen? Or those three
DN>> unused BASIC variables?

YV> And if you check RAMTOP, and if below, say 30000 (or
YV> if a specific
YV> number, for example 29123), then autopilot? After all, if you start from

I like the idea.

YV> of something
YV> (tp-dos, boot, manager), then the ramtop is always high. And then,

Are you sure? IMHO, you shouldn't count on it 100%

Once Thu 28 Dec 2000 at 08:12:56 Kirill and Dmitriy were arguing about Hrip

KF> How is he interfering? Over there, hundreds of files are lying around and don't
KF> bother anyone.
WE ARE ABOUT TR DOS (for those who don't understand)

KF> THE FIRST BASIC (IN CAPITAL LETTERS) is GUY FOR THE USER.
KF> Doesn't
KF> contain unpacking functions.
what if it doesn't find the second file?

KF> the second BASIC (small letters) -- AUTOMATIC FOR
KF> COMPUTER. Only
KF> knows how to unpack.
well, that’s understandable

KF> Also a cool hacker, don’t like to read documents?
Yes! and who reads them, for example, I learned about the function ss+5 from the author (almost3), and
not at all because I don’t read FM, it’s just that this time I got UnZip from other
sources

Sincerely yours, Yuri /I \
\ZX/

YV> And if you check RAMTOP, and if it is lower, say 30000 (or
YV> if a specific
YV> number, for example 29123), then autopilot? After all, if you let something
YV> from
YV> (tp-dos, boot, manager), then the ramtop is always high. And then,
YV> if
YV> write in your program CLEAR 29123:RUN USR 15619:REM:RUN
YV> "HRIP",
YV> then the autopilot will start, and in other cases - the gui (and moreover
YV> the probability
YV> of an accidental start in the autopilot almost equal to 0, in contrast to
YV> POKE).
how complicated it all is. It’s easier to check before work whether there is a command
file on the disk, and then depending on the situation

KF>> Does not contain unpacking functions.
YP> what if it doesn’t find the second file?

Will format the screw.

KF> second BASIC (small letters) - AUTOMATIC FOR
KF> COMPUTER. It only knows how to unpack.

For those who cannot move at all: what you suggest is for
more other computers. And on the Spectrum, no one (I hope) will do this nonsense: launch the guy, destroy the old command file, create a command file, write the command file, start the machine, load the command file, execute the command file, destroy the command file, launch the guy. Insanity.

EG> there is an opinion - the LAST KEY variable.

EG> If you launched it manually, then we catch it using a key code different
EG> from 0,
EG> otherwise all launches were done automatically.

Old, but convenient. I'm kind of okay with that. (in the drawling, contemptuous voice of a
new Russian) \W/ \W/ ;-))))))

2 TIGGR: Well, are you connecting this feature to the automatic unzip?

With respect, Dmitriy.

29 Dec 00 09:18, Dmitriy Nesmachny wrote to Kirill Frolov:

KF>> Why is this inconvenient for the user, for example? How the
KF>> program works is not important, that’s its problem.
DN> Because generating a file with commands is slower and clumsier than
DN> using the gui directly.

The gui is made specifically for weak-minded people who cannot humanly
tell the computer
what they want. So they came up with the idea - a person points his finger (mouse) at
the picture (he doesn’t know how to read) and says “Y”, and Windows asks him - “copy?”, in response “Y”,
well, and so on...

And the computer will work with the file, it’s iron and it doesn’t care. And to
not be slow
the file can be placed in RAM.

DN>>> of the file - not for the Spectrum. Imagine the brakes for writing (first) and
DN>>> reading (later),
KF>> iS-DOS ?
DN> FDD

iS-DOS.

DN> I need to keep a file with commands constantly: I pick up mail every day
DN>, and copying it again from some backup disk every
DN> day I consider it stupid and inconvenient.

All because you don’t know how to work with tr-dos.
The COPY command “newfile”, “oldfile” copies everything on one disk and very
quickly.
And besides, I wrote that the file should not be on A:, but on the CURRENTACTIVE
disk (this is not the disk
from which the program is launched).

KF>> BASIC you are wrong.
DN> Why? The machine launches a special program: task manager.

And if you want to do it manually?

27 Dec 00 23:04, Evgeny Goljakov wrote to Dmitriy Nesmachny:

EG> there is an opinion - the LAST KEY variable.

EG> If you launched it manually, then we catch it using a key code other than 0,
EG> otherwise all launches were done automatically.

Nothing it won't work.

YV>> And if you check RAMTOP, and if it is lower, say 30000 (or
YV>> if a specific
YV>> number, for example 29123), then autopilot? After all, if you let out

YV>> random launch in autopilot is almost equal to 0, in
YV>> unlike POKE).
MS> somehow all this is complicated. It’s easier to check before work that there is a command file on the
MS> disk, and then depending on the situation

What’s so complicated about that? If you want a regular GUI, do it as before, but if you want a console mode, write CLEAR XXXXX before running (or create an additional B-file that will launch the main one with clear)

Always yours Combin8or/PHT

YV>> the probability of an accidental launch in the autopilot is almost equal to 0, in
YV>> unlike POKE).
DN> But explain here: I didn’t understand. You can post a long line: 10-20
DN> bytes, so the probability of accidentally starting the machine is about zero.

Well, if it’s long, then of course yes. Although it still depends on where to put it so that there is nothing left later. But isn't it easier to write CLEAR NUMBER, and you don't have to know where and what to leave ;)

Always yours Combin8or/PHT

DN>> I like the idea.
KF> How to launch such an autopilot from MMD?

Everything ingenious is simple ;)
- if necessary, make yourself another B-file in which you launch the
main one after CLEAR.

Always yours Combin8or/PHT

02 Jan 01 15:10, Yuri Voynalovich wrote to Kirill Frolov:

YV> Everything ingenious is simple ;)
YV> - if necessary, make yourself another B-file in which you run
YV> the main one after CLEAR.

This is what is called through ()().

02 Jan 01 14:59, Yuri Voynalovich wrote to Dmitriy Nesmachny:

YV> If you check for a specific number, then the probability of correct
YV> operation will be close to 99.(9)% ;)

Everything is clear. Again pkunzip which unpacks only 99% of the files... To the garden.

31 Dec 00 09:43, Dmitriy Nesmachny wrote to Evgeny Goljakov:

DN> Old, but convenient. I'm kind of okay with that. (in a drawling, contemptuous
DN> voice of a new Russian) \W/ \W/ ;-))))))

This will fail. Are the lamers here alone?

Write to file:
|
10 PRINT PEEK 0x5C0A |
20 GOTO 10 |
|
--------------------------+

Launch from MMD:

+----------
|13
|13
|13
|13
|13

then the spec hung... (mmd got bugged with RST 8)

There will be no automation anymore, but will it be possible to start it manually?

Launch from Max Petrov's boot:

+------------
|0
|0
|0
|0
|0
|scroll?

Further without comments...

Do you know why on Spece software is so poor? It’s not just not professionals
who are writing it,
and not even complete dummies and those same lamers who should die, but such
people
whom it is dangerous to let near a computer.

Before using such 'extreme' methods, it would be a good idea to
test them
on at least two programs (which I did did).

29 Dec 00 01:46, Igor Turashev wrote to Dmitriy Nesmachny:

DN>> That's it. Extra BASIC is not rulez IMHO. It’s still better to have one.
DN>> Plus or
IT> There will be only one Anzip, but it can work both from a file with a log saved,
IT> and with a guy. Setups rule :)

As a result, there will be two of them. One will be played by hand, the other somehow.
Well, maybe DJs will have them on different disks...

DN> For those who cannot move at all: what you
DN> are suggesting is for other computers. And on the Spectrum, no one
DN> (I hope) will do this nonsense: launch the guy, destroy the old
DN> command file, create a command file, write the command
DN> file, start the machine, load the command file, execute
DN> the command file, destroy the command file, launch the guy. Insanity.

Why insanity? The computer will do the work, not you with your hands. And the computer is iron, it will endure everything.

And the insanity is what you offered here with zero in the swallow, look at my second
letter.

DN> Yes, the coolest and most hacker damn thing. But compared to you -
DN> is just a user. I don’t like holding a huge directory of different-sized pieces of paper
DN>. And memorize the features of each program too.

So we need to create a help system in the Spectrum. You write help
"something"
and it tells you what you need. In is-dos, in each directory there was a
subdirectory
HELP with help for each program. There even seemed to be a help program that
made it possible to automate the search for help.

And there’s no need to talk about the fact that there are few files
fitting on the hard drive and only
one directory. Trdos in the Spectrum (my absolute opinion) is only neededfor one
goal - run
is-dos or cp/m.

KF> Will format the screw.

I wonder why you even respond to messages if you can’t say anything smart
? I also understand our deputies: before (I don’t know how it is now) they were paid extra for speaking in front of a microphone, so they are just like you: and there’s nothing to say - they still interfere. But why do you need this? Or are you training, will you run for the Duma? ;-)))))

Sincerely, Dmitriy.

Monday 25 Dec 2000 09:09:44, Sergey Kulkov -> Dmitriy Nesmachny:

SK> You can make two Basiks, one for the machine gun, the other for the
SK> gun. Is it possible to have the machine turn on if you don’t hold down the keys while
SK> loading. In general, a solid
SK> setup on this topic, and not only that, wouldn’t hurt.

We still need to break through a standard for software developers: how will they differentiate
guy/automatic. It is inconvenient for the user to hold the keys when he is trying to navigate. Yes
also remember where to press which button for which mode. Everything should be transparent
for a person.

With respect, Dmitriy.

DN>> is clumsier than
DN>> using the gui directly.

KF> The gui is made specifically for the weak-minded who cannot
KF> humanly tell the computer what they want. So

This phrase will go down in the annals of history. No, honestly, I will keep it and show it to my descendants. And in "Arguments and Facts" on New Year's Eve they usually award prizes for language: golden tongue, silver tongue, boneless tongue... This year Zhirinovsky received the boneless tongue. If you were a politician and this
message would get there... Next year it would be yours!

Kirill!!! Did you even think before writing? Or have you not sobered up yet after the holiday? I don’t even know, it makes sense to argue in favor of the gui, or
after thinking about it, you’ll guess that when manually working with files, the gui gives
performance an order of magnitude higher, comfort an order of magnitude higher, reliability an order of magnitude higher, pleasant impressions half an order of magnitude higher than an interface like a “command file”?

KF> came up with - the person
KF> points his finger (mouse) at picture (
KF> can’t read) and says “Y”, and Windows asks him -
KF> “copy?”, in response “Y”, and so on...

Of course, it’s more convenient to go to the editor, rewrite the names of 10-20 files with
extensions and attributes (what did you want?) into a file, then a filesave,
then activate the copy command with the “file name” key, and then after 10
minutes of work you can happily see how everything is automatically
copied! Well, unless, of course, it turns out that somewhere you entered something
wrong, and then the copying won’t happen, but the file will simply be killed.

KF> And the computer will work with the file, it’s iron and
KF> it doesn’t care. And so that the
KF> file is not slow, you can place the file in RAM.

Then you still need to have standards for combining the user interface and
archivers... Well, you’re talking nonsense, all this is not effective... :-(

KF> Nothing will work.

I wonder why?

Sincerely, Dmitriy.

YV>>> from
DN>> I like the idea.

KF> How to launch such an autopilot from MMD?

No way. The autopilot is launched from the autopilot launcher.

Regards, Dmitriy.

YV> What's so complicated about that? If you want a regular gui - let it be like
YV> before, and if
YV> you want console mode - write before running CLEAR XXXXX
YV> (or create
YV> an additional B-file that will launch the main one with clear)

And the difficulty is this: execute CLEAR from the machine code can you?

With respect, Dmitriy.

DN>> about zero.

YV> Well, if it’s long, then of course yes. Although it still depends on where to put
YV> so that there will be no
YV> left later. But isn't it easier to write CLEAR NUMBER,
YV> and you don't need
YV> to know where and what to leave ;)

There is a high probability that you will have to use the machine code.

Regards, Dmitriy.

IT> by saving the log, and with the guy. Setups rule :)

Not always. Why redo the setup every time? After all, how should the file be used? It should be used by the machine constantly, for example every night after
retrieving files from the board, and if necessary, when starting not from the “launcher
of the machine”, but from any other program at hand (boot / basic / etc...) the guy should
start, and there is no need to force the user to redo the setup every time.

Regards, Dmitriy.

04 Jan 01 10:12, Dmitriy Nesmachny wrote to Kirill Frolov:

KF>> Nothing will work out.
DN> I wonder why?

I have already written a separate letter to this question. Lameness is everything.

DN> I wonder why you even answer messages if you can’t say anything smart
DN>?

Why ask stupid questions?

KF>> don’t care. And so that it’s not too slow, the file can be placed in RAM.

DN> Then it is still necessary that there be standards for combining the user interface and
DN> archivers... Well, you’re talking nonsense, all this is not effective... :-(

On a normal computer, for exchanging information between processes there are
"pipes" files,
message queues, shared memory, all sorts of semaphores and more There are so many different things that
it’s difficult to remember everything. And what is there in the Spectrum, how can one
transmit any
information to another program? For example, what else is there? There’s nothing else,
there’s not even a command line. So why not transfer information in a file? convey,
is it bad?
Or do you know another way? Storing this into memory is a glitch - there is no guarantee that there won’t be unnecessary information there, even just
when launched from some boot.

Next, why combine the guy with the archiver? I have a console rar,
and if I
need to pack a lot of files there, then I don’t have to worry about it. Commander
with the F5 button I do everything. So, RAR is one program, Commander is another and they get along well together.
There are two different programs - the user interface and the packer. And maybe.It
will happen that
only one packer is needed, and the interface is not needed, so why will it
take up space on
the disk? You can, of course, make two unpackers - one with
a built-in interface, the other
without an interface. But if the user suddenly needs both on one disk at the same time, then again
the part that unpacks will take up extra space on the disk. As a result, no matter how you look at it, you end up with two files. Because there is no reliable way (except through a
file) to tell
the unpacker in which mode to work. And if there is such a method, then this
option may
take up extra disk space if the interface is not needed.

DN>> guya. Insanity.

KF> Why insanity? The computer will do it, not you
KF> with your hands. But the computer is iron, it will endure anything.

The disk, for example, is not iron. And it will “tolerate” a finite number of read/
write cycles. I'm not made of steel either. I'm not going to wait 10 minutes. I have a real one, not a pc.

KF> And the insanity is what you proposed here with zero in the lastkey,
KF> see my second letter.

Firstly, it was not me who proposed, I only praised the idea, and secondly, I am responsible for my
words: this idea will work even despite your second letter.

[]

KF> So you need to create a help system in the Spectrum.
KF> You write a help “something”
KF> and it tells you what you need. In is-dos, in each
KF> directory there was a subdirectory
KF> HELP with help for each program. It seems like there was even a
KF> help program that
KF> allowed you to automate the search for hints.

Well, if you need it, do it...

KF> And there’s no need to talk here again about the fact that the
KF> hard disk doesn’t fit enough files and there’s only
KF> one directory. Trdos in the Spectrum (my Absolute opinion)
KF> is needed only for one purpose - to launch
KF> is-dos or cp/m.

It’s time to learn to separate your personal opinion and the Absolute truth. You are still doing it with difficulty.

With respect,Dmitriy.

KF> This will glitch. Are there only lamers gathered here?

Well, except for Frolov, probably :-F

KF> Write to file:
KF> |
KF> 10 PRINT PEEK 0x5C0A |
KF> 20 GOTO 10 |
KF> |
KF> --------------------------+

KF> Launch from MMD:

KF> +-------------------------
KF> |13
KF> |13
KF> |13
KF> |13
KF> |13

KF> then the spec hung... (mmd got bugged with RST 8)

KF> There will be no automation anymore, but will it be possible to start
KF> manually?

Well, first of all, MMD is not a machine launcher. EMS will be able to launch so that
LASTKEY will have the value that was ordered.

KF> Launch from Max Petrov's boot:

KF> +---------------------------
KF> |0
KF> |0
KF> |0
KF> |0
KF> |0
KF> |scroll?

KF> Continue without comments...

What do you mean by "scroll?" didn't like it? Or are the zeros not enough for you? Well, no one
will identify the machine by 0, the machine will be determined by the presence of the code "A".

KF> Do you know why the software on the spec is so poor? It’s not

How do you usually define the wretchedness/ruleness of the software?

KF> it’s just not professionals who write it,
KF> and not even completeteapots and those very lamers who
KF> should die, and such people
KF> whom it is dangerous to let near a computer.

Such “professionals” as you, if I’m not mistaken, have not written anything at all. And
they will never write. Because instead of taking and writing something, they
are engaged in useless flames.

KF> Before using such 'extreme' methods
KF> it would be nice to test them
KF> on at least two programs (which I did).

Damn tester. There's only one thing you didn't understand: how it was all supposed to work according to
plan, from your test you drew completely wrong conclusions.

Regards, Dmitriy.

Sun 31 Dec 2000 I dug up a letter from Dmitriy Nesmachny to Kirill Frolov
on the topic "Hrip"...

DN> about this) and you won't get confused, but in TR-DOS, no matter how shock
DN> it may be for you, there is only one directory in which EVERYTHING is!
By the way, this is what KILLS. I can't stand it when there are a lot of files. Therefore, all sorts of
file_id.diz & read.me enrage.

Sincerely, Oleg. [ZX]

KF> at least in two programs (which is what I did).
No... you didn’t do it, so, I guessed it out of the blue. If you're bending your fingers like that,
it would be better if you wrote the FAQ thread yourself.

Damn, apart from a bunch of verbal diarrhea (2All: sorry) there's nothing meaningful/visible from you.
You only spoil people's mood.

Sincerely, Oleg. [ZX]

DN> Well, first of all, MMD is not a machine launcher. EMS will be able to launch
DN> so that LASTKEY will contain the value that
DN> was ordered.

to the underlined:
you still need to think about the value, i.e. what kind of UNPRINTING symbol to use.

...
KF>> No further comments...
I immediately felt better...

DN> What do you mean by "scroll?" didn't like it? Or did the zeros not suit you? Well, no one will identify the machine by 0,
DN> the machine will be determined by the presence of code “A” there.
^^^^^^^^
...
DN> Damn tester. There’s only one thing you didn’t understand: how all of this
DN> was supposed to work as planned, from your test you drew
DN> completely wrong conclusions.
DN>

explain again in this case, because the excitement has subsided and give
a link to NICRON#119 (PARAGRAPH#2).

Thank you for your attention.

06 Jan 01 10:59, Dmitriy Nesmachny -> Kirill Frolov:
[skipped]

KF>> There will be no automation anymore, but will it be possible to start
KF>> manually?

DN> Well, first of all, MMD does not have a starter machine gun.

Who said that? ~E

DN> EMS will be able to launch in such a way that LASTKEY will contain the value that
DN> was ordered.

In MMD this is also done easily!
Not only will it launch
what is needed at the right time (according to the right conditions), it will also write what is needed in any memory area.
At least in LastKey, at least somewhere.

And the fact that FK had 13 there is absolutely correct!
He also started the fire from the MMD with his hands!
Who pressed the “Enter” button? ;)

And the glitch with the absence of “scroll” has already been fixed. ;)

[Windows were killed]

KF>> No further comments...

DN> What do you mean by “scroll?” didn't like it? Or did the zeros not suit you? Hy
DN> so no one will identify the machine by 0, the machine will be determined
DN> by the presence of the code “A” there.

Why exactly “A”?

[Windows were killed]

KF>> it would be nice to test them
KF>> on at least two programs (which is what I did).

DN> Damn tester. There’s only one thing you didn’t understand: how it was all supposed to
DN> work according to the plan, from your test you made completely wrong
DN> conclusions.

Why?
Many byts withthey use ROM polling of the keyboard.
And the same program can be called from it with different LastKey values!
Selecting the letters “A” as an autostart marker is stupid.
If you do choose, then it’s a code that cannot be entered by hand :))

Aleksandr

06 Jan 01 10:59, Dmitriy Nesmachny wrote to Kirill Frolov:

DN> Well, first of all, the MMD does not have a machine trigger.

What is this??? This is a PROGRAMMABLE terminal. Inside there is a language like
assembler with BASIC,
you can program this... even on a nearby PC you can
format the disk!

DN> EMS will be able to launch so that the LASTKEY will have the value
DN> that you ordered.

Yes, that’s not the problem, and in MMD you can use POKE to
drive anything into
before starting lastkey.

DN> What do you mean by "scroll?" didn't like it? Or are the zeros not enough for you? Well
DN> so no one will define the automaton by 0, the automaton will
DN> be determined by the presence of the code “A” there.

The letter “A” and any other code can just as “accidentally” end up in this
variable as zero. Let's say you decide to use 255 - well, there is no such
button in
Spectrum. But who or what gives a guarantee that there is no such
rebooted program
that, when running other programs from under itself, does not shove 255 into the swallow? And
there is no need for fairy tales
about the theory of probability.

DN> “Professionals” like you, if I’m not mistaken, do nothing at all

I’m not a professional. And not a cool coder. That's why I write mostly in golded...

DN> they wrote. And they will never write. Because instead oftake
DN> and write something, they are engaged in useless flames.

But I don’t need to write anything like that. Why should I write for Spectrum?
Spectrum is now only needed to play with a toy and feel nostalgic...

DN> Damn tester. There’s only one thing you didn’t get right: how it was all supposed to
DN> work as planned, from your test you drew completely incorrect
DN> conclusions.

The conclusions are correct - different programs write what they want in flippers.
The only way to be guaranteed to run the part of the unzip you need is to have two different launch files on disk.

DN> The disk, for example, is not made of iron. And it will “endure” a finite number of read/write cycles
DN>.

A magnetic disk can be rewritten almost an unlimited number of times.
Almost because the disk can simply physically wear out, the holes will wear out
for example.
And whether you write it or just read it, the degree of wear does not change.
But the disk spins all the time, in short, it makes no difference...

DN> I’m not made of iron either. I'm not going to wait 10 minutes. I have real, but
DN> not PC.

Copying a file takes less than 10 seconds. And if you have a Spectrum with
a tape recorder,
then it’s time for you to upgrade it. Connect the screw and don’t worry.

KF>> In is-dos, in each directory there was a HELP subdirectory with help for each
KF>> program. There seemed to even be a help program that allowed
KF>> to automate the search for a hint.
DN> Well, if you need it, do it...

I have this. Only the program is called not help, but man.
And without help it is impossible, if I have 1500 programs, then of course I cannot
remember why they are all needed. I only know maybe a hundred.

DN> It’s time to learn to separate your personal opinion and the Absolute
DN> truth. You still do it with difficulty.

There is no such thing as absolute truth.

06 Jan 01 13:16, Oleg Groskow wrote to Kirill Frolov:

OG> Show me at least one Spectrumist who became a lamer at the PC?

I am!

4.01.2001 at 09:51 Dmitriy Nesmachny wrote to Sergey Kulkov:

[the rat gnawed it]

DN> We still need to create a standard for software developers: how will
DN> differentiate between a manual and an automatic machine.

The standard is a good thing, but at the moment it’s already possible without it There's so much software written that you don't know what to grab onto. And it’s convenient for everyone in their own way.
Even file marking has survived two standards...

DN> Holding the keys is inconvenient for the user when he starts to use the user.

It’s a lot to hold there... Enter didn’t immediately release, and that’s it. Standard CV, however
:)

Well, that seems to be all for now. Happy!

... My prince is the Prince of Silence. (C) Nautilus Pompilius

EG> to the underlined:
EG> you still need to think about the meaning, i.e. which
EG> UNPRINTING symbol to use.

IMHO: #1B will do just fine. You're right, some kind of bot can launch files using the "A" button. Bv launches them using the "R" key...

Regards, Dmitriy.

DN>> this... :-(

KF> On a normal computer for exchanging information
KF> between processes there are “pipe” files,
KF> message queues, shared memory, all sorts of semaphores and
KF> there are so many other things that
KF> it’s difficult to remember everything. And what is there in the Spectrum, how can one
KF> program transfer some
KF> information? For example, there are files. And
KF> there is nothing else, not even a command line. So why not transfer
KF> information in a file? effective, but what is actually not effective? 63kb

Damn, it’s not effective to introduce a new, fundamentally unnecessary operation:
transferring information through a file between the UI and the program, if this GUY can be built
into the program. On the Spectrum, it’s hard to imagine a situation when the program
is only required to use the automatic mode, never using the GUY.

KF> to transfer it at once, isn’t it bad?

Yes. It's bad, space for the file is needed, media is worn out... I've already written all this, as much as possible? But I don't need 63 kb, I need 1 bit: automatic/gui.

KF> Or do you know another way? Storing it into memory is a glitch -

Storing it into memory.

KF> there is no guarantee that at least just
KF> won't end up there by accident.unnecessary information when launched from
KF> some boot.

Even a monkey can turn out Hamlet (if it hammers on the keys),
just remember the theory: with what probability? A few bytes are quite enough
to state that the probability of random operation is PRACTICALLY
equal to 0. In addition, for the machine you can simply not use a boot that
is buggy with mode detection. All the same, it will be easiest to launch something from the boot that is there. Debug it so that it runs OK under RC, and we'll just
use it...

KF> Next, why combine the UI with the archiver? Here I have a console rar, and if I
KF> need to pack a lot of files there, then in order not to
KF> suffer in the commander with the F5 button, I do everything
KF>. So, rar is one program, commander is another, and
KF> they get along well together.

On the PC. This requires a huge redundancy of resources, as if you are seeing a computer for the first time, everything has to be explained to you... Yes, it’s cool, yes, flexibility
immeasurable, yes, it has been tested over the years, yes, everyone likes it, yes... But TR-DOS is not
adapted for this (alas), if the developers of TR-DOS supported an electronic disk
... Then we could talk about a standard for the location of files in memory and
based on this, exchange files between programs through memory. And since this is not the case,we have to talk ONLY about exchanging files via disk. And this
is unprofitable for 1 bit. If there is no other way out, then, of course, you can
do it this way, but in the examples that you gave there is an alternative: to
define the machine/gui poki in memory, for transfer between the gui/archiver
to combine these two programs...

KF> There are two different programs - the user interface and the
KF> packer. And it may happen that
KF> only needs one packer, and the interface is not needed, so
KF> why will it take up space on the
KF> disk? You can, of course, make two unpackers - one with

On the Spectrum this is unlikely, I’ve had the machine running for six months now, PKUNZIP
converted to an machine is used, but still sometimes you have to run it for
unpacking in manual mode, and then you use the guy.

KF> with a built-in interface, the other
KF> without an interface. But if the user suddenly needs both on one
KF> disk at the same time, then again

What, the one with the gui cannot be used without the gui? I mean run it automatically. What difference does it make to the computer whether it displays a nice progress bar on the screen or not, because the monitor is turned off anyway. How will it interfere?

KF> the part that unpacks will take up extra space
KF> on the disk. As a result, there will be no

, since there will only be the version in whichbuilt in.

KF> cool, you get two files. Because there is no reliable
KF> way (except through a file) to tell the
KF> unpacker in which mode to work. And if there is such a
KF> method, then this option may
KF> take up extra disk space if the interface is not needed.

All this can be read in the MSDOS description. That's not what I asked.

DN> IMHO: #1B will do just fine. You're right, some kind of boot on
^^^^^^^^^^^^^
DN> button "A" can launch files. Launches them bv on
DN> the "R" key...

to the underlined:
I would like to hear a more specific rationale.

Thank you for your attention.

DN> Really? I meant preparing the file actually...

The program should do this itself. There's no need to climb with your hands where you're not supposed to.

DN> Damn, it's not effective to introduce a new, fundamentally unnecessary
DN> operation: transferring information through a file between the guy and the program, if this
DN> guy can be built into the program. On the Spectrum it is difficult to imagine
DN> a situation where the program requires only automatic mode
DN> without ever using the user interface.

Yes, easily. And it was and is. You can’t imagine this.

DN> Yes, it’s bad. Slowly, space for the file is needed, media wears out... I'm

Nothing wears out... Finally install the screw.

DN> Put it in memory.
KF>> there is no guarantee that there won't be unnecessary
KF>> information there, at least by accident, when launched from some boot.
DN> Even a monkey can turn out Hamlet (if it uses the keys
DN> hammer), just remember the theory: with what probability? A few
DN> bytes are quite enough to state that the probability
DN> of random operation is ALMOST equal to 0.

A computer is not a monkey and here you need to count from someone else. For example
they started the machine, but it malfunctioned. Then they launched it by hand, but the memory was not
cleaned,
the program there is this magic codewill find it and fail again. Yes, and a monkey too
can
do something that doesn’t fit into the theory...

I already wrote that the only 100% way is to have two DIFFERENT file names.

DN> worth it. Debug it so that it runs OK under RC, and we will only use it
DN>...

But I don’t use RC and won’t. I'm not interested in loading it from disk for a few seconds every
time
and then watching what kind of slow cursor is barely crawling.

DN> yes... But TR-DOS is not suitable for this (alas), if the developers
DN> TR-DOS supported the electronic disk... Then we could talk
DN> about a standard for the location of files in memory and based on this make
DN> exchange files between programs through memory. And since this is not the case,
DN> we have to talk ONLY about exchanging files via disk. And this
DN> is unprofitable for 1 bit.

There will be not one bit, but several hundred times more.

KF> The letter "A" and any other code can just as well
KF> "accidentally" end up in this
KF> variable, just like zero. Let's say you decide to use 255
KF> - well, there is no such button in the
KF> Spectrum. But who or what gives a guarantee that there is no
KF> such a rebooted program
KF> that, when running other programs from under itself, does not push
KF> into the 255 fold? And there is no need for fairy tales about the theory of probability.

Well, if you don’t like it, don’t listen, you don’t have to use this particularly
glitched program with the machine gun. And when using the same archiver
NOT with an automatic machine, you can provide for automatic start blocking in the setup.

[...]

KF> But I don’t need to write anything like that. Why do I need to write for
KF> Spectrum?
KF> Spectrum is now only needed to play a toy and
KF> to be nostalgic...

Then why are you constantly interfering with those who are doing something else? Will the new version of TRDN, for example, prevent you from feeling nostalgic?

DN>> real, not PC.

KF> Copying a file takes less than 10 seconds. And if you
KF> have a Spectrum with a tape recorder, then it’s time for you to upgrade it.
KF> Connect the screw and don’t worry.

10 seconds? (Write - load archiver) - load packages - write
result - (erase batch file - load gui). What is in brackets is what you insist on and what I want to avoid. Will it take 10 seconds? And even
even if it works with small files, why would I
lose these 10 seconds? You are suggesting stupidity. :-(

Sincerely, Dmitriy.

DN>> value,
DN>> what
DN>> ordered.

AM> This is also done easily in MMD!
AM> Not only will it launch at the right time (according to the right conditions)
AM> what is needed, it will also write it to any memory area whatever
AM> is needed.
AM> Whether in LastKey or anywhere.

It doesn’t matter what is more convenient for us in the project. Moreover, IMHO, making a machine launcher - a kind of task manager - in a terminal is not the most
correct thing. The terminal has a slightly different task: exchanging files with a remote computer. So you can use it as a launcher, no one argues, but
_it would be more convenient_ to use what our group is currently working on.

AM> And the fact that FK was 13 there is absolutely correct!
AM> He also _hands_ started the burner from the MMD!
AM> Who pressed the "Enter" button? ;)

And the running program will determine the manual launch... ;-)

AM> And the glitch with the absence of “scroll” has already been fixed. ;)

Listen, can you give me a description of MMD? Otherwise I didn’t even read it...

AM> [Windows killed]

KF>>> No further comments...

DN>> coolness.

KF> And I’m not (root0th $tsENER.

Mr. Frolov, let’s not be distracted from the echotag.

Besides, let me remind you that in this echo the main language is Russian, English and Ukrainian are not prohibited
but nothing is written in the rules about the stager’s language.

KF> @PATH: 5030/827 588 23 5020/238 465/132 213

[I ZX] [Team Guardian] [Team Kelly]

Hasta la vista.
Tim Kelly

Don't tell me what I need to do
and I won't tell you where you need to go

... tim_...@mail.ru 500:622/1@zxnet http://kgs.h1.ru

SK> There’s a lot to keep there... Enter didn’t let go right away, and that’s all. Standard
SK> ChV, however :)

What if I launched it with a mouse?

KF> I!
A friend told this story about 2 years ago:
He asks, in short, he asked his classmate, who began to attend courses
“computer operators”, when, they say, will you become a lamer? And she answers: “I’ll study for two more months and I’ll be.”

Bye! Vivid^Brainwave of X-Project.
e-mail me: vivi...@e-mail.ru
vivi...@mailru.com

OG>> lamer?
KF> I !
There’s a special conversation about you. You need to be treated.

Sincerely, Oleg. [ZX]

DN>> Last
DN>> I repeat: this is not feasible on spec.
KF> ^^^^^^^^^^^^^^^^^^^^^^^^^
KF> You should make a small program that will
KF> prove the opposite?

don’t bring FK0 to sin ;)

...
KF> they started the machine, but it malfunctioned. Then they launched it
KF> by hand, but the memory was not cleared,
KF> the program will find this magic code there and fail again.

An interesting idea, by the way, since it is necessary to develop
more methods for determining the continuity of the chain of launched programs of the current
task/event, executed automatically.

The accepted concept looks only in the log file, and only
when a new/next event is activated - Is this enough? What is the supposed inter-program control of the kernel?

Are idle control switches on the ZXA necessary?
If so, then after what events are they required?

There is an idea to program the clock not to turn off after a certain time (to prevent the task from freezing), but to program
the control RESTART before executing the task, but when When the task is completed correctly, turn it off immediately.

I would like to hear KPN’s comments and ideas on how much this will complicate
the original circuit of the machine. (toMRL: contact us as soon as possible)

Thank you forattention.

EG> to the underlined:
EG> I would like to hear a more specific rationale.

Do you know how to enter code #1B from the keyboard? There's a "chord" like EXT, then
CS+3 or something like that. Not a single programmer in his right mind and sober memory would
attach the “run file” function to this button...

Sincerely, Dmitriy.

SK>> Standard
SK>> ChV, however :)

KF> What if I launched it with a mouse?

Exactly, I’m talking about the same thing! :-)

Sincerely, Dmitriy.

And when it failed, did we press reset? And she erased this magic code. (It’s just the way the monitor in the ROM is designed, it will definitely be erased, unless you climbed into the ROM with a blunt
ultraviolet object).

EG> An interesting idea, by the way, since it is necessary to develop
EG> also methods for determining the continuity of the chain of programs launched
EG> of the current task/event, executed automatically.

EG> The accepted concept looks only at the log file, and
EG> only
EG> when a new/next event is activated - is this
EG> enough? What is the supposed inter-program control of the kernel?

EG> Are idle control switches on ZXA necessary?
EG> If so, then after what events are they required?

The concept is this: when starting a task consisting of a chain of programs, for example:
EMS->PKUNZIP->LARA
we will do this: ZXA->EMS->ZXA->PKUNZIP->ZXA->LARA->ZXA
with a mark about the completion of the next step by writing a log file for each
program or some kind of flag (not yet worked out). When we load the ZXA
and launch the next task, we program the CMOS clock alarm for a time
knowingly sufficient to complete the task; when loading the ZXA, we move this time
even further forward; before turning it off, we set it to the time
of the next task from the task list.
If the alarm went off whenrunning computer, it will generate a RESET signal, after
which ZXA will boot and, by the absence of logs of the frozen program or by the flag, determines that the chain has broken, that this is an emergency call. By its variables
it determines at which step of which task it hung, writes about it in the log and, in
according to the program, tries again or interrupts the execution of
task.

EG> There is an idea to program the clock not to turn off after
EG> a certain time (to prevent the task from freezing), but
EG> to program it to the control RESTART before execution tasks, and
EG> immediately turn off when the task is completed correctly.

Well, that’s how it’s intended.

EG> I’d like to hear KPN’s comments and ideas on how much this
EG> will make
EG> heavier than the original circuit of the machine. (toMRL: contact as soon as possible)

Well, he’s counting on it anyway.

Sincerely, Dmitriy.

SK>> Standard
SK>> CW, however :)

KF> What if I ran it with a mouse?

You can use a command line like
RUN "DEPAK","archive"
If there is no comma, then there will be a GUI, otherwise the archive file is unpacked.
The command line is practically endless, but is really limited only by
RAMTOP...

- Alone Coder

DN> All the same, what will be more convenient for us in the project. Moreover,
DN> IMHO, making a machine launcher - a kind of task manager - in a
DN> terminal is not the most correct thing. The terminal has a slightly different task: exchanging files with a remote computer. So you can use
DN> as a launcher, no one argues, but it will be _ymore convenient_ to
DN> to use what our group is currently working on.

Let's consider an example with working on a network.

You need to: accept an incoming call or make a call,
exchange files, launch some program with the indication that it was launched by
"automatic launcher".

Now tell us why MMD is not a "launcher".

[skipped]

[*] - offtopic

[I ZX] [Team Guardian] [Team Kelly]

Hasta la vista.
Tim Kelly

... tim_...@mail.ru 500:622/1@zxnet http://kgs.h1.ru

... tim_...@mail.ru 500:622/1@zxnet http://kgs.h1.ru

DN> You answered your own question: this is a terminal. The launcher of the machine
DN> - this will be something somewhat similar, but specially created for
DN> the operation of the machine.

I'm tired of this useless flame. You're trying to argue with me when you
haven't even seen this very MMD! (judging by your next letter). For me
the combination MMD + Melon + Hacked UnZiP + UZTOSSER worked as a Wicom BBS,
took
and sent mail to two other Wicom BBSs (point system only, routing
primitive
by file name), and also took mail from three pisishniks with hackers. So I
launched
everything there was just MMD and there was no need for any automatic machines. At the same time, the SPbzkhnetnaya
mail in general
was delivered fully automatically, like golded on PC - launched and read,
only instead of
golded DME.

DN> Then why are you constantly interfering with those who are doing something else?
DN> But will the new version of TRDN, for example, prevent you from being nostalgic?

As for TRDH, from my point of view This is generally a harmful program
for the Spectrum,
however, like many other tr-dos programs. They simply slow down the development of
Spectrum.
There are, for example, is-dos and the problems that people are trying to solve have already been
solved there long ago. And it’s much easier to deal with the still
unsolved ones than in tr-dos. And don’t write that is-dos
sucks just
because you have somethingit slows down - firstly, the system needs to be adjusted at least a little,
and secondly, your computer is slow. The green scorpion with smook
works just
ideally, but even on my yellow one with the ramdisk it can work. Yes, and on Spec-48
you can...

DN> you can refuse to use THIS SPECIFIC PROGRAM together
DN> with the machine.

Everything can be boiled down to the fact that it’s easier not to use this machine.
There is a Linux
shell for MMD from the Spectrum. There are no problems with unpacking files on the PC.

DN> 10 seconds? (Write - load archiver) - load packages -
DN> write result - (erase batch file - load gui). What
DN> in brackets is what you insist on and what I want to avoid. Will this take 10
DN> seconds? And even if it works with small files, all the same
DN> why would I waste these 10 seconds? You are suggesting stupidity. :-(

You are writing nonsense, I don’t even quite understand what and where you should
download
there. And the place of the GMD has long been in the museum. Now a disk is at least called a
CD-ROM disk.
Install the screw, is-dos and it will be not 10 seconds, but 10 milliseconds.

DB> You can use a command line like
DB> RUN "DEPAK","archive"

Only in ZX.SPECTRUM the flame was finished, so here you decided to start...

DB> If there is no comma, then there will be a GUI, otherwise the archive file is unpacked.

There will never be a comma. It will be killed when the program starts.

KF>>> with your hands, but the memory has not been cleared, the program there will find this magic code
KF>>> and fail again.
DN> And when it failed, did we press reset? And she erased this magic code
DN>. (It’s just the way the monitor in the ROM is designed, it will definitely be erased if
DN> you didn’t climb into the ROM with a blunt ultraviolet object).

It’s your brake firmware that sucks. But I have MadROM, there
the memory is not cleared and as a result it works instantly and files
are also not deleted in 10 seconds.

DN> The concept is this: when starting a task consisting of a chain of programs,
DN> for example: EMS->PKUNZIP->LARA we will do this:
DN> ZXA->EMS->ZXA->PKUNZIP->ZXA->LARA->ZXA with a mark about the execution
DN> of the next step by recording a log file by each program or some
DN> flag (not yet worked out). When we load the ZXA and launch
DN> the next task, we program the CMOS clock alarm for a time
DN> that is obviously sufficient to complete the task, when loading the ZXA we are

Insanity. The only sober thought is to use an alarm clock as a
watchdog timer.

After all, no one is stopping _ALL_ the programs listed here from being taught to run
not
through BASIC, but in some other way, so that they can simply return via
RET.

KF> The PC is messing with your brain too. THERE IS NO SUCH COMPUTER "PC"!
KF> PC is a Personal Computer.

Hmmm... We'll treat... Haven't you read the book "The Adventures of Captain Vrungel on the yacht "Trouble""? If you read it, then remember the chapter where Vrungel remembers how he tried not to use marine terminology in order to wean himself off marine slang. And so he gives a lecture to the students, and each time he replaces “mast” with
“a wooden cylinder vertically installed on the deck with a height from ... to ...
with a diameter of about ... intended for...”, “yard” with “horizontally
located on a vertically installed on the deck ..., ... profile,
intended for...” and so on, as a result of which he lost a lot of time,
didn’t really say anything, but what he said, no one understood. Well, especially for you, change the phrase “works on a PC” to “works on a computer assembled on the basis of processors compatible with X86 or higher from INTEL”? Or will you understand
that when they say “PC”, they are talking about them?

KF> Spectrum is also a PC, even more PC than some
KF> Pentium. It works on other computers
KF> and not only on the PC as you understand it, and on machines
KF> comparable to the Spectrum it also
KF> worked, butHow is spec so different that it can’t work on it?

I’ve already said and am tired of repeating: mainly focused on FDD. I
said that where this cannot be avoided, interprogram exchange via files is really the most convenient way. But to split the archiver into two programs,
to exchange between them via disk - this should die without being born, because
it’s bad... And the start flag in automatic mode should also not be transmitted in
the file/by the presence of a file, because it is inconvenient to erase the file each time to manually start
and then to restore the machine again write down...

DN>> let it go.

SK> Keep it there a lot... Enter didn’t let go right away, and that’s it.
SK> Standard CV, however :)

Yeah, just to find out about this you’ll have to dig through a mountain of manuals. And
the user will not even think that it is possible to work there somehow in manual mode, he
will see that the machine starts up every time and will do as Kirill suggests: manually
create a file with commands, run it, wait until everything works, erase...
;-)

Regards, Dmitriy.

Once Fri 19 Jan 2001 at 00:48:06 Kirill and Dima were arguing about Hrip

KF> There will never be a comma. It will be killed when the
KF> program is launched.

If your program uses more than 1 cell of the calculator

if the loader looks like this

1 randomize usr 0 :rem codeloader

then everything is ok because only 5 bytes are killed: (RUN "fil) (ename".automatic) a
this will remain! and that's enough

and if you have programs on disk with the names "a" "b" "c"
then it's YOUR problem - you'll get a GUI :)

Sincerely yours, Yuri /I \
[No RAR allowed] \ZX/

DN> Yeah, just to find out about this you’ll have to dig through a mountain of manuals
DN>.

Let the help read it right away, before using it. Or you can throw out one line of
information on the screen during the loading process.

19 Jan 01 10:41, Dmitriy Nesmachny wrote to Kirill Frolov:

DN> You need a computer plus programs, since goldeds cannot be allowed in without a computer
DN>. And your phrase about the fact that the computer is created for
DN> programs, and not for the user - this is something from science fiction, like
DN> "The Matrix" or "The Werewolf Law"...

Yes, you've seen enough science fiction... Of course, for programs. Well, explain
why would I need it
without programs? I would disassemble it for spare parts for spec... Or
you say the programs
don’t live there?

DN> to use your program, the majority will prefer the previous
DN> version, where the archiver and the user interface are made as one whole. At least
DN> this is really normal and works quickly. IMHO.

On a floppy drive, loading the archiver will actually take a long time. Well, then
you should also
remember about users with a tape recorder...

DN> especially for you, change the phrase “works on a PC” to “works on a
DN> computer assembled on the basis of processors compatible with X86 or higher
DN> from INTEL”? Or will you understand that when they say “PC”, they are talking specifically
DN> about them?

So this works not only on computers built on x86 processors from
Intel.
It works everywhere, not even on the Spectrum.

DN> PC's approach: insteadin order to think with your head how to do it so that
DN> would work on the current configuration - plug in a new piece of hardware and not
DN> suffer... Think about something else...

It's cheaper. Program development also costs money. On the Spectrum, this
is not valued at all.
When you buy all the programs for money, then their cost
will very quickly exceed
the cost of your computer several times.

DN> If our machine malfunctions, then we usually press RESET. And RESET -
DN> cleans the memory like a darling. Well, unless, of course, all sorts of smart people with
DN> ultraviolet lamps didn’t climb into the computer...

But I did. And you don't need a lamp. Because:

1. There are different versions of TR-DOS and BASIC...
2. There is RESET interception on Scorpio.
3. About the same thing is on ATM-TURBO.
4. There are resident commanders using the MAGIC button.
5. There are smart people with homemade firmware.

I have 4 and 5 yes.