freemint-discuss Mailing List for FreeMiNT

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi;

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

Thanks,
Bob
Sent from my iPhone

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

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

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

Jo Even

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

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

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

>> violations, but can contain any text.

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

Jo Even

Hi,

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

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

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

	- Eero

On Tue, 23 Sept 2025 at 20:44, Jo Even Skarstein via Freemint-discuss <
fre...@li...> wrote:

> Here's why I wanted to monitor the alert-pipe with a separate
> application (see attached screenshot). I want to assist the casual user
> in resolving the memory violations that can occur when using certain
> popular applications.

Great idea, I applaud the effort.

-- 
http://mikro.atari.org

On Dienstag, 23. September 2025 20:43:50 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> Here's why I wanted to monitor the alert-pipe with a separate
> application (see attached screenshot)

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

On Dienstag, 23. September 2025 20:09:55 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> You can't do this if you don't have the sources for the crashing
> program.

Ah ok i thought you were hunting some bug in your program.

What you could eventually do is still try to run the program under the control 
of the debugger, either the new elf version, or maybe even the version 5.1 
from sparemint. That should give you atleast the opportunity to examine any 
address you want, before the program terminates.

On Thu, 2025-09-04 at 13:16 +0200, Thorsten Otto via Freemint-discuss
wrote:
> On Donnerstag, 4. September 2025 13:08:42 CEST Jo Even Skarstein via
> Freemint-discuss wrote:
> > It would be nice if it was possible for other applications to
> > monitor the
> > alert-pipe and not just XaAES itself.
> 
> That won't work, then you would have 2 processes trying to read data
> from the pipe. And why do you want to do that?

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

Jo Even

On Tue, 2025-09-23 at 17:09 +0200, Thorsten Otto via Freemint-discuss
wrote:
> On Dienstag, 23. September 2025 14:45:09 CEST Jo Even Skarstein via
> Freemint-discuss wrote:
> > if I understand you correctly then the docs means "memory currently
> > allocated to a process or the kernel"
> 
> Yes, i think that is what was actually meant there. Reading memory
> that is not assigned to any process would just return random garbage.
> 
No, not really. Even if it's currently not allocated to a process it
doesn't necessarily contain random garbage. It's also a bit strange
limitation, as peeking around in free memory is pretty harmless
compared to doing the same to allocated memory. But yes, this is a
marginal usecase :)

> For that you would have to know where the program stores what. Might

It is of course more difficult than source level debugging. And not
always possible. But when a program crashes you know the address of the
basepage, and thus the text, data and bss segments. You also know the
address of the instruction that caused the crash, and the address that
caused the memory violation. So you have quite a bit of information.
You could have had even more - like a register dump and a list of all
memory pages allocated to the process - if the kernel hadn't discarded
this information before informing the user about the crash.

> make more sense to compile the program with the elf toolchain, and
> run it in gdb to see where it crashes (yes i know, thats not your
> favorite option).

You can't do this if you don't have the sources for the crashing
program.

Jo Even

On Dienstag, 23. September 2025 14:45:09 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> if I understand you correctly then the docs means "memory currently
> allocated to a process or the kernel"

Yes, i think that is what was actually meant there. Reading memory that is not 
assigned to any process would just return random garbage.

> It would be useful to be able to inspect these when a process is terminated 
> due to a memory violation.

For that you would have to know where the program stores what. Might make more 
sense to compile the program with the elf toolchain, and run it in gdb to see 
where it crashes (yes i know, thats not your favorite option).

The address that actually caused the memory violation will also be helpful.

The freemint discord can be useful for sharing screenshots and videos.

⁣Peter

