freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

On Thu, 3 Jul 2025 14:12:13 +0200, "Miro Kropáček" <mir...@gm...> wrote:

>> I'm getting very similar vibes here as from
>> https://github.com/freemint/freemint/issues/273#issuecomment-1832685444.

Yes, this sounds like the exact same problem. I have added a link to this thread to that issue.

Jo Even

Re: [Freemint-discuss] XaAES often crashes during boot after a reboot

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

Hi,

somehow I had completely overlooked your test program, especially when you
say that 0x55 makes it crash almost instantly.

I'm getting very similar vibes here as from
https://github.com/freemint/freemint/issues/273#issuecomment-1832685444.

I'll try this at some point, ideally in Hatari or Aranym.

On Mon, 30 Jun 2025 at 22:41, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> Has anybody attempted/been able to reproduce this problem?
>
> Jo Even
>
> On Tue, 2025-01-21 at 20:19 +0000, Jo Even Skarstein via Freemint-
> discuss wrote:
> > Good tips! I changed the program to set the free memory to 0x55, and
> > if I run this program before mint.prg I can reproduce the crash
> > almost every time on both the Milan and Falcon/CT60. Different
> > network hardware, different drivers, same snapshot. Crashes somewhere
> > between route (in mint.cnf) and starting the desktop.
> >
> > Also, it does not happen if I don't run route. ifconfig alone does
> > not cause the crash, ifconfig+route does.
> >
> > I've attached the test program (no I haven't, the mail was rejected
> > because of the .zip attachment. Get it here:
> > https://atari.joska.no/download/memset.zip). It would be very
> > interesting if you could reproduce this on your Falcon.
> >
> > --------------->8------------------
> >
> > #include <stdio.h>
> > #include <string.h>
> > #include <tos.h>
> >
> > #define VALUE 0x55
> >
> > int main(int argc, char **argv)
> > {
> >    long s, total = 0;
> >
> >     printf("Setting all available memory to 0x%02x:\n", VALUE);
> >
> >     printf("\nST-RAM:\n");
> >     while ((s = (long) Mxalloc(-1L, 0)) > 0)
> >     {
> >         char *m = Mxalloc(s, 0);
> >         printf("0x%08p (%ld Kb)\n", m, s / 1024L);
> >         memset(m, VALUE, s);
> >         total += s;
> >     }
> >
> >     printf("\nFast-RAM:\n");
> >     while ((s = (long) Mxalloc(-1L, 1)) > 0)
> >     {
> >         char *m = Mxalloc(s, 1);
> >         printf("0x%08p (%ld Kb)\n", m, s / 1024L);
> >         memset(m, VALUE, s);
> >         total += s;
> >     }
> >
> >     printf("\n%ld Kb set.\n\n", total / 1024L);
> >     return 0;
> > }
> >
> > --------------8<-----------------
> >
> > It must be run before mint.prg, if I run it from mint.cnf before
> > ifconfig/route it doesn't make a difference. Same with clearing the
> > RAM instead - do it before mint.prg and the crash never happens. So
> > it looks like the kernel assumes that atleast one byte of the RAM it
> > allocates is zeroed.
> >
> > I run ifconfig/route as the last thing before GEM= in mint.cnf.
> > GlueSTiK is started immediately before. It doesn't matter if GlueSTiK
> > is started or not.
> >
> > Jo Even
> >
> > On Tue, 21 Jan 2025 14:04:05 +0100, "Miro Kropáček"
> > <mir...@gm...> wrote:
> >
> > > > - since your CT60 scenario is far less reproducible: what about
> > > > filling RAM
> > > > with 0xFF instead of 0x00? Does it lead to more reliable crashes?
> > > > (just to
> > > > be on the safe side, check on Milan before, too - the 0xFF may be
> > > > one of
> > > > those "safe" ones)
> > > >
> > > > - do not run both ifconfig and route, just one of them and
> > > > alternatively,
> > > > do not configure the given network interface, just the loopback
> > > > one
> >
> >
> >
> > _______________________________________________
> > 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] XaAES often crashes during boot after a reboot

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

Has anybody attempted/been able to reproduce this problem?

Jo Even

