Once again about drivers in the BIOS

Hey, I figured out a little how to free up memory after drivers. The result is a kind of modified second method (see my original letter about drivers).
In general, now drivers, in addition to Intel and non-Int, are also divided into the following
groups: installed by NeOS and installed by the user. The user
can call any procedure a driver, therefore, when deleting
a custom driver, the memory cannot be cleared in any way,
but when deleting the NeOS driver, the memory can be freed up according to the principle
of the second method. So, memory can still be freed! Thanks to my crazy brain ;-) Today I finally start writing NeOS driver functions! Maybe I’ll write something today.
If I complete this work in the next few days, then we can safely
say that the BIOS is half written, since the only serious
work that will remain is working with files, and the error manager is hardly a serious work at all, although there will be problems with it. The most
important of them: remember all the errors that may arise ;-)
Well, if laziness doesn’t overcome me specifically (for the last week
I’ve only been doing mental work - I haven’t written a single line of code): )
then by the end of summer you can expect a beta version. The beta version will be a completely finished BIOS, a littlestripped-down NeOS (some of the commands will be missing), a very stripped-down installer and a very modest set of drivers. Of the software, there will probably only be an adapted ZASM v3.00.
By the way, regarding ZASM, no one can tell me the fidosh addresses
of the authors (that they have them is for sure, I saw them myself, but I just
lost them), otherwise I wouldn’t want to get into their own creation without their knowledge.
Besides, it might be useful They'll share the information, you'll see we'll redo it faster.

PS: People, let's suggest something else, it looks like it'll work out better!
PPS: It's easy to do: the BIOS code currently occupies 10 sectors ;-) +
another 2 kilos of font (full-fledged for 256 characters)
2Denis_Dmitriev: I promised to send you a document, but I broke it
then I started typing it, but only yesterday I got around to it. I filled about half of it.
If you want, write, I’ll drop it in.

With respect, Roman aka Megus of Brainwave Association.

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

I greet you from the bottom of my heart, Roman!

Sat Jun 13, 1998, Roman Petrov squeezed the keyboard, hoping that the following
words would reach All:

RP> drivers. Of the software, there will probably only be an adapted ZASM v3.00.
RP> By the way, regarding ZASM - no one can tell me the fidosh
RP> addresses of the authors (the fact that they have them is for sure, I saw it myself, but
RP> I just lost it), otherwise I wouldn’t want to go into their own creation without their knowledge
RP> climb. Besides, maybe they’ll share some useful information, you see, quickly
RP> we’ll redo it.

But it wasn’t like that... Kostya Afendikov retired... and Rubtsov doesn’t have Fido
:( So, if you need to ask anything, please let me know.
By the way, there are also intermediate versions of ZASM, between 3.0 and 3.10, which work
much better than 3.0
But you need to ask Rubtsov about them.

But I’ll give Afendikov’s address, after all: Konstantin Afendikov (2:465/69.39)

Hasta la vista.
Tim Kelly

Once, 13 Jun 98, a certain Roman Petrov,
wrote to All, on the topic: [Once again about drivers in the BIOS]

[a lot of useful things have been killed...]

RP> PPS: It’s easy to do: the BIOS code still takes 10
RP> sectors ;-) +
RP> 2 more kilos of font (full font for 256 characters)

What font will it be? 32/42/51/64 ?
IMHO, 51 rules...

[skip]

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

KC> What font will it be? 32/42/51/64 ?
KC> IMHO, 51 rules...
Whatever driver you install, that’s how it will be. The standard delivery set
plans to include 32,42,64. But if there are people who like 51 -
please, I will make a driver for 51 as well. There are no problems with compatibility,
everything has been taken care of (although not everything has been done yet - there is only one
small moment left).

RP> Whatever driver you install, that’s what it will be. The standard
RP> delivery kit
RP> is planned to include 32,42,64. But if there are people who
RP> like 51 -
RP> please, I’ll make a driver for 51 as well. There are no problems with
RP> compatibility,
RP> everything has been taken care of (although not everything has been done yet -
RP> there is only one left
RP> oh-so-small moment).

Here we go. wonderful, therefore, we just have to wait...

At 00:44, Tuesday June 16, 1998 there was such a thing that
Tim Kelly dashed off a letter from Roman Petrov:

TK> But that was not the case... Kostya Afendikov retired... and Rubtsov
Oh, it’s a shame - the most useful, IMHO, assembler. After Tasm, I immediately switched to it - well, I really liked the interface.
TK> no Fido :( So, if you need to ask anything, please let me know, I
TK> will pass it on. By the way, there are also intermediate versions of ZASM, between 3.0 and 3.10,
TK> that work much better than 3.0
TK> But you need to ask Rubtsov about them.
But you can’t ask in any way (otherwise how will I get it if he doesn’t have Fido?)? I would be very pleased to receive the updated version 3.0.
But somehow I didn’t really like working with the disk drive -
quiet horror, that’s all. is loaded somewhere, just shoot yourself. And they hung too many baubles, completely unnecessary for the assembler (like the Mouzon player, and especially Minesweeper (which, by the way, is not pro at all,
but only mows under it, it’s still rather weak ;-))

TK> And the address I'll give Afendikov, after all: Konstantin Afendikov
TK> (2:465/69.39)
Thanks!

Thu Jun 25 1998, Roman Petrov squeezed the keyboard, hoping that the following words would reach Tim Kelly:

TK>> By the way, there are also intermediate versions of ZASM, between 3.0 and
TK>> 3.10, which work much better than 3.0 But you need to ask about them
TK>> Rubtsov.

RP> But you can’t ask in any way (otherwise how will I get him if
RP> he doesn’t have Fido?)? I would be very pleased to receive the updated version
RP> 3.0.

I can ask, but I already know the answer in advance - no! :( Probably all
these betas will be published after the release of 3.10 (if it comes out at all).

RP> But somehow I didn’t really like 3.10. Working with the drive with it
RP> is a quiet horror, everything is loaded somewhere, just at least
RP> shoot.

...

TK> ...
Translate the reaction. And then I didn’t understand a little. Although, regarding the heap of overlays
I would tolerate the following exception: all the necessary overlays are loaded into the extended
(over 128k) memory and work from there (well, if they don’t work, then at least
are stored there), and it is advisable to unload the configured ZASM in one monoblock so that it loads faster. If this is done in ZASM 3.10, then I will probably even buy it (if by that time I don’t want to write ASM, under the BIOS).

2All: People, I don’t understand, did my letters with questions about the BIOS not reach you?
If not, I’ll repeat it, otherwise I’m already tired of waiting for answers :( And the questions are there were
quite important.

Sun Jun 28 1998, Roman Petrov squeezed the keyboard, hoping that the following words would reach Tim Kelly:

TK>> ...

RP> Translate the reaction. And then I didn’t understand a little. Although, regarding the heap of

Who cares...

RP> overlays, I would tolerate the following exception: all the necessary overlays
RP> are loaded into extended (over 128k) memory and work from there (well, if
RP> do not work, then at least they are stored there), and the configured ZASM is desirable
RP> unload in one candy bar so that it loads faster. If this is done in ZASM 3.10
RP>, then I will probably even buy it (if by that time
RP> I myself don’t want to write ASM, under the BIOS).

And that’s exactly what it is - the necessary overlays are stored on a virtual disk, in the
setup you remember the configuration and... forward!

RP> 2All: People, I don’t understand, did my letters with questions about
BIOS not reach you?
RP> If not, I’ll repeat it, otherwise I’m already tired of waiting for answers :( And the questions there
RP> were quite important.

they’re always saying something here.
maybe I missed the beginning of the conversation... but I I haven’t seen anywhere
an answer to the main question - why is it needed. As I understand it, it’s a BIOS
for a regular computer. So it requires modification of the computer itself,
you need to flash the ROM somewhere, etc. It will never be a standard.
If something is wrong, correct it.
I could understand the following: a compact set of subroutines
is being written to work with all sorts of hardware according to all sorts of standards. distributed
in the form of a source code with a proposal to glue it to all new programs.
this is a purely software way, there are fewer problems here.

All the best.

Dmitry aka -=LD=- / X-TRADE GROUP.

At 01:23, Wednesday July 01, 1998 there was such a thing that
Dmitry Lomov wrote a letter to Roman Petrov:

DL> perhaps I missed the beginning of the conversation... but I have not seen anywhere
DL> the answer to the main question - why it is needed. as I understand it, this is a BIOS
It is needed for standardization and to facilitate the work of system software developers. Game and demo makers can easily get by with TR-DOS,
they don't need anything more.
DL> to a regular computer. so this requires modification of the computer itself,
Yes, to the usual one, but which one did you want? To the unusual? ;-)
DL> you need to flash the ROM somewhere, etc. this will never be a standard.
DL> if something is wrong, correct it.
Sorry, if flashing the ROM is a modification of the computer... There is no need to get into the hardware
absolutely. To install the BIOS, you just need to change the ROM page on your computer where 128 BASIC is located. Nobody really needs it anyway.
I’m currently writing a BIOS under an emulator and it (BIOS) is now connected to me
instead of a ROM. So far there haven't been any problems with startup (although I haven't played with it very much yet). The BIOS will not be distributed in the form of standard firmware. There will be an installer in which the user himself
can configure the system as he wishes: configure colors, screen output driver, connect any other drivers (modems, printers, disk systems,keyboards, mice, etc.). All drivers are divided into
device classes. For each class there is a strict standard, in this way
the compatibility of fundamentally identical, but differently
implemented devices is ensured.
DL> I could understand the following: a compact set of subprograms
DL> is written to work with all kinds of hardware according to all sorts of standards and
DL> is distributed as a source code with a proposal to glue it to
DL> to all new programs. This is a purely software way, there are fewer problems here.
As for convenience, yes and no, but as for problems... I somewhat
disagree with you. New hardware may appear constantly, and such a set
will need to be constantly updated and distributed among software authors.
What do we have as a result? The growing volume of programs, since each
program has to be crammed with heap support, for example, modems. And if
there is a BIOS in which the functions of the modem driver are standardized, then
programmers will not have to worry about which modem
their program will work with. The main thing is that the user has a driver for his modem
and that’s it! Likewise with mice, and also with extended memory! Since
the memory manager is located in the BIOS and changes depending on the type of machine
(after all, for each specific computer its own individual
firmware is generated), and programs for the BIOS should be used as much as possible (if possible)
function, then there will be no memory problems, since the function is called in the same way, only on different machines
it is implemented differently. This is actually my point of view.
Yes, I uploaded the BIOS documentation, read it!

DL> in the form of a source code with a proposal to glue it to all
DL> new programs.

Were there few of these?
This will not help.
Programmers want some kind of freedom. They are hoping for a new OS.

DL> this is a purely software path, there are fewer problems.

IMHO, without _small_new_ hardware standards, the problem here cannot be solved.

But if you propose some other acceptable path (besides the one proposed by R.P. -
we will be interested! :).

All the best.
Regards Roman.