freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

On Tue, 2 Dec 2025 at 01:32, Daroou via Freemint-discuss <
fre...@li...> wrote:

> I was expecting at least a slight gain with LIBCmini ELF, but it's the
> opposite: the target sizes increase by 5KB...

Don't forget that you are using a different compiler (often a new version =
bigger produced code, EmuTOS uses 4.6.4, too).

I see that your LIBCmini ELF is quite large:
>
> LIBCmini 4.6.4    96.832
>
> LIBCmini ELF     203.428
>
> Does this affect the program size?
>
You have seen it for yourself, it doesn't. My guess is that ELF format
produces more symbols. You can verify that by calling

m68k-atari-mint(elf)-strip -s libc.a

After that you can't link the library again but you will see its raw size.

I'll continue using GCC 4.6.4... However, GCC 13.2.0 ELF allowed me to fix
> many errors and warnings in my code.
>
One good practice, again from EmuTOS: compile your code with the latest ELF
compiler but release binaries with your 4.6.4 => you will get the best of
both worlds.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Le 01/12/2025 à 00:52, Miro Kropáček a écrit :
> On Mon, 1 Dec 2025 at 01:04, Daroou via Freemint-discuss 
> <fre...@li...> wrote:
>
>     [/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o:
>
>     file not recognized: file format not recognized
>     collect2: error: ld returned 1 exit status ]
>
> Hmm, not sure where this comes from. It looks like using old binutils 
> (which do not know about the ELF format?)

This error is normal because it's a copy of LIBCmini for GCC 'standard' 
(not ELF).


(I can't compile LIBCmini in ELF format; however, EmuTOS compiles 
perfectly in ELF format.)


> However I have built http://naprvyraz.sk/private/libcmini.tar.gz for 
> you, if you prefer this way. _stksize can be modified with 
> m68k-atari-mintelf-stack --fix=<amount>k command.

Ďakujem Miro :)


I didn't have to change anything; _stksize is set to 64KB.


However, I'm a little disappointed. Given the size reduction with the 
MINTlib targets (-30KB),

I was expecting at least a slight gain with LIBCmini ELF, but it's the 
opposite: the target

sizes increase by 5KB...


                m68k-atari-mint-gcc  m68k-atari-mintelf-gcc
MINTlib  68k         263.988                 235.923
MINTlib  206         244.519                 217.028

LIBCmini 68K          99.134                 104.022
LIBCmini 206          90.999                  95.847


RAM 1Mo              192.940 free            189.856 free


I see that your LIBCmini ELF is quite large:

LIBCmini 4.6.4    96.832

LIBCmini ELF     203.428

Does this affect the program size?


I'll continue using GCC 4.6.4... However, GCC 13.2.0 ELF allowed me to 
fix many errors and warnings in my code.


  Have a good day, Thank you for your help.

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

On Mon, 1 Dec 2025 at 01:04, Daroou via Freemint-discuss <
fre...@li...> wrote:

> [/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o:
>
> file not recognized: file format not recognized
> collect2: error: ld returned 1 exit status ]
>
Hmm, not sure where this comes from. It looks like using old binutils
(which do not know about the ELF format?)

Is it possible to find LIBCmini ELF format with
> _stksize==MINKEEP somewhere? ;-)
>
Not sure which OS are you using but if it's WSL2 or Linux, you can try:
https://github.com/mikrosk/m68k-atari-mint-build and
https://github.com/mikrosk/build-scripts. This will install you latest gcc,
binutils, mintlib, libcmini and a few other libs I'm using regularly.

However I have built http://naprvyraz.sk/private/libcmini.tar.gz for you,
if you prefer this way. _stksize can be modified with
m68k-atari-mintelf-stack --fix=<amount>k command.


> Soon, but not on daroou.fr; I no longer own that domain.

Great!

-- 
http://mikro.atari.org

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Hello Miro,


