freemint-discuss — The official FreeMiNT Mailing List

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

[Freemint-discuss] Vampire V2 Saga Mouse

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

Hi Everyone,

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

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

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

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

Thanks,
Mark

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

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

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

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

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


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

Too bad for us in any case.

-- 
http://mikro.atari.org

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

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

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

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

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


-- 
http://mikro.atari.org

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

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

Hi,

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

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

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


> IMHO a very bad decision by the debian people.

And apparently Gentoo maintainer too.


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


	- Eero

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

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

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

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

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

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

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

Hi,

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

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

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


	- Eero

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

Re: [Freemint-discuss] Weird problem with MiNTnet

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

Ok, haven't had much time to spend on real hardware the last month, but sat down Friday night
and tried to figure out what the problem was. I suspected either a Linux/Windows update, or a
router update. Most likely the latter, as the problem started at the exact same time on all my
computers.

Turns out that it's a routing issue with my router, and probably my MiNTnet configuration. When I
access other devices on my LAN from MiNTnet, all LAN traffic goes via the router - which is set up
as the default route. For some unknown to me reason (I know very little about network configuration)
this suddenly caused all my non-MiNTnet machines to not be able to communicate with my MiNTnet
machines. Looks like packets where received by MiNTnet, but the response never reached the other
machine. Except if that machine runs MiNTnet as well.

Adding a route specifically to my LAN solved the issue. However, the dhclient script does not do this
so I can't use DHCP anymore. Or I probably could if I modified the dhclient script, but that involves
another thing I don't know much and don't like - shell scripts.

Jo Even



On Thu, 17 Apr 2025 19:02:57 +0000, Jo Even Skarstein via Freemint-discuss <fre...@li...> wrote:

>> I've ran into a weird problem with MiNTnet. Suddenly none of my Ataris running MiNTnet are available to other devices on my LAN, except the router. Networking between my Ataris works normally, and I can ping my other devices (PC's running Linux or Windows) from my Ataris but not vice versa. I can't access any servers on my PC's from my Ataris, but any external servers (ftp, http, mail...) works fine. This happened suddenly and at the same time for all my Ataris, so the problem is not caused by any changes on the Atari side.
>>
>> What's strange is that if I boot TOS and run UIPtool instead of MiNT/MiNTnet everything works fine. The Atari is assigned the same IP as under MiNTnet (using DHCP in both cases), but with UIPtool running I can access the Atari from any device on my LAN.
>>
>> Any idea on what's going on?
>>
>> Jo Even
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> phclock.prg: skipped 0x9be4 bytes trailer

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

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

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

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

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

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

-- 
http://mikro.atari.org

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

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

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

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




  

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

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

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

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

-- 
http://mikro.atari.org

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

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

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

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

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

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

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

[Freemint-discuss] Stripex .... WOW

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

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