On 23 Sept 2025, 09:04, at 09:04, "Miro Kropáček" <mir...@gm...> wrote:
>That sounds fine to me. So what do you see? It has been some time since
>I
>booted the ST archive on a stock machine, it's really not so well
>suited
>for 4 MB (the bash itself eats about 500 KB) so it's possible you are
>just running out of memory. Some pictures or video would help to
>diagnose
>the problem further.
>
>On Tue, 23 Sept 2025 at 01:21, ROBERT MYERS <rj...@ya...> wrote:
>
>> I downloaded freemint-1-19-23dc029a-000-st_str.zip and installed it
>on my
>> stock Mega ST/4 having TOS 1.0.
>>
>> Regards,
>> Bob
>>
>> Sent from my iPhone
>>
>> On Sep 20, 2025, at 1:34 AM, Miro Kropáček <mir...@gm...>
>> wrote:
>>
>> 
>> Hi Bob,
>>
>> maybe first tell us which archive you downloaded.
>>
>> http://mikro.atari.org
>>
>> Dňa so 20. 9. 2025, 1:05 Bob Myers <rj...@ya...> napísal(a):
>>
>>> Hi Miro;
>>>
>>> I did this on my TOS 1.0 Mega ST/4 and booted the machine.  It did
>not
>>> switch desktops or presented me with a  bash shell.  What am I
>supposed to
>>> see?  I'm going to check you link now.
>>>
>>>
>>> Regards,
>>>
>>> Bob
>>>
>>>
>>> On 9/18/2025 10:29 PM, Miro Kropáček wrote:
>>>
>>>
>>> just unzip the archive on C:.
>>>
>>> http://mikro.atari.org
>>>
>>> Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss <
>>> fre...@li...> napísal(a):
>>>
>>>
>
>-- 
>http://mikro.atari.org
>
>
>------------------------------------------------------------------------
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Freemint-discuss mailing list
>Fre...@li...
>https://lists.sourceforge.net/lists/listinfo/freemint-discuss

On Tue, 23 Sep 2025 09:01:26 +0200, Thorsten Otto via Freemint-discuss <fre...@li...> wrote:

>> Thats not the only problem here, but even if you know the address of the
>> crashed program, its memory does not belong to any process anymore, and
>> is not managed by mint currently.

I do know the address of the crashed program's basepage, as this address is displayed in the crash alert.

Free memory *is* managed by MiNT, as this is literally the memory pool that memory is allocated from. But if I understand you correctly then the docs means "memory currently allocated to a process or the kernel" and not all memory managed by MiNT.

>> I also don't know what you want to examine in the basepage, there is nothing
>> that changes there during the runtime of the process? >> _______________________________________________

It contains the size and addresses for the TEXT, DATA and BSS sections. It would be useful to be able to inspect these when a process is terminated due to a memory violation.

Jo Even

That sounds fine to me. So what do you see? It has been some time since I
booted the ST archive on a stock machine, it's really not so well suited
for 4 MB (the bash itself eats about 500 KB) so it's possible you are
just running out of memory. Some pictures or video would help to diagnose
the problem further.

On Tue, 23 Sept 2025 at 01:21, ROBERT MYERS <rj...@ya...> wrote:

> I downloaded freemint-1-19-23dc029a-000-st_str.zip and installed it on my
> stock Mega ST/4 having TOS 1.0.
>
> Regards,
> Bob
>
> Sent from my iPhone
>
> On Sep 20, 2025, at 1:34 AM, Miro Kropáček <mir...@gm...>
> wrote:
>
> 
> Hi Bob,
>
> maybe first tell us which archive you downloaded.
>
> http://mikro.atari.org
>
> Dňa so 20. 9. 2025, 1:05 Bob Myers <rj...@ya...> napísal(a):
>
>> Hi Miro;
>>
>> I did this on my TOS 1.0 Mega ST/4 and booted the machine.  It did not
>> switch desktops or presented me with a  bash shell.  What am I supposed to
>> see?  I'm going to check you link now.
>>
>>
>> Regards,
>>
>> Bob
>>
>>
>> On 9/18/2025 10:29 PM, Miro Kropáček wrote:
>>
>>
>> just unzip the archive on C:.
>>
>> http://mikro.atari.org
>>
>> Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss <
>> fre...@li...> napísal(a):
>>
>>

-- 
http://mikro.atari.org

On Montag, 22. September 2025 21:53:30 CEST Jo Even Skarstein via Freemint-
discuss wrote:
> And yes, I am aware that the memory of the
> crashed process may have been allocated and overwritten by another
> process since the crash

Thats not the only problem here, but even if you know the address of the 
crashed program, its memory does not belong to any process anymore, and 
is not managed by mint currently.

