Re: graphic patch???

[rubywand@aol.com (RUBYWAND)]

In article <4gm1pa$in3@news.ysu.edu>, be404@yfn.ysu.edu (Adalbert Goertz)
writes:

>
>I have a complaint about all the graphic programs that I have
>used, i.e.
>GIF3200, jpeGS, Convert3200, ImageQuant:
> 
>They dont recognize and dont use the RamFactor memory like
>AppleWorks does (which makes the full aux.mem available to
>the desktop).
>Since these programs use up about 700+k of memory which is lost
>for processing pictures, it would be nice, if these programs
>would load to RamFactor rather than to aux.memory.
>The extra 700+k free memory could be used to process larger
>image files.
>Are there any patches available which would utilize the RamFactor
>memory?
>Am I missing something here?

    To run in some large Slot card RAM array a program has to know about
and work around too many bank-switching, memory access, and other
restrictions. This excludes all major programs designed for 'regular' RAM.


    On the other hand, a C200 option to use big blocks of Slot card RAM
for storing and manipulating graphics data is certainly doable. However,
someone would have to develop (and debug) the necessary routines; and, the
new program would be larger. I do not know of any patches to achieve such
a modiffication.

    So long as 4MB of system RAM is enough, most developers are not going
to be very concerned about complaints from a few Slot card RAM users.
Their advice will remain "Get 4MB of 'real' RAM"!

    Meanwhile, we are rapidly approaching a time when even 8MB will be
inadequate. The 'big mod' may be an FPI extension + Mem Slot expander
and/or a super Slot card RAM. Whatever, _something_ will have to give.





     

 the rules' for switching banks, etc. of the particular card. Also, a
program running in a Slot's expansion memory cannot access many important
addresses without turning OFF that Slot's expansion memory.



Rubywand