On Tue, 2025-01-21 at 20:19 +0000, Jo Even Skarstein via Freemint-
discuss wrote:
> Good tips! I changed the program to set the free memory to 0x55, and
> if I run this program before mint.prg I can reproduce the crash
> almost every time on both the Milan and Falcon/CT60. Different
> network hardware, different drivers, same snapshot. Crashes somewhere
> between route (in mint.cnf) and starting the desktop.
> 
> Also, it does not happen if I don't run route. ifconfig alone does
> not cause the crash, ifconfig+route does.
> 
> I've attached the test program (no I haven't, the mail was rejected
> because of the .zip attachment. Get it here:
> https://atari.joska.no/download/memset.zip). It would be very
> interesting if you could reproduce this on your Falcon.
> 
> --------------->8------------------
> 
> #include <stdio.h>
> #include <string.h>
> #include <tos.h>
> 
> #define VALUE 0x55
> 
> int main(int argc, char **argv)
> {
>    long s, total = 0;
> 
>     printf("Setting all available memory to 0x%02x:\n", VALUE);
> 
>     printf("\nST-RAM:\n");
>     while ((s = (long) Mxalloc(-1L, 0)) > 0)
>     {
>         char *m = Mxalloc(s, 0);
>         printf("0x%08p (%ld Kb)\n", m, s / 1024L);
>         memset(m, VALUE, s);
>         total += s;
>     }
> 
>     printf("\nFast-RAM:\n");
>     while ((s = (long) Mxalloc(-1L, 1)) > 0)
>     {
>         char *m = Mxalloc(s, 1);
>         printf("0x%08p (%ld Kb)\n", m, s / 1024L);
>         memset(m, VALUE, s);
>         total += s;
>     }
> 
>     printf("\n%ld Kb set.\n\n", total / 1024L);
>     return 0;
> }
> 
> --------------8<-----------------
> 
> It must be run before mint.prg, if I run it from mint.cnf before
> ifconfig/route it doesn't make a difference. Same with clearing the
> RAM instead - do it before mint.prg and the crash never happens. So
> it looks like the kernel assumes that atleast one byte of the RAM it
> allocates is zeroed.
> 
> I run ifconfig/route as the last thing before GEM= in mint.cnf.
> GlueSTiK is started immediately before. It doesn't matter if GlueSTiK
> is started or not.
> 
> Jo Even
> 
> On Tue, 21 Jan 2025 14:04:05 +0100, "Miro Kropáček"
> <mir...@gm...> wrote:
> 
> > > - since your CT60 scenario is far less reproducible: what about
> > > filling RAM
> > > with 0xFF instead of 0x00? Does it lead to more reliable crashes?
> > > (just to
> > > be on the safe side, check on Milan before, too - the 0xFF may be
> > > one of
> > > those "safe" ones)
> > > 
> > > - do not run both ifconfig and route, just one of them and
> > > alternatively,
> > > do not configure the given network interface, just the loopback
> > > one
>  
> 
> 
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

[Freemint-discuss] Vampire V2 Saga Mouse

[Mark D. <mdu...@at...>]

Hi Everyone,

When I use Vincent's original V2 saga fvdi driver, all is well and 
things appear to work (under 1024x768 resolution anyway, monitor doesn't 
like timings above that).

When I move to the latest version which I see has mouse work done by 
Thorsten I have some troubles.

It seems whether I use hwmouse or not my mouse cursor is red and white 
instead of black and white and the click position is off. Further it 
seems like clicks don't always register properly.

This is on Amiga 500.  Any idea how to go about further troubleshooting?

Thanks,
Mark

Re: [Freemint-discuss] m68k alignment change in Debian/Gentoo

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

On Fri, 13 Jun 2025 at 20:20, Eero Tamminen <oa...@he...> wrote:

> On 13.6.2025 17.49, Thorsten Otto via Freemint-discuss wrote:
> > On Freitag, 13. Juni 2025 16:39:45 CEST Eero Tamminen wrote:
> >> What would break / need fixing if MiNT GCC & related tools would be
> >> built / using 4-byte alignment?   Or should everything "just work"?
> >
> > No, it would not work. You can try mixing code by using -malign-int
> (which
> > basically does the same) and get different structure layouts.
>
> Wouldn't "just" recompiling everything (including TOS?), and using
> different library paths take care of that?
>
Out of curiosity I looked it up in our discussions about mintelf toolchain.
This post by Vincent summarises it well:
https://github.com/freemint/m68k-atari-mint-gcc/issues/20#issuecomment-1697651610.
So answer to my previous question is that no, mintelf is not using 4-byte
alignment.

