NeOS

Damn work! Today I wrote a command line editor, a procedure for recognizing decimal and hex numbers. NeOS began to understand
some commands. There are four of them so far, but this is a temporary phenomenon. What am I actually writing - what commands are needed in NeOS? Interested in everything!

With respect, Roman aka Megus of Brainwave Association.

[Team ZX-Spectrum] [Team Agatha Christie] [Team Metallica] [Team Iron Maiden]

Once, 13 Aug 98, a certain Roman Petrov
wrote to All, on the topic: [NeOS]

[skip]

RP> temporary. Actually
RP> what am I writing - what commands are needed in NeOS? Everything is of interest!

format C: /q /u

;)

With that, Roman, let me say goodbye.
KIR.

I don’t know the commands, but 63 letters per line is NOT ENOUGH! Better than 256.

But this is for manual work, and for automation you need more
progressive ways of transferring parameters to the task.
The most important thing is to provide for the possibility of expanding the system!
(otherwise it will be like isdos...)

W!7h Be$7 W!$he$, FK0.

RP> Damn, work! Today I wrote a command
RP> line editor, a procedure for recognizing decimal and hex numbers. NeOS
RP> began to understand some commands. There are four of them so far, but this phenomenon
RP> is temporary. What am I actually writing - what commands are needed in NeOS?

Let's pose the question differently - are commands needed there? And in general
the command line as such?

There is such a UNIX system. And there is a shell there, which they like to call the command line. This is a very useful thing: firstly, you can write
scripts that execute automatically, and secondly, you can
work as a terminal on a remote machine on the network. Further, the UNIX shell
is the same user program as everyone else.

So, this is what I mean. Do you plan to have remote access?
Will you have scripts? If not, then why the command line?
The user will still put some kind of commander - if there is one,
naturally. So arrange for the presence of a commander. ;)

__
__/ / Powered [pepsi inside]
\_\/ by MOTOROLA [smoking suxx]

At 01:42, Saturday August 15, 1998 it was such a thing that
Kirill Chubenko wrote a letter to Roman Petrov:

RP>> temporary. Actually
RP>> what am I writing - what commands are needed in NeOS? Everyone is interested!
KC> format C: /q /u
KC> ;)
No, I’m serious ;-) In general, the formatter, due to the multi-system nature of NeOS
is placed in a separate program, and is not a NeOS command. Today I'll post a list of all NeOS commands. If anything, please add (there are about 30 teams).

With respect, Roman aka Megus of Brainwave Tracks.

[Team ZX-Spectrum] [Team Iron Maiden] [Team Die Krupps] [Team Guitar]

At 01:04, Sunday August 16, 1998 there was such a thing that
Kirill Frolov scribbled a letter Roman Petrov:

KF> I don’t know the commands, but 63 letters per line is NOT ENOUGH! Better than 256.
Give me an example when 63 characters are not enough for you? When passing
parameters to a program? This is the only case, but for example, even in my case, this rarely happens. If you can suggest a way in which I can freely implement 256 characters per line, and also make it convenient to pass parameters to the program, then I will do it and thank you very much. Why I shortened the length of the command line: I have little space for system variables. And anywhere, except for system variables, the command line is not allowed.
And so the command line is perfectly remembered and the program does not cost anything
freely take your parameters. By the way, on the PC the length of the command line is 128.

KF> But this is for manual work, and for automation you need more
KF> progressive ways of transferring parameters to the task.
Give me a hint, I’ll implement it.
KF> The most important thing is to provide for the possibility of expanding the system!
Expanding the system? What did you mean by that? Possibility of programmatic
extension of the command system? There is a possibility by intercepting the error
Unknown command.

At 11:41, Tuesday August 18, 1998 there was such a thing that
Denis Sotchenko wrote a letter to Roman Petrov:

DS> Let's pose the question differently - are teams needed there? And in general
DS> the command line as such?
Necessary due to some spec features. In general, I’ll explain now.

DS> So, this is what I mean. Do you plan to have remote access?
Hmm, interesting idea, but for now Spectrum doesn’t need it, IMHO. Once the Spectrum grows up, local networks of Spectrums will appear, then I will specially make a version of NeOS with remote access. In principle, there won’t be anything
very complicated there, but with such a server, you must agree, only one user will be able to work, because multitasking on Speccy is
impossible.

DS> Will you have scripts? If not, then why the command line?
Scripts - there will be. This was planned right away.

DS> The user will still appoint some commander - if there is one,
DS> naturally. So arrange for the presence of a commander. ;)
And the team will definitely be in order. It’s even already well-developed
on paper; we haven’t started writing it yet due to the BIOS being unfinished.

And now I’m explaining some of Spec’s features, which
require a command line.
Programmers on the Spectrum are not spoiled by integrated environments (assembler +
debugger + moresomething), although there are some. And yet programmers sometimes
have to return to the system (in the case of TR-DOS, this is BASIC). If
there is no line command, then where will the assembler return? On the team?
What if it’s not necessary? This is exactly why the command line is needed. Its capabilities
are not very inflated, but at least it will be good for something.

PS: After some thought, I decided that NeOS will only be 1.0, that is,
all the advanced commands will be in it, except EDUMP - they will be thrown out, considered to be
excess.

RP> but with such a server, you must admit, only one
RP> user can work, because multitasking on Speccy is impossible.

Did Bill Gates tell you that? ;)

We're talking about a new OS, right? So why not make it
multitasking? Why rely on something as crap as MS-DOS?

Briefly, how to do multitasking.

