Re: Virtual Memory

[hohmuth@inf.tu-dresden.de (Michael Hohmuth)]

Hi Eddy!

Eddy Morfan wrote:

> I'm currently including virtual memory features in a MiNT kernel (1.12.h3).

Wonderful!

(Is there any serious reason why you don't use the latest kernel,
1.12.5?)

> 1) As the "mint.cnf" file is loaded after memory and file systems
>    configuration, how can I configure the virtual memory ?

Can't most of the configuration wait until mint.cnf is read?  For
instance, it wouldn't hurt much if paging was disabled until the name
of the paging device has been read from mint.cnf, would it?

Other possibilities include:

- use MiNT's command line switches and configure thru argv[]

- use your own configuration file (use normal TOS/GEMDOS functions to
  access it);

- hardwire configurations into the kernel and use some binary patch
  program which manipulates kernel variables by looking them up in the
  binary's symbol table (`genmagic.pl' could certainly be hacked to do
  this using `nm', or NetBSD's `binpatch' could be ported).

- scan the disks' partition tables yourself for finding the paging
  device

> 2) The handling of the TT RAM by applications and the TOS isn't
>    correct : The VDI uses TT RAM for bit blocks so that when you
>    really have TT RAM the Blitter gets confused as it's address bus
>    is 24 bits wide !  This didn't matter until yet because the only
>    machines with TT RAM didn't have any Blitter. But using a Falcon
>    with TT RAM will result in making the Blitter chip
>    reading/writing in a wrong memory place if the given address is
>    in TT RAM ( it will use only the 24 least significants bits !).
>    This could be solved by using only ST RAM for bitblocks but it
>    would be a bit complex to force both the ROM-OS and the
>    Multitasking AES using ST-RAM.  It would be also necessary to
>    make applications which have icons/bitmaps in their data segment
>    load in ST-RAM (so no virtual memory for them !). AES ressources
>    should also be loaded in ST-RAM. It's obvious that using this
>    method will result in having many situations where the virtual
>    memory could not be used. So the solution could be to use the
>    Blitter only when the data are in ST-RAM, but we are not the
>    VDI. 

Can the Falcon's TOS be told not to use the blitter at all (as it is
possible in the Mega ST)?

Has anybody ever seen a free VDI driver (with sources)?

>    I also discovered a bug in AES 4.1 Desktop : it always loads
>    an application in TT-RAM even if its header indicates that it
>    must be loaded in ST-RAM.  [...]

I don't understand that...  I think it's MiNT which loads apps into
memory, so if the app is loaded into the wrong type of memory it's
MiNT's fault.

(Perhaps you've just forgotten to reset the "malloc from TT-RAM"
flag?)

Michael
-- 
Email: hohmuth@inf.tu-dresden.de
WWW:   http://www.inf.tu-dresden.de/~mh1/