TL; DR is that both TOS and FreeMiNT/XaAES use internal structures which
are passed to user code and expect 16-bit alignment. Changing that would be
a massive effort, if not straight impossible (due to TOS).


> > IMHO a very bad decision by the debian people.
>
> And apparently Gentoo maintainer too.
>
>
> > I think a lot of people misunderstand the difference between sizeof() and
> > alignof(). And if projects fall into this trap, those projects should be
> > fixed, not the compiler.
>
I have glanced over the discussion, I can understand why they are doing it.
I think this post: https://lists.debian.org/debian-68k/2025/05/msg00051.html
explains it very well. Convincing maintainers to fix alignment bugs is
really painful, I can tell from my own experience.

Too bad for us in any case.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] m68k alignment change in Debian/Gentoo

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

Please refresh my memory: isn't the m68k-atari-mintelf toolchain already
doing it?

On Fri, 13 Jun 2025 at 16:40, Eero Tamminen <oa...@he...> wrote:

> Hi,
>
> Apparently both Debian/m68k and Gentoo/m68k are in process of switching
> m68k architecture alignment from 2-bytes to 4-bytes, because several
> upstream projects require it:
>         https://wiki.debian.org/M68k/Alignment
>
> While this has no immediate impact on MiNT, it means that there won't
> any more be somebody constantly building latest SW with latest
> toolchains, using 2-byte alignment, and filing upstream bugs about the
> issues. So eventually support for that is going to break in GCC & other
> projects and not get fixed, like happened for a.out.
>
> What would break / need fixing if MiNT GCC & related tools would be
> built / using 4-byte alignment?   Or should everything "just work"?
>
>
>         - Eero
>
> (If somebody is already testing that, I would be interested to compare /
> profile perf difference between such binaries at some point.)
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

Re: [Freemint-discuss] m68k alignment change in Debian/Gentoo

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

Hi,

On 13.6.2025 17.49, Thorsten Otto via Freemint-discuss wrote:
> On Freitag, 13. Juni 2025 16:39:45 CEST Eero Tamminen wrote:
>> What would break / need fixing if MiNT GCC & related tools would be
>> built / using 4-byte alignment?   Or should everything "just work"?
> 
> No, it would not work. You can try mixing code by using -malign-int (which
> basically does the same) and get different structure layouts.

Wouldn't "just" recompiling everything (including TOS?), and using 
different library paths take care of that?

*Except* for all the assembly code which would need to be investigated 
and fixed manually...


> IMHO a very bad decision by the debian people.

And apparently Gentoo maintainer too.


> I think a lot of people misunderstand the difference between sizeof() and
> alignof(). And if projects fall into this trap, those projects should be
> fixed, not the compiler.


	- Eero

Re: [Freemint-discuss] m68k alignment change in Debian/Gentoo

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

On Freitag, 13. Juni 2025 16:39:45 CEST Eero Tamminen wrote:
> What would break / need fixing if MiNT GCC & related tools would be
> built / using 4-byte alignment?   Or should everything "just work"?

No, it would not work. You can try mixing code by using -malign-int (which 
basically does the same) and get different structure layouts. IMHO a very bad 
decision by the debian people.

I think a lot of people misunderstand the difference between sizeof() and 
alignof(). And if projects fall into this trap, those projects should be 
fixed, not the compiler.

[Freemint-discuss] m68k alignment change in Debian/Gentoo

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

Hi,

Apparently both Debian/m68k and Gentoo/m68k are in process of switching 
m68k architecture alignment from 2-bytes to 4-bytes, because several 
upstream projects require it:
	https://wiki.debian.org/M68k/Alignment

While this has no immediate impact on MiNT, it means that there won't 
any more be somebody constantly building latest SW with latest 
toolchains, using 2-byte alignment, and filing upstream bugs about the 
issues. So eventually support for that is going to break in GCC & other 
projects and not get fixed, like happened for a.out.

What would break / need fixing if MiNT GCC & related tools would be 
built / using 4-byte alignment?   Or should everything "just work"?


	- Eero

(If somebody is already testing that, I would be interested to compare / 
profile perf difference between such binaries at some point.)

Re: [Freemint-discuss] Weird problem with MiNTnet

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

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

Re: [Freemint-discuss] Stripex .... WOW

[WongCK <won...@ya...>]

 Thanks for the suggestion. It did not make any difference with the -o option.