1) All programs must be relocatable. To do this, each
executable file must be accompanied by a relocation table,
according to which all absolute addresses in
the body of the program are corrected before it is launched. The table can be made in the form of a bit field (as
we did before on the RK-86) or a list of adjustable addresses -
the specific implementation does not matter. You can even do both
options and choose the smallest one for each case.

2) Tasks in memory are located one after another, like on a TR-DOS disk.
They can be loaded and unloaded. New tasks can “take” the place occupied by old ones. In this case, memory fragmentation
is inevitable, but it will all work.

3) Each task has three possible states: waiting,
ready for execution and execution. In the third state
there is only one task - the one that is currently being executed
at the moment. Eacha task is a variable area where the system
stores the values ​​of its registers, currently enabled
pages, etc. - the so-called task context.

4) The operating system has INT at its disposal. Based on this INT, it
will take control away from the task that is in
the execution state and transfer it to the task that is in the
state of waiting for execution. When transferring control from task to task
, the context of the old one is preserved and the context of the new one is restored.

5) Tasks that wait for an event, for example, a user reaction - pressing a
button or moving the mouse, call the system and receive
control back only when an event arrives. Until this
moment, they are in a waiting state, do not participate in
context switching and do not consume machine time.

I'm ready to bet anyone $10,000 that multitasking on
Speccy is possible. I'll sit down and write it myself :)

RP> And yet, programmers sometimes have to return to the system
RP> (in the case of TR-DOS, this is BASIC). If there is no line command,
RP> then where will the assembler return? In the teamp?

First, you need to abandon the very concept of “returning.”
The commander needs to be made one of the tasks. And you won’t have to go back anywhere - it will be enough to switch to it. And thenобратно.

DS> Did Bill Gates tell you this? ;)
No, I said so myself ;-)

DS> We're talking about a new OS, aren't we? So why not make it
DS> multitasking? Why focus on such crap as MS-DOS?
Wait.

I’ll comment now ;-)

DS> 1) All programs must be relocatable. To do this, each
DS> executable file must be accompanied by a relocation table, according to
DS> all absolute addresses in the
DS> program body are corrected before it is launched. The table can be made in the form of a bit field (as
DS> we did earlier on the RK-86) or a list of adjustable addresses -
DS> the specific implementation does not matter. You can even do both
DS> options and choose the smallest one for each case.
Would you hesitate to create such a table
for a program with a capacity of about 30 kilobytes? This requires a special program, manually this is something from the category of perversions.
Then the question is: how do you place 4 programs of 20 kilos each in one main memory (25000-49152)? And you can't throw them on the pages
they actively use the pages themselves.

DS> I'm ready to bet anyone $10,000 that multitasking on the
DS> Speccy is possible. I'll sit down and write it myself :)
Possible, but have you thought about the speed of work? After all, if you dofull-fledged multitasking, then there still must be such concepts as working in the background, otherwise how will several programs share one screen? And if you make a full-fledged
multi-window, then this will slow down the work VERY, since you will have to constantly
update the windows.

If I underexplained something, did not explain to you that your idea is somewhat half-baked, then write, I will explain it to you ;-) Everything will work too slowly.
Do you want Windows on the Spectrum? At 3.5 MHz it is better not to engage in such perversions. I suggest this option:
Pseudo-multitasking. There may be several programs in memory, but only one can be active. You can freely switch between programs. In general, the idea is similar to MagOS. This idea, with proper
implementation, is devoid of all the shortcomings of your idea - and programs in one
shared memory will coexist (when switching, the old program is thrown
onto pages that are immediately locked so that another program does not touch them),
and you won’t have to create awesome tables it is necessary.

In short, since such a binge has begun, I’m immediately making an announcement:
After the release of BIOS v1.0, work will begin on BIOS v2.0 with support
pseudo-multitasking. It will immediately come with a window shell
Studios that supports multitasking.

DS> First, you need to abandon the very concept of “returning.”
DS> The commander needs to be made one of the tasks. And returnno need to go anywhere
DS> will be there - just switch to it. And then back.
As long as there is no multitasking, there will be a return.

RP> Give me an example when 63 characters are not enough for you? When transferring
RP> parameters to the program? The only case, but for example, even on my PC

copy A:\12345678\23456781\34567812\45678123\56781234\filename.ext [aaa]

[aaa] - this is like the first parameter.

Convincing?

I think like on a PC with 128 They are tormented by symbols by making
8-letter directories...

256 and period. And the parameters are not only through com. line,
and also come up with something! A certain area
of memory allocated by the system to one program just for
such purposes. Read, for example, smart books about MS-DOS.

[...]

RP> System expansion? What did you mean by that? Possibility of software
RP> extension of the command system? There is an opportunity by intercepting
error
RP> Unknown command.

Anything. Only we were not as if in despair.

W!7h Be$7 W!$he$, FK0.

[.....]
This is not at all difficult, although somewhat hectic.

DS> 2) Tasks in memory are located one after another, like on a TR-DOS disk.
DS> They can be loaded and unloaded. New tasks can “take” the
DS> place occupied by old ones. Memory fragmentation in this case
DS> is inevitable, but it will all work.
Point number one - there is too little memory on the Spectrum to waste it on
storing inactive tasks. Moreover, for full-fledged work, each task would need to allocate 128Kb of space. A typical example is MagOs for Scorpio.
If you have worked with it, you will see for yourself what “cool” tasks you can load
from under it. The only way out is swap. But, even with a screw, this is a very
long process.

[.....]

DS> 4) The OS has INT at its disposal. Based on this INT, it
DS> will take control away from the task that is in the
DS> execution state and transfer it to the task that is in the
DS> state of waiting to be executed.
That is. is the time quantum equal to 1/50 of a second? Can you imagine how everything will
work? At what speeds?

