freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

On Mittwoch, 27. August 2025 15:52:48 CEST Peter Slegg wrote:
> BubbleGem app never worked reliably for me.

Then it would be better to fix that. Sources of it are available at https://
github.com/thmuch/bubblegem

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

I think I requested it. To me it feels like an environment service that can be used by any app.

BubbleGem app never worked reliably for me.

⁣Peter​

On 27 Aug 2025, 13:46, at 13:46, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:
>PS.: most of that other "unrelated stuff" also had caused problems, and
>was 
>already reverted.
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

PS.: most of that other "unrelated stuff" also had caused problems, and was 
already reverted.

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

On Mittwoch, 27. August 2025 13:16:22 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> I tend to agree, this doesn't belong in XaAES itself and IMO it can safely
> be removed

I agree to that, too. What can be done in userspace, should be done in 
userspace, not inside AES.

Most of this seems to be added by https://github.com/freemint/freemint/commit/
6d5af713d62619a8b7fb6b027f8395eb40accf5e (along with some unrelated changes)

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

Yes, this is what I do and it works with the actual BubbleGEM application. But it does not work when sending the message to appl_find("BUBBLE  ") when using XaAES' bubble implementation.

Jo Even


On Wed, 27 Aug 2025 08:59:13 +0000, "Jean-François Lemaire" <jfl...@po...> wrote:

>> On 27/08/2025 10:37, Jo Even Skarstein via Freemint-discuss wrote:
>>
>> > - Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner of the window the mouse currently hovers above.
>> > - BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES puts the apid of the owner of the window here.
>> > - appl_find("BUBBLE ") returns apid 4 if no actual "BUBBLE " application is running. However, sending BUBBLEGEM_SHOW messages to this apid does not do anything.
>> >
>> > In short, I could not figure out how to get XaAES to actually show a bubble.
>>
>> Here's how I've been doing it, and it always worked for me. Hope it'll help.
>>
>> if ((id = appl_find("BUBBLE ")) != -1)
>> {
>> msg[0] = BUBBLEGEM_SHOW;
>> msg[1] = _AESapid;
>> msg[2] = 0;
>> msg[3] = xpos;
>> msg[4] = ypos;
>> msg[5] = (short)(((int)bubbles->p[idx] >> 16) & 0x0000ffffL);
>> msg[6] = (short)(( int)bubbles->p[idx] & 0x0000ffffL);
>> msg[7] = 0;
>> appl_write(id, 16, msg);
>> }
>>
>> Cheers,
>> JFL
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

I tend to agree, this doesn't belong in XaAES itself and IMO it can safely be removed. But if it stays then it should work. Which maybe it does, and I just don't understand how to use/set it up. Unfortunately I don't have time (well, that's not strictly true, but that would mean less time spent on other Atari stuff) to do much testing, not really motivated either because I don't use BubbleGEM.

Jo Even


On Wed, 27 Aug 2025 10:44:20 +0200, "Miro Kropáček" <mir...@gm...> wrote:

>> I haven't been a fan of this feature / integration, it comes from Helmut's
>> era. I do remember seeing it in action, though. So maybe as the first step,
>> maybe try some older FreeMiNT release(s) ?
>>
>> On Wed, 27 Aug 2025 at 10:37, Jo Even Skarstein via Freemint-discuss <
>> fre...@li...> wrote:
>>
>> > How is this supposed to work? While debugging some AV-stuff I noticed that
>> > my application was sent BUBBLEGEM_REQUEST messages even though BubbleGEM
>> > was not installed. Turned out that I had enabled the XaAES built-in
>> > BubbleGEM replacement by mistake ages ago. But then it struck me - I
>> > haven't seen any bubbles in any applications. So I looked into it a bit
>> > closer.
>> >
>> > - Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner of
>> > the window the mouse currently hovers above.
>> > - BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES puts
>> > the apid of the owner of the window here.
>> > - appl_find("BUBBLE ") returns apid 4 if no actual "BUBBLE " application
>> > is running. However, sending BUBBLEGEM_SHOW messages to this apid does not
>> > do anything.
>> >
>> > In short, I could not figure out how to get XaAES to actually show a
>> > bubble.
>> >
>> > 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] XaAES' integrated BubbleGEM

[Jean-François L. <jfl...@po...>]

On 27/08/2025 10:37, Jo Even Skarstein via Freemint-discuss wrote:

> - Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner of the window the mouse currently hovers above.
> - BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES puts the apid of the owner of the window here.
> - appl_find("BUBBLE  ") returns apid 4 if no actual "BUBBLE  " application is running. However, sending BUBBLEGEM_SHOW messages to this apid does not do anything.
> 
> In short, I could not figure out how to get XaAES to actually show a bubble.

Here's how I've been doing it, and it always worked for me. Hope it'll help.

if ((id = appl_find("BUBBLE  ")) != -1)
{
     msg[0] = BUBBLEGEM_SHOW;
     msg[1] = _AESapid;
     msg[2] = 0;
     msg[3] = xpos;
     msg[4] = ypos;
     msg[5] = (short)(((int)bubbles->p[idx] >> 16) & 0x0000ffffL);
     msg[6] = (short)(( int)bubbles->p[idx] & 0x0000ffffL);
     msg[7] = 0;
     appl_write(id, 16, msg);
}

Cheers,
JFL

Re: [Freemint-discuss] XaAES' integrated BubbleGEM

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

I haven't been a fan of this feature / integration, it comes from Helmut's
era. I do remember seeing it in action, though. So maybe as the first step,
maybe try some older FreeMiNT release(s) ?

On Wed, 27 Aug 2025 at 10:37, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> How is this supposed to work? While debugging some AV-stuff I noticed that
> my application was sent BUBBLEGEM_REQUEST messages even though BubbleGEM
> was not installed. Turned out that I had enabled the XaAES built-in
> BubbleGEM replacement by mistake ages ago. But then it struck me - I
> haven't seen any bubbles in any applications. So I looked into it a bit
> closer.
>
> - Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner of
> the window the mouse currently hovers above.
> - BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES puts
> the apid of the owner of the window here.
> - appl_find("BUBBLE  ") returns apid 4 if no actual "BUBBLE  " application
> is running. However, sending BUBBLEGEM_SHOW messages to this apid does not
> do anything.
>
> In short, I could not figure out how to get XaAES to actually show a
> bubble.
>
> Jo Even
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
http://mikro.atari.org

[Freemint-discuss] XaAES' integrated BubbleGEM

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

How is this supposed to work? While debugging some AV-stuff I noticed that my application was sent BUBBLEGEM_REQUEST messages even though BubbleGEM was not installed. Turned out that I had enabled the XaAES built-in BubbleGEM replacement by mistake ages ago. But then it struck me - I haven't seen any bubbles in any applications. So I looked into it a bit closer.

