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: WongCK <won...@ya...> - 2024-08-09 03:50:16
|
Hi Experts, Need help.So been trying to re-compile most of my programs with new gcc v13.But I keep hitting a brick wall.... and takes me weeks to resolve ( note: not full time) Here's another one... Now I cannot re-compile an assembler file needed for my pdf program.Just a tiny file like this: == drv-init.s =========================== .xdef entry .xref _c_dispatch entry: /* * set up our own stack first. We cannot rely on the kernels stack * to be large enough */ link a6,#0 lea gdos_stack_end,a7 move.l d1,a0 move.l d1,-(a7) bsr _c_dispatch unlk a6 rts .bss gdos_stack: .ds.b 32000gdos_stack_end: .ds.l 1 === eof ================================== I use the following simple command "gcc -c -odriv-init.o drv-init.s"This is with gcc v13.2.But it gives me the following errors : drv-init.s: Assembler messages:drv-init.s:9: Error: operands mismatch -- statement `link a6,#0' ignoreddrv-init.s:10: Error: operands mismatch -- statement `lea gdos_stack_end,a7' ignoreddrv-init.s:14: Error: operands mismatch -- statement `unlk a6' ignoreddrv-init.s:12: Error: can't resolve 0 - a7 I know this was working on older gcc v4, as I was relying on it for all my pdf program. So wat am I missing ?? |
|
From: Miro K. <mir...@gm...> - 2024-07-25 16:51:09
|
On Thu, 25 Jul 2024 at 16:29, Thorsten Otto <ad...@th...> wrote: > That allows you to trigger a rebuild of the current snapshot without > having to push anything to the repo. Useful mainly if some of the > prerequisites had changed (mintlib, gemlib, cflib etc.) > Thanks, that's indeed useful. >From what I recall, it should be possible to do this even automatically, i.e. dispatch the workflow via a REST API URL with some token. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-07-25 14:29:08
|
Hi, I've just added github workflow dispatch events to some repos (qed, toswin2, teradesk, cops). That allows you to trigger a rebuild of the current snapshot without having to push anything to the repo. Useful mainly if some of the prerequisites had changed (mintlib, gemlib, cflib etc.) To use it, go to the "Actions" tab in the web interface, then select the "Linux build" action. You should see something like Then just click on "Run workflow" to trigger a new run. |
|
From: David G. <dga...@gm...> - 2024-06-18 06:30:20
|
El lun, 17 jun 2024 a las 17:56, Anders Lindström (<ata...@gm...>) escribió: > > This is not really a question belonging to EmuTOS, but I was kindly wondering; how do I properly check the bogomips on Atari machines? > You can read it in the file U:\kern\cpuinfo > Regards.. > @nders > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Miro K. <mir...@gm...> - 2024-06-17 18:00:43
|
On Mon, 17 Jun 2024 at 17:56, Anders Lindström <ata...@gm...> wrote: > This is not really a question belonging to EmuTOS, but I was kindly > wondering; how do I properly check the bogomips on Atari machines? > Check out e.g. https://github.com/freemint/freemint/blob/master/sys/arch/kernfs_mach.c. -- http://mikro.atari.org |
|
From: Anders L. <ata...@gm...> - 2024-06-17 15:55:58
|
This is not really a question belonging to EmuTOS, but I was kindly wondering; how do I properly check the bogomips on Atari machines? Regards.. @nders |
|
From: Thorsten O. <ad...@th...> - 2024-06-14 14:51:47
|
On Freitag, 14. Juni 2024 15:31:12 CEST pslegg--- via Freemint-discuss wrote: > There is probably a good reason. Yes. The bootable aranym build is eg. compiled for 040, but it has also some aranym specific features built in (like the hostfs driver embedded into the kernel). The other CPU builds are just for convenience. There might be a few performance differences. E.g. when compiling for 020-60, the compiler avoids 32x32 multiplications and calls a library function instead, because that instruction has to be emulated by the ISP. But not so when you compile only for 020 or 030. Dunno how big the differences are, but the CPU builds are just optimized for a specific CPU, and may perform bad (or not work at all) on a different CPU. |
|
From: <ps...@sc...> - 2024-06-14 13:31:23
|
Hello, I update mint using the bootable builds, just habit. However, I was just looking at the cpu builds and noticed that they differ. There are 4 bootable builds and 6 cpu builds. freemint-latest-000-st_ste.zip 2024-06-12 16:42 8.6M freemint-latest-040-aranym.zip 2024-06-12 16:42 8.5M freemint-latest-02060-tt_falcon_clones.zip 2024-06-12 16:42 9.2M freemint-latest-col-firebee.zip 2024-06-12 16:42 8.2M freemint-latest-000.zip 2024-06-12 16:42 3.7M freemint-latest-040.zip 2024-06-12 16:42 3.5M freemint-latest-030.zip 2024-06-12 16:42 3.3M freemint-latest-060.zip 2024-06-12 16:42 3.3M freemint-latest-02060.zip 2024-06-12 16:42 4.3M freemint-latest-col.zip 2024-06-12 16:42 3.2M 1. The cpu builds have an 030 version. 2. The cpu builds have 060 as well as 02060 There is probably a good reason. Peter |
|
From: Miro K. <mir...@gm...> - 2024-06-13 17:16:34
|
On Thu, 13 Jun 2024 at 10:08, WongCK via Freemint-discuss < fre...@li...> wrote: > Having $SYSDIR as part of the pathname would be very use and helps a lot. > I have to rename the path to xaloader manually and so it becomes 2nd nature > to me when I update to a new snapshot. So it will be good to be able to use > this sysdir.tos instead. > Just for the sake of completeness -- there's an easier way, using the non-bootable snapshots. What I usually do on new installs is downloading both bootable and non-bootable builds. I copy tools from the bootable one (QED, TosWin2 etc) as well as initial configuration to the non-bootable (02060) one and since that moment I only update my drive with non-bootable builds <https://tho-otto.de/snapshots/freemint/cpu/> without setting up anything (as it's always depacked into c:\mint\1-19-cur). However with this sysdir.tos workaround... perhaps the meaning and usefulness of the CPU builds is not that high anymore. -- http://mikro.atari.org |
|
From: <ps...@sc...> - 2024-06-13 14:29:58
|
Great analysis. Peter On 12 Jun 2024, 18:42, at 18:42, "Miro Kropáček" <mir...@gm...> wrote: >On Wed, 24 Jan 2024 at 16:50, Philippe Noble <phi...@gm...> >wrote: > >> I am reviving this old thread as I continue to have an error message >with >> QED. >> >As I bumped into this yesterday on CT60TOS I told myself "Ok, this is >the >day this mystery gets solved". And it did: >https://github.com/freemint/qed/issues/8. :) > >-- >http://mikro.atari.org > > >------------------------------------------------------------------------ > > > >------------------------------------------------------------------------ > >_______________________________________________ >Freemint-discuss mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: WongCK <won...@ya...> - 2024-06-13 08:08:05
|
Ah Ok... thanks for confirming my thoughts about the program.Having $SYSDIR as part of the pathname would be very use and helps a lot. I have to rename the path to xaloader manually and so it becomes 2nd nature to me when I update to a new snapshot. So it will be good to be able to use this sysdir.tos instead.
Another idea.... the wallpaper in XaAES. I only have a 1 copy of the wall paper but few Mint release. So I do a symlink of the XA_FORM.MFD to the one single wallpaper. This helps to keep disk usage lower. And it is a simple copy over the symlink to the new snapshot xaaes resolution folder ( of course the resolution needs to be the same for all snapshot which is HD on my CT63).
On Thursday, 13 June 2024 at 03:44:12 pm SGT, Miro Kropáček <mir...@gm...> wrote:
On Thu, 13 Jun 2024 at 08:37, WongCK via Freemint-discuss <fre...@li...> wrote:
Enlighten me how to use sysdir,tos.
It's just a convenience tool. If you have your mint.cnf / xaaes.cnf all set up, you don't need it.
It is targeted for users which like to boot a new complete ("bootable") snapshot and then decide to keep it: with help of sysdir.tos you can just copy mint.cnf & xaaes.cnf from your old snapshot. Of course, you have to upgrade from a snapshot which is already using sysdir.tos.
Ideally, one day sysdir.tos will go away and mint.cnf will allow parsing either relative paths or paths like $SYSDIR/xaaes/xaloader.prg.
--
http://mikro.atari.org_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Miro K. <mir...@gm...> - 2024-06-13 07:43:56
|
On Thu, 13 Jun 2024 at 08:37, WongCK via Freemint-discuss <
fre...@li...> wrote:
> Enlighten me how to use sysdir,tos.
>
It's just a convenience tool. If you have your mint.cnf / xaaes.cnf all set
up, you don't need it.
It is targeted for users which like to boot a new complete ("bootable")
snapshot and then decide to keep it: with help of sysdir.tos you can just
copy mint.cnf & xaaes.cnf from your old snapshot. Of course, you have to
upgrade from a snapshot which is already using sysdir.tos.
Ideally, one day sysdir.tos will go away and mint.cnf will allow parsing
either relative paths or paths like $SYSDIR/xaaes/xaloader.prg.
--
http://mikro.atari.org
|
|
From: WongCK <won...@ya...> - 2024-06-13 06:37:21
|
So it is time to update Mint on my system.I found a sysdir.tos inside Mint folder of v1-19-731 - what does sysdir.tos do?I remember some talks of have the sysdir environment available for use within the mint.cnf or something like that or I am just talking out of my head ?? I briefly looked into the Mint.cnf and Xaaes.cnf but missed finding it. Enlighten me how to use sysdir,tos. Thanks guys. |
|
From: Miro K. <mir...@gm...> - 2024-06-12 17:42:37
|
On Wed, 24 Jan 2024 at 16:50, Philippe Noble <phi...@gm...> wrote: > I am reviving this old thread as I continue to have an error message with > QED. > As I bumped into this yesterday on CT60TOS I told myself "Ok, this is the day this mystery gets solved". And it did: https://github.com/freemint/qed/issues/8. :) -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-06-11 22:32:11
|
On Tue, 11 Jun 2024 at 22:31, Dan Horák <da...@da...> wrote: > isn't it possible to reduce the amount of debuginfo put into the object > files? If "-g" is used to compile gcc, can you try with "-g1" (or even > with "-g0")? gcc is now a C++ application and it adds huge amounts of > debuginfo data. And in theory passing "-Wl,--no-keep-memory > -Wl,--reduce-memory-overheads" to the linker flags might also help. > Those are good hints however I wasn't able to convince gcc's CFLAGS/CXXFLAGS to listen to me. When I left them as is, it was compiled with "-O2 -g ...". However when I ran "CFLAGS='-O2 -fomit-frame-pointer' CXXLAGS='-O2 -fomit-frame-pointer' ./configure" it was not only not taken into account but all that was left was "-g" during the compilation (i.e. even the "-O2" somewhere disappeared). Perhaps I did something wrong but the room/patience for experiments quickly ran out... On Tue, 11 Jun 2024 at 23:17, Thorsten Otto <ad...@th...> wrote: > BTW, how long did it run before it failed? > About 20 hours, on aranym-mmu. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-11 21:17:09
|
> just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. Thats sad news, but it sounds strange. Building for mingw32 and cygwin32 was still possible, and those should have similar limits. BTW, how long did it run before it failed? |
|
From: Dan H. <da...@da...> - 2024-06-11 20:30:51
|
On Tue, 11 Jun 2024 20:53:11 +0200 Miro Kropáček <mir...@gm...> wrote: > Hi, > > just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib > started to complain at the 2047 mark (mallocs failing very early on) and > IIRC 2 GiB is the limit of our TOS API anyway. > > The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but > finally failed on 'cc1plus' with being out of memory. So actually it seems > it was the linker's fault, not gcc's (for stage1 compilation I used my > native gcc 13.3.0 builds built by the cross compiler). > > So I guess that's it. There's no way to build gcc/g++ on Atari anymore. isn't it possible to reduce the amount of debuginfo put into the object files? If "-g" is used to compile gcc, can you try with "-g1" (or even with "-g0")? gcc is now a C++ application and it adds huge amounts of debuginfo data. And in theory passing "-Wl,--no-keep-memory -Wl,--reduce-memory-overheads" to the linker flags might also help. Fighting with OOM is not a uncommon issue in Linux distros on 32-bit platforms these days. Dan |
|
From: Christian H. <chr...@gm...> - 2024-06-11 20:03:39
|
That's really sad news :( Is it possible to build it on a Linux PC? Miro Kropáček <mir...@gm...> schrieb am Di., 11. Juni 2024, 20:54: > Hi, > > just wanted to share something with you: even having 1900 MB of TT RAM in > Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib > started to complain at the 2047 mark (mallocs failing very early on) and > IIRC 2 GiB is the limit of our TOS API anyway. > > The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but > finally failed on 'cc1plus' with being out of memory. So actually it seems > it was the linker's fault, not gcc's (for stage1 compilation I used my > native gcc 13.3.0 builds built by the cross compiler). > > So I guess that's it. There's no way to build gcc/g++ on Atari anymore. > > -- > http://mikro.atari.org > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Miro K. <mir...@gm...> - 2024-06-11 18:53:35
|
Hi, just wanted to share something with you: even having 1900 MB of TT RAM in Aranym didn't allow me to natively bootstrap gcc 13.3.0. FreeMiNT / mintlib started to complain at the 2047 mark (mallocs failing very early on) and IIRC 2 GiB is the limit of our TOS API anyway. The 1900 MB setup so-so passed the first (stage1) linking of 'cc1' but finally failed on 'cc1plus' with being out of memory. So actually it seems it was the linker's fault, not gcc's (for stage1 compilation I used my native gcc 13.3.0 builds built by the cross compiler). So I guess that's it. There's no way to build gcc/g++ on Atari anymore. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-06-09 16:35:09
|
On Sonntag, 9. Juni 2024 17:45:07 CEST WongCK via Freemint-discuss wrote: > I have been following the updates from polarssl to mbedtls. As you mentioned > in AF, the migration is pretty simple by just changing the prefix to > mbedtls. Yes, but mbedTLS has one big disadvantage compared to openssl/wolftls: they have completely removed support for TLSv1.1. In other libs it is also disabled by default, but it is still there and can be enabled if you compile the library yourself. So if you need that support because you are talking to old servers, newer versions of mbedtls might not work. OTOH, it is much smaller. >gcc-14 with enable-checking took 4 mins 15 secs >gcc-14 without enable-checking took 2 mins 52 secs Thats still quite a difference, would not have expected that. So recompiling them again was atleast not for nothing ;) |
|
From: WongCK <won...@ya...> - 2024-06-09 15:46:03
|
Thanks the Atari mbedtls link.
I already compiled it with gcc-14 and using it with my programs, except the programs are not upload to my website yet.The programs that uses TLS 1.3 on my website are still v3.40.
Unlike Rajah, I have been following the updates from polarssl to mbedtls. As you mentioned in AF, the migration is pretty simple by just changing the prefix to mbedtls. They even have a doc that tells you what to do.
Back to gcc topic....
Just for kicks, I measure compiling a small library that I use, using both gcc-14 with/without enable-checking:gcc-14 with enable-checking took 4 mins 15 secs
gcc-14 without enable-checking took 2 mins 52 secs So not double time.
I just used rather clumsy method to measure -- just put "date" into the Makefile before and after the compile, so nothing seriously scientific about it.
On Sunday, 9 June 2024 at 08:46:18 pm SGT, Thorsten Otto <ad...@th...> wrote:
> it's the latest v3.6.0.
That is now also available at
http://tho-otto.de/crossmint.php#mbedtls
(but was compiled by gcc-7)
_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Thorsten O. <ad...@th...> - 2024-06-09 12:46:02
|
> it's the latest v3.6.0. That is now also available at http://tho-otto.de/crossmint.php#mbedtls (but was compiled by gcc-7) |
|
From: WongCK <won...@ya...> - 2024-06-09 11:58:12
|
Thanks. I will try them.it's the latest v3.6.0. On Friday, 7 June 2024 at 09:21:53 pm SGT, Thorsten Otto <ad...@th...> wrote: I've recompiled them now without those checks (both gcc-13 and gcc-14). Time for another try ;) BTW, the code you sent me to trigger the bug was from mbedtls. Which version are you trying to compile? _______________________________________________ Freemint-discuss mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2024-06-07 13:21:30
|
I've recompiled them now without those checks (both gcc-13 and gcc-14). Time for another try ;) BTW, the code you sent me to trigger the bug was from mbedtls. Which version are you trying to compile? |
|
From: WongCK <won...@ya...> - 2024-06-07 12:05:37
|
I felt it was like double the time to compile the same code as compared to before.Did not measure it but so may be in the region of 50% may be more realistic.
On Friday, 7 June 2024 at 01:45:24 am SGT, Miro Kropáček <mir...@gm...> wrote:
On Thu, 6 Jun 2024 at 17:23, Thorsten Otto <ad...@th...> wrote:
As far as i've seen, that mostly enable some assertion checks. That should normally be hardly noticable, given that the compiler is surely already not very fast on real hardware.
>From my experience on working on ScummVM, asserts did make a big difference. People normally (i.e. on PC) don't notice them (except some extreme cases) but on Atari, all it takes is one assert in an often-called inner loop and performance goes 50% down.
I have no problem removing that again, with the risc that if the compiler generates bad code, this will be harder to notice. In the worst case, it will cause you to hunt bugs in your code that are really just the compilers fault ;)
If you take into account that such a bug occurs maybe once per year, I think it's ok. We can always provide an additional build with the check(s) enabled when such situations occur.
--
http://mikro.atari.org_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
5 messages has been excluded from this view by a project administrator.