I now strongly believe it is yet another quirky behaviour due to my setup and usage.Nevertheless your stripex came to the rescue :-)
    On Wednesday, 30 April 2025 at 10:53:31 pm SGT, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:  
 
 
On Mittwoch, 30. April 2025 14:43:30 CEST WongCK via Freemint-discuss wrote:

> I am probably the only person seeing this phenomena as I compile on the

> Falcon..... that's where the enjoyment happens.


That would be another hint that ftruncate()/truncate() is the culprit. When cross-compiling, that will use the hosts system function, and works. When running natively on mint, it may work or not, depending on which filesystem is in use. It could also be that there is somewhere a bug, either in mintlib, or the kernel, or the filesystem driver. Hard to tell.


You could try using the -o <filename> option when running strip. That should create a new file, rather than operating on the existing file.

_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
  

Re: [Freemint-discuss] Stripex .... WOW

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

On Mittwoch, 30. April 2025 14:43:30 CEST WongCK via Freemint-discuss wrote:
> I am probably the only person seeing this phenomena as I compile on the
> Falcon..... that's where the enjoyment happens.

That would be another hint that ftruncate()/truncate() is the culprit. When 
cross-compiling, that will use the hosts system function, and works. When 
running natively on mint, it may work or not, depending on which filesystem is 
in use. It could also be that there is somewhere a bug, either in mintlib, or 
the kernel, or the filesystem driver. Hard to tell.

You could try using the -o <filename> option when running strip. That should 
create a new file, rather than operating on the existing file.

Re: [Freemint-discuss] Stripex .... WOW

[WongCK <won...@ya...>]

 Just to see whats going on, i loaded the strip -s PRG and the stripex PRG into a HEX editor in windows. Compared side by side by just eyeballing it - totally non-scientific method and mostly just stabbing into the dark.
The code matches each other in most places... of course it should.The strip -s PRG has word ELF dotted around the place not found in stripex PRG (we know this is as expected).When the stripex PRG comes to the end, the strip -s PRG of course continues as it is bigger.
The area where the strip -s PRG continues becomes a sea of zeros. Until it comes to a bunch of strings. These strings are duplicated from the segment above (.data or .rodata I guess).After that another sea of zeros follows.Then a bunch of code (scrambled text) which I can use the find function to find same groups of code elsewhere in the above section (found 2 times in strip -s PRG). The same group of code can only be found once in the stripex PRG.
So looks like these are some bunch of buffers that was appended by the linker. And stripex rightfully removed them. Great !!!
Is this a weird feature that I have found.... probably. The program runs like it should so nothing bad.My guess is that it only uses more storage space on the HDD. Mint may not load those duplicated parts as they are not part of .text or .data.
I am probably the only person seeing this phenomena as I compile on the Falcon..... that's where the enjoyment happens.
    On Wednesday, 30 April 2025 at 04:38:21 pm SGT, Miro Kropáček <mir...@gm...> wrote:  
 
 On Wed, 30 Apr 2025 at 10:15, WongCK via Freemint-discuss <fre...@li...> wrote:
 So I did not have file on my system, so I grabbed it from Thorsten website.... seriously? 8.8 MB for just file?
Not sure what you mean, it's part of the mintbin package?

Looks like 40K comes from trailer stuff that stripex skipped at the last line.  0x9be4 is damn near 40K.No idea what are those.  
I've tried it on ScummVM (a 21 MB executable stripped). For me, stripex takes out 2664 bytes: 0xA0 (header) + 0x234 (symbols) and 0x794 (trailer). So I really wonder where it comes from in your case.
-- 
http://mikro.atari.org_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
  

Re: [Freemint-discuss] Stripex .... WOW

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

On Mittwoch, 30. April 2025 10:04:24 CEST WongCK via Freemint-discuss wrote:
> seriously? 8.8 MB for just file?

Not my fault, i only ported the package ;) Main reason for the size is the 
magic database.

> phclock.prg: skipped 0x9be4 bytes trailer

Hm that looks dubious. Looks like something was left behind by strip -s. Could 
maybe because it tries to call ftruncate on the file, and that is not 
supported? That would be in a bug in the binutils then.

Re: [Freemint-discuss] Stripex .... WOW

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

On Wed, 30 Apr 2025 at 10:15, WongCK via Freemint-discuss <
fre...@li...> wrote:

> So I did not have file on my system, so I grabbed it from Thorsten
> website.... seriously? 8.8 MB for just file?
>
Not sure what you mean, it's part of the mintbin package?