- Like BubbleGEM, XaAES sends BUBBLEGEM_REQUEST messages to the owner of the window the mouse currently hovers above.
- BubbleGEM put's it's own (the BubbleGEM "server") in msg[1], XaAES puts the apid of the owner of the window here.
- appl_find("BUBBLE  ") returns apid 4 if no actual "BUBBLE  " application is running. However, sending BUBBLEGEM_SHOW messages to this apid does not do anything.

In short, I could not figure out how to get XaAES to actually show a bubble.

Jo Even

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

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

On Sun, 24 Aug 2025 at 22:08, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> Have updated to the latest build on my Falcon, will test on the Milan
> later ("later" as in "maybe this year").
>
Haha, it took me about 8 months to take a look, so no worries. All I can
say is that I have had an absolute blast this weekend playing with
NetUSBee, ASIX, PicoWifi and Svethlana. With that huge pile of software
layers you'd expect that I saw at least some crash or freeze but nope,
nothing!

-- 
http://mikro.atari.org

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

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

This is great news :) I can finally set the fastboot-flag on mint.prg again :D Have updated to the latest build on my Falcon, will test on the Milan later ("later" as in "maybe this year").

Jo Even



On Sat, 23 Aug 2025 01:07:22 +0200, "Miro Kropáček" <mir...@gm...> wrote:

>> This took some time to track down but it should be fixed now:
>> https://github.com/freemint/freemint/commit/a7befbe369f4560020a0fd884bd53c6acf545fd2
>> .
>>
>> Introduced after FreeMiNT 1.18 release and worked totally by chance even
>> with clear memory (route_get() got 0x00000000 there which was interpreted
>> as any IP address while 0x55555555 made it crash sooner or later).
>>
>> Interestingly, after this fix I see following lines in the log:
>>
>> pid 5 (aesthred): if_send(lo): >= HWTYPE_NONE
>> pid 5 (aesthred): route_get: daddr = 0xC0A80002
>> pid 5 (aesthred): route_get: try: mask=0xFFFFFFFF daddr=0xC0A80002
>> net=0xC0A80002
>> *pid 5 (aesthred): igmp_input: bad checksum from 0xC0A80002 8 0xC0A80002*
>>
>> Not sure how or why, it could be some bug in Alan's IGMP implementation.
>> Seems harmless (as it's related to the localhost routing) but perhaps
>> should be investigated at some point.
>>
>> Btw the reason why the crashes happened at various places (gluestik, bash,
>> xaaes, ...) is that this code was executed from FreeMiNT's timer
>> (scheduler), i.e. within an interrupt. Basically igmp_tmr -> igmp_timeout
>> -> igmp_send -> ip_send. Also, sometimes the kernel was able to recover
>> from the first (and following) crashes and let the system boot as far as
>> the desktop.
>>
>> On Wed, 20 Aug 2025 at 00:29, Miro Kropáček wrote:
>>
>> > A bit of progress on this one. I have noticed that the crash occurs just
>> > after allocating 32 KiB of (kernel) memory and that happens only at one
>> > place:
>> > https://github.com/freemint/freemint/blob/244fa78f65e823ce540ee70b42e994d60d2fed42/sys/sockets/buf.c#L69C17-L69C31.
>> > And indeed, when adding
>> >
>> > memset(new, 0, BUF_BLOCK_SIZE);
>> >
>> > just after the kmalloc(), the crashes are gone (still with Jo Even's
>> > memset.prg).
>> >
>> > However, it's not so simple. When replacing the memset with:
>> >
>> > new->dstart = NULL;
>> > new->dend = NULL;
>> > new->next = NULL;
>> > new->prev = NULL;
>> > new->link3 = NULL;
>> > new->info = 0;
>> >
>> > i.e. basically zeroing out all other elements in
>> > https://github.com/freemint/freemint/blob/master/sys/sockets/buf.h#L17,
>> > the crash still occurs. So the uninitialised content is actually inside
>> > "data", used by buf_alloc, buf_reserve and buf_clone, basically just
>> > forwarding the problem one layer higher.
>> >
>> > So further investigation is still needed.
>> >
>>
>>
>> --
>> http://mikro.atari.org >> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

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

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

This took some time to track down but it should be fixed now:
https://github.com/freemint/freemint/commit/a7befbe369f4560020a0fd884bd53c6acf545fd2
.

Introduced after FreeMiNT 1.18 release and worked totally by chance even
with clear memory (route_get() got 0x00000000 there which was interpreted
as any IP address while 0x55555555 made it crash sooner or later).

Interestingly, after this fix I see following lines in the log:

pid   5 (aesthred): if_send(lo): >= HWTYPE_NONE
pid   5 (aesthred): route_get: daddr = 0xC0A80002
pid   5 (aesthred): route_get: try: mask=0xFFFFFFFF daddr=0xC0A80002
net=0xC0A80002
*pid   5 (aesthred): igmp_input: bad checksum from 0xC0A80002 8 0xC0A80002*

Not sure how or why, it could be some bug in Alan's IGMP implementation.
Seems harmless (as it's related to the localhost routing) but perhaps
should be investigated at some point.

Btw the reason why the crashes happened at various places (gluestik, bash,
xaaes, ...) is that this code was executed from FreeMiNT's timer
(scheduler), i.e. within an interrupt. Basically igmp_tmr -> igmp_timeout
-> igmp_send -> ip_send. Also, sometimes the kernel was able to recover
from the first (and following) crashes and let the system boot as far as
the desktop.

On Wed, 20 Aug 2025 at 00:29, Miro Kropáček <mir...@gm...> wrote:

> A bit of progress on this one. I have noticed that the crash occurs just
> after allocating 32 KiB of (kernel) memory and that happens only at one
> place:
> https://github.com/freemint/freemint/blob/244fa78f65e823ce540ee70b42e994d60d2fed42/sys/sockets/buf.c#L69C17-L69C31.
> And indeed, when adding
>
> memset(new, 0, BUF_BLOCK_SIZE);
>
> just after the kmalloc(), the crashes are gone (still with Jo Even's
> memset.prg).
>
> However, it's not so simple. When replacing the memset with:
>
> new->dstart = NULL;
> new->dend = NULL;
> new->next = NULL;
> new->prev = NULL;
> new->link3 = NULL;
> new->info = 0;
>
> i.e. basically zeroing out all other elements in
> https://github.com/freemint/freemint/blob/master/sys/sockets/buf.h#L17,
> the crash still occurs. So the uninitialised content is actually inside
> "data", used by buf_alloc, buf_reserve and buf_clone, basically just
> forwarding the problem one layer higher.
>
> So further investigation is still needed.
>


-- 
http://mikro.atari.org

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

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

A bit of progress on this one. I have noticed that the crash occurs just
after allocating 32 KiB of (kernel) memory and that happens only at one
place:
https://github.com/freemint/freemint/blob/244fa78f65e823ce540ee70b42e994d60d2fed42/sys/sockets/buf.c#L69C17-L69C31.
And indeed, when adding

memset(new, 0, BUF_BLOCK_SIZE);

just after the kmalloc(), the crashes are gone (still with Jo Even's
memset.prg).

However, it's not so simple. When replacing the memset with:

new->dstart = NULL;
new->dend = NULL;
new->next = NULL;
new->prev = NULL;
new->link3 = NULL;
new->info = 0;

i.e. basically zeroing out all other elements in
https://github.com/freemint/freemint/blob/master/sys/sockets/buf.h#L17, the
crash still occurs. So the uninitialised content is actually inside "data",
used by buf_alloc, buf_reserve and buf_clone, basically just forwarding the
problem one layer higher.

So further investigation is still needed.

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

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

On Tue, 19 Aug 2025 at 22:10, Eero Tamminen <oa...@he...> wrote:

> (Alternative would be just writing all free physical system memory with
> specific bit pattern before any allocations are done by the code in
> question, instead of allocator doing that per-allocation.)
>
That's exactly what has been done.

-- 
http://mikro.atari.org

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

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

Hi,

On 19.8.2025 22.53, Miro Kropáček wrote:
> On Thu, 3 Jul 2025 at 14:12, Miro Kropáček <mir...@gm...> wrote:
> 
>> I'll try this at some point, ideally in Hatari or Aranym.
>>
> Having already a working setup with network on my Falcon, in the end I have
> tried this on CT60+Svethlana. It's more interesting than it had seemed.
> 
> First I booted my setup with Jo Even's memset.prg just before mint.prg and
> ... all good. So I was about to reply that nope, sorry, not happening here.
> Then I rebooted from Teradesk and what do I see: a memory violation in
> gluestik. More reboots => more memory violations at random places (but
> always after mint.cnf which launches /bin/bash + ifconfig/route commands).
> 
> Powered the computer off, booted again: all good. Rebooted: memory
> violations again.
> 
> So it isn't just a straight-forward case of an uninitialised memory. It
> seems like FreeMiNT is leaving something behind (see also mentioned
> https://github.com/freemint/freemint/issues/109) and *that* relies on that
> piece of released memory. Unfortunately, I couldn't see any 0x55 anywhere
> in the crash messages.

Does MiNT allocator have support for "poisoning" all the allocations 
i.e. returning allocations that are set to some specific bit pattern 
(instead of being potentially zeroed, especially first time after boot)?

Or was 0x55 reference to such a thing?

(Alternative would be just writing all free physical system memory with 
specific bit pattern before any allocations are done by the code in 
question, instead of allocator doing that per-allocation.)


> Since this requires a working network driver, Aranym was the next logical
> option and surprisingly, here it kills XaAES or gluestik on the first boot,
> even when choosing "Cold boot" in Aranym's menu. Hmm.
> 
> I'll see how much time I get to look into this but the idea of fixing #273
> and #109 in one go (not to mention all the frustrated users suffering from
> this) makes me very happy.


	- Eero

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

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

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

> I'll try this at some point, ideally in Hatari or Aranym.
>
Having already a working setup with network on my Falcon, in the end I have
tried this on CT60+Svethlana. It's more interesting than it had seemed.

First I booted my setup with Jo Even's memset.prg just before mint.prg and
... all good. So I was about to reply that nope, sorry, not happening here.
Then I rebooted from Teradesk and what do I see: a memory violation in
gluestik. More reboots => more memory violations at random places (but
always after mint.cnf which launches /bin/bash + ifconfig/route commands).

Powered the computer off, booted again: all good. Rebooted: memory
violations again.

So it isn't just a straight-forward case of an uninitialised memory. It
seems like FreeMiNT is leaving something behind (see also mentioned
https://github.com/freemint/freemint/issues/109) and *that* relies on that
piece of released memory. Unfortunately, I couldn't see any 0x55 anywhere
in the crash messages.

Since this requires a working network driver, Aranym was the next logical
option and surprisingly, here it kills XaAES or gluestik on the first boot,
even when choosing "Cold boot" in Aranym's menu. Hmm.

I'll see how much time I get to look into this but the idea of fixing #273
and #109 in one go (not to mention all the frustrated users suffering from
this) makes me very happy.

-- 
http://mikro.atari.org

Re: [Freemint-discuss] GPT-OSS Freemint Questions

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

On 8/17/25 6:41 PM, Rob M wrote:
> IMark, what AI model?
>
> It really depends on the model. Using Gemini 2.5 Pro and Claude are 
> different beasts. I've used my Claude usage and need to wait 2 more 
> hours to ask. But, Here is asking your first question to Gemini.
> With my new Samsung s25, I received 6 free months of Gemini Pro. You 
> can give it some knowledge by uploading files and telling it to add it 
> to its knowledge(for that chat only), like the Compendium pdf.
>
> Gemini 2.5 Pro: (I did not feed it any documents)
> What are the deficiencies in the freemint operating system?
>
> Gemini:
>
*snip*

That's pretty good!  I guess I just need to learn more about the models 
and how they are best used.  I do like the idea of feeding it documents 
and asking it to interpret it.  I think that is a good use case that it 
can probably do pretty well right now.

Thanks,
Mark

Re: [Freemint-discuss] Weird problem with MiNTnet

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

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

Re: [Freemint-discuss] GPT-OSS Freemint Questions

[Rob M <rma...@gm...>]

IMark, what AI model?

It really depends on the model. Using Gemini 2.5 Pro and Claude are
different beasts. I've used my Claude usage and need to wait 2 more hours
to ask. But, Here is asking your first question to Gemini.
With my new Samsung s25, I received 6 free months of Gemini Pro. You can
give it some knowledge by uploading files and telling it to add it to
its knowledge(for that chat only), like the Compendium pdf.

Gemini 2.5 Pro: (I did not feed it any documents)
What are the deficiencies in the freemint operating system?

Gemini:

FreeMiNT, while a powerful and impressive multitasking operating system for
the Atari platform, has several deficiencies, primarily stemming from its
nature as a volunteer-driven project for vintage hardware. Its limitations
are best understood in the context of modern computing standards.
------------------------------

Hardware Support and Performance

A major deficiency of FreeMiNT is its limited support for modern hardware.
While it excels on original Atari hardware and clones like the FireBee and
Hades, it lacks drivers and support for contemporary peripherals and
architectures.

   -

   *Limited Modern Hardware Drivers*: There is virtually no support for
   modern graphics cards, USB 3.0/4.0 devices, Wi-Fi 6, or NVMe storage.
   Interfacing with modern hardware often requires specialized, often
   custom-built, adapters which may have limited or experimental driver
   support.
   -

   *CPU Architecture*: FreeMiNT is fundamentally tied to the Motorola 680x0
   architecture. While it supports ColdFire processors, it cannot run on
   modern x86-64 or ARM CPUs, completely separating it from the mainstream
   hardware market.
   -

   *Performance on Emulators*: While FreeMiNT runs well on emulators like
   Hatari or ARAnyM, performance can be bottlenecked by the emulation layer
   itself, and it doesn't always take full advantage of the host machine's
   power in the way a modern OS would.

------------------------------

Software Ecosystem and Compatibility

The software available for FreeMiNT is a fraction of what's available for
modern operating systems, and compatibility with older Atari software can
be complex.

   -

   *Small Application Pool*: The number of native, 32-bit applications that
   can take full advantage of FreeMiNT's features is small. While you have
   essential tools like the *Highwire web browser* and various programming
   tools, the selection pales in comparison to Windows, macOS, or even
   mainstream Linux distributions.
   -

   *TOS/GEM Compatibility*: While FreeMiNT aims for compatibility with the
   original Atari TOS, it's not perfect. Older applications, especially games
   and demos that bypass the OS to directly access the hardware (often called
   "banging the hardware"), frequently fail to run or exhibit glitches under
   FreeMiNT's multitasking kernel. Running such software often requires
   booting into a pure TOS environment.
   -

   *Lack of Modern Software*: You won't find modern versions of popular
   applications like Adobe Photoshop, Microsoft Office, or current web
   browsers like Chrome or Firefox. Projects like the Highwire browser are
   impressive feats but lag significantly behind modern standards in terms of
   CSS3, HTML5, and JavaScript performance.
   -

   *Complex Dependencies*: Getting some modern open-source software to
   compile and run can be a significant challenge, often requiring manual
   patching, a deep understanding of the system's libraries (like MiNTLib),
   and dealing with various dependency issues.

------------------------------

User Experience and Modernity

The user experience can be challenging for those accustomed to modern,
plug-and-play operating systems.

   -

   *Steep Learning Curve*: Configuring FreeMiNT is a hands-on, technical
   process. It requires manually editing text files (like MINT.CNF) to
   configure drivers, network settings, and system parameters. There is no
   central, graphical control panel for most deep system settings.
   -

   *Inconsistent User Interface*: The graphical environment is provided by
   AES (Application Environment Services) front-ends like N.AES or MyAES,
   layered on top of a desktop like Teradesk or Thing. This can lead to a less
   integrated and sometimes inconsistent look and feel compared to a modern
   desktop environment where the kernel and UI are more tightly coupled.
   -

   *Limited Networking Features*: While its TCP/IP stack (based on glibc)
   is robust for its era, it lacks the sophisticated, out-of-the-box
   networking features of modern systems, such as easy Wi-Fi network
   management or built-in VPN support. Setting up a network connection is a
   manual process.

------------------------------

Development and Community

The project's forward momentum is entirely dependent on a small, dedicated
community of volunteer developers.

   -

   *Slow Development Pace*: As a passion project, development can be slow
   and sporadic. Updates and bug fixes depend on the limited free time and
   motivation of its contributors.
   -

   *Niche Community*: The user and developer base is very small. While the
   community is knowledgeable and often helpful, finding solutions to obscure
   problems can be difficult, and documentation can sometimes be outdated or
   incomplete. This contrasts sharply with the vast resources available for
   mainstream operating systems.



On Sun, Aug 17, 2025 at 3:30 PM Mark Duckworth via Freemint-discuss <
fre...@li...> wrote:

> Hello all,
>
> Every now and then I try out the latest "AI" stuff.   I know people use
> this stuff to solve straightforward problems successfully but I am most
> interested in intelligence (or the emulation thereof) and reasoning.  I
> find that asking it questions about freemint is a really good way to go
> about it.  Here is the current state of the art:  (it's not there but
> closer!  I especially like how nearly everything at the bottom is the
> exact opposite of truth)
>
>
>  >>> What are the deficiencies in the freemint operating system?
> Thinking...
> The user asks: "What are the deficiencies in the freemint operating
> system?" We need to explain deficiencies. FreedMint is a DOS-like OS for
> Atari ST,
> built on OS-9? Actually FreeMint is a free and open-source operating
> system for Atari 8-bit computers? Wait: Let's recall. FreeMint is a free
> OS for
> Atari 8-bit computers based on the 6502, derived from the free MINT OS.
> Or there is "Mint" as in "Mint (Macintosh)". But "freemint" is a 2007
> open source
> OS for the Atari ST and compatible with OS-9? Let's check. Actually
> FreeMint is an open-source OS for Atari ST, based on the original MINT
> OS. It's
> written in C and assembly, runs on the Motorola 68000. It offers a
> command line shell, a file manager, etc. It is fairly minimal.
> Deficiencies: Not fully
> compatible with the original MINT, lacking some drivers, poor
> documentation, limited file system support, limited memory management,
> limited
> multitasking, no GUI, no networking, no modern utilities. Might have
> memory leaks, unimplemented features. It also hasn't been actively
> maintained. Also
> lacks hardware support for modern peripherals. Not enough test coverage.
>
> We need to answer thoroughly. Provide list of deficiencies: limited
> hardware support (no floppy, no IDE, no SCSI), incomplete OS-9
> compatibility, lack of
> user-friendly features, missing libraries, missing command line
> utilities, missing documentation, limited memory management, no process
> isolation, no
> dynamic linking, no robust file system, no GUI. Provide suggestions.
>
> Also mention that MINT originally had a GUI, but FreeMint is
> command-line only. Might be missing multitasking, though FreeMint is
> single-tasking. Provide
> a comparative table.
>
> Let's produce an answer. Use bullet points, sections: Hardware,
> Software, Development, Community, Performance, etc. Provide references
> maybe.
>
> Let's write.
> ...done thinking.
>
> ### 1.  Quick‑look:  What *FreeMint* actually delivers
>
> | Feature | Status in FreeMint | Why it matters |
> |---------|--------------------|----------------|
> | **Command‑line shell** | ✅ | Core of the OS |
> | **File manager** | ✅ | Minimal, no GUI |
> | **Disk subsystem** | ✅ (MSDOS‑style) | Supports FAT, HFS, and a few
> custom filesystems |
> | **Multitasking** | ❌ (single‑tasking) | No pre‑emptive scheduling |
> | **Memory management** | ❌ (no paging, no segmentation) | No virtual
> memory, all apps share a flat address space |
> | **GUI** | ❌ | Only a command‑line interface |
> | **Networking** | ❌ | No TCP/IP stack or sockets |
> | **Graphics** | ❌ | No high‑level graphics libraries |
> | **Hardware drivers** | ⚠ Partial | Very limited to the original ST
> peripherals |
> | **Development tools** | ❌ | Minimal C compiler, no IDE integration |
> | **Documentation** | ❌ | Fragmented, no central manual |
> | **Community & Support** | ❌ | Small, no active maintainer |
> | **Portability** | ⚠ | Works only on 68000 (and a few clones) |
> | **Security** | ❌ | No user accounts, no isolation |
>
> Below is a deeper dive into the **deficiencies** that keep FreeMint from
> being a full‑featured OS today.
>
> ---
>
> ## 2.  Hardware‑Side Deficiencies
>
> | Problem | Detail | Impact |
> |---------|--------|--------|
> | **Floppy support is incomplete** | Only the ST‑type 5¼″/3½″ drives are
> supported; no support for higher‑density floppies, or non‑ST drive
> formats. |
> Many modern users still need to plug in a floppy, and the current driver
> is buggy on newer clones. |
> | **IDE / IDE‑like drivers missing** | No real‑time support for IDE or
> ATAPI; the OS can read/write disks via the ST’s legacy disk controller
> but *not*
> via modern IDE/ATAPI chips. | Users cannot boot from or store files on
> modern hard‑disk controllers. |
> | **SCSI / CD‑ROM not supported** | No driver stack, no device class, no
> SCSI‑2 implementation. | Cannot use the most common legacy peripheral
> for Atari
> ST. |
> | **No support for USB / PCI / PCI‑e** | Modern Atari ST clones (like
> the *Atari ST PCI*) have USB, Ethernet, PCI‑e cards, but FreeMint simply
> ignores
> them. | Impossible to connect a mouse, keyboard, network card, or even a
> second monitor. |
> | **Limited I/O ports** | Only the ST’s serial, printer, and joystick
> ports are handled. | Many older peripherals (e.g., SCSI hard‑drives,
> Modems) remain
> inaccessible. |
> | **No video‑card abstraction** | The graphics subsystem is a thin
> wrapper around `Move`/`Set` calls; no hardware acceleration. |
> High‑resolution
> graphics and 3‑D are impossible without writing raw assembler. |
>
>  > **Bottom line:**  FreeMint is a *legacy‑only* OS – it knows how to
> talk to the ST’s original ISA‑style hardware, but not to the vast
> majority of
> peripherals that a user might want today.
>
> ---
>
> ## 3.  Software‑Side Deficiencies
>
> ### 3.1  No Multitasking / Poor Scheduler
>
> * The original MINT had cooperative multitasking with a *process stack*
> and *interrupt‑driven tasks*.
> * FreeMint **runs everything in a single address space** – if a program
> crashes, the whole OS dies.
> * There is **no pre‑emptive scheduler**; you must manually `kill` or
> `reboot` a program that misbehaves.
>
> **Why it matters**
> In 2024, even “simple” hobby‑operating systems (e.g., RISC‑OS, AROS, or
> even the minimal Linux kernels on older hardware) support at least *basic*
> pre‑emptive multitasking. FreeMint’s lack of this feature limits its
> usability for anything beyond very small command‑line tools.
>
> ### 3.2  No Virtual Memory / Paging
>
> * FreeMint’s memory model is *flat*: the CPU’s 32 MiB address space is
> shared by everything.
> * No segmentation or paging → no *memory protection* → no way to isolate
> a runaway process.
> * Applications must be compiled with `-m68000` and cannot rely on
> OS‑provided heap management.
>
> **Impact**
> Large programs or long‑running services cannot safely coexist; a single
> badly written program can corrupt the entire system or exhaust the limited
> 512 KiB/1 MiB RAM available on older ST clones.
>
> ### 3.3  Limited File‑System & I/O
>
> | Filesystem | Support Level | Missing Features |
> |------------|---------------|------------------|
> | **FAT12/16/32** | ✅ (basic read/write) | No 64‑bit timestamps, no long
> filenames on FAT32 |
> | **HFS** | ⚠ (read‑only) | Write support is buggy; only HFS‑Plus v1.0 |
> | **MINT custom FS** | ❌ | No implementation at all – original “MINTFS”
> is missing |
> | **Ext3/Ext4, Btrfs, etc.** | ❌ | No Linux‑style file systems |
> | **Encryption** | ❌ | No disk encryption or secure erase |
>
>  > **Result:**  Most of FreeMint’s filesystem layer works for *very*
> simple storage tasks, but it cannot act as a drop‑in replacement for a
> modern OS that
> expects ext4, NTFS, or even a sane FAT32 implementation.
>
> ### 3.4  No Networking Stack
>
> * No TCP/IP, no UDP, no POSIX sockets.
> * The only network interface FreeMint can talk to is a **very basic
> serial “net”** that was a part of the original MINT demo.
> * No ARP, no DHCP, no PPP.
>
> **Consequence**
> FreeMint cannot run any modern networking applications (e.g., web
> browsers, SSH clients, etc.). It also cannot act as a host for any
> network services
> (e.g., FTP, HTTP, or even simple telnet).
>
> ---
>
> ## 3.  Software‑Side Deficiencies
>
> ### 3.1  Library / API Deficiencies
>
> | Library | Status | What you’re missing |
> |---------|--------|---------------------|
> | **C standard library** | Minimal (`libc`) | No `stdio.h` (just basic
> `getc`/`putc`), no `stdlib.h`, no dynamic memory allocation beyond a
> single static
> heap |
> | **POSIX‑like API** | ❌ | No `fork`, `exec`, `signal`, `select`, `mmap` |
> | **Graphics & Sound** | ❌ | Only low‑level blitter calls; no SDL‑style
> abstraction |
> | **GUI toolkit** | ❌ | The original MINT used a light windowing system;
> FreeMint has none. |
>
>  > **Result:**  Writing a real application on FreeMint is painful. Even
> a simple “Hello, world!” requires you to dig through the C source,
> compile with a
> hand‑rolled 68000 compiler, and then link by hand.
>
> ### 3.2  Toolchain & Build System
>
> * The official toolchain is an old **Turbo C‑like compiler** that
> targets 68000 only.
> * No `make` or `CMake` integration in the upstream project.
> * The build system is *fragile* – you often have to patch the makefiles
> to get anything to compile on a modern GCC toolchain.
> * No support for cross‑compilation to other CPUs (e.g., the 68020 or
> 68030).
>
> **Impact**
> Developers must resort to third‑party compilers or write their own
> assembler/linker scripts. This makes community contribution very difficult.
>
> ### 3.3  Documentation & Support
>
> | Issue | What it means | Current state |
> |-------|---------------|---------------|
> | **Fragmented docs** | The official “Manual” is split across the source
> tree (`doc/`, `src/`, etc.) | Hard to find a single reference |
> | **No “user manual”** | No quick‑start guide or FAQ | Newcomers are lost |
> | **No online resources** | The original project website (freemint.com)
> has been offline for years | No up‑to‑date FAQ or forum |
> | **No active maintainer** | The last commit was 2015‑2016 | Security
> bugs never get patched, features never added |
>
> ---
>
> ## 4.  Performance & Stability
>
> | Aspect | Issue | Consequence |
> |--------|-------|-------------|
> | **No CPU affinity / SMP support** | The OS only runs on a single 68000
> core (even if you have a 68030/68040) | Cannot make use of multi‑core
> systems |
> | **No cache / MMU configuration** | The 68000’s cache is never properly
> set up (except in the original MINT) | Slow I/O and sub‑optimal memory
> usage |
> | **Memory leaks** | Several of the higher‑level tools (e.g., the file
> manager) leak the heap in long‑running sessions | Eventually crashes
> after a few
> hours of use |
> | **No journaling file system** | FAT writes are performed without a
> journal | File system corruption after power loss |
>
> ---
>
> ## 5.  Real‑world Use‑Case Shortcomings
>
> | Use‑Case | FreeMint’s Capabilities | Deficiency | How it hurts |
> |----------|------------------------|------------|--------------|
> | **Running a desktop environment** | None | No window system, no
> mouse/graphics APIs | Cannot run a GUI program |
> | **Running a network‑based backup** | None | No TCP/IP, no sockets | No
> remote backups or NFS |
> | **Running a real‑time embedded system** | No real‑time scheduler |
> Hard to guarantee latency | Cannot be used in embedded projects |
> | **Running modern 68000 software** | Basic DOS compatibility | Many
> binaries use undocumented 68020 features | Compatibility breakage |
> | **Running a multi‑user system** | No user accounts | No security
> boundaries | Cannot host multiple users safely |
>
> ---
>
> ## 6.  A Comparison Snapshot
>
> | Feature | FreeMint | Original MINT (1988‑1991) | Modern Hobby OS
> (e.g., AROS, Hatari‑OS) |
>
> |---------|----------|---------------------------|----------------------------------------|
> | GUI | ❌ | ✅ (basic windowing) | ✅ (windowing) |
> | Multitasking | ❌ | ✅ (cooperative) | ✅ (pre‑emptive) |
> | Virtual Memory | ❌ | ❌ | ✅ (paging) |
> | Networking | ❌ | ❌ | ✅ (TCP/IP) |
> | File System | ❌ (limited) | ✅ (MSDOS‑style + others) | ✅ (FAT, HFS,
> ext, etc.) |
> | Development Tools | ❌ | ❌ | ✅ (make, GCC, CMake) |
> | Documentation | ❌ | ✅ | ✅ |
> | Community | ❌ | ❌ | ✅ (active) |
>
> ---
>
> ## 7.  Bottom‑Line Takeaway
>
>  > **FreeMint is a nice little *command‑line* hobby OS that emulates a
> subset of the original Atari ST MINT features, but it falls short on the
> major axes
> that users care about today—multitasking, virtual memory, modern
> file‑system support, networking, and a usable development stack.**
>
> It is *not* a drop‑in replacement for the original MINT, nor is it a
> viable platform for running modern software or building embedded
> solutions. Anyone
> who wants to use the Atari ST platform today would be better served by
> an actively maintained fork (e.g., **AROS** or **Hatari‑OS**), or by
> running a
> fully‑featured emulator (e.g., **Hatari**) that supports the full 68000
> instruction set and modern peripherals.
>
> ---
>
> ## 8.  Possible Paths Forward
>
> If you’re a developer interested in breathing life back into FreeMint,
> consider the following:
>
> 1. **Implement a minimal pre‑emptive scheduler** – even a simple
> round‑robin with time‑outs would mitigate the single‑process crash problem.
> 2. **Add a small paging/virtual‑memory layer** – using the 68030’s MMU
> to provide basic protection.
> 3. **Port the FAT32 driver** to support long filenames, 64‑bit
> timestamps, and journaling.
> 4. **Build a minimal networking stack** – starting with a serial “PPP”
> and then adding TCP/IP.
> 5. **Create a basic GUI toolkit** – or at least provide an abstraction
> over the blitter.
> 6. **Modernize the toolchain** – expose the build process via CMake and
> allow cross‑compilation.
>
>  > **But** the reality is that the cost of doing all that is high, and
> the community around FreeMint simply does not exist to pull it off.
>
> ---
>
> ## 8.1  Suggested Alternatives for 68000 Hobbyists
>
> | Project | What it offers | Why it’s better for a hobbyist |
> |---------|---------------|--------------------------------|
> | **AROS** | Full AROS compatible, multi‑core, networking, GUI |
> Actively maintained, large community |
> | **Hatari‑OS** | Hatari emulator + OS for classic Atari ST | Fully
> featured, easy to set up |
> | **RISC‑OS** | Real‑time, multitasking, GUI | Great for low‑power devices
> |
> | **Hatari OS** | Emulated environment + OS for classic systems | Modern
> hardware support |
>
> If you need a *real* operating system on an Atari ST clone, consider one
> of these instead of FreeMint. They all have modern toolchains,
> documented APIs,
> and a healthy user base.
>
> ---
>
> **TL;DR** – FreeMint is *legacy* in every sense: no multitasking, no
> virtual memory, no networking, limited hardware support, minimal
> documentation, and
> no active community. It can still be useful for teaching basic 68000
> assembly or running ultra‑small command‑line programs, but it is *not* a
> practical
> OS for any real use today.
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

[Freemint-discuss] GPT-OSS Freemint Questions

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

Hello all,

Every now and then I try out the latest "AI" stuff.   I know people use 
this stuff to solve straightforward problems successfully but I am most 
interested in intelligence (or the emulation thereof) and reasoning.  I 
find that asking it questions about freemint is a really good way to go 
about it.  Here is the current state of the art:  (it's not there but 
closer!  I especially like how nearly everything at the bottom is the 
exact opposite of truth)


 >>> What are the deficiencies in the freemint operating system?
Thinking...
The user asks: "What are the deficiencies in the freemint operating 
system?" We need to explain deficiencies. FreedMint is a DOS-like OS for 
Atari ST,
built on OS-9? Actually FreeMint is a free and open-source operating 
system for Atari 8-bit computers? Wait: Let's recall. FreeMint is a free 
OS for
Atari 8-bit computers based on the 6502, derived from the free MINT OS. 
Or there is "Mint" as in "Mint (Macintosh)". But "freemint" is a 2007 
open source
OS for the Atari ST and compatible with OS-9? Let's check. Actually 
FreeMint is an open-source OS for Atari ST, based on the original MINT 
OS. It's
written in C and assembly, runs on the Motorola 68000. It offers a 
command line shell, a file manager, etc. It is fairly minimal. 
Deficiencies: Not fully
compatible with the original MINT, lacking some drivers, poor 
documentation, limited file system support, limited memory management, 
limited
multitasking, no GUI, no networking, no modern utilities. Might have 
memory leaks, unimplemented features. It also hasn't been actively 
maintained. Also
lacks hardware support for modern peripherals. Not enough test coverage.

We need to answer thoroughly. Provide list of deficiencies: limited 
hardware support (no floppy, no IDE, no SCSI), incomplete OS-9 
compatibility, lack of
user-friendly features, missing libraries, missing command line 
utilities, missing documentation, limited memory management, no process 
isolation, no
dynamic linking, no robust file system, no GUI. Provide suggestions.

Also mention that MINT originally had a GUI, but FreeMint is 
command-line only. Might be missing multitasking, though FreeMint is 
single-tasking. Provide
a comparative table.

Let's produce an answer. Use bullet points, sections: Hardware, 
Software, Development, Community, Performance, etc. Provide references 
maybe.

Let's write.
...done thinking.

### 1.  Quick‑look:  What *FreeMint* actually delivers

| Feature | Status in FreeMint | Why it matters |
|---------|--------------------|----------------|
| **Command‑line shell** | ✅ | Core of the OS |
| **File manager** | ✅ | Minimal, no GUI |
| **Disk subsystem** | ✅ (MSDOS‑style) | Supports FAT, HFS, and a few 
custom filesystems |
| **Multitasking** | ❌ (single‑tasking) | No pre‑emptive scheduling |
| **Memory management** | ❌ (no paging, no segmentation) | No virtual 
memory, all apps share a flat address space |
| **GUI** | ❌ | Only a command‑line interface |
| **Networking** | ❌ | No TCP/IP stack or sockets |
| **Graphics** | ❌ | No high‑level graphics libraries |
| **Hardware drivers** | ⚠ Partial | Very limited to the original ST 
peripherals |
| **Development tools** | ❌ | Minimal C compiler, no IDE integration |
| **Documentation** | ❌ | Fragmented, no central manual |
| **Community & Support** | ❌ | Small, no active maintainer |
| **Portability** | ⚠ | Works only on 68000 (and a few clones) |
| **Security** | ❌ | No user accounts, no isolation |

Below is a deeper dive into the **deficiencies** that keep FreeMint from 
being a full‑featured OS today.

---

## 2.  Hardware‑Side Deficiencies

| Problem | Detail | Impact |
|---------|--------|--------|
| **Floppy support is incomplete** | Only the ST‑type 5¼″/3½″ drives are 
supported; no support for higher‑density floppies, or non‑ST drive 
formats. |
Many modern users still need to plug in a floppy, and the current driver 
is buggy on newer clones. |
| **IDE / IDE‑like drivers missing** | No real‑time support for IDE or 
ATAPI; the OS can read/write disks via the ST’s legacy disk controller 
but *not*
via modern IDE/ATAPI chips. | Users cannot boot from or store files on 
modern hard‑disk controllers. |
| **SCSI / CD‑ROM not supported** | No driver stack, no device class, no 
SCSI‑2 implementation. | Cannot use the most common legacy peripheral 
for Atari
ST. |
| **No support for USB / PCI / PCI‑e** | Modern Atari ST clones (like 
the *Atari ST PCI*) have USB, Ethernet, PCI‑e cards, but FreeMint simply 
ignores
them. | Impossible to connect a mouse, keyboard, network card, or even a 
second monitor. |
| **Limited I/O ports** | Only the ST’s serial, printer, and joystick 
ports are handled. | Many older peripherals (e.g., SCSI hard‑drives, 
Modems) remain
inaccessible. |
| **No video‑card abstraction** | The graphics subsystem is a thin 
wrapper around `Move`/`Set` calls; no hardware acceleration. | 
High‑resolution
graphics and 3‑D are impossible without writing raw assembler. |

 > **Bottom line:**  FreeMint is a *legacy‑only* OS – it knows how to 
talk to the ST’s original ISA‑style hardware, but not to the vast 
majority of
peripherals that a user might want today.

---

## 3.  Software‑Side Deficiencies

### 3.1  No Multitasking / Poor Scheduler

* The original MINT had cooperative multitasking with a *process stack* 
and *interrupt‑driven tasks*.
* FreeMint **runs everything in a single address space** – if a program 
crashes, the whole OS dies.
* There is **no pre‑emptive scheduler**; you must manually `kill` or 
`reboot` a program that misbehaves.

**Why it matters**
In 2024, even “simple” hobby‑operating systems (e.g., RISC‑OS, AROS, or 
even the minimal Linux kernels on older hardware) support at least *basic*
pre‑emptive multitasking. FreeMint’s lack of this feature limits its 
usability for anything beyond very small command‑line tools.

### 3.2  No Virtual Memory / Paging

* FreeMint’s memory model is *flat*: the CPU’s 32 MiB address space is 
shared by everything.
* No segmentation or paging → no *memory protection* → no way to isolate 
a runaway process.
* Applications must be compiled with `-m68000` and cannot rely on 
OS‑provided heap management.

**Impact**
Large programs or long‑running services cannot safely coexist; a single 
badly written program can corrupt the entire system or exhaust the limited
512 KiB/1 MiB RAM available on older ST clones.

### 3.3  Limited File‑System & I/O

| Filesystem | Support Level | Missing Features |
|------------|---------------|------------------|
| **FAT12/16/32** | ✅ (basic read/write) | No 64‑bit timestamps, no long 
filenames on FAT32 |
| **HFS** | ⚠ (read‑only) | Write support is buggy; only HFS‑Plus v1.0 |
| **MINT custom FS** | ❌ | No implementation at all – original “MINTFS” 
is missing |
| **Ext3/Ext4, Btrfs, etc.** | ❌ | No Linux‑style file systems |
| **Encryption** | ❌ | No disk encryption or secure erase |

 > **Result:**  Most of FreeMint’s filesystem layer works for *very* 
simple storage tasks, but it cannot act as a drop‑in replacement for a 
modern OS that
expects ext4, NTFS, or even a sane FAT32 implementation.

### 3.4  No Networking Stack

* No TCP/IP, no UDP, no POSIX sockets.
* The only network interface FreeMint can talk to is a **very basic 
serial “net”** that was a part of the original MINT demo.
* No ARP, no DHCP, no PPP.

**Consequence**
FreeMint cannot run any modern networking applications (e.g., web 
browsers, SSH clients, etc.). It also cannot act as a host for any 
network services
(e.g., FTP, HTTP, or even simple telnet).

---

## 3.  Software‑Side Deficiencies

### 3.1  Library / API Deficiencies

| Library | Status | What you’re missing |
|---------|--------|---------------------|
| **C standard library** | Minimal (`libc`) | No `stdio.h` (just basic 
`getc`/`putc`), no `stdlib.h`, no dynamic memory allocation beyond a 
single static
heap |
| **POSIX‑like API** | ❌ | No `fork`, `exec`, `signal`, `select`, `mmap` |
| **Graphics & Sound** | ❌ | Only low‑level blitter calls; no SDL‑style 
abstraction |
| **GUI toolkit** | ❌ | The original MINT used a light windowing system; 
FreeMint has none. |

 > **Result:**  Writing a real application on FreeMint is painful. Even 
a simple “Hello, world!” requires you to dig through the C source, 
compile with a
hand‑rolled 68000 compiler, and then link by hand.

### 3.2  Toolchain & Build System

* The official toolchain is an old **Turbo C‑like compiler** that 
targets 68000 only.
* No `make` or `CMake` integration in the upstream project.
* The build system is *fragile* – you often have to patch the makefiles 
to get anything to compile on a modern GCC toolchain.
* No support for cross‑compilation to other CPUs (e.g., the 68020 or 68030).

**Impact**
Developers must resort to third‑party compilers or write their own 
assembler/linker scripts. This makes community contribution very difficult.

### 3.3  Documentation & Support

| Issue | What it means | Current state |
|-------|---------------|---------------|
| **Fragmented docs** | The official “Manual” is split across the source 
tree (`doc/`, `src/`, etc.) | Hard to find a single reference |
| **No “user manual”** | No quick‑start guide or FAQ | Newcomers are lost |
| **No online resources** | The original project website (freemint.com) 
has been offline for years | No up‑to‑date FAQ or forum |
| **No active maintainer** | The last commit was 2015‑2016 | Security 
bugs never get patched, features never added |

---

## 4.  Performance & Stability

| Aspect | Issue | Consequence |
|--------|-------|-------------|
| **No CPU affinity / SMP support** | The OS only runs on a single 68000 
core (even if you have a 68030/68040) | Cannot make use of multi‑core 
systems |
| **No cache / MMU configuration** | The 68000’s cache is never properly 
set up (except in the original MINT) | Slow I/O and sub‑optimal memory 
usage |
| **Memory leaks** | Several of the higher‑level tools (e.g., the file 
manager) leak the heap in long‑running sessions | Eventually crashes 
after a few
hours of use |
| **No journaling file system** | FAT writes are performed without a 
journal | File system corruption after power loss |

---

## 5.  Real‑world Use‑Case Shortcomings

| Use‑Case | FreeMint’s Capabilities | Deficiency | How it hurts |
|----------|------------------------|------------|--------------|
| **Running a desktop environment** | None | No window system, no 
mouse/graphics APIs | Cannot run a GUI program |
| **Running a network‑based backup** | None | No TCP/IP, no sockets | No 
remote backups or NFS |
| **Running a real‑time embedded system** | No real‑time scheduler | 
Hard to guarantee latency | Cannot be used in embedded projects |
| **Running modern 68000 software** | Basic DOS compatibility | Many 
binaries use undocumented 68020 features | Compatibility breakage |
| **Running a multi‑user system** | No user accounts | No security 
boundaries | Cannot host multiple users safely |

---

## 6.  A Comparison Snapshot

| Feature | FreeMint | Original MINT (1988‑1991) | Modern Hobby OS 
(e.g., AROS, Hatari‑OS) |
|---------|----------|---------------------------|----------------------------------------|
| GUI | ❌ | ✅ (basic windowing) | ✅ (windowing) |
| Multitasking | ❌ | ✅ (cooperative) | ✅ (pre‑emptive) |
| Virtual Memory | ❌ | ❌ | ✅ (paging) |
| Networking | ❌ | ❌ | ✅ (TCP/IP) |
| File System | ❌ (limited) | ✅ (MSDOS‑style + others) | ✅ (FAT, HFS, 
ext, etc.) |
| Development Tools | ❌ | ❌ | ✅ (make, GCC, CMake) |
| Documentation | ❌ | ✅ | ✅ |
| Community | ❌ | ❌ | ✅ (active) |

---

## 7.  Bottom‑Line Takeaway

 > **FreeMint is a nice little *command‑line* hobby OS that emulates a 
subset of the original Atari ST MINT features, but it falls short on the 
major axes
that users care about today—multitasking, virtual memory, modern 
file‑system support, networking, and a usable development stack.**

It is *not* a drop‑in replacement for the original MINT, nor is it a 
viable platform for running modern software or building embedded 
solutions. Anyone
who wants to use the Atari ST platform today would be better served by 
an actively maintained fork (e.g., **AROS** or **Hatari‑OS**), or by 
running a
fully‑featured emulator (e.g., **Hatari**) that supports the full 68000 
instruction set and modern peripherals.

---

## 8.  Possible Paths Forward

If you’re a developer interested in breathing life back into FreeMint, 
consider the following:

1. **Implement a minimal pre‑emptive scheduler** – even a simple 
round‑robin with time‑outs would mitigate the single‑process crash problem.
2. **Add a small paging/virtual‑memory layer** – using the 68030’s MMU 
to provide basic protection.
3. **Port the FAT32 driver** to support long filenames, 64‑bit 
timestamps, and journaling.
4. **Build a minimal networking stack** – starting with a serial “PPP” 
and then adding TCP/IP.
5. **Create a basic GUI toolkit** – or at least provide an abstraction 
over the blitter.
6. **Modernize the toolchain** – expose the build process via CMake and 
allow cross‑compilation.

 > **But** the reality is that the cost of doing all that is high, and 
the community around FreeMint simply does not exist to pull it off.

---

## 8.1  Suggested Alternatives for 68000 Hobbyists

| Project | What it offers | Why it’s better for a hobbyist |
|---------|---------------|--------------------------------|
| **AROS** | Full AROS compatible, multi‑core, networking, GUI | 
Actively maintained, large community |
| **Hatari‑OS** | Hatari emulator + OS for classic Atari ST | Fully 
featured, easy to set up |
| **RISC‑OS** | Real‑time, multitasking, GUI | Great for low‑power devices |
| **Hatari OS** | Emulated environment + OS for classic systems | Modern 
hardware support |

If you need a *real* operating system on an Atari ST clone, consider one 
of these instead of FreeMint. They all have modern toolchains, 
documented APIs,
and a healthy user base.

---

**TL;DR** – FreeMint is *legacy* in every sense: no multitasking, no 
virtual memory, no networking, limited hardware support, minimal 
documentation, and
no active community. It can still be useful for teaching basic 68000 
assembly or running ultra‑small command‑line programs, but it is *not* a 
practical
OS for any real use today.

Re: [Freemint-discuss] Weird problem with MiNTnet

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

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

Re: [Freemint-discuss] Weird problem with MiNTnet

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

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

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