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
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark D. <mdu...@at...> - 2024-12-16 00:18:49
|
I actually ported a much newer procps-ng and ported all those apps... But yours is nicer On 12/15/24 2:59 PM, Jo Even Skarstein via Freemint-discuss wrote: > On Fri, 2023-12-08 at 21:41 +0100, Jo Even Skarstein wrote: >> The old SpareMiNT top crashes with a bus error on recent kernels. >> >> https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html > I wrote my own simple "top", it might be of use for others: > > https://atari.joska.no/jtop/ > > Jo Even > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Jo E. S. <jo...@on...> - 2024-12-15 23:22:49
|
The build before this commit works: https://github.com/freemint/freemint/commit/81fb50786aa0aaf939733c0e5005e648a12de84f Jo Even On Sun, 15 Dec 2024 23:12:01 +0100, "Miro Kropáček" <mir...@gm...> wrote: >> Hi Jo, >> >> I'm currently away from my Atari gear but I remember having the same >> experience -- a couple of months ago I wiped my old FreeMiNT setup and to >> my surprise, I haven't been able to get a stable networking setup since >> then. >> >> Not that I tried very hard. But I did try changing to the very same litchi >> version I had been using for so long and imagine my surprise when it didn't >> work either. >> >> So I'm wondering whether there was something changed in gluestik.prg or in >> some network code in the last few months. >> >> I'll try to take a closer look on Monday but feel free to bisect the >> failing build from the snapshots download in the meantime. >> >> Dňa ne 15. 12. 2024, 22:44 Jo Even Skarstein via Freemint-discuss < >> fre...@li...> napísal(a): >> >> > I've recently made a small game >> > (https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK >> > API. The rather old gluestik.prg I had appeared to be a debug version, >> > so I tried gluestik from the latest snapshot. Unfortunately there seems >> > to be a problem with this, any application that tries to initialise the >> > STiK API crashes immediately. In addition to my own game I have tried >> > Litchi and Troll, which both use the STiK resolver. They all crash with >> > a bus error. >> > >> > Jo Even >> > >> > >> > _______________________________________________ >> > Freemint-discuss mailing list >> > Fre...@li... >> > https://lists.sourceforge.net/lists/listinfo/freemint-discuss >> > |
|
From: Miro K. <mir...@gm...> - 2024-12-15 22:12:25
|
Hi Jo, I'm currently away from my Atari gear but I remember having the same experience -- a couple of months ago I wiped my old FreeMiNT setup and to my surprise, I haven't been able to get a stable networking setup since then. Not that I tried very hard. But I did try changing to the very same litchi version I had been using for so long and imagine my surprise when it didn't work either. So I'm wondering whether there was something changed in gluestik.prg or in some network code in the last few months. I'll try to take a closer look on Monday but feel free to bisect the failing build from the snapshots download in the meantime. Dňa ne 15. 12. 2024, 22:44 Jo Even Skarstein via Freemint-discuss < fre...@li...> napísal(a): > I've recently made a small game > (https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK > API. The rather old gluestik.prg I had appeared to be a debug version, > so I tried gluestik from the latest snapshot. Unfortunately there seems > to be a problem with this, any application that tries to initialise the > STiK API crashes immediately. In addition to my own game I have tried > Litchi and Troll, which both use the STiK resolver. They all crash with > a bus error. > > Jo Even > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Jo E. S. <jo...@on...> - 2024-12-15 21:43:46
|
I've recently made a small game (https://www.atari-forum.com/viewtopic.php?t=44483) that use the STiK API. The rather old gluestik.prg I had appeared to be a debug version, so I tried gluestik from the latest snapshot. Unfortunately there seems to be a problem with this, any application that tries to initialise the STiK API crashes immediately. In addition to my own game I have tried Litchi and Troll, which both use the STiK resolver. They all crash with a bus error. Jo Even |
|
From: Jo E. S. <jo...@on...> - 2024-12-15 19:59:51
|
On Fri, 2023-12-08 at 21:41 +0100, Jo Even Skarstein wrote: > The old SpareMiNT top crashes with a bus error on recent kernels. > > https://freemint.github.io/sparemint/sparemint/html/packages/pstop.html I wrote my own simple "top", it might be of use for others: https://atari.joska.no/jtop/ Jo Even |
|
From: Peter S. <ps...@sc...> - 2024-12-05 07:49:06
|
There is a native freepascal compiler as well. https://build.alb42.de/fpcbin/ Peter On 5 Dec 2024, 05:53, at 05:53, Thorsten Otto via Freemint-discuss <fre...@li...> wrote: >On Dienstag, 3. Dezember 2024 14:28:01 CET Peter Slegg via >Freemint-discuss >wrote: >> I've been playing with freepascal. Could it support the same format ? > >Freepascal only uses the assembler & linker from the gcc toolchain, so >there >won't be much benefit in using the elf toolchains. And normally, it >uses VASM >for this purpose, which already supports elf. > >I also wonder why you need a native gcc for this (although that is >available). >AFAIK freepascal is only available as cross-compiler. > > > >------------------------------------------------------------------------ > > > >------------------------------------------------------------------------ > >_______________________________________________ >Freemint-discuss mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2024-12-05 05:53:36
|
On Dienstag, 3. Dezember 2024 14:28:01 CET Peter Slegg via Freemint-discuss wrote: > I've been playing with freepascal. Could it support the same format ? Freepascal only uses the assembler & linker from the gcc toolchain, so there won't be much benefit in using the elf toolchains. And normally, it uses VASM for this purpose, which already supports elf. I also wonder why you need a native gcc for this (although that is available). AFAIK freepascal is only available as cross-compiler. |
|
From: WongCK <won...@ya...> - 2024-12-05 02:45:09
|
Yes, I have been using native ELF gcc for my programs.All are working as advertised.
On Tuesday, 3 December 2024 at 09:28:31 pm SGT, Peter Slegg via Freemint-discuss <fre...@li...> wrote:
Is there a native gcc compiler that produces the (mint) elf binaries ?
Other native tools like gdb ?
I've been playing with freepascal. Could it support the same format ?
PeterOn 3 Dec 2024, at 12:59, "Miro Kropáček" <mir...@gm...> wrote:
On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss <fre...@li...> wrote:
With Christmas just around the corner, I thought it time to ask how is Elf coming along :-)
Anything specific you have in mind? I've been using the ELF compiler for nearly a year, (native and finally working) debugger included.
--
http://mikro.atari.org
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Peter S. <ps...@sc...> - 2024-12-04 17:41:07
|
Hi, Over the weekend I had some hdd problems, thankfully fixed now, but I had a look for fdisk and see version 1.0 was ported back in 2000. It runs but expects the drive to be in /dev so it cannot do anything. Is there any workaround for this ? Peter |
|
From: Miro K. <mir...@gm...> - 2024-12-03 14:01:53
|
On Tue, 3 Dec 2024 at 14:28, Peter Slegg via Freemint-discuss < fre...@li...> wrote: > Is there a native gcc compiler that produces the (mint) elf binaries ? > Not an official release (I have to do it one day...) but Thorsten already offers such binaries: https://tho-otto.de/crossmint.php. Other native tools like gdb ? > Sure: http://vincent.riviere.free.fr/soft/m68k-atari-mintelf/archives/mint/gdb. > I've been playing with freepascal. Could it support the same format ? > I guess you will have to ask FreePascal authors. -- http://mikro.atari.org |
|
From: Peter S. <ps...@sc...> - 2024-12-03 13:28:17
|
Is there a native gcc compiler that produces the (mint) elf binaries ? Other native tools like gdb ? I've been playing with freepascal. Could it support the same format ? Peter On 3 Dec 2024, 12:59, at 12:59, "Miro Kropáček" <mir...@gm...> wrote: >On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss < >fre...@li...> wrote: > >> With Christmas just around the corner, I thought it time to ask how >is Elf >> coming along :-) >> >Anything specific you have in mind? I've been using the ELF compiler >for >nearly a year, (native and finally working) debugger included. > >-- >http://mikro.atari.org > > >------------------------------------------------------------------------ > > > >------------------------------------------------------------------------ > >_______________________________________________ >Freemint-discuss mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2024-12-03 13:00:14
|
On Tue, 3 Dec 2024 at 13:15, Peter Slegg via Freemint-discuss < fre...@li...> wrote: > With Christmas just around the corner, I thought it time to ask how is Elf > coming along :-) > Anything specific you have in mind? I've been using the ELF compiler for nearly a year, (native and finally working) debugger included. -- http://mikro.atari.org |
|
From: Peter S. <ps...@sc...> - 2024-12-03 12:15:20
|
With Christmas just around the corner, I thought it time to ask how is Elf coming along :-) Peter |
|
From: Miro K. <mir...@gm...> - 2024-12-02 20:15:18
|
On Mon, 2 Dec 2024 at 21:08, Jo Even Skarstein via Freemint-discuss < fre...@li...> wrote: > What was the outcome of this? Was O_GLOBAL re-introduced? And if so, has > anybody tested vconsd? > Yes, it was: https://github.com/freemint/freemint/pull/379 vcons has a different problem why it doesn't work: https://github.com/freemint/freemint/issues/118. -- http://mikro.atari.org |
|
From: Jo E. S. <jo...@on...> - 2024-12-02 20:08:25
|
On Sun, 2024-09-15 at 13:24 +0200, Miro Kropáček wrote: > Hi, > I guess I'll post it here for better visibility. Basically I'm trying > to solve a bag if issues: What was the outcome of this? Was O_GLOBAL re-introduced? And if so, has anybody tested vconsd? Jo Even |
|
From: Eero T. <oa...@he...> - 2024-10-13 19:19:43
|
Hi, On 12.3.2024 10.44, Thorsten Otto wrote: > On Montag, 11. März 2024 21:15:42 CET Miro Kropáček wrote: >> Having the insane (for Atari world) amounts of RAM in TT/CT60/V4S/Aranym, >> this could work well on our systems, too: >> https://www.phoronix.com/news/Linux-Tracing-Post-Reboots. Long before that (by ~20 years), Linux kernels have had ability to dump similar things to a specific "oops" partition on the disk: https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdoops.c > For aranym atleast, that wont work since the memory may already be cleared by > the host. Also that assumes that we have some backtrace ability in the kernel, > which isn't the case. If you have backtrace ability, like Hatari debugger has (with symbols loaded and profiling enabled), one can just print the backtrace when things crash. There's no need to reboot to working config and printing things from inside the emulation. But on real HW, saving other things than backtrace (regs etc) to reboot-safe buffer might also be useful. - Eero |
|
From: Jo E. S. <jo...@on...> - 2024-10-12 11:55:11
|
Ok, got it. This struct is protected and can not be accessed directly, you need to use Fread to access it.
Jo Even
On Thu, 10 Oct 2024 19:28:19 +0000, "Jo Even Skarstein" <jo...@on...> wrote:
>> From tos.hyp (Fcntl):
>>
>> > PPROCADDDR (0x5001):
>> >
>> > In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.
>>
>> The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:
>>
>> void main(void)
>> {
>> long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
>> struct PCB *p;
>> printf("%ld\n", Fcntl((int) f, &p, 0x5001));
>> printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
>> }
>>
>> However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.
>>
>> I have compiled it with both gcc and PureC with identical results.
>>
>> Jo Even
>>
>>
>> _______________________________________________
>> Freemint-discuss mailing list
>> Fre...@li...
>> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Jo E. S. <jo...@on...> - 2024-10-10 20:03:11
|
>From tos.hyp (Fcntl):
> PPROCADDDR (0x5001):
>
> In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.
The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:
void main(void)
{
long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
struct PCB *p;
printf("%ld\n", Fcntl((int) f, &p, 0x5001));
printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
}
However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.
I have compiled it with both gcc and PureC with identical results.
Jo Even
|
|
From: Jo E. S. <jo...@on...> - 2024-10-10 20:01:19
|
>From tos.hyp (Fcntl):
> PPROCADDDR (0x5001):
>
> In the parameter arg a pointer to the address of the PCB (Process Control Block) is returned.
The following code works and prints correct values (when compared with XaAES task manager and ps) when MP is disabled:
void main(void)
{
long f = Fopen("u:\\proc\\.11", 0); /* Same behaviour when opening .-1 too */
struct PCB *p;
printf("%ld\n", Fcntl((int) f, &p, 0x5001));
printf("pid: %d systime: %ld usrtime: %ld\n", p->pid, p->systime, p->usrtime);
}
However, if MP is enabled the same binary crashes with a bus error. Fcntl returns E_OK and the value of *p after the call looks sensible, but accessing the memory pointed to by *p results in a bus error. Am I doing something stupid here? I would assume so, since ps (the ancient one from MiNTOS/KGMD/SpareMiNT) works and I'm pretty sure it gets this information the same way.
I have compiled it with both gcc and PureC with identical results.
Jo Even
|
|
From: Miro K. <mir...@gm...> - 2024-10-10 19:55:05
|
Testing https://github.com/freemint/freemint/issues/386 -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-09-17 08:50:26
|
Hi, perhaps you are aware, freemint repositories include also https://github.com/freemint/hypview. This used to be a software developed by Philipp Donzé (https://xn--donz-epa.ch/atari/software/hypview) which was moved into freemint cvs in 2006. Around 2018 Thorsten took this source code as base for this hypview ( https://github.com/th-otto/hypview) and completely reworked it (as it serves as base for https://tho-otto.de/hypview/index.php and other non-Atari projects, too). Since his port has many more features and bugfixes, I'm wondering whether there is a reason to keep the original under freemint wings. There are issues (https://github.com/freemint/hypview/issues) not present in Thorsten's build and there's nobody to fix them. So I'm considering archiving this repository and removing hypview from snapshot builds, to encourage people using other alternatives. Any objections? -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-09-16 07:23:54
|
On Mon, 16 Sept 2024 at 09:03, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > the fix does still not solve all problems with it > Like what? AFAIK O_GLOBAL actually fixes *all* the issues with AES 4.1 I know of and I have even suspected it will fix one other long standing issue with another piece of software but I have to verify it tonight. I don't like (re)introducing hacks into the kernel either but in this case I would say backward compatibility wins over cleanliness. When / if someone (;-)) manages to recompile AES 4.1 from sources resulting in an exact binary match and fixes it there, I'll be the first to remove this code from the kernel. If you absolutely have to, instead of using a dedicated handle, i would > suggest to set a bit in the FILEPTR->flags variable instead. > Not a bad idea at all, thanks. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-09-16 07:03:04
|
On Montag, 16. September 2024 08:46:44 CEST Miro Kropáček wrote: > So allocating one special file descriptor for /dev/console per process seems > like a better solution I guess? I just wonder whether we need such ugly hacks at all. For N.AES, there is already a solution by setting gemcon=false. AES 4.1 is another matter, but the fix does still not solve all problems with it, and (theoretically), source for it are available, so it could as well be fixed there. If you absolutely have to, instead of using a dedicated handle, i would suggest to set a bit in the FILEPTR->flags variable instead. |
|
From: Miro K. <mir...@gm...> - 2024-09-16 06:47:08
|
On Mon, 16 Sept 2024 at 08:15, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > First off, the mask 0x8000 will result in a negative value if you assign > it to a 16bit variable. > Is that a problem? Fopen() and friends return the corresponding file handle in the lower WORD of the positive LONG, or a negative error-message. But even if it were a problem, I can always change the mask to 0x4000 (16k opened files per process, still far away from the current 1024 limit). > And secondly, what if you want to use the file handle in a Fselect() or > Fpoll() call? > Hmm. Thanks for this question, it reminded me of one post I saw when trying to learn something about it: https://mikro.naprvyraz.sk/mint/199801/msg00110.html. Back then I didn't understand the question but now I do, and yes, it seems this was a limitation of O_GLOBAL. So allocating one special file descriptor for /dev/console per process seems like a better solution I guess? -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-09-16 06:14:50
|
On Sonntag, 15. September 2024 21:28:11 CEST Miro Kropáček wrote: > OR'ing e.g. 0x8000 to the resulting file handle would work perfectly well, > too. Hm, i don't think this is a good idea. First off, the mask 0x8000 will result in a negative value if you assign it to a 16bit variable. And secondly, what if you want to use the file handle in a Fselect() or Fpoll() call? |
5 messages has been excluded from this view by a project administrator.