I also don't know what you want to examine in the basepage, there is nothing 
that changes there during the runtime of the process?

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I downloaded freemint-1-19-23dc029a-000-st_str.zip and installed it on my stock Mega ST/4 having TOS 1.0. &nbsp;&nbsp;<div><br></div><div>Regards,</div><div>Bob</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Sep 20, 2025, at 1:34 AM, Miro Kropáček &lt;mir...@gm...&gt; wrote:<br><br></div><div dir="ltr"><div dir="auto"><div>Hi Bob,</div><div dir="auto"><br></div><div dir="auto">maybe first tell us which archive you downloaded.</div><div><br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div><a href="http://mikro.atari.org" target="_blank">http://mikro.atari.org</a></div></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Dňa so 20. 9. 2025, 1:05 Bob Myers &lt;<a href="mailto:rj...@ya...">rj...@ya...</a>&gt; napísal(a):<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  <div>
    <p>Hi Miro;</p>
    <p>I did this on my TOS 1.0 Mega ST/4 and booted the machine.&nbsp; It
      did not switch desktops or presented me with a&nbsp; bash shell.&nbsp; What
      am I supposed to see?&nbsp; I'm going to check you link now.</p>
    <p><br>
    </p>
    <p>Regards,&nbsp;</p>
    <p>Bob</p>
    <p><br>
    </p>
    <div>On 9/18/2025 10:29 PM, Miro Kropáček
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">just unzip the archive on C:.</div>
        <div><br>
        </div>
        <div data-smartmail="gmail_signature">
          <div dir="ltr">
            <div><a href="http://mikro.atari.org" target="_blank" rel="noreferrer">http://mikro.atari.org</a></div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">Dňa št 18. 9. 2025, 23:06
          ROBERT MYERS via Freemint-discuss &lt;<a href="mailto:fre...@li..." target="_blank" rel="noreferrer">fre...@li...</a>&gt;
          napísal(a):</div>
      </div>
    </blockquote>
  </div>

</blockquote></div>
</div></div></body></html>
Hi,

I want to examine the basepage and TEXT segment of a *crashed* process.

mint-prg.hyp (
https://tho-otto.de/hypview/hypview.cgi?url=%2Fhyp%2Fmint-prg.hyp&charset=UTF-8&index=14
):

> If you Fopen() process zero (MiNT itself) then you can
> Fseek() to any address that is managed by MiNT and read or
> write there. This is for debuggers and similarly dangerous
> tools.

Not quite sure how this is supposed to work.

- I open u:\\proc\\*.000, with Fopen, it returns a valid filepointer.
- I Fseek to the desired address (address of basepage of the crashed
process), Fseek returns the address I Fseek'ed to.
- I try to read the basepage with Fread(f, sizeof(BASEPAGE), &buffer).
Fread returns error -36, EACCESS.

What am I doing wrong here? And yes, I am aware that the memory of the
crashed process may have been allocated and overwritten by another
process since the crash, but that should not cause the access issue if
I understand the quote from mint-prg.hyp correctly.

Jo Even

Hi Bob,

maybe first tell us which archive you downloaded.

http://mikro.atari.org

Dňa so 20. 9. 2025, 1:05 Bob Myers <rj...@ya...> napísal(a):

> Hi Miro;
>
> I did this on my TOS 1.0 Mega ST/4 and booted the machine.  It did not
> switch desktops or presented me with a  bash shell.  What am I supposed to
> see?  I'm going to check you link now.
>
>
> Regards,
>
> Bob
>
>
> On 9/18/2025 10:29 PM, Miro Kropáček wrote:
>
>
> just unzip the archive on C:.
>
> http://mikro.atari.org
>
> Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss <
> fre...@li...> napísal(a):
>
>

Hi Miro;

I did this on my TOS 1.0 Mega ST/4 and booted the machine.  It did not 
switch desktops or presented me with a  bash shell.  What am I supposed 
to see?  I'm going to check you link now.

Regards,

Bob

On 9/18/2025 10:29 PM, Miro Kropáček wrote:
>
> just unzip the archive on C:.
>
> http://mikro.atari.org
>
> Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss 
> <fre...@li...> napísal(a):
Hi Bob,

just unzip the archive on C:.

http://mikro.atari.org

Dňa št 18. 9. 2025, 23:06 ROBERT MYERS via Freemint-discuss <
fre...@li...> napísal(a):