Looks like 40K comes from trailer stuff that stripex skipped at the last
> line.  0x9be4 is damn near 40K.
> No idea what are those.
>
I've tried it on ScummVM (a 21 MB executable stripped). For me, stripex
takes out 2664 bytes: 0xA0 (header) + 0x234 (symbols) and 0x794 (trailer).
So I really wonder where it comes from in your case.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Stripex .... WOW

[WongCK <won...@ya...>]

 So I did not have file on my system, so I grabbed it from Thorsten website.... seriously? 8.8 MB for just file?
Ok, so I have run both scenario with freshly make prg - 1st one with strip -s then stripex and 2nd one with stripex directly.Command mkclk is my alias to make the program, so executing it creates a fresh non-stripped program.My bash prompt 132elf:<path> is just to remind me of which gcc version I am using.
Here are my bash output, only added CRLF to make it easier to read (hopefully).
Looks like 40K comes from trailer stuff that stripex skipped at the last line.  0x9be4 is damn near 40K.No idea what are those.  

==== start =====
132elf:/k/dev4-clock>132elf:/k/dev4-clock>mkclkgcc -ophclock.prg  -m68020-60 -nostdlib -Wl,-Map,ldmap.map  /usr/lib/libcmini/crt0.o phclock.o main_win.o config.o samples.o  -lzcodec -lmywin -lmywin_dat -lgem -lldg -lcmini -lgccstack -S 64k phclock.prgstack size: 65536 bytes (64 kilo bytes).Fixed stack to 65536 bytes (64 kilo bytes).
132elf:/k/dev4-clock>ls -l phclock.prg-rw-r--r--    1 197613   197121       121k Apr 30 15:29 phclock.prg
132elf:/k/dev4-clock>file phclock.prgphclock.prg: Atari executable, ELF, text len 59148, data len 3070, bss len 40192, symboltab len 19834, fastload, load to Alt-RAM, malloc from Alt-RAM private
132elf:/k/dev4-clock>strip -VGNU strip (GNU Binutils for MiNT ELF 20240309) 2.42.0Copyright (C) 2024 Free Software Foundation, Inc.This program is free software; you may redistribute it under the terms ofthe GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty.
132elf:/k/dev4-clock>strip -s phclock.prg132elf:/k/dev4-clock>ls -l phclock.prg-rw-r--r--    1 197613   197121       102k Apr 30 15:30 phclock.prg132elf:/k/dev4-clock>file phclock.prgphclock.prg: Atari executable, ELF, text len 59148, data len 3070, bss len 40192, symboltab len 388, fastload, load to Alt-RAM, malloc from Alt-RAM private
132elf:/k/dev4-clock>stripex -v phclock.prgphclock.prg: text=0xe70c, data=0xbfe, syms=0x184phclock.prg: skipped 0xa0 bytes extra headerphclock.prg: copied 0xf26a bytes text+dataphclock.prg: skipped 0x184 bytes symbolsphclock.prg: copied 0x7d2 bytes relocation tablephclock.prg: skipped 0x9be4 bytes trailer132elf:/k/dev4-clock>ls -l phclock.prg-rw-r--r--    1 197613   197121        63k Apr 30 15:31 phclock.prg132elf:/k/dev4-clock>file phclock.prgphclock.prg: Atari executable, text len 58988, data len 3070, bss len 40192, symboltab len 0, fastload, load to Alt-RAM, malloc from Alt-RAM private
132elf:/k/dev4-clock>132elf:/k/dev4-clock>132elf:/k/dev4-clock>132elf:/k/dev4-clock>mkclkgcc -ophclock.prg  -m68020-60 -nostdlib -Wl,-Map,ldmap.map  /usr/lib/libcmini/crt0.o phclock.o main_win.o config.o samples.o  -lzcodec -lmywin -lmywin_dat -lgem -lldg -lcmini -lgccstack -S 64k phclock.prgstack size: 65536 bytes (64 kilo bytes).Fixed stack to 65536 bytes (64 kilo bytes).
132elf:/k/dev4-clock>ls -l phclock.prg-rw-r--r--    1 197613   197121       121k Apr 30 15:35 phclock.prg132elf:/k/dev4-clock>file phclock.prgphclock.prg: Atari executable, ELF, text len 59148, data len 3070, bss len 40192, symboltab len 19834, fastload, load to Alt-RAM, malloc from Alt-RAM private
132elf:/k/dev4-clock>stripex -v phclock.prgphclock.prg: text=0xe70c, data=0xbfe, syms=0x4d7aphclock.prg: skipped 0xa0 bytes extra headerphclock.prg: copied 0xf26a bytes text+dataphclock.prg: skipped 0x4d7a bytes symbolsphclock.prg: copied 0x7d2 bytes relocation tablephclock.prg: skipped 0x9be4 bytes trailer
132elf:/k/dev4-clock>ls -l phclock.prg-rw-r--r--    1 197613   197121        63k Apr 30 15:36 phclock.prg132elf:/k/dev4-clock>file phclock.prgphclock.prg: Atari executable, text len 58988, data len 3070, bss len 40192, symboltab len 0, fastload, load to Alt-RAM, malloc from Alt-RAM private132elf:/k/dev4-clock>
=== end ====   
additional tool  information:
132elf:/k/dev4-clock>gcc -vUsing built-in specs.COLLECT_GCC=gccCOLLECT_LTO_WRAPPER=/d/usr/bin/../lib/gcc/m68k-atari-mintelf/13/lto-wrapperTarget: m68k-atari-mintelfConfigured with: /home/sebilla/m68k-atari-mint-gcc/configure --target=m68k-atari-mintelf --host=m68k-atari-mintelf --build=x86_64-suse-linux-gnu --prefix=/usr --libdir=/usr/lib --bindir=/usr/bin --libexecdir='' --with-pkgversion='MiNT ELF 20240214' --disable-libcc1 --disable-werror --with-gxx-include-dir=/usr/include/c++/13 --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-gcc-major-version-only --with-gcc --with-gnu-as --with-gnu-ld --with-system-zlib --disable-libgomp --without-newlib --disable-libstdcxx-pch --disable-threads --disable-win32-registry --enable-lto --enable-ssp --enable-libssp --disable-plugin --disable-decimal-float --disable-nls --disable-sjlj-exceptions --with-cpu=m68000 --with-build-sysroot=/usr/m68k-atari-mintelf/sys-root --enable-languages=c,c++,fortran,ltoThread model: singleExceptions: Dwarf2Supported LTO compression algorithms: zlib zstdgcc version 13.2.0 (MiNT ELF 20240214)
132elf:/k/dev4-clock>ld -vGNU ld (GNU Binutils for MiNT ELF 20240309) 2.42.0132elf:/k/dev4-clock>




  