Le 30/11/2025 à 10:15, Miro Kropáček a écrit :
> I tried to reproduce your problem on my m68-atari-mintelf-gcc 13.4.0 
> and all worked fine (I even edited the Makefile as per your example). 
> Do you have mintlib installed? It's a bit counter intuitive but 
> libcmini requires mintlib for some of its parts. I suspect 
> that isblank might be one of such examples.

Ok, so the problem is on my side.


For info, I'm a novice; I don't understand much about Makefiles or other ;)

In the Makefile, I only change the options to Y or N.  I can only 
compile LIBCmini for GCC 4.6.4.


Currently, I can compile my programs with GCC 4.6.4 or with GCC ELF 
13.2.0 with MintLIB, and only with GCC 4.6.4 with LIBCmini.


Example for Boing -m68000:

GCC 4.6.4 MintLIB 263.803

GCC 4.6.4 LIBCmini 99.006

GCC ELF 13.2.0 MintLIB 235.767

GCC ELF 13.2.0 LIBCmini: need LIBCmini ELF format

[/cygdrive/e/cygwin64/opt/cross-mintelf/m68k-atari-mintelf/libcmini/lib/crt0.o: 
file not recognized: file format not recognized
collect2: error: ld returned 1 exit status ]


Is it possible to find LIBCmini ELF format with _stksize==MINKEEP 
somewhere? ;-)

(It's going to be too hard to figure out why it's not compiling, I think.)


[...]

> P.S. Hope to see http://atari.daroou.fr online again soon! :-)
>
Soon, but not on daroou.fr; I no longer own that domain.


P.S.: Sorry for the poor web translation ;)

Re: [Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Miro K. <mir...@gm...>]

Hi,

I tried to reproduce your problem on my m68-atari-mintelf-gcc 13.4.0 and
all worked fine (I even edited the Makefile as per your example). Do you
have mintlib installed? It's a bit counter intuitive but libcmini requires
mintlib for some of its parts. I suspect that isblank might be one of such
examples.

P.S. Hope to see http://atari.daroou.fr online again soon! :-)

On Sat, 29 Nov 2025 at 06:17, Daroou via Freemint-discuss <
fre...@li...> wrote:

> Bonjour,
>
>
> I'm currently testing Vincent Rivière's m68k-atari-mintelf cross-tools
> (under cygwin)
>
> 'Hello world' compiles perfectly with Mintlib.
>
> However, I want to use LIBCmini for my programs.
>
> https://github.com/freemint/libcmini
>
> GCC ELF refuses to compile LIBCmini because of this error:
>
> [Makefile]
>
> ONLY_68K=Y
> BUILD_CF=N
> BUILD_FAST=N
> BUILD_SOFT_FLOAT=Y
> BUILD_SHORT=Y
> COMPILE_ELF=Y
> STDIO_WITH_LONG_LONG=N
>
>
> $ m68k-atari-mintelf-gcc --version
>
> m68k-atari-mintelf-gcc (GCC MiNT ELF 20240130) 13.2.0
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> make clean
>
> make libs
>
> CC build/./objs/isblank.o
> sources/isblank.c: In function 'isblank':
> sources/isblank.c:4:6: error: infinite recursion detected
> [-Werror=infinite-recursion]
>      4 | int (isblank)(int c)
>        |      ^~~~~~~
> sources/isblank.c:6:16: note: recursive call
>      6 |         return isblank(c);
>        |                ^~~~~~~~~~
> cc1: all warnings being treated as errors
> make: *** [Makefile:162: build/./objs/isblank.o] Error 1
>
>
> [isblank.c]
>
> #include <ctype.h>
> #include "ctypeint.h"
>
> int (isblank)(int c)
> {
>      return isblank(c);
> }
> [/isblank.c]
>
>
>
>
> Compiles perfectly with standard GCC
>
> [Makefile]
>
> ONLY_68K=Y
> BUILD_CF=N
> BUILD_FAST=N
> BUILD_SOFT_FLOAT=Y
> BUILD_SHORT=Y
> COMPILE_ELF=N
> STDIO_WITH_LONG_LONG=N
>
>
> $ m68k-atari-mint-gcc --version
>
> m68k-atari-mint-gcc (GCC) 4.6.4 (MiNT 20200504)
> Copyright (C) 2011 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> make clean
>
> make libs
>
> [...]
>
> CC build/./objs/setstack.o
> AR build/./libcmini.a
> CC build/./objs/iio/doprnt.o
> AR build/./libiiomini.a
>
> make clean
>
> make all
>
> [...]
>
> CC build/./objs/setstack.o
> AR build/./libcmini.a
> CC build/./objs/iio/doprnt.o
> AR build/./libiiomini.a
> CC build/crt0.o
> CC build/minicrt0.o
>
>
> Thank you for your help.
>
> Merci.
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] LIBCmini don't build with Gcc ELF 13.2.0