DS> 5) Tasks that wait for an event, for example, a user reaction - a pressed
DS> button or mouse movement, call the system and receive
DS> control back only upon receiptevents.
So they “call the system” or “get control when an event occurs”?
These are two different things... Moreover, this requires an event mechanism that is not inferior to Windows'95.

RP> Would you hesitate to compile such a table for a program with a capacity of about 30 kilobytes? This requires a special program,

This should be done by an assembler. In the meantime, there is no special assembler,
it’s also easy to do - you need to assemble to two different addresses, and
the simplest program will create a table based on the differences between the files.

RP> Next, the question is: how can you place 4 programs of 20 kilograms each in one main memory
RP> (25000-49152)?

Overlay structure. The main module is in the main memory, a number of
working procedures are located on pages.

RP> Possible, but have you thought about the speed of work? After all, if you do
RP> a full-fledged multitasking, then there must still be such concepts
RP> as working in the background, otherwise how can several programs share one screen?

You can do something clever with the screen: make it a shared
resource. More precisely, this resource will be all input/output devices - screen, keyboard, mouse. The essence of the idea is that the current “owner” of the I/O must capture this I/O, that is, inform the system that the user is currently working with it. Other tasks can:

1) check whether this resource is busy,
2) seize it if it is not busy,
3) release it when the work is completed.

As a result, it will be possible to switch between _managing_
tasks. Tasks that are almost impossiblerequire an interface (for example, a
music player in which you once selected a couple of Mouzons and
listen to them) will constantly play in the background without disturbing others.

RP> Pseudo-multitasking. There may be several
RP> programs in memory, but only one can be active. You can freely switch between
RP> programs. In general, the idea is similar to MagOS. This
RP> idea, if properly implemented, is devoid of all the shortcomings of your idea

For starters, it will do. But this will not allow you to do things like
for example, a resident music player, as tasks at the system level.

p.s. By the way, even the idea of ​​a pseudo-multi-task can immediately make
memory expansions >1mb...

DS>> it will take control from the task that is in the
DS>> execution state and transfer it to the task that is in the
DS>> state of waiting to be executed.
EM> That is. is the time quantum equal to 1/50 of a second?

Absolutely right.

EM> Can you imagine how everything will work? At what speeds?

Everything will work normally. Apparently, you just don’t quite
imagine what multitasking is.

There are currently 55 tasks in the memory of the machine on which I am writing this letter to you. The text editor in which I type the letter. Mail reader. "Commander". A mailer downloading mail... And a large number of
service tasks - the same watch, for example. Tasks servicing
working with the disk, files, responding to input-output, and the like.
And this whole zoo is currently waiting for some events.
The input servicing process - when will I press a button or move the mouse
. Text editor - when a notification about this arrives from the mentioned process. Mail reader - when the editor has finished
editing the letter, put the letter into the database and let
edit its header. Mailer - when the next byte arrives from the modem. Clock - when the next second
interval expires. Tasks that maintain disks - when someone
finally needs these disks. INAs a result, the processor is actually idle 99% of the time
waiting for the next interrupt.
Sometimes a task appears that “eats up” all the remaining time
- for example, when a mail reader unpacks zips and imports *.pkt.
But there are very few such moments when two such tasks are launched simultaneously
. As a result, almost all the power of the CPU will be available to the task.
Even if two such tasks suddenly appear, they will simply divide
the processor equally. It is possible that three, four, and the like will appear - this will be honestly worked out. But the normal state of the system
is the processor “sleeping” 99% of the time.

EM>> Windows'95.
DS> Are there even events there? I wouldn’t have thought...
Yes.

DS> Apparently, the authors of Concurrent CP/M (not to be confused with Concurrent
DS> BIOS on Pro) were unlucky - they didn’t know you and foolishly
DS> made a multitasking... ;)
And where does this cunning CP/M work? Is it possible to run it on Specky class cars?

Okay, let's move on. Multitasking is, of course, good, but without a pipe
(that is, a turbo), you still won’t get far. Everything will slow down. Let's take the same Amiga (you're sitting on it, right?): did it ever have a 3.5MHz processor? And she always had a cool 32-bit processor. That's it,
it was originally a powerful machine. Now let's take the same PC:
normal multitasking requires at least 386 percent, since it
has such a useful feature as protected mode. And yet, multitasking successfully slows down the execution of any task. Do you want multitasking
on the Spectrum? It has only 3.5MHz and 8-bit percent. Well, what can you get out of it? The Spectrum's features do not yet allow for truly powerful multitasking. Until turbines around 14 MHz become widespread, you can completely forget about it. Yes, also about the overlay
structure. So you say: the body is in main memory. Well, if this body
is very large, then how much are youCan you post the program? That's right, 1-2,
although there is still a lot of page memory. Also: procedures on pages, data
also on pages. Can you imagine the speed of work when a page
procedure will use page data? It can’t do without some resident in the main memory, and it’s easier to throw it into the main memory, as a result of which the body of the program again grows and again we won’t be able to load anything worthwhile. Better is pseudo-multitasking, when
programs can be crammed into really full memory. Do you need any more arguments? I can give you more.

RP> Of course, yes, the entire multitask is built on interruptions, but
RP> only on good machines these interruptions can come with different
RP> frequencies.

Ideally, you need to have a timer with scheduling the arrival time
of the next interrupt. But it is what it is. You can, of course
make it later and support it in the OS, but the game of allotment(s)
IMHO is not worth it.

RP> It turns out like this: for each program there is 1 interrupt, and I launched
RP> 10 tasks. Well, and at what speed will the player sing when called once
RP> in 10 interruptions? In any case, such a thing should be done as a
RP> resident driver, which you can install anyway.

