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 establishes the > end of the table) have been reused :-), but wouldn't it be possible to > manipulate the maximum number of slave blocks by manipulating the apparent > max RAM found when the table is first created?
Looking at the source this was in fact what I did (after the fast memory trick, I forgot). But well, it didn't boot anymore. And debugging this case is a pain in the... you know what I mean ;-) The code is not really easy to understand, but I might have another go. [some explanations] Thanks Nasta, this may help me understanding it. What bugs me a bit is that the whole thing is possibly a simple and short finger exercise for Tony whereas I have to invest hours and hours to find out what to do to make it work. > I guess that way on QPC with enough RAM in the PC, we could finally > see if programs can cope with 512M :-) (shich seems to be the > maximum...) 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 limit I've set. Marcel
