Phoebus R. Dokos wrote:
> The beta one...
Ah well, that explains it. The issue with beta versions is that
they're not finished ;-)
Marcel
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 t
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 i
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 bothere
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
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
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 ju
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
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 est
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
---
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 transferabl
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 slav
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
>
>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 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
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 trick to speed things up under QPC.
I tried
On Fri, 11 Jan 2002 15:01:34 -0500, Phoebus R. Dokos wrote:
> At 06:45 ðì 11/1/2002 +0100, you wrote:
>
> >On Fri, 11 Jan 2002 00:04:59 +0100, Richard Zidlicky wrote:
> >
> > > On Thu, Jan 10, 2002 at 10:00:33PM +0100, Thierry Godefroy wrote:
Err... please quote at least a little bit so that I
17 matches
Mail list logo