Well, why think in terms of such squalor as MS-DOS??

There is such a thing as priorities. When the system has a number of
tasks ready to be executed, it places these tasks in a queue, sorting
it in order of decreasing priority. Thus, the first task in this
queue will always be the task with the highest priority.
The player needs to set the maximum priority. In this case
every interruption, it will receive control first, even despite 10
tasks ready to be executed, will work a little and then go into
hibernation again - and the remaining 90-95% of the INT time will be processed
the next task.

In general, II strongly recommend that you read something on the theory of operating systems. There it’s all “laid out on the shelves.”
On the PC-11/16 machine (I wrote about it not long ago in ZX.SPECTRUM), with
a processor power approximately corresponding to Z80/7MHz,
priority preemptive multitasking worked GREATLY. And
the player was playing in the background, and the mail was swinging, and was immediately read in parallel, and
the clock was ticking. The system core was hardwired into ROM and occupied only a couple of kilobytes. I don’t see ANY difficulties in implementing such a system on a regular Spectrum.

Once, 01 Sep 98, a certain Kirill Frolov
wrote to Evgeny Milun, on the topic: [NeOS]

[skip]

EM> from under her. The only way out is swap. But, even with
EM> the presence of a screw, this is a very
EM> long process.

KF> Nothing of the kind. HDD-RAM transfer speed is sometimes
KF> faster
KF> than RAM-RAM. Unless, of course, the propeller slows down.

Where have you seen this? Nonsense.

With that, Kirill, let me say goodbye.
KIR.

├┤i Evgeny & Denis !

[...]

EM> from under her. The only way out is swap. But, even with a screw, this is a very long process.

Nothing of the kind. HDD-RAM transfer speed is sometimes faster

Geum. :)

DS> There are currently 55 tasks in the memory of the machine on which I am writing this letter to you
DS>.
Tasks (applications), processes or threads? I now have only 5
applications, but... somewhere around 25-30 processes. I don’t even know how many threads there are.

DS> The text editor in which I type the letter. Mail reader. "Commander".
DS> Mailer downloading mail...
Yes, all these are applications.
DS> And a large number of office tasks - the same watch, for example.
But this is perhaps a task, or perhaps just a thread. And even more
more likely - this is a thread of the OS itself. (Although, there is an option that this application simply
takes the time value from system variables in a loop and displays it on
the screen).

DS> Tasks that handle working with the disk, files, reacting to input/output,
DS> and the like.
But these are already pipes. These are not tasks at all. These are drivers of various levels.
Moreover, system drivers that have nothing to do with applications...

DS> And this whole zoo is currently waiting for some events.
DS> The input service process - when will I press the button or move the mouse
DS>. Text editor - when the mentioned process
DS> receives a notification about this.
Then what is the role of the OS? If two processes calmly interact with each other, moreover, one ofthem (the process of servicing the input) also arbitrarily
performs the role of the operating system, managing the computer, then why
do we need an OS?
As you described, this is cooperative multitasking. So ? But, using
INT is already preemptive... Which one are we talking about? About the first one? Then it needs INT
maximum for processing the keyboard (but, after all, it turns out that this is
the responsibility of the “external” application), and switching between tasks will
be done by the dispatcher, called via the same RST8.

DS> Mail reader - when the editor finishes
DS> editing the letter, to put the letter in base and let
DS> edit its header.
This is already somewhat different...

DS> Mailer - when the next byte arrives from the modem.
But here you are not entirely right. The sequence is as follows - the mailer itself waits for the next byte to appear in the FIFO buffer. And it will appear there only if
a byte arriving from the modem causes an interruption, and therefore the corresponding
thread, which, mind you, does not wait for anything. Moreover, if at this moment you are browsing the menus in it, then it only waits for keystrokes, and it “gets to” analyzing
the state of the FIFO buffer only when you exit this menu.
But, again, “that’s a completely different story” (C).

DS> The clock - when the next second interval expires.
The clock is waitingarrival of interruption. More precisely, not even that; it would be more correct to say that they personally do not expect anything at all. When the next tick arrives, they
are, as it were, “born again,” and having worked, they die (rather than “fall asleep while waiting”).
But the procedure for displaying time on the screen actually waits for the
interval to expire.

DS> Tasks servicing disks - when these disks are finally needed for someone
DS> will be needed.
More precisely, the system, having recognized an event (and it does not necessarily wait) associated with accessing the disk, calls the appropriate driver.

DS> Sometimes a task appears that “eats up” all the remaining time
DS> - for example, when a mail reader unpacks zips and imports *.pkt.
DS> But such moments when two such ones are launched simultaneously tasks
DS> are very few. As a result, almost the entire power of the CPU will be available to the task.
But, in this case, is it worth it to fence this whole garden? For such cases
(when in fact only one task is active) the Spectrum has MagOS.

DS> Even if two such tasks suddenly appear, they will simply divide
DS> the processor equally. It is possible that three, four, and the like will appear - this will be honestly worked out. But the normal state of the
DS> system is that the processor is “sleeping” 99% of the time.
Okay, but then the role assigned to INT is not at all the same asyou described her
initially. Do you agree ?

├┤i Denis & Roman !

[...]

DS> This should be done by the assembler. In the meantime, there is no special assembler,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do not spread deliberately distorted information.
There is such an assembler in isdos.

There will be no multitasking. You saw the described neos - a typical isdos.
Strict connection to the architectural capabilities of the pentagon-128 and that's all.

W!7h Be$7 W!$he$, FK0.

