About drivers in BIOS

A question has arisen related to how the driver system will be organized in the BIOS. Since not all drivers can be written relocatable, it is therefore necessary when installing a driver to configure it to the memory area in which it will function. However, when uninstalling a driver, it would be advisable to free up the memory it occupied. Here
two options are possible:
1. When installing a driver into memory, the configuration table is saved,
therefore, when a driver is removed, the entire driver structure is rebuilt:
drivers located in lower addresses are moved upward, occupying
the freed up area and freeing up memory for programs.
2. The configuration table is not saved, so drivers cannot
be moved when uninstalled. Memory is freed only when the driver
located at the very bottom is removed.

The first option is more difficult to implement, takes up more memory (tables
need to be stored), but is more sophisticated and convenient. The second is much
simpler to implement, takes up less memory (both in ROM and RAM), but is less
universal.

PS By the way, 40 percent of the BIOS has already been written. Memory
Manager (for 128 machines), Screen Manager, half of System Manager have been written.
All the rest have so far been worked out only on paper.

C Respectfully, Roman aka Megus of BrainWave association.

[Team ZX-Spectrum] [Team AgataКpисти] [Team Metallica] [Team Iron Maiden]

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

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

RP> The first option is more difficult to implement, takes up more memory (tables
RP> need to be stored), but it is more sophisticated and convenient. The second is much
RP> simpler to implement, takes up less memory (both in ROM and RAM), but is less
RP> universal.

I don’t know which one is more convenient to do, but, IMHO, it should free up space!

Hasta la vista.
Tim Kelly

RP>> (tables must be stored), but it is more sophisticated and convenient. The second
RP>> is much simpler to implement, takes up less memory (both in ROM and
RP>> in RAM), but is less universal.
TK> I don’t know which one is more convenient to do, but, IMHO, it should free up space
TK>!
So the first one: more complex, but better ;-)

TK> must liberate!

RP> So the first one: more complex, but better ;-)

But I wouldn’t want it to be slower. And then memory?.. - On Spec
this is very relevant!

All the best.
With respect, Roman Milukov.

RM> But I wouldn’t want it to be slower. And then memory?.. -
RM> This is very important on Spec!
But nothing can be done - it will be slower, to what extent I can’t say yet.
But several times that’s for sure. Look: when you remove a driver using the second
method, no operations occur with the memory area occupied by the drivers... DAMN! I'M THE BRAKE! SCARY! Looks like I'm starting to get confused...
I completely forgot that the driver can be located in any
memory area it wants. And how interesting was I going to shift the driver base? Everything is clear, neither the first nor the second method is suitable.
To remove a driver, you only need to remove it from the driver table,
then compacting this table.
By the way, people, access to drivers will most likely go directly
through the driver address. Although if you want to lose one more register in which you could set parameters for a function, then you can do it through a restart.
But this is very unprofitable: out of the entire relatively small set of registers in the Z80, two are lost: one for the driver number, the second for the function number of this drivers. I understand that the option of accessing memory directly is a little less convenient, but it has wider capabilities and a complete absence of problems with deleting drivers (the table is compacted there and the driver numbers change). And so that there are no problems withIf
for example, you want to access a remote driver and the driver
is still present in memory, then you can add a flag byte in the body
of the driver itself, which will need to be changed when removing/installing
the driver.

With respect, Roman aka Megus of Brainwave Association.

Once on 05 Jun 98 Roman Petrov sent a
letter to All:

[ skip about the driver ]

RP> 1. When installing a driver into memory, the configuration table
RP> is saved,
RP> so when you remove the driver the entire
RP> driver structure is being rebuilt:
RP> drivers located in lower addresses are moved
RP> upward, occupying
RP> the freed-up area and freeing up memory for the program.

This is exactly what is needed, with the release. After all, drivers
are not deleted so often, or rather, drivers can be deleted
only at the moment of deleting a “task” from memory that used its
own subjects. Therefore, there are no problems with the time spent on this process (plus two seconds per hour for the system to work ;).
By the way, will the drivers be in the main memory? 8[ ]
or will they still run away across the pages? :)

With the best, Denis.

At 22:10, Thursday June 11 1998 there was such a thing that
Denis Dmitriev wrote a letter to Roman Petrov:

DD> This is exactly the option that is needed, with release. After all, the drivers
Well, as I wrote a little earlier, the option with full release
is no longer available :( Unfortunately :(
DD> By the way, will the drivers sit in the main memory? 8[ ] or
DD> will they still run across pages? :)
Well, it’s also possible by pages, although I I assumed in the main one. And if you push through the pages, then you will have to create extra system variables, which I really don’t want - so the lower limit for the start of a user program has crawled to #6000 :( However, theoretically (and practically) you can free up 512 bytes - by throwing out the driver table ;-) And the drivers will be loaded into the main memory only by the NeOS command interpreter itself, but in programs you can install the driver not through NeOS, but through the BIOS, then there are no problems - you can only use NeOS wherever you place it. to configure the driver for the address, and not for
loading.