Re: [Freemint-discuss] Stripex .... WOW

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

On Wed, 30 Apr 2025 at 06:03, Thorsten Otto via Freemint-discuss <
fre...@li...> wrote:

> Thats strange, if the binary was already stripped by the normal strip
> tool, stripex should only remove a few bytes.
>
I'm equally surprised. Did you WongCK really run m68k-atari-mintelf-strip
-s <given exe>, ls -l and then stripex <given exe> ls -l  and saw 40K
stripped?

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Stripex .... WOW

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

On Mittwoch, 30. April 2025 04:07:19 CEST WongCK via Freemint-discuss wrote:
> So using stripex, the ELF binary is now down to 65K just like the a.out
> version. Totally blow my brains....

Thats strange, if the binary was already stripped by the normal strip tool, 
stripex should only remove a few bytes. But it also removes a symbol table, 
should there be any, so that could explain the size difference. Maybe, when 
running strip, you specified some options that left part of that symbol table? 
You should normally be able to detect the size of the symbol table by running 
the file command on the executable. It should print something like

a.out: Atari executable, text len 123808, data len 10752, BSS len 191362 
symboltab len 8484, fastload, load to Alt-RAM, malloc from Alt-RAM

Actually, the main purpose of stripex is to remove extended a.out (or ELF) 
headers that our gcc produces. This is sometimes needed when applications load 
the code as module without executing it, and expect the code to start right 
after the gemdos header.

Anyway, i'm glad that it could help ;)

[Freemint-discuss] Stripex .... WOW

[WongCK <won...@ya...>]