[Daroou <da...@fr...>]

Bonjour,


I'm currently testing Vincent Rivière's m68k-atari-mintelf cross-tools 
(under cygwin)

'Hello world' compiles perfectly with Mintlib.

However, I want to use LIBCmini for my programs.

https://github.com/freemint/libcmini

GCC ELF refuses to compile LIBCmini because of this error:

[Makefile]

ONLY_68K=Y
BUILD_CF=N
BUILD_FAST=N
BUILD_SOFT_FLOAT=Y
BUILD_SHORT=Y
COMPILE_ELF=Y
STDIO_WITH_LONG_LONG=N


$ m68k-atari-mintelf-gcc --version

m68k-atari-mintelf-gcc (GCC MiNT ELF 20240130) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make clean

make libs

CC build/./objs/isblank.o
sources/isblank.c: In function 'isblank':
sources/isblank.c:4:6: error: infinite recursion detected 
[-Werror=infinite-recursion]
     4 | int (isblank)(int c)
       |      ^~~~~~~
sources/isblank.c:6:16: note: recursive call
     6 |         return isblank(c);
       |                ^~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:162: build/./objs/isblank.o] Error 1


[isblank.c]

#include <ctype.h>
#include "ctypeint.h"

int (isblank)(int c)
{
     return isblank(c);
}
[/isblank.c]




Compiles perfectly with standard GCC

[Makefile]

ONLY_68K=Y
BUILD_CF=N
BUILD_FAST=N
BUILD_SOFT_FLOAT=Y
BUILD_SHORT=Y
COMPILE_ELF=N
STDIO_WITH_LONG_LONG=N


$ m68k-atari-mint-gcc --version

m68k-atari-mint-gcc (GCC) 4.6.4 (MiNT 20200504)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

make clean

make libs

[...]

CC build/./objs/setstack.o
AR build/./libcmini.a
CC build/./objs/iio/doprnt.o
AR build/./libiiomini.a

make clean

make all

[...]

CC build/./objs/setstack.o
AR build/./libcmini.a
CC build/./objs/iio/doprnt.o
AR build/./libiiomini.a
CC build/crt0.o
CC build/minicrt0.o


Thank you for your help.

Merci.

[Freemint-discuss] Announcement - "Crash Assistant"

[Jo E. S. <jo...@on...>]

I've just released "Crash Assistant" (http://atari.joska.no/crash/), a
GEM-tool that monitors the alertpipe and catches crash notifications
from the kernel. I find this to be a useful tool when dealing with
memory violations under MiNT.

Jo Even

Re: [Freemint-discuss] Weird problem with MiNTnet

[Miro K. <mir...@gm...>]

On Mon, 3 Nov 2025 at 21:25, Stefan Niestegge <be...@ab...> wrote:

> I also wanted to start fresh HDD setup on my Falcon, with latest snapshot.
> I installed the unix stuff on my ext2 fs with the EasyMiNT installer, then
> unpacked the snapshot to the MiNT folder on C: and configured mint.cnf to
> start INIT as the shell and xaaes.cnf for SV usage and put SVethLANa driver
> into the sysdir. Configured config.if, hostname, defaultroute and
> resolve.conf for my network instead of starting dhclient at boot.
>
> Network comes up and only ping to 192.168.2.61 (my Falcon's IP) works, but
> not to router, and ping www.google.de doesn't resolve.
>
You should investigate output of "ifconfig" and "route" from your new setup
and your old setup, that should give you some clues.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Weird problem with MiNTnet

[Stefan N. <be...@ab...>]

Hello List,

I also wanted to start fresh HDD setup on my Falcon, with latest 
snapshot. I installed the unix stuff on my ext2 fs with the EasyMiNT 
installer, then unpacked the snapshot to the MiNT folder on C: and 
configured mint.cnf to start INIT as the shell and xaaes.cnf for SV 
usage and put SVethLANa driver into the sysdir. Configured config.if, 
hostname, defaultroute and resolve.conf for my network instead of 
starting dhclient at boot.

Network comes up and only ping to 192.168.2.61 (my Falcon's IP) works, 
but not to router, and ping www.google.de doesn't resolve.

BUT, if i boot into the ancient EasyMiNT 1-19-cur (using the same INIT 
from ext2 partition as with the snapshot) pinging around all works, i 
can connect to IRC and browse the web.


I managed to get the new "ready to run" 4GB FreeMiNT Distro image 
running, not sure what kernel it uses, uname -a reports 1-19a. Here i 
can also ping everything, and network works as desired.

This setup doesn't use init but calls ipconfig and route from xaaes.cnf 
instead. Therefore its not a "real" FreeMiNT setup IMHO.


I'd really like to know what the problem is. The least thing as a user 
to support you developers is actually running your latest code, and not 
say "ah well, i just run the old EasyMiNT, thats stable.".

Why would you even continue developing, then?

Greetings, and thanks for keeping FreeMiNT alive

Stefan "Beetle" Niestegge


Am 18.08.25 um 00:48 schrieb Miro Kropáček:
> Just to post an update on this... it went away the same way it 
> appeared -- without any plausible explanation. What I did was to 
> reassemble the SuperVidel, connect everything together and voila, now 
> ping 127.0.0.1 worked and so did NetUSBee's networking. I had to 
> reseat Svethlana's cable and voila, it started to work as well 
> (otherwise I was seeing a lot of error reports from svethlana's driver).
>
> How all of this is connected to pinging localhost, I do not know.
>
> On Thu, 14 Aug 2025 at 00:19, Miro Kropáček <mir...@gm...> 
> wrote:
>
>     Typo: Dec 2024. Oh and I tried also older FreeMiNT versions (1.16,
>     1.17, 1.18...)
>
>     On Thu, 14 Aug 2025 at 00:16, Miro Kropáček
>     <mir...@gm...> wrote:
>
>         Speaking of weird problems... today I have encountered
>         something equally strange and without any clue what has caused
>         it.
>
>         Basically I tried to reinstall my system from scratch. So I
>         download the bootable snapshot, add ping and set up some basic
>         static IP. Pinging my PC doesn't work. Router ditto. Local IP
>         ditto. 127.0.0.1 ditto. All I see is "PING .... 56 data bytes"
>         and that's it, no response. I can interrupt it with CTRL+C any
>         time.
>
>         So I stared at it for a while and then I tried to boot the
>         same CF card from Hatari on my PC. Didn't bother with anything
>         else than ping 127.0.0.1 and ... it worked. Swapped back to
>         the Falcon ... didn't work.
>
>         Reverted back to the snapshot, and just added 'ping' into /bin
>         (even deleted the two xif drivers in $SYSDIR). Same result:
>         Hatari OK, real machine not OK. Tried in both 030 and 060 mode.
>
>         Booting with MP enabled, nothing out of ordinary spotted.
>         Tried to copy a huge ZIP file from Hatari to CF card and unzip
>         it on Falcon (to make sure that IDE reading is OK): all fine.
>
>         Then I tried to download a snapshot from Dec 2014, which I
>         vaguely remember using: same result. Then I deleted basically
>         everything but mint.prg and inet4.xdd: same result.
>
>         As a last resort, I tried to boot the same card and default
>         snapshot on another Falcon and ... ping worked! So that leaves
>         me perplexed... I could understand all sorts of reasons why
>         the actual network interface doesn't work. But pinging
>         127.0.0.1 ??? The Falcon with non-working ping is even
>         recapped, in perfect health otherwise.
>
>         So I swapped the last thing -- the CF adapter which was
>         holding the card (from the working Falcon), and even removed
>         SuperVidel in the process (not active at that time, booting in
>         030 mode!) ... ping still stubbornly refuses to work.
>
>         As an act of desperation, I even cleaned NVRAM on the falcon,
>         as the working one has a dead NVRAM battery so it's booting
>         into ST LOW. No help.
>
>         I'm totally clueless. I guess I could try to remove the CT60e
>         but that's... that's just terrible. I guess I'll try to force
>         myself into debugging this further (i.e. to recompile 'ping'
>         from Vincent's source code) as it smells like a nice issue to
>         look at but still, I cannot think of any explanation other
>         than "bad luck".
>
>         On Sun, 18 May 2025 at 22:11, Jo Even Skarstein via
>         Freemint-discuss <fre...@li...> wrote:
>
>             Ok, haven't had much time to spend on real hardware the
>             last month, but sat down Friday night
>             and tried to figure out what the problem was. I suspected
>             either a Linux/Windows update, or a
>             router update. Most likely the latter, as the problem
>             started at the exact same time on all my
>             computers.
>
>             Turns out that it's a routing issue with my router, and
>             probably my MiNTnet configuration. When I
>             access other devices on my LAN from MiNTnet, all LAN
>             traffic goes via the router - which is set up
>             as the default route. For some unknown to me reason (I
>             know very little about network configuration)
>             this suddenly caused all my non-MiNTnet machines to not be
>             able to communicate with my MiNTnet
>             machines. Looks like packets where received by MiNTnet,
>             but the response never reached the other
>             machine. Except if that machine runs MiNTnet as well.
>
>             Adding a route specifically to my LAN solved the issue.
>             However, the dhclient script does not do this
>             so I can't use DHCP anymore. Or I probably could if I
>             modified the dhclient script, but that involves
>             another thing I don't know much and don't like - shell
>             scripts.
>
>             Jo Even
>
>
>
>             On Thu, 17 Apr 2025 19:02:57 +0000, Jo Even Skarstein via
>             Freemint-discuss <fre...@li...>
>             wrote:
>
>             >> I've ran into a weird problem with MiNTnet. Suddenly
>             none of my Ataris running MiNTnet are available to other
>             devices on my LAN, except the router. Networking between
>             my Ataris works normally, and I can ping my other devices
>             (PC's running Linux or Windows) from my Ataris but not
>             vice versa. I can't access any servers on my PC's from my
>             Ataris, but any external servers (ftp, http, mail...)
>             works fine. This happened suddenly and at the same time
>             for all my Ataris, so the problem is not caused by any
>             changes on the Atari side.
>             >>
>             >> What's strange is that if I boot TOS and run UIPtool
>             instead of MiNT/MiNTnet everything works fine. The Atari
>             is assigned the same IP as under MiNTnet (using DHCP in
>             both cases), but with UIPtool running I can access the
>             Atari from any device on my LAN.
>             >>
>             >> Any idea on what's going on?
>             >>
>             >> Jo Even
>             >>
>             >>
>             >> _______________________________________________
>             >> Freemint-discuss mailing list
>             >> Fre...@li...
>             >>
>             https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>             _______________________________________________
>             Freemint-discuss mailing list
>             Fre...@li...
>             https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
>
>
>         -- 
>         http://mikro.atari.org
>
>
>
>     -- 
>     http://mikro.atari.org
>
>
>
> -- 
> http://mikro.atari.org
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] C alternative to fscheck.sh

[Miro K. <mir...@gm...>]

On Fri, 24 Oct 2025 at 05:31, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> Now, 14 years later, I fixed the bugs and improved it slightly. It can be
> downloaded from https://atari.joska.no/fscheck/

Great stuff! I'd like to look at the fsck.vfat problem again but that wont
happen anytime soon, unfortunately.

-- 
http://mikro.atari.org

[Freemint-discuss] C alternative to fscheck.sh

[Jo E. S. <jo...@on...>]

Back in 2011 I wrote a c replacement for the fscheck.sh shell script
for VanillaMiNT. It turned out to have a couple of nasty bugs so I
removed it with the intention of fixing it and adding it again.

Now, 14 years later, I fixed the bugs and improved it slightly. It can
be downloaded from https://atari.joska.no/fscheck/

It doesn't depend on external binaries except the various fsck's, so it
should work fine with even the most basic setup. Doesn't make much
sense without atleast one ext2 or minix partition though, as the FAT
fsck insists on checking the entire filesystem every time.

It can also be used with fscheck.sh - it can generate an fstab-
compatible list of drives which then can be used by a slightly modified
fscheck.sh. Then there is no need to manually maintain /etc/fstab.

E.g.

    fscheck -fstab -skipfs dos > /ram/fstab

...will generate an "fstab" with all drives with other filesystems than
dos/FAT.

Sources included.

Jo Even

Re: [Freemint-discuss] FAT-FS dirty bit?

[Jo E. S. <jo...@on...>]

On Tue, 2025-10-21 at 10:49 +0000, Jo Even Skarstein via Freemint-
discuss wrote:
> > > Have you tried the one from the freemint repository?
> 
> I was not aware that there was one :) Will test it tonight.

- On FAT16 partitions it always reports "Dirty bit set" and
"Automatically removing dirty bit".
- On FAT32 partitions the check always fails the "Checking if we can
access the last sector of the filesystem" check. rwabs_xhdi: access
outside of partition.

Jo Even

Re: [Freemint-discuss] FAT-FS dirty bit?

[Jo E. S. <jo...@on...>]

On Tue, 21 Oct 2025 08:10:09 +1000, "Miro Kropáček" <mir...@gm...> wrote:

>> Have you tried the one from the freemint repository?

I was not aware that there was one :) Will test it tonight.

Btw I just noticed that there's some files in the sysroot-folder of the bootable build with filenames that's too long for a FAT partition:

bin/fsck.minix
bin/mount_nfs
etc/mke2fs.conf

Jo Even

Re: [Freemint-discuss] FAT-FS dirty bit?

[Miro K. <mir...@gm...>]

Have you tried the one from the freemint repository?

http://mikro.atari.org

On Tue, 21 Oct 2025, 5:34 am Jo Even Skarstein via Freemint-discuss, <
fre...@li...> wrote:

> Hi,
>
> I'm trying to use fsck.fat from Thorsten
> ( https://www.tho-otto.de/download/mint/dosfstools-4.1+git-mint-000.tar.xz
> ), and it always complains about "dirty bit set" even after a clean
> shutdown. How is this supposed to work?
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] FAT-FS dirty bit?

[Jo E. S. <jo...@on...>]

Hi,

I'm trying to use fsck.fat from Thorsten
( https://www.tho-otto.de/download/mint/dosfstools-4.1+git-mint-000.tar.xz
), and it always complains about "dirty bit set" even after a clean
shutdown. How is this supposed to work?

Jo Even

Re: [Freemint-discuss] Purpose of saving sr in context.S

[Miro K. <mir...@gm...>]

On Sat, 4 Oct 2025 at 12:39, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> What also buffles me: shouldn't the part inside `ifdef MMU040` (which is
> now `#if defined (M68040) || defined (M68060)` in current code) accompanied
> by a runtime check of the cpu actually in use? Otherwise code that is
> compiled for m68020-60, with only M68030 being defined, will always fall
> into the 68030 case.
>
This should be taken care of by the fact that on 040+ machines you are
never supposed to run anything other than MINT040 and/or MINT060.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Purpose of saving sr in context.S

