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 the memory available for slaving is from sys_fsbb to the basic area sys_sbab. As I can't move sys_sbab down the next idea was of course to move sys_fsbb up. However, the translation slave-block-table-entry-address to slave-block-address is fixed: sbt = sbt_base + (sb - base_of_sys_var) / 64. Perhaps it would work by creating a big enough slaving table for the whole memory and adjusting the borders to only work within a slim limit (right below the basic area). But IMO this is quite dirty and I won't try it. Especially as it can cause problems when all of the chosen area is filled by the transient program area, resulting in a loss of the complete slaving system. All in all the concept of slaving was great for 128kb QLs with microdrives, but on todays systems a dedicated caching area would be much more favorable. And I'm not sure whether I can do anything about it, probably not. Marcel