DS> Well, why think in terms of such squalor as MS-DOS??
Point your finger where in the phrase you quoted above I said something from
the concept of MS-DOS? In MS-DOS there is no multitasking at all, and in our conversation
you can successfully forget about MS-DOS.

DS> There is such a thing as priorities. When the system has a number of
We know about priorities, but this is a very hectic task - implementing
priorities.
DS> The player needs to set the maximum priority. In this case,
DS> he will receive control first every interruption, even despite 10
DS> tasks ready to execute, will work a little and again go into
DS> hibernation - and the remaining 90-95% of the INT time will be processed by
DS> the next task.
Logical. But writing programs taking into account their further work in conditions of
multitasking... Constantly considering hibernation... Creepy...

DS> In general, I strongly recommend that you read something on
DS> the theory of operating systems. It’s all “laid out on the shelves” there.
Give me examples of books - I’ll look for them. Otherwise, I’m not spoiled by such literature -
I have to figure everything out myself, and ask other people.
DS> On the PK-11/16 typewriter (I wrote about it not long ago in ZX.SPECTRUM) with
DS> processor power approximately correspondingZ80/7MHz,
DS> Priority preemptive multitasking worked GREATLY. And
Great - how is that? In Windows'95, my tasks also work great, they don't crash, but they slow down. Not much, but they slow down ;-)
DS> the player was playing in the background, and the mail was shaking, and was immediately read in parallel,
DS> and
DS> the clock was ticking. The system core was hardwired into ROM and occupied only a couple
DS> kilobytes. I don’t see ANY difficulties in implementing such a system on a regular
DS> Spectrum.
Question: is memory addressing linear on this computer? If it's page-based, like
Spectrum, then yes - no difficulties, if it's linear or segmented
(something in the spirit of Intel's processors), then this is the main difficulty.

DS> It was 68,000 for seven. This is not much faster (quite comparable to)
DS> Z80/7MHz and is even much inferior to the offtopic Z84C15/21MHz.
And not everyone has a pipe on the Spectrum, for example I don’t ;-)
By the way, you want to say that the 32-bit percentage is not much ahead 8-bit
percentage at a similar frequency? Tell me - what is the fastest command
at 68000? In beats, please. And let’s compare it with 4 clock cycles on the Spectrum.

DS> I dare say that neither three and a half megahertz nor eight
DS> bits will in the least interfere with the implementation of multitasking. You can squeeze exactly the same thing out of it
DS>.
Yes, they won’t hurt, but the efficiencyThe system will suffer due to a rather complex task manager hanging on interruptions. In addition, programs
will have to be written specifically for multitasking, otherwise it will be like this -
every task has an interruption.

DS> Why should it be big? All that is needed in this body is
DS> initial initialization, a set of program variables, scattering
DS> code/data across pages and several subroutines called by overlays
DS> for inter-page data exchange and calling their subroutines.
This very inter-page exchange is the real brake. You still have to move some of the procedures into the main memory, otherwise they will work at the speed of a turtle. Well, for example, let's take this example: write a
procedure for searching a word in a text (even just a sequence of bytes)
working in main memory with text on pages and a procedure sitting
on a page and searching for text on other pages. Compare the speed. How many times will it work there? Probably at least 2-3.

DS> Obviously, these are not exactly overlays in the classical sense. This, in
DS> idea, looks more like a swap ;)
Wow. Swap in memory. As they said about it somewhere: memory, which pretends to be
a disk, which pretends to be memory ;-)

RP> Logical. But write programs taking into account their further work in
RP> multitasking conditions... Constantly consider going into
RP> hibernation...

How could it be otherwise?

In all, ABSOLUTELY all multitasking OS, this is done exactly
this way. There is no other way to do it. They haven't yet invented processors that can themselves put tasks into hibernation :)

RP> The horror...

The whole horror is that instead of working with ports to poll the keyboard and wait for interrupts using HALT, you will have to
call the system function for input from the keyboard and the system function for waiting
for the completion of a time interval. Just imagine what will happen if five
tasks (for example) wait for a button to be pressed, polling a port, and
the sixth task, for example, an archiver, will slow down 6 times only because the remaining 5/6 of the time the processor is spinning in an absolutely
meaningless loop...

RP> By the way, you want to say that the 32-bit percentage is not much ahead
RP> 8-bit percent at a similar frequency? Tell me - what is the fastest
RP> team at 68000? In beats, please. And compare with 4 clock cycles
RP> on the Spectrum.

Any register-to-register operation on 16-bit operands
68000 does at least 4 clock cycles, on 32-bit ones - in 6 clock cycles.
And on such a deadprocess, with linear memory, with a purely software
implementation of windows (not like on offtopic;) and at “some kind of” seven
megahertz - multitask works great. The multitasking hardware
doesn’t help at all - I already know this kitchen from the inside.

True, the 68060 does almost everything in half a cycle, but that’s
another story and 16 years later. The Z80 doesn’t stand still either.

RP> No. Straining your brain is not a problem. I just don’t want to make
RP> an ineffective system.

Make it effective. It's really not worth doing ineffective systems - it's not very pleasant, getting a cake on your face... ;)

RP> Just the peculiarity of the Spectrum is its low frequency and effective
RP> programs that work wonders at such a low frequency.

That's right. So create another miracle! :-)

Summarizing the denominator of everything that has already been said, I will repeat.
Everything I described on the Spectrum CAN be done. The experience of the PK-11/16 - a machine of the same class - showed this perfectly. The PK-11/16 was made by ordinary Soviet people like us. The only two factors that
can prevent this are laziness and incompetence.

Both are not a problem. The road will be mastered by the one who walks...