[Thorsten O. <ad...@th...>]

On Samstag, 4. Oktober 2025 12:12:15 CEST Miro Kropáček wrote:
> To me it looks like a random addition with no particular purpose.

I agree, that saving of sr seems superfluous.

What also buffles me: shouldn't the part inside `ifdef MMU040` (which is now 
`#if defined (M68040) || defined (M68060)` in current code) accompanied by a 
runtime check of the cpu actually in use? Otherwise code that is compiled for 
m68020-60, with only M68030 being defined, will always fall into the 68030 
case.

[Freemint-discuss] Purpose of saving sr in context.S

[Miro K. <mir...@gm...>]

Hi,

while looking into context.S I have noticed an odd couple of lines. These
were added in https://github.com/freemint/freemint/commit/de7af1b3 and I
can't understand their meaning, take save_context for instance:

- sr is obviously destroyed by the tst.w just before move.w sr,d1 so why
bother saving it?

- sr is obviously destroyed after move.w d1,sr by tst.w _fpu and all the
following lines up to move.w sr,C_SR(a0) so again, why bother at that
specific place?

- Why only save_context and change_context but no build_context and
restore_context? There's literally the same code in there.

To me it looks like a random addition with no particular purpose.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] How to join FreeMINT discord group?

[ROBERT M. <rj...@ya...>]

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thank you! &nbsp;That’s what I meant.<div><br></div><div>Regards,</div><div>Bob</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Oct 2, 2025, at 2:55 AM, Miro Kropáček &lt;mir...@gm...&gt; wrote:<br><br></div><div dir="ltr"><div dir="ltr">I think Robert means the actual Discord group:&nbsp;<a href="https://discord.gg/5yZC4NwCr9">https://discord.gg/5yZC4NwCr9</a>.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 2 Oct 2025 at 08:49, David Gálvez &lt;<a href="mailto:dga...@gm...">dga...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>You can subscribe from this site:</div><div><br></div><div dir="ltr"><a href="https://sourceforge.net/projects/freemint/lists/freemint-discuss" target="_blank">https://sourceforge.net/projects/freemint/lists/freemint-discuss</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (&lt;<a href="mailto:fre...@li..." target="_blank">fre...@li...</a>&gt;) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi;<br>
<br>
I would like to join this group. Can someone send me an invite?&nbsp; Email address is <a href="mailto:rj...@ya..." target="_blank">rj...@ya...</a><br>
<br>
Thanks,<br>
Bob<br>
Sent from my iPhone<br>
<br>
<br>
_______________________________________________<br>
Freemint-discuss mailing list<br>
<a href="mailto:Fre...@li..." target="_blank">Fre...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/freemint-discuss" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/freemint-discuss</a><br>
</blockquote></div></div>
_______________________________________________<br>
Freemint-discuss mailing list<br>
<a href="mailto:Fre...@li..." target="_blank">Fre...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/freemint-discuss" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/freemint-discuss</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://mikro.atari.org" target="_blank">http://mikro.atari.org</a></div></div></div>
<span>_______________________________________________</span><br><span>Freemint-discuss mailing list</span><br><span>Fre...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/freemint-discuss</span><br></div></div></body></html>