> Hi;
>
> Can someone point me to discussions describing how to install this version
> onto a mega st4?  I’m unsure how to do this since I don’t see an
> install.pkg file in the mint folder.
>
> Thanks,
> Bob
> Sent from my iPhone
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

Hi;

Can someone point me to discussions describing how to install this version onto a mega st4?  I’m unsure how to do this since I don’t see an install.pkg file in the mint folder.

Thanks,
Bob
Sent from my iPhone

On Sat, 13 Sept 2025 at 00:00, Vincent Barrilliot via Freemint-discuss <
fre...@li...> wrote:

> A while back, I rewrote the keyboard/midi handling stuff in C in my fork
> of EmuTOS and it works great (
> https://github.com/vinz6751/genxtos/blob/main/bios/aciavecs_c.c). I event
> rewrote the VBL handler in C there :D It's possible to write interrupt
> handlers with GCC (tried it, it works) so it's to be considered when the
> sole reason is "need to save scratch registers and terminate with RTE"
>
I couldn't find an example of that in your source tree (but I didn't look
too hard). I presume you are talking about using gcc's interrupt attribute
<https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/m68k-Function-Attributes.html> ?
Could be an interesting thing to do, indeed. But one has to be
*extremely* careful
when rewriting those handlers into C because one typo can have a
catastrophic outcome. So no huge PRs there please, make them as simple as
possible.

> As part of doing that, I also have as a secondary objective to be able to
> "#define-out" code that is irrelevant for a ST, so to hopefully save a bit
> of space/overhead and make MiNT more vanilla-ST-friendly (every kilobyte of
> memory counts there :D)
>
As you are perhaps aware, "KERNELDEFS_000 = -DM68000 -DNO_RAMFS
-DNO_FAKE_SUPER -DNO_DEV_RANDOM" has more or less the same objective, so
maybe you can just extend the scope of "M68000" if you find something
unrelated to ST to be still included.

In general your ideas seem right, just be cautious and progress in small
steps: the last thing we need is a huge PR messing with hundreds of asm
lines while introducing hundreds of C lines. :)

-- 
http://mikro.atari.org

Hi Miro,

1 Thank for the advice. I cleaned up and created another PR as a result, 
I hope it's now in a decent state though it's still a single PR (there 
is just one commit there that moves a method). I'll pay attention to 
create different PRs going forward.

2 Next I'll check if it makes sense to improve the install_vector() 
function so it automatically detects if the handler to install supports 
XBRA (if handler-12 is 'XBRA' and handler-8 is 'MiNT'), and if so, save 
the old handler. And likewise for restoring. Factoring that would allow 
to eliminate some code.

3 Next I would like to see if I can split init_intr because it says 
"init" but it actually has the code for different handlers dealing with 
different things (timers, TOS disk vectors etc.) so it's a "God" module. 
I'll probably split that so to have the timer stuff separated in its own 
files (e.g. timer_5ms, timer_20ms), the TOS disk handlers on another, etc.

4 Also I'm wondering why the TOS disk vectors handlers (new_rawbs etc.) 
really need assembly code. There is code duplication there that could be 
eliminated between the 3 vectors. In general, I would also like to 
rewrite some things in C unless there is a clear performance reason to 
keep it in asm. This is also because:

* the Coldfire support makes the asm source quite unreadable because of 
all the "#if __coldfire__".

* it gives no chance to the compiler to use 68020+ instructions 
(indirections, scale factors) that could give a positive performance 
improvements