DS>> input-output, and the like.
EM> But these are pipes. These are not tasks at all. These are drivers
EM> of various levels.

Correct. But from the OS point of view, these are the same tasks.

For example, working with a disk can be implemented like this. The task
calls the OS with a request like “open file such and such.” The OS looks to
which disk this request refers to and determines the file
system driver associated with this disk. A driver for a specific file system
(of which there are usually several in memory - one for floppy disks and a screw, another for a CD-ROM
...) is also a task, albeit a very specific one. This task
receives a message from the OS like “they want to open a file here.” Messages
are queued by the OS kernel. The file system selects these messages from
the queue and processes them. It doesn't work with the disk itself - it transmits a message to the disk driver, which again is also a task. The disk driver selects from its queue messages
from file systems (of which there can also be several - different
file systems on different hard drive partitions, for example) and accesses
the disk.

Organizing drivers as tasks allows us to solve the problem
of trying to work with the disk simultaneously, without breaking
multitasking. Imagine if the drivers worked in the context of the
callertasks. In this case, one task would work with the disk
excellently, but if two tasks tried to write something to the disk
at the same time, it would immediately crash - in MS-DOS, for example, residents when working with the disk _MUST_ check the disk activity flag, and if
the "main task" is working with the disk at that moment, they
do not have the right to work with the disk.
It could be done differently - put the work with the disk into the kernel,
then the tasks would work with it strictly in turn. But this will cause
another problem - when the kernel is running, the tasks are resting. This
is equivalent to the fact that working with the disk is carried out as a task at absolutely
the highest priority, and no other task can interfere with this.

In relation to the Spectrum, this would mean that, for example, in
the process of reading a large array from the hard drive, you will not be able to work in
a text editor running in parallel. And if
organized file systems and device drivers as tasks, I could
without problems, giving the text editor a higher priority.

EM> system drivers that have nothing to do with applications...

Obviously. But from an OS point of view, there is no such thing as an "application". Applications exist only from the user's point of view.

The simplest analogy is that people are united in families, and tasks are in
applications ;) But from the supervisor's point of viewthere are only people and
tasks. In the first case, the supervisor is the cosmic mind, God or
Mother Nature - there are many points of view. And in the second - the OS kernel.

EM> Then what is the role of the OS? If two processes calmly
EM> interact with each other, and one of them (the input servicing process
EM> also arbitrarily acts as an operating
EM> system, managing the computer, then why do we need an OS?

You didn’t see the forest for the trees :-)

Operating System - this is not just a kernel or just some
piece of code. This is a conglomerate of a kernel and a huge number of
servicing tasks - input, output, drivers, etc. The input servicing process given as
an example does not “arbitrarily perform the role” of the OS,
it is part of this OS.

EM> As you described, this is cooperative multitasking. So?

No. Cooperative multitasking does not allow applications to run simultaneously without special tricks. Examples of pure
cooperative multitasking are MacOS 7/8x, Acorn RISC/OS, Psion EPOC.

The model I described is UNIX of all varieties, RSX, TSX,
AmigaOS, VMS and many lesser-known operating systems (I have listed
those with which I am familiar and have experience). The system core of the already mentioned machine PK-11/16 is also built according to thisмодели.

KF> very
EM>> long process.

KF> Nothing of the kind. HDD-RAM transfer speed is sometimes faster
KF> than RAM-RAM. Unless, of course, the propeller slows down.
What are you talking about? About the traffic police? There is no such thing on the Spectrum. And even if there is...
The access speed to RAM is mainly determined by the maximum switching frequency of the microcircuit (and even on braking microcircuits it is at least 15-18 megahertz). But the speed of access to the HDD - I don’t even want to think about what, here is the maximum frequency, and the positioning speed, and the speed
of rotation of the disk itself, etc.

DS> Perhaps this will happen with cooperative multitasking. But in the
DS> model I’m describing, everything is completely different - the mailer expects messages from the
DS> system. Messages in our specific case can be of two types -
DS> “new information has appeared in the buffer” and “the user clicked such and such a
DS> menu item.” The menu is a purely system feature, the task only describes the type of menu to the
DS> system and subsequently receives information about the user’s actions with it.
DS> The mailer, having received a message about new bytes in the buffer, begins to rake them out from
DS> - and it can rake out not only the first
DS> byte that appears, but the entire buffer at once. The buffer can be set quite
DS> large (8 kilobytes, for example) and it will have to be raked out very rarely.
But who fills this buffer? ;)

DS> And task interruptions also have nothing to do with them - they are
DS> serviced by the system, and from the point of view of the task there is simply such a
DS> device as a serial port. Port implementations can be completely different - returning to the Spectrum, it can be a
DS> personal internal modem on the bus, or a built-in Profi port, and even
DS> proprietary Interface-1.
But returning to the Spectrum - about the serial port (more precisely about the modem,
to ithooked up) with such a “trick” you can forget. Even with
internal buffering you won't be able to achieve higher speeds.

DS> In all, ABSOLUTELY all multitasking operating systems, this is done exactly
DS> this way. There is no other way to do it. They haven't yet invented processors
DS> that can themselves put tasks into hibernation :)
I believe.

DS> The whole horror is that instead of working with ports for
DS> polling the keyboard and waiting for interrupts using HALT, you will have to
DS> call the system function for input from the keyboard and the system function for waiting
DS> for the completion of a time interval. Just imagine what will happen if five
So is not waiting, there is no need to poll the port.
DS> tasks (for example) will wait for a button press, polling the port, and the
DS> sixth task, for example, an archiver, will slow down 6 times only
DS> only because the remaining 5/6 of the time the processor is spinning in an absolutely
DS> meaningless loop...
Think a little, what did he say: why should inactive programs scan the keyboard?
The keyboard is scanned only for the active program. Or do you want all 6 programs to react to the nearest pressed key? It will be fun ;-) Well, okay,
that's just me, I corrected the inaccuracy.

