[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Latest Re-sync



It's clear that the latest set of patches was needed to get everyone
in the same place, and it seems to use less memory than my last version
of MiNT (slightly patched 1.09).  It is more stable on the console and
no longer crashes all the programs that used to crash on the console, such
as vi and me and bash and ... well pretty much everything - my system
was pretty weird using the console.  Anyway, there are still some bugs.
Someone has said that the new MiNT doesn't work well with MultiTOS AES,
and I have found some weird problems with Xcontrol and such using ROM
AES.  Fasttext is still leaving little black squares on the screen, but
this could be a conflict with NVDI - I haven't tested anything without
NVDI, but since my NVDI font is not being displayed, I don't think
NVDI has anything to do with it.  I get more squares when the cursor
moves alot.
 
There is also a problem with BIOS FS.  My terminal reads AUX for about
... well .. it reads until the buffer is empty but then it no longer
reads any more characters.  I can still send characters, but none are
read.  This is definately a bug.  I am using MODM0DEV instead of MiNTs
built-in MODEM1 in order to fix the problem.  MODEM1 is broke, MODM0DEV
isn't (although it would be nice it MODM0DEV used addroottimeout 
instead of its daemon - it's daemon uses CPU time too - is it polling
at all?).
 
The last problem is TOSWIN.  Even if I run TOSWIN as a program instead
of an ACC, it still loses about 27K every time a window opens.  Can someone
else verify this for me?   Do a PS or TOP, MiNT should be using about 48K
or less.   Now run TOSWIN and run PS in a window.  Now MiNT is using 77K
or something.   Now open some other windows, a bunch, PID 0 now owns
about 200K.  Quit TOSWIN and run PS from the console .. MiNT is still
using over 200K.  The memory won't come back, and the more windows that
open, the more memory is simply dumped on the floor.  This may be a bug
in TOSWIN, but MiNT is at least partialy at fault here.  MiNT should
not allow memory to be lost - especially when it thinks it owns it!