Just want to shout out to ThorstenOtto for his stripex.  Amazing tool. 
Apologise for those who already know this tool.
So the size of my ELF program using libcmini was bugging me for more than a year (or so since I started using ELF tools).Size after normal strip (with -s) was nearly 60% bigger in size compared to a.out binaries ( 102K vs 65K).I attributed it to my ELF libcmini being over 200K compared to original a.out libcmini which is less than 90K large.
Being slow week due to Easter holiday and now labour day, I had time to researched and found stripex mentioned on Atari Forum.Not sure how I missed that thread earlier.
So using stripex, the ELF binary is now down to 65K just like the a.out version. Totally blow my brains....Program still works like normal.
Sorry for taking up space in this maillist...   just slightly excited. :-)

Re: [Freemint-discuss] vq_devinfo and vqt_devinfo

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

Hi Olivier,

On Mon, 24 Mar 2025 at 19:58, OL <o....@lu...> wrote:

> Looking at toshyp documentation and NVDI 4 english documentation, look
> like there is a small error, third parameter, shoudl not be dev_exist
> but dev_open,

I guess you meant *gemlib* and NVDI4 documentation? TOS.HYP correctly lists
it as dev_open, it is gemlib which goes an extra mile and slightly changed
the function signature AFAICS.


> so the return if driver is found could not be always 1 but
> could be 0 link to vdi_ptsout[0], this value is here the return value
> while documentation said void, return value could be interesting but not
> this one, better I think should be the actual value in dev_exist if we
> want have one (usefull for vqt_devinfo). If something is changed in
> vq_devinfo, warning it impact vqt_devinfo that call it.
>
I'm not sure I completely follow, I guess you are referring to gemlib here?
Maybe propose a patch if you would like to have something changed there?

vqt_devinfo, there is not same number of parameters between gemlib
> and toshyp

This again seems like some kind of oddity in gemlib.

Since you are way more experienced in GEM programming than I am, I can only
repeat my request for providing a patch. :-)

-- 
http://mikro.atari.org

Re: [Freemint-discuss] Weird problem with MiNTnet

[Björn B. <bj...@cu...>]

That would have been a packet fragmentation issue. Some node in the 
chain would have an MTU <1500. Had to troubleshoot a zillion of those 
with PPPoE in the zero years, before somewhat intelligent routers came 
to people's homes.

Peace,

       Björn Buske
-->bj...@cu... <--

On 20.04.25 20:03, Peter Slegg via Freemint-discuss wrote:
> The weirdest thing I ever had was caused by the packet size. I 
> couldn't send anything over a certain size.
>
> Once the packet size was changed everything worked normally.
>
> Peter
> On 20 Apr 2025, at 17:37, "Miro Kropáček" <mir...@gm...> 
> wrote:
>
>     I can only speculate that something changed on your router, i.e.
>     it suddenly became sensitive to some of MiNT-Net's settings.
>     Really odd.
>
>     On Thu, 17 Apr 2025 at 21:33, 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
>
>
>
>     -- 
>     http://mikro.atari.org
>
>     ------------------------------------------------------------------------
>
>     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

Re: [Freemint-discuss] Weird problem with MiNTnet

[Peter S. <ps...@sc...>]

The weirdest thing I ever had was caused by the packet size. I couldn't send anything over a certain size. 

Once the packet size was changed everything worked normally.

⁣Peter​

On 20 Apr 2025, 17:37, at 17:37, "Miro Kropáček" <mir...@gm...> wrote:
>I can only speculate that something changed on your router, i.e. it
>suddenly became sensitive to some of MiNT-Net's settings. Really odd.
>
>On Thu, 17 Apr 2025 at 21:33, 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
>>
>
>
>-- 
>http://mikro.atari.org
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] Weird problem with MiNTnet

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

I can only speculate that something changed on your router, i.e. it
suddenly became sensitive to some of MiNT-Net's settings. Really odd.

On Thu, 17 Apr 2025 at 21:33, 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
>


-- 
http://mikro.atari.org

[Freemint-discuss] Weird problem with MiNTnet

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

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] vq_devinfo and vqt_devinfo

[OL <o....@lu...>]

Hello


Looking at toshyp documentation and NVDI 4 english documentation, look 
like there is a small error, third parameter, shoudl not be dev_exist 
but dev_open, so the return if driver is found could not be always 1 but 
could be 0 link to vdi_ptsout[0], this value is here the return value 
while documentation said void, return value could be interesting but not 
this one, better I think should be the actual value in dev_exist if we 
want have one (usefull for vqt_devinfo). If something is changed in 
vq_devinfo, warning it impact vqt_devinfo that call it.


vqt_devinfo, there is not same number of parameters between gemlib and 
toshyp


Olivier