Menu
▾
▴
freemint-discuss — The official FreeMiNT Mailing List
You can subscribe to this list here.
| 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
(13) |
Nov
|
Dec
|
|
From: Miro K. <mir...@gm...> - 2025-10-23 23:07:14
|
On Fri, 24 Oct 2025 at 05:31, Jo Even Skarstein via Freemint-discuss < fre...@li...> wrote: > Now, 14 years later, I fixed the bugs and improved it slightly. It can be > downloaded from https://atari.joska.no/fscheck/ Great stuff! I'd like to look at the fsck.vfat problem again but that wont happen anytime soon, unfortunately. -- http://mikro.atari.org |
|
From: Jo E. S. <jo...@on...> - 2025-10-23 19:30:49
|
Back in 2011 I wrote a c replacement for the fscheck.sh shell script for VanillaMiNT. It turned out to have a couple of nasty bugs so I removed it with the intention of fixing it and adding it again. Now, 14 years later, I fixed the bugs and improved it slightly. It can be downloaded from https://atari.joska.no/fscheck/ It doesn't depend on external binaries except the various fsck's, so it should work fine with even the most basic setup. Doesn't make much sense without atleast one ext2 or minix partition though, as the FAT fsck insists on checking the entire filesystem every time. It can also be used with fscheck.sh - it can generate an fstab- compatible list of drives which then can be used by a slightly modified fscheck.sh. Then there is no need to manually maintain /etc/fstab. E.g. fscheck -fstab -skipfs dos > /ram/fstab ...will generate an "fstab" with all drives with other filesystems than dos/FAT. Sources included. Jo Even |
|
From: Jo E. S. <jo...@on...> - 2025-10-21 17:36:28
|
On Tue, 2025-10-21 at 10:49 +0000, Jo Even Skarstein via Freemint- discuss wrote: > > > Have you tried the one from the freemint repository? > > I was not aware that there was one :) Will test it tonight. - On FAT16 partitions it always reports "Dirty bit set" and "Automatically removing dirty bit". - On FAT32 partitions the check always fails the "Checking if we can access the last sector of the filesystem" check. rwabs_xhdi: access outside of partition. Jo Even |
|
From: Jo E. S. <jo...@on...> - 2025-10-21 10:49:22
|
On Tue, 21 Oct 2025 08:10:09 +1000, "Miro Kropáček" <mir...@gm...> wrote: >> Have you tried the one from the freemint repository? I was not aware that there was one :) Will test it tonight. Btw I just noticed that there's some files in the sysroot-folder of the bootable build with filenames that's too long for a FAT partition: bin/fsck.minix bin/mount_nfs etc/mke2fs.conf Jo Even |
|
From: Miro K. <mir...@gm...> - 2025-10-20 22:10:26
|
Have you tried the one from the freemint repository? http://mikro.atari.org On Tue, 21 Oct 2025, 5:34 am Jo Even Skarstein via Freemint-discuss, < fre...@li...> wrote: > Hi, > > I'm trying to use fsck.fat from Thorsten > ( https://www.tho-otto.de/download/mint/dosfstools-4.1+git-mint-000.tar.xz > ), and it always complains about "dirty bit set" even after a clean > shutdown. How is this supposed to work? > > Jo Even > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Jo E. S. <jo...@on...> - 2025-10-20 19:34:36
|
Hi, I'm trying to use fsck.fat from Thorsten ( https://www.tho-otto.de/download/mint/dosfstools-4.1+git-mint-000.tar.xz ), and it always complains about "dirty bit set" even after a clean shutdown. How is this supposed to work? Jo Even |
|
From: Miro K. <mir...@gm...> - 2025-10-04 11:19:25
|
On Sat, 4 Oct 2025 at 12:39, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > What also buffles me: shouldn't the part inside `ifdef MMU040` (which is > now `#if defined (M68040) || defined (M68060)` in current code) accompanied > by a runtime check of the cpu actually in use? Otherwise code that is > compiled for m68020-60, with only M68030 being defined, will always fall > into the 68030 case. > This should be taken care of by the fact that on 040+ machines you are never supposed to run anything other than MINT040 and/or MINT060. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2025-10-04 10:38:47
|
On Samstag, 4. Oktober 2025 12:12:15 CEST Miro Kropáček wrote: > To me it looks like a random addition with no particular purpose. I agree, that saving of sr seems superfluous. What also buffles me: shouldn't the part inside `ifdef MMU040` (which is now `#if defined (M68040) || defined (M68060)` in current code) accompanied by a runtime check of the cpu actually in use? Otherwise code that is compiled for m68020-60, with only M68030 being defined, will always fall into the 68030 case. |
|
From: Miro K. <mir...@gm...> - 2025-10-04 10:12:38
|
Hi, while looking into context.S I have noticed an odd couple of lines. These were added in https://github.com/freemint/freemint/commit/de7af1b3 and I can't understand their meaning, take save_context for instance: - sr is obviously destroyed by the tst.w just before move.w sr,d1 so why bother saving it? - sr is obviously destroyed after move.w d1,sr by tst.w _fpu and all the following lines up to move.w sr,C_SR(a0) so again, why bother at that specific place? - Why only save_context and change_context but no build_context and restore_context? There's literally the same code in there. To me it looks like a random addition with no particular purpose. -- http://mikro.atari.org |
|
From: ROBERT M. <rj...@ya...> - 2025-10-02 17:57:25
|
<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Thank you! That’s what I meant.<div><br></div><div>Regards,</div><div>Bob</div><div><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Oct 2, 2025, at 2:55 AM, Miro Kropáček <mir...@gm...> wrote:<br><br></div><div dir="ltr"><div dir="ltr">I think Robert means the actual Discord group: <a href="https://discord.gg/5yZC4NwCr9">https://discord.gg/5yZC4NwCr9</a>.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, 2 Oct 2025 at 08:49, David Gálvez <<a href="mailto:dga...@gm...">dga...@gm...</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>You can subscribe from this site:</div><div><br></div><div dir="ltr"><a href="https://sourceforge.net/projects/freemint/lists/freemint-discuss" target="_blank">https://sourceforge.net/projects/freemint/lists/freemint-discuss</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (<<a href="mailto:fre...@li..." target="_blank">fre...@li...</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi;<br> <br> I would like to join this group. Can someone send me an invite? Email address is <a href="mailto:rj...@ya..." target="_blank">rj...@ya...</a><br> <br> Thanks,<br> Bob<br> Sent from my iPhone<br> <br> <br> _______________________________________________<br> Freemint-discuss mailing list<br> <a href="mailto:Fre...@li..." target="_blank">Fre...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/freemint-discuss" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/freemint-discuss</a><br> </blockquote></div></div> _______________________________________________<br> Freemint-discuss mailing list<br> <a href="mailto:Fre...@li..." target="_blank">Fre...@li...</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/freemint-discuss" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/freemint-discuss</a><br> </blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><a href="http://mikro.atari.org" target="_blank">http://mikro.atari.org</a></div></div></div> <span>_______________________________________________</span><br><span>Freemint-discuss mailing list</span><br><span>Fre...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/freemint-discuss</span><br></div></div></body></html> |
|
From: Miro K. <mir...@gm...> - 2025-10-02 07:54:56
|
I think Robert means the actual Discord group: https://discord.gg/5yZC4NwCr9 . On Thu, 2 Oct 2025 at 08:49, David Gálvez <dga...@gm...> wrote: > You can subscribe from this site: > > https://sourceforge.net/projects/freemint/lists/freemint-discuss > > El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (< > fre...@li...>) escribió: > >> Hi; >> >> I would like to join this group. Can someone send me an invite? Email >> address is rj...@ya... >> >> Thanks, >> Bob >> Sent from my iPhone >> >> >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss >> > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > -- http://mikro.atari.org |
|
From: David G. <dga...@gm...> - 2025-10-02 06:48:54
|
You can subscribe from this site: https://sourceforge.net/projects/freemint/lists/freemint-discuss El jue, 2 oct 2025 a las 2:46, ROBERT MYERS via Freemint-discuss (< fre...@li...>) escribió: > Hi; > > I would like to join this group. Can someone send me an invite? Email > address is rj...@ya... > > Thanks, > Bob > Sent from my iPhone > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: ROBERT M. <rj...@ya...> - 2025-10-02 00:46:44
|
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 |
|
From: Jo E. S. <jo...@on...> - 2025-09-24 10:27:03
|
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 |
|
From: Jo E. S. <jo...@on...> - 2025-09-24 10:22:46
|
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 |
|
From: Eero T. <oa...@he...> - 2025-09-24 08:20:36
|
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 |
|
From: Miro K. <mir...@gm...> - 2025-09-24 07:27:00
|
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 |
|
From: Thorsten O. <ad...@th...> - 2025-09-23 22:36:36
|
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. |
|
From: Thorsten O. <ad...@th...> - 2025-09-23 22:31:22
|
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. |
|
From: Jo E. S. <jo...@on...> - 2025-09-23 18:44:06
|
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 |
|
From: Jo E. S. <jo...@on...> - 2025-09-23 18:10:16
|
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 |
|
From: Thorsten O. <ad...@th...> - 2025-09-23 15:10:05
|
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. |
|
From: Peter S. <ps...@sc...> - 2025-09-23 13:28:08
|
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 |
|
From: Jo E. S. <jo...@on...> - 2025-09-23 12:45:28
|
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 |
|
From: Miro K. <mir...@gm...> - 2025-09-23 08:04:52
|
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 |
5 messages has been excluded from this view by a project administrator.