* Some things don't need to be ultra fast. For example, the keyboard 
stuff doesn't need to be ultra fast (just need to check it can keep up 
with the mouse events). A while back, I rewrote the keyboard/midi 
handling stuff in C in my fork of EmuTOS and it works great 
(https://github.com/vinz6751/genxtos/blob/main/bios/aciavecs_c.c). I 
event rewrote the VBL handler in C there :D It's possible to write 
interrupt handlers with GCC (tried it, it works) so it's to be 
considered when the sole reason is "need to save scratch registers and 
terminate with RTE"

I would like to isolate or make more apparent the hardware dependency of 
FreeMiNT (e.g. it assumes the Atari user vector addresses for ACIAs, 
interruption levels etc.), so I could consider adapting it for my Foenix 
Retro Systems GenX to harness the power of the 060 installed there. 
(That's why i started looking at the init_intr.) As part of doing that, 
I also have as a secondary objective to be able to "#define-out" code 
that is irrelevant for a ST, so to hopefully save a bit of 
space/overhead and make MiNT more vanilla-ST-friendly (every kilobyte of 
memory counts there :D)

Vincent B. (Vinz)

Le 12/09/2025 à 13:11, Miro Kropáček a écrit :
> Hi Vincent,
>
> welcome to the mailing list. First I'd like to ask you to actually 
> subscribe (register) to the list otherwise I need to accept every 
> single email from you in the admin panel.
>
> Your initiative is certainly welcome, me and the few remaining 
> freemint developers usually spend time on "hotter" issues, leaving 
> this kind of work neglected. I have briefly browsed through your 
> commits, I find majority of the changes very useful and definitely 
> improving the current state of things.
>
> If you want to see your changes merged, I'd ask for for the following:
>
> - create PR for each group of your changes: e.g. renaming 
> variables/magic constants is fine to have as one PR (much appreciated 
> the work you did there, splitting everything nicely in separate 
> commits, please keep that), then I saw some vector restoration fixes - 
> another PR, moving functions into other files - another PR etc
>
> - if you have some commits fixing your own bugs (I saw a commit like 
> that there), please merge those commits together so there's only one 
> final good commit
>
> - it's fine to say "this PR depends on that PR, so merge the latter first"
>
> If you need some help with git(hub), just ask. It's somewhat dull work 
> to rebase/reorder/cherry-pick for the PRs but it makes the reviewer's 
> work much easier.
>
> On Fri, 12 Sept 2025 at 12:57, Vincent Barrilliot via Freemint-discuss 
> <fre...@li...> wrote:
>
>     Hello,
>
>     I have started looking at the FreeMiNT code and I am not finding
>     it very
>     "easy" or modern. I would like to refactor things a bit to make
>     the code
>     base easier to grasp for new comers like me, so maybe to help people
>     figure things out and contribute more easily. For example:
>
>     Renaming variables, moving where it belongs (so modules should have
>     single responsibility), avoiding magic numbers, adding comments or
>     updating/writing notes on how things work. This should be rather
>     rather
>     safe.
>
>     An example of what I'm doing is here
>     https://github.com/vinz6751/freemint/pull/2/files
>
>     (the individual commits tell the story).
>
>     I'd like to know how I can get these changes in, if that is possible.
>
>     Thank you!
>
>     Vincent Barrilliot
>
>
>
>
>
>     _______________________________________________
>     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
Hi Vincent,

welcome to the mailing list. First I'd like to ask you to actually
subscribe (register) to the list otherwise I need to accept every single
email from you in the admin panel.

Your initiative is certainly welcome, me and the few remaining
freemint developers usually spend time on "hotter" issues, leaving this
kind of work neglected. I have briefly browsed through your commits, I find
majority of the changes very useful and definitely improving the current
state of things.

If you want to see your changes merged, I'd ask for for the following:

- create PR for each group of your changes: e.g. renaming variables/magic
constants is fine to have as one PR (much appreciated the work you did
there, splitting everything nicely in separate commits, please keep that),
then I saw some vector restoration fixes - another PR, moving functions
into other files - another PR etc

- if you have some commits fixing your own bugs (I saw a commit like that
there), please merge those commits together so there's only one final good
commit

- it's fine to say "this PR depends on that PR, so merge the latter first"

If you need some help with git(hub), just ask. It's somewhat dull work to
rebase/reorder/cherry-pick for the PRs but it makes the reviewer's
work much easier.

On Fri, 12 Sept 2025 at 12:57, Vincent Barrilliot via Freemint-discuss <
fre...@li...> wrote:

> Hello,
>
> I have started looking at the FreeMiNT code and I am not finding it very
> "easy" or modern. I would like to refactor things a bit to make the code
> base easier to grasp for new comers like me, so maybe to help people
> figure things out and contribute more easily. For example:
>
> Renaming variables, moving where it belongs (so modules should have
> single responsibility), avoiding magic numbers, adding comments or
> updating/writing notes on how things work. This should be rather rather
> safe.
>
> An example of what I'm doing is here
> https://github.com/vinz6751/freemint/pull/2/files
>
> (the individual commits tell the story).
>
> I'd like to know how I can get these changes in, if that is possible.
>
> Thank you!
>
> Vincent Barrilliot
>
>
>
>
>
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>

-- 
http://mikro.atari.org

Hello,

I have started looking at the FreeMiNT code and I am not finding it very 
"easy" or modern. I would like to refactor things a bit to make the code 
base easier to grasp for new comers like me, so maybe to help people 
figure things out and contribute more easily. For example:

Renaming variables, moving where it belongs (so modules should have 
single responsibility), avoiding magic numbers, adding comments or 
updating/writing notes on how things work. This should be rather rather 
safe.

An example of what I'm doing is here 
https://github.com/vinz6751/freemint/pull/2/files

(the individual commits tell the story).

I'd like to know how I can get these changes in, if that is possible.

Thank you!

Vincent Barrilliot

On Wed, 2025-09-10 at 16:04 +0200, Thorsten Otto via Freemint-discuss
wrote:
> It would still interfere i think, since only one application will
> receive mouse events. Also, even a widget-less window would have a

When evnt_multi times out it should return also the current mouse
position and button status, regardless of which application has input
focus. XaAES doesn't, I have created an issue for this:

https://github.com/freemint/freemint/issues/424

> border frame, unless you explitcly disable that in xaaes.cnf. But i'm
> not sure whether other AES like MyAES or N.AES support that (not to
> speek about SingleTOS, where you would not have widget-less windows
> at all).

You confuse widget-less with frame-less :) You can have a window
without any widgets in any AES. If you for some reason wants a frame-
less window only XaAES supports that I think, and unfortunately only
via appsettings in xaaes.cnf.

But that's not a problem, you don't have to draw "bubbles" but can
simply put the help-text in a normal, rectangular window like e.g.
Windows does.

> Anyway, attached is my first attempt to port the Pascal code to Pure-
> C. Maybe someone will give this a try. Note that when you 

Thanks, but I already have a pretty feature-complete implementation
using windows instead of locking the screen like BubbleGEM does. The
mouse button bug mentioned above prevents this from working correctly
when the help-text is displayed by right-clicking on an item though. In
this case the text should be closed as soon as the right mousebutton is
released, but as I can't reliably detect the button status upon
receiving the BUBBLEGEM_SHOW message this does not work under XaAES.
Works fine in N.AES.

Jo Even

2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (3)	Nov (30)	Dec (10)
2018	Jan (44)	Feb (44)	Mar (32)	Apr (49)	May (45)	Jun (7)	Jul (15)	Aug (84)	Sep (95)	Oct (36)	Nov (88)	Dec (41)
2019	Jan (21)	Feb (27)	Mar (67)	Apr (25)	May (69)	Jun (45)	Jul (65)	Aug (15)	Sep (20)	Oct (42)	Nov (109)	Dec (62)
2020	Jan (58)	Feb (36)	Mar (84)	Apr (169)	May (325)	Jun (267)	Jul (43)	Aug (3)	Sep (27)	Oct (25)	Nov (25)	Dec (7)
2021	Jan (11)	Feb (66)	Mar (1)	Apr (55)	May (24)	Jun (36)	Jul (10)	Aug	Sep (1)	Oct (21)	Nov (2)	Dec (22)
2022	Jan (3)	Feb (98)	Mar (15)	Apr (31)	May (4)	Jun (23)	Jul (45)	Aug (15)	Sep (75)	Oct (8)	Nov (10)	Dec (12)
2023	Jan (5)	Feb (49)	Mar (31)	Apr (3)	May (7)	Jun (5)	Jul (7)	Aug (161)	Sep (8)	Oct (7)	Nov (27)	Dec (26)
2024	Jan (24)	Feb (35)	Mar (11)	Apr (38)	May (13)	Jun (39)	Jul (2)	Aug (24)	Sep (7)	Oct (5)	Nov	Dec (18)
2025	Jan (82)	Feb (11)	Mar (9)	Apr (13)	May (2)	Jun (7)	Jul (2)	Aug (38)	Sep (46)	Oct (1)	Nov	Dec

freemint-discuss Mailing List for FreeMiNT

FreeMiNT is a free alternative OS kernel for Atari systems & clones

freemint-discuss — The official FreeMiNT Mailing List