ZN wrote:
I know that with the way the table works, limiting it's size also limits
the position of the block of RAM that can be used as slave blocks.
I have again tried to limit the slave block table size and again it
just resulted in a crash: the slave block routines rely on the fact
that
Phoebus R. Dokos wrote:
The beta one...
Ah well, that explains it. The issue with beta versions is that
they're not finished ;-)
Marcel
On 13 Jan 2002, at 21:12, Richard Zidlicky wrote:
you see, its not only me who is asking for this feature. I am convinced
once it is reasonably possible to write drivers in SBasic and 'c' we will
have an abundance.
Sbasic? you've GOT to be joking. Shock, horror!
Wolfgang
-
ZN wrote:
if I recall correctly, the size of the slave block table and therefore the
number of slave blocks is established at SMSQDOS init time after the amount
of free RAM is determined. Unfortunately, the neurons that held
information on how the actual SBT search is performed (what
P Witte wrote:
There should be a SCSI driver in there somewhere too. Is that transferable
to other SMSQ/Es?
Probably, the hardware dependant part seems to be somewhat separated.
Marcel
At 08:12 ìì 14/1/2002 +0100, you wrote:
ZN w
The QPC kernel is currently limited to (IIRC) 256MB. This is due to
the fact that some applications use the upper address bits for data
purposes, therefore 4 bits are masked out.
In fact current versions don't allow more than 128MB, but this is just
Phoebus R. Dokos wrote:
The QPC kernel is currently limited to (IIRC) 256MB. This is due to
the fact that some applications use the upper address bits for data
purposes, therefore 4 bits are masked out.
In fact current versions don't allow more than 128MB, but this is just
an artificial config
At 08:20 ìì 14/1/2002 +0100, you wrote:
Phoebus R. Dokos wrote:
The QPC kernel is currently limited to (IIRC) 256MB. This is due to
the fact that some applications use the upper address bits for data
purposes, therefore 4 bits are masked out.
In fact current versions don't allow more than
Phoebus R. Dokos wrote:
So although it accepts the parameter it doesn't really do anything... h
I beg your pardon?
Probably you missed my earlier message... I had entered a value of 384 in
qpc's configuration screen... I assumed it saw the whole thing (then again
I never bothered to
At 08:34 ìì 14/1/2002 +0100, you wrote:
Phoebus R. Dokos wrote:
So although it accepts the parameter it doesn't really do
anything... h
I beg your pardon?
Probably you missed my earlier message... I had entered a value of 384 in
qpc's configuration screen... I assumed it saw the
On 1/13/02 at 2:26 PM Marcel Kilgus wrote:
Thierry Godefroy wrote:
Another way to use them wisely, is to limit the amount of total caching
memory they can use (thus also limiting the amount of time needed to
search among all existing slave blocks for your data...). IIRC Marcel
uses this
With memory sizes what they are today, we could also just dedicate an
amount of memory for slaving only, no need for any overlaps. Overlaps would
only happen if the actual RAM was smaller or equal to the maximum slave
block limit chosen. This would make it much simpler to try out stuff in
On Sun, Jan 13, 2002 at 02:10:22PM +0100, Thierry Godefroy wrote:
Also you wouldn't have to remove or disable the IOSSS module (possible
according to TT) and at the same time effectively kill the slave blocking
mechanism... no block devices no slave blocks ;-) hehe
Slave blocks are NOT
On Sun, Jan 13, 2002 at 02:57:31PM -0500, Phoebus R. Dokos wrote:
With memory sizes what they are today, we could also just dedicate an
amount of memory for slaving only, no need for any overlaps. Overlaps would
only happen if the actual RAM was smaller or equal to the maximum slave
block
Marcel Kilgus writes:
I tried (by exploiting the Atari kernel whose fast memory support
already prohibits slave blocks in fast memory), but couldn't get it to
work. Not much joy in debugging there, so I trashed it.
There should be a SCSI driver in there somewhere too. Is that transferable
to
15 matches
Mail list logo