DS> Any operations of the register-register type on 16-bit operands
DS> 68000 performs in at least 4 clock cycles, on 32-bit ones - in 6 clock cycles.
You see - on 16-bit ones. And on the Spectrum - 8 cycles (two LDs in a row).
Total, not taking into account other commands, a difference of 2times. Do you feel it?
DS> And on such a dead process, with linear memory, with purely software
^^^^^^^^^^^^^^^^^^^ Key phrase.
Why - I already said.
DS> implementation of windows (not like on offtopic;) and on “some kind of” seven
And on the Spectrum perhaps not software?

DS> True, the 68060 does almost everything in half a clock cycle, but that's
DS> another story and 16 years later. The Z80 doesn’t stand still either.
Where does it not stand still? Until now, most people have non-turbo
cars.

At 00:20, Wednesday August 26, 1998 there was such a thing that
Denis Dmitriev dashed off a letter from Roman Petrov:

DD> Situation: the mail program calls the external protocol Zmodem
DD> to send 28 files, the names of which are transmitted in the command
DD> line... (under BCC you won’t see this, the mailer does everything without
DD> displaying it on the screen)
Well, I just said about this option. But I will probably
increase the line to 256 characters.

RP>> Think a little about what I said: why should inactive programs scan
RP>> the keyboard?
DS> I gave this as an example of running a program under a multitasking that was not
DS> written in a special way for this multitasking.
Most likely, programs not written for such a multitasking will not be able to work at all
, well, yes this is not important.

DS> But nevertheless, in real tasks the 68000/7MHz and the turbocharged
DS> Z80 work at quite comparable speeds. A specific example -
DS> digital multi-channel music.
Well, yes, I willingly believe ;-)

DS>>> software implementation of windows (not like on offtopic;)
RP>> And on the Spectrum, perhaps it’s not software?
DS> I’m talking about offtopic ;) There’s hardware.
And I’m talking about Spectrum ;-)

DS>>> Z80 doesn’t stand still either.
RP>> Where is it not standing still?
DS> Yes, on the same offtopic :)) Z80 (more precisely Z84C15) at 21MHz.
So this very offtopic hasn’t even really come out yet and it’s not at all a fact that it will be widely widespread. I would like to make a system for the masses.

DS> Not to mention the Z180, Z280, Z380. The latter is generally 32-bit with
DS> full software compatibility with the Z80. Frequencies of tens of megahertz.
So, it’s not Z80 anymore (although they are compatible). By the way, I am very surprised why no one has yet thought of buildingcar on the Z380. It would be such a miracle that I would write a multitasking without any argument - there is complete freedom there.
RP>> Until now, most people have non-turbocharged cars.
DS> Well, there will be a good reason to turbocharge;)
Yeah, exactly ;-) Let's start upgrading Spectrums and become like PCs. Although, of course,
yes - modernization is a necessary thing.

RP>> How to make an effective system on a machine that, in principle, is not
RP>> adapted to such tasks?
DS> Let's approach from the other side. Why do you think so? I agree
DS> that having only one window for pages in the basic version is not
DS> the most successful option for multitasking. Four ATM windows are better.
DS> But this does not mean that the system will be ineffective.
The system itself will be effective, but I just expressed it a little incorrectly.
There will be some reduction in efficiency for tasks written for such
multitasking.

DS> 1) code that intensively works with pages. Procedures for copying,
DS> searching, drawing on the screen, and the like. This also includes
DS> program variables. The resulting piece is placed in the main
DS> memory. When designing a program, you need to try to make this piece
DS> the smaller the better.
That’s right, the smaller the better, otherwise nothing will fit into memory :(

DS> 2) code,does not require intensive work with pages. Displaying on the screen
DS> information generated during the work process, all sorts of calculations, logic
^^^^^^^
But sometimes it’s useful to throw this into the main memory.

DS> Memory distribution can be done according to the model you have already proposed -
DS> bit map of kilobyte sections. The PC-11/16 also had a bit one
After thinking a little, I decided: 4 mega sooner or later may not be enough, I’ll have to
increase it. And at the moment (for now) NeOS is able to support up to 4 Mb.
The possibility of expanding the memory up to 1Gb (2 bytes per page) will be introduced.
If with a memory of 4Mb the memory card is already 512 bytes, then with large volumes...
In general, I don’t know now what is the best way to deal with the memory: either leave it map, or do it the way Pasha Fedin suggests to me, and he suggests it almost
like on the Amiga.
DS> Obviously, compiling programs with a block structure should
DS> be handled by an assembler. The assembler will still have to be made specifically
DS> for the new system - ordinary TR-DOS ones will not fit.
Naturally, here we get completely different things. Here, damn it,
even something like Dynamic Linking Library will have to be done ;-) A new style
of programming, which may not be liked by the cool coders, but for
programmers - everything is normal.

DS>Actually, this is what I was thinking about. If you are too lazy to make a System with
DS> with a capital letter, and the very thought of the required amount of work -
DS> frightens you, you can continue to assert that “this is impossible on the Spectrum.” I
DS> won't try to persuade you anymore. And if you’re not too lazy, I can offer assistance
DS> in its design and implementation. So decide...
I didn’t actually say that this is not possible on the Spectrum, I just said
that the Spectrum is not an ideal machine for such things. And the volume of work
doesn’t scare me at all - once you’ve got it, just work ;-)

DS> Page. And on the Amiga it’s linear. The same model works in both places, equally effectively.
Бppp, and how does the same model work there? By the way, on this PC
pages could be included anywhere?

PS: And all the same, in the first version of the BIOS there will be no multitasking - this is only
in the second. Therefore, for now, let’s finish talking about multitasking -
untimely. The first BIOS has not yet been released.

Writing the kernel is a quarter of the work, you also need to “introduce” people to this system
(and, for starters, write a couple of tools)... And before all
this, make sure that on the Spectrum you really just need
multitasking.

DS>>> Z380. The latter is generally 32-bit with full software
DS>>> compatibility with the Z80. Frequencies in the tens of megahertz.
RP>> Well, then it’s no longer Z80 (although they are compatible).
DS> Does it matter?
No, it doesn’t, you just said that the Z80 does not stand still, but Spectrum
on the new processors, alas, there are no.

RP>> If, with 4Mb of memory, the memory card is already 512 bytes, then for large
RP>> volumes...
DS> For larger volumes, the size of the card will not bother anyone... ;)
Taking into account the fact that this card can fit perfectly on pages.
It will also be necessary to take into account that the card can occupy more than 1 page.
If supported up to 1Gb, then the map can grow up to 8 pages!

DS> the size of the list of free sites (Pasha suggested this?) can easily
DS> exceed the size of the bitmap. In addition, it changes dynamically and
DS> can increase fragmentation.
This is exactly what Pasha proposed, but problems arose with such a feature.

DS> If you have nowhere to look, I’ll describe it with soap.
We have a mind-boggling number of Amigas in our city - 0 ;-)

DS> Disk names should be text strings, not letters.
DS> Otherwise, there will be a type of insanity - we connect the second screw, and the CD
DS> is now called differently.
Ku, I won’t have such insanity. I can have devicesdistribute
in any order. That is, if you set yourself a CD on F (for example), then
you will have it there until you remove it from there yourself. The idea with strings is, of course, good, but it's memory intensive. I will limit myself to 26 letters,
especially since even they will be organized better than PC.

DS> In the file descriptor, you need to allocate at least 20-30
DS> characters for the name. 11 characters is too few. At the bookmaker, where there was one of the
DS> FAT options, I always lacked the length of the name. The result was pearls
DS> like the toy "INVIBERABLE.MY" :-))))
The problem can only be solved with the invention of a new disk system.
One will appear and support for long names will be possible. I don’t know exactly
how yet, but there is a possibility.

DS> Add an acceleration factor to the system variables for the mouse.
We’ll see. In general, sensitivity is designed for this, but if it is necessary
it won’t take long to enter.

DS> In addition, I recommend working with logical names
DS> disks - for purely disk drive (without a hard drive) systems this
But this is an interesting idea, I’ll take note, thank you.

DS> You have an interesting point of view: There are no Spectrums on new processors anymore
DS>, and everything that is on new processors is no longer Spectrum. ;)
Well, I misspoke ;-)

DS> Is there an offtopic? Eat. Do you have GMX? Almost there...
Br, is GMX doing something special? I just don’t know, maybe you can tell
about GMX?

DS> If memory reservation is done by system calls, then in the
DS> current version there is no point in doing this. In the future, it will be possible
DS> to simply release a new version of the system, and compatibility will still
DS> remain.
That's right, I'll do that.

DS> That is, with two bytes per page? I recommend making more
DS> right away. In a year or two, memory may become incredibly cheaper, and a gigabyte
DS> will cost 5-10 bucks ;)
DS> Just don’t ask me “why is there so much
DS> memory on the Spectrum.” :-)
And I’ll ask: “Well, why the hell does the Spectrum need GIGABYTES of RAM?” This is not even possible, excuse me,
on the PC, I get by with 32 meters and don’t complain ;-)

DS> Then it’s better to do it like on the PC-11/16 (more precisely, in OS RT-11)
[ Someone was hungry... ]
Ugums, of course, we’ll see.

DS> The problem cannot be solved subsequently. It needs to be solved
DS> immediately and on the spot. Otherwise, you won’t be able to change it later. You won't
DS> introduce a new file descriptor format whenAre programs already using the old one?
The new descriptor format will differ only in that after the standard
36 bytes additional name bytes are possible. By the way, can you tell me how to implement this more conveniently? It seems that everything is not bad and is crammed into 8 characters,
but then the full name is taken from another place. So wouldn't it be easier to leave
the old 8 characters and introduce a function to get the full name? After all, on the PC
there are 8 characters left for the native DOS and everything lives perfectly and does not conflict.

DS> Why reinvent the wheel? Take FAT with Windows names as
DS> basis. The format of the sections is written. That's it.
I just don’t know this veil with the Windows names yet, that’s the whole problem and the
option of reinventing the wheel.

Not only is it possible, but it is also necessary, and has already been done... Although much still needs to be brought to a normal state.

Yes, by the way, since you are here, answer me this question:
[may the almighty M. forgive me] but how is it possible? ru.amiga
write via i-net?

evil Vitalik AKA Dark / X-Trade

RP> Bp, is GMX doing something special?

DS> In essence, this is very similar to the essence of the offtopic.
DS> The entire circuit
DS> of the machine is in the PLM. You can invent new circuits, features, and
DS> etc.

DS> No one is stopping you from inventing, for example, a particularly cool
DS> page
DS> memory, especially convenient for multitasking. ;)

Please, closer to the actually used Speck clones and away from the offtopic!!!
If you mention Amigas, PCs and other platforms in a conversation, then this should be
in relation to the real Spectrum. The OS project for _Spectrum_ is being discussed here!

All the best.
Roman.