Re2 : Virtual Memory

[morfan@calvin.info.unicaen.fr (Eddy Morfan)]

Hi,

Michael wrote :
> (Is there any serious reason why you don't use the latest kernel,
> 1.12.5?)
> 
No, the 1.12.h3 kernel is just the last kernel version I've downloaded.
I think there's no reason why it could'nt be included in a newer version.

> 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?

It wouldn't matter if I  didn't check the paging device, but in order to install
the MMU tree I must at least know the size of the virtual memory space.
(Otherwise I would have to fix a maximum swap space which could either be too
small, or too large (each mega of virtual memory means two kilobytes of MMU tree
plus one kilobyte of MMU tree per application).

> 
> Other possibilities include:
> 
> - use MiNT's command line switches and configure thru argv[]

I don't like it as a run my kernel from the auto folder.
 
> - 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
>

Intersting suggestions, maybe could I read the mint.cnf twice, once for my
memory configs, and after the mint memory and filesys inits for the other
configs.

About the Blitter :
It has always been reported to be impossible to invalidate it physically
(I mean using the xbios function) on an Atari Falcon 030 and the MegaSTe
and STe tools don't succeed in stopping it.
I think that NVDI don't invalidate the Blitter, as it's aimed to be a VDI
replacement, it replaces most of the VDI functions (at least the bit blitting)
and so it is able to use no Blitter routine if it wants, but Outside can do it.

> >    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.

I know that it's MiNT's job to load apps, but I just described what I saw :
( TT-RAM run and allocate prog flags ignored under the desktop). I'll check
this once again, but if I didn't make any mistake, the only explanation may be
found by looking the way the AES/Desktop launches an app.

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

I'm sure I didn't, as I had to make the AES/Desktop allocate from ST-RAM to
avoid the Blitter problem, but I discovered that the AES uses the Mxalloc
call, not the Malloc, so it ignores the prog flag. (I had to patch my AES
to make it work !)

+---------------------------------------------------------------------+
| Eddy MORFAN      ( Email : morfan@info.unicaen.fr )                 |
+---------------------------------------------------------------------+
| Atari STf    2.5Mo                                                  |
| Atari Falcon 030/4Mo/340Mo                                          |
+---------------------------------------------------------------------+