Re: [Freemint-discuss] How to join FreeMINT discord group?

[Miro K. <mir...@gm...>]

I think Robert means the actual Discord group: https://discord.gg/5yZC4NwCr9
.

On Thu, 2 Oct 2025 at 08:49, David Gálvez <dga...@gm...> wrote:

> You can subscribe from this site:
>
> https://sourceforge.net/projects/freemint/lists/freemint-discuss
>
> El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (<
> fre...@li...>) escribió:
>
>> Hi;
>>
>> I would like to join this group. Can someone send me an invite?  Email
>> address is rj...@ya...
>>
>> Thanks,
>> Bob
>> Sent from my iPhone
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] How to join FreeMINT discord group?

[David G. <dga...@gm...>]

You can subscribe from this site:

https://sourceforge.net/projects/freemint/lists/freemint-discuss

El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (<
fre...@li...>) escribió:

> Hi;
>
> I would like to join this group. Can someone send me an invite?  Email
> address is rj...@ya...
>
> Thanks,
> Bob
> Sent from my iPhone
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] How to join FreeMINT discord group?

[ROBERT M. <rj...@ya...>]

Hi;

I would like to join this group. Can someone send me an invite?  Email address is rj...@ya...

Thanks,
Bob
Sent from my iPhone

Re: [Freemint-discuss] Reading free memory via /proc/*.000

[Jo E. S. <jo...@on...>]

On Wed, 24 Sep 2025 00:31:04 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> On Dienstag, 23. September 2025 20:09:55 CEST Jo Even Skarstein via Freemint-
>> discuss wrote:
>> > You can't do this if you don't have the sources for the crashing
>> > program.
>>
>> Ah ok i thought you were hunting some bug in your program.
>>
>> What you could eventually do is still try to run the program under the control
>> of the debugger, either the new elf version, or maybe even the version 5.1
>> from sparemint. That should give you atleast the opportunity to examine any
>> address you want, before the program terminates.

This is related to the "crash assistant" I posted about in the alertpipe thread. My idea was to bring up a disassembled text-segment, highlighting the instruction that caused the memory violation. It is not strictly necessary to access the released memory of the crashed process for this, in most cases I know the location of the binary and can just read the file instead. Not yet sure if this is going to happen though - the casual user will not benefit from this and the ones capable of reading disassembled 68k are already perfectly capable of loading the program in TT-Digger or similar themselves.

Jo Even

Re: [Freemint-discuss] Alert pipe

[Jo E. S. <jo...@on...>]

On Wed, 24 Sep 2025 00:36:18 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> Hm, that would certainly be useful. But maybe we can find a different solution
>> for this. After all, the alert pipe is not only used to report access

The program displays all alerts coming in from the pipe, crash/memory violation alerts are automatically detected and the "crash assistant" UI is only used for these. But some API with more details would of course be better. E.g. I have to periodically poll the process list to be able to display details about the crashed process, as the process is gone once the alert is sent. So in some cases where the program crashes immediately after start  the location of the binary is unknown and the "restart" feature won't work.

>> violations, but can contain any text.

Looks like all the current program that monitors this pipe (XaAES, MultiTOS' alert.prg) expects the text to be formatted as an alertstring and does not display anything if it isn't. As I mentioned in another post - this is a bit weird and it should be up to the UI to decide how to present it. Btw my program does not care and displays the message regardless of format as long as it's plain text, but that's just a side-effect of the implementation. It can also show the alerts in a non-blocking window with automatic timeout, and it can show multiple alerts at once. So in theory the alert pipe can be used as a generic notification pipe.

Jo Even

Re: [Freemint-discuss] Alert pipe

[Eero T. <oa...@he...>]

Hi,

On 23.9.2025 21.43, Jo Even Skarstein via Freemint-discuss wrote:
> Here's why I wanted to monitor the alert-pipe with a separate
> application (see attached screenshot). I want to assist the casual user
> in resolving the memory violations that can occur when using certain
> popular applications. I want to give the user a clear explanation of
> the crash and tips on how to resolve it. It's not finished yet, and the
> "SERVER" and "CLIENT" processes referred to in the screenshot are the
> test programs I use to generate the various memory violations for
> testing.

Something like Linux core dump pipe helper:
https://docs.kernel.org/6.7/admin-guide/sysctl/kernel.html#core-pipe-limit
?

(That is used by every major Linux distro to catch/upload core dumps and 
centrally process them to get a database of backtraces providing 
statistics of crash points.)


	- Eero