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: Miro K. <mir...@gm...> - 2024-09-15 19:28:34
|
>
> I can see the implementation of O_GLOBAL but I'm not 100% confident of its
> purpose. To me it looks like a way to ensure that whatever file is opened
> (even created in the past), it should be always handled as a file belonging
> to the root process ("MiNT") and not others (AESSYS, NEWDESK, SCREEN etc).
> That seems to have some unique properties like ensuring that no key is lost
> due to task switching (or so, happy to be corrected here). The way it was
> implemented was quite weird, basically any process handle >= 100 was
> considered global, essentially limiting the number of open (non-global)
> file handles to 99.
>
I have spent some time looking into this and now I get it (I think). The
idea behind O_GLOBAL is that one process (e.g. the root one) can
open/create a file (identified by a file handle) and other processes
(NEWDESK, AESYSS, ...) can read/write from/to it. You might think "huh? but
why not just pass them the same file handle upon opening?" and that's the
issue here: in a multitasking OS, file handles are a process property. So
file handle = 6 is a different file for "MiNT", different file for "AESSYS"
etc.
In a nutshell:
- "MiNT" (the kernel) opens /dev/console for read/write
- "AESSYS" opens /dev/console for read/write with O_GLOBAL and gets a
file handle
- ("AESSYS" somehow distributes returned file handle to everyone
interested, perhaps as "this is the console device")
- Everyone can now read and write from/to /dev/console as if they were
all root processes
As this has been deprecated, I'm wondering: couldn't we just make one flag
> in console.c (or dosfile.c) which would tell "this file handle is
>
global because it belongs to /dev/console" and treat it always as root
> process handle?
>
Now we see that this is not possible: we can't compare file handles and
even process IDs: any process is allowed to access the "root file handle"
and yet any process can have the same file handle (e.g. 6) used for
completely different purposes! So the only way to differentiate between
those two is to add some kind of flag to the returned file handle value.
Original MiNT authors decided to use +100 but OR'ing e.g. 0x8000 to the
resulting file handle would work perfectly well, too.
So this is the reason why Helmut's workaround works only partially: it just
pretends that O_GLOBAL doesn't exist. So sometimes it reads from the
correct file handle (AESSYS is reading from regular /dev/console),
sometimes reading fails (e.g. NEWDESK is instructed to open file handle = 6
for accessing /dev/console and it fails because it doesn't have such a file
handle assigned) and sometimes it reads garbage (because file handle = 6 is
e.g. c:\cops.inf and not /dev/console...).
So what can be done about it?
1. Reverting back to the original O_GLOBAL code for /dev/console but
using a much bigger offset (e.g. 0x8000, i.e. max 32k opened files)
2. Making sure that the file handle assigned to "AESSYS" is never used
in another process, i.e. making the comparison in the way I'm proposing
above
3. ???
Having in mind that removal of O_GLOBAL led to lifting the max file
handles limit from 32 to 1024, I don't have any bad feelings about doing
the first proposal with 0x8000. It's tested and easy to understand but
maybe the second one is a bit cleaner. I don't know.
Oh and since we need this workaround in any case (to make N.AES, AES 4.1
and maybe others happy), we can apply a similar exception to the other bad
boy in town: slip.xif.
--
http://mikro.atari.org
|
|
From: Miro K. <mir...@gm...> - 2024-09-15 11:25:22
|
Hi, I guess I'll post it here for better visibility. Basically I'm trying to solve a bag if issues: - https://github.com/freemint/freemint/issues/143 (N.AES not working with /dev/console) - https://github.com/freemint/freemint/issues/173 (AES 4.1 stuck keyboard, mouse freeze and non-working double-click) - https://github.com/freemint/freemint/issues/378 (basically #173) All of those are caused by removal of O_GLOBAL handling in https://github.com/freemint/freemint/commit/9668d6797eaed45ffd9ee8e32770fb04e453f11a. Helmut realised the same thing and even provided a fix for it: https://mikro.naprvyraz.sk/mint/201511/msg00014.html so I have just implemented it in my PR here: https://github.com/freemint/freemint/pull/379. However, as it turns out, this fix solves most of the issues but not all of them. Most notably the double-click issue and to some extent also the stuck key issue (occasionally AES 4.1 still "overflows" with some stray keyboard characters). I can see the implementation of O_GLOBAL but I'm not 100% confident of its purpose. To me it looks like a way to ensure that whatever file is opened (even created in the past), it should be always handled as a file belonging to the root process ("MiNT") and not others (AESSYS, NEWDESK, SCREEN etc). That seems to have some unique properties like ensuring that no key is lost due to task switching (or so, happy to be corrected here). The way it was implemented was quite weird, basically any process handle >= 100 was considered global, essentially limiting the number of open (non-global) file handles to 99. As this has been deprecated, I'm wondering: couldn't we just make one flag in console.c (or dosfile.c) which would tell "this file handle is global because it belongs to /dev/console" and treat it always as root process handle? Thorsten perhaps implied something similar here: https://github.com/freemint/freemint/pull/379#issuecomment-2351411469 but I want to double check. To me it seems like the best of both worlds, /dev/console is always global and we don't need any kludges limiting the number of open file descriptors. -- http://mikro.atari.org |
|
From: Miro K. <mir...@gm...> - 2024-08-28 12:28:07
|
On Wed, 28 Aug 2024 at 13:30, Thorsten Otto via Freemint-discuss < fre...@li...> wrote: > Could there be something wrong in mintlib? Would be rather strange that > this bug has not occured anywhere else. > There always could be something wrong in our Atari world. ;) > The program needs NVDI to be installed (its purpose is to print out most > values of the NVDI structure). I've attached it below (pnvdi.tos is the > Pure-C version, pnvdi is the version compiled by gcc). > I guess the first step should be removal of the NVDI dependency (e.g. you can let it print an uninitialised struct or set it to some custom values), and then basically shave it to the last printf. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-08-28 12:18:35
|
Argl, forget it. I forgot that i also tried to call some functions in the kernel, but those use Pure-C calling convention and cannot be easily called from gcc. But still strange that it worked when run for the first time. |
|
From: Thorsten O. <ad...@th...> - 2024-08-28 11:30:10
|
Hi, I have a strange problem here with a program that does some printf to the screen and at the same time to a file. It works fine when run for the first time. However, when running it again, it - pauses after some lines of output for a few seconds, then continues - it then prints a few more lines, and hangs (or pauses for more than 10 min, did not wait longer before killing it) I first thought it might be a problem with toswin2, so i modified the first version to write to an output file only, but this had the same effect, even when not doing any screen output at all. Then i thought it might be a problem of aranym, but the same program compiled by Pure-C does not have this issue. Could there be something wrong in mintlib? Would be rather strange that this bug has not occured anywhere else. The program needs NVDI to be installed (its purpose is to print out most values of the NVDI structure). I've attached it below (pnvdi.tos is the Pure-C version, pnvdi is the version compiled by gcc). |
|
From: WongCK <won...@ya...> - 2024-08-21 00:50:48
|
As a quick fix, just use characters for the classical ST resolutions for now.
On Tuesday, 20 August 2024 at 07:25:18 pm SGT, skaftetryne <not...@gi...> wrote:
Almost all of the widget sets are made for colour/high resolution modes and would not look good in med-res anyway. Maybe a dedicated widget set for med-res would be the easiest solution?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <freemint/freemint/issues/360/229...@gi...>
|
|
From: OL <o....@lu...> - 2024-08-20 20:05:37
|
Ok compil cflib and gemlib (need new one for cflib), now Qed work as expected Thanks for help Olivier > Ok try compil cflib and see > >> And yet another problem could be that I was messing with CF-Lib a >> while ago which resulted in a regression in Qed which I just fixed a >> couple of days ago: >> https://github.com/freemint/qed/commit/502a8b0c2f3e65728e10fdfee8231f5c24a85eb9. >> >> While I can't imagine how this particular fix could influence ... >> oooooh wait. Do you have the latest CF-Lib installed? Because if you >> don't then yes, this can lead to exactly that kind of issue as you >> described. >> >> On Tue, 20 Aug 2024 at 07:00, Thorsten Otto <ad...@th...> wrote: >> >> On Dienstag, 20. August 2024 00:15:08 CEST OL wrote: >> >> > Any idea why? Issue with my old GCC 4 configuration? >> >> >> Maybe. Argument parsing is done in mintlib. Another problem could >> be how is it started. Does the shell/desktop use ARGV to pass >> parameters? Your problem sounds as if someone incorrectly >> terminates the commandline in the BASEPAGE. >> >> >> >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss >> >> >> >> -- >> http://mikro.atari.org >> >> >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss > > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: OL <o....@lu...> - 2024-08-20 18:41:38
|
Ok try compil cflib and see > And yet another problem could be that I was messing with CF-Lib a > while ago which resulted in a regression in Qed which I just fixed a > couple of days ago: > https://github.com/freemint/qed/commit/502a8b0c2f3e65728e10fdfee8231f5c24a85eb9. > > While I can't imagine how this particular fix could influence ... > oooooh wait. Do you have the latest CF-Lib installed? Because if you > don't then yes, this can lead to exactly that kind of issue as you > described. > > On Tue, 20 Aug 2024 at 07:00, Thorsten Otto <ad...@th...> wrote: > > On Dienstag, 20. August 2024 00:15:08 CEST OL wrote: > > > Any idea why? Issue with my old GCC 4 configuration? > > > Maybe. Argument parsing is done in mintlib. Another problem could > be how is it started. Does the shell/desktop use ARGV to pass > parameters? Your problem sounds as if someone incorrectly > terminates the commandline in the BASEPAGE. > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > > > > -- > http://mikro.atari.org > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: OL <o....@lu...> - 2024-08-20 18:40:39
|
I just drag a file from desktop on Qed icon to start Qed. > > On Dienstag, 20. August 2024 00:15:08 CEST OL wrote: > > > Any idea why? Issue with my old GCC 4 configuration? > > > Maybe. Argument parsing is done in mintlib. Another problem could be > how is it started. Does the shell/desktop use ARGV to pass parameters? > Your problem sounds as if someone incorrectly terminates the > commandline in the BASEPAGE. > > > > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2024-08-20 09:46:55
|
On Samstag, 17. August 2024 19:41:04 CEST Miro Kropáček wrote: > I have just fixed a stupid bug in QED and I can't propagate it back to the > snapshots. Should be fixed now. Currently building anyway because of the push, but you can test afterwards. |
|
From: Miro K. <mir...@gm...> - 2024-08-20 08:12:06
|
And yet another problem could be that I was messing with CF-Lib a while ago which resulted in a regression in Qed which I just fixed a couple of days ago: https://github.com/freemint/qed/commit/502a8b0c2f3e65728e10fdfee8231f5c24a85eb9 . While I can't imagine how this particular fix could influence ... oooooh wait. Do you have the latest CF-Lib installed? Because if you don't then yes, this can lead to exactly that kind of issue as you described. On Tue, 20 Aug 2024 at 07:00, Thorsten Otto <ad...@th...> wrote: > On Dienstag, 20. August 2024 00:15:08 CEST OL wrote: > > > Any idea why? Issue with my old GCC 4 configuration? > > Maybe. Argument parsing is done in mintlib. Another problem could be how > is it started. Does the shell/desktop use ARGV to pass parameters? Your > problem sounds as if someone incorrectly terminates the commandline in the > BASEPAGE. > > > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-08-20 05:00:01
|
On Dienstag, 20. August 2024 00:15:08 CEST OL wrote: > Any idea why? Issue with my old GCC 4 configuration? Maybe. Argument parsing is done in mintlib. Another problem could be how is it started. Does the shell/desktop use ARGV to pass parameters? Your problem sounds as if someone incorrectly terminates the commandline in the BASEPAGE. |
|
From: OL <o....@lu...> - 2024-08-19 22:30:26
|
Hello I have compiled Qed from current github repo, Qed look work except failed to pass parameter correctly, path to a file is not complete last letter is lost, so Qed can't find file. Any idea why? Issue with my old GCC 4 configuration? Olivier |
|
From: WongCK <won...@ya...> - 2024-08-18 16:07:32
|
Actually the most important thing for me is that my Falcon is still working, so any software that I am using even if the GUI is not exactly looking what is suppose to be, I will take it. For I do not know when will I cannot use it any more... when will my bird stop flying... I cannot tell.
On Monday, 19 August 2024 at 12:03:52 am SGT, WongCK <won...@ya...> wrote:
Yes Mikro, correct.Changing XaAES to keep up with the modern times and any great ideas that we see other GUI are having.... and also to be keeping compatible with as many of the old software are possible ( due to lack of new applications).
No Lonny. I do not know those stuff you mentioned especially the technical ones... way above my head.
If that $ char appears, I probably move my mouse over it to see what effect it has.If it pop-down a menu, fine. If it does nothing, fine.So long as the program works as expected, it is great.
May be I have a big tolerance for defective GUI at least for the Atari - I don't mind if arrows or menu rendering is off by an centimeter so long as it register the click. There are many old software that I have come across having GUI issues. may it is my screen resolution, may be it is my number of colours, may be the wrong RSC for that resolution or even may be RSC translation messed something... IDK.
It great that you guys are fixing all these.... even a 1 pixel offset. Frankly, I will not seen that given my eye sight.
And so I thank to all of you for contributing to Mint XaAES Emutos GBE.(for giving ordinary users the ability make great stuff)... and keep the platform alive
On Sunday, 18 August 2024 at 11:20:10 pm SGT, Lon Pursell <not...@gi...> wrote:
@mikrosk: The artifact build passes all my tests, even my stress tests that are fully within Atari's guidelines. The indicator looks consistent across all apps even RSM which attempts use 2 different indicators ends up using only the configured one.
Another suggestion. I'd like to see the config option changed if possible so any asc code can be applied. I think asc 175 would look nice and give even more options for personal customization.
* @lpgb @GokMasE please review (just the two commits, the reverting one is not needed)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <freemint/freemint/pull/369/c22...@gi...>
|
|
From: WongCK <won...@ya...> - 2024-08-18 16:04:08
|
Yes Mikro, correct.Changing XaAES to keep up with the modern times and any great ideas that we see other GUI are having.... and also to be keeping compatible with as many of the old software are possible ( due to lack of new applications).
No Lonny. I do not know those stuff you mentioned especially the technical ones... way above my head.
If that $ char appears, I probably move my mouse over it to see what effect it has.If it pop-down a menu, fine. If it does nothing, fine.So long as the program works as expected, it is great.
May be I have a big tolerance for defective GUI at least for the Atari - I don't mind if arrows or menu rendering is off by an centimeter so long as it register the click. There are many old software that I have come across having GUI issues. may it is my screen resolution, may be it is my number of colours, may be the wrong RSC for that resolution or even may be RSC translation messed something... IDK.
It great that you guys are fixing all these.... even a 1 pixel offset. Frankly, I will not seen that given my eye sight.
And so I thank to all of you for contributing to Mint XaAES Emutos GBE.(for giving ordinary users the ability make great stuff)... and keep the platform alive
On Sunday, 18 August 2024 at 11:20:10 pm SGT, Lon Pursell <not...@gi...> wrote:
@mikrosk: The artifact build passes all my tests, even my stress tests that are fully within Atari's guidelines. The indicator looks consistent across all apps even RSM which attempts use 2 different indicators ends up using only the configured one.
Another suggestion. I'd like to see the config option changed if possible so any asc code can be applied. I think asc 175 would look nice and give even more options for personal customization.
* @lpgb @GokMasE please review (just the two commits, the reverting one is not needed)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <freemint/freemint/pull/369/c22...@gi...>
|
|
From: WongCK <won...@ya...> - 2024-08-18 10:43:01
|
Pretty sad to see you guys tearing it here.
Hanging on to some specs that are 40 years old, how can we progress ?Comparing to NAES and TOS AES.... why? You should be comparing to something more modern say... Windoze/Linux GUI.Yeah aim for the sky and see how high we can go.Like MyAES has some stuff similar to Windoze GUI (ala mouse over the task bar shows a small window of the application running... blew my mind off or am I just dreaming).
Keep making XaAES work with old programs, that's a priority as we have not many development like work processor, spreadsheet and email clients.May be some users are still using LDW Power or Pheonix instead of Sheets. IDK.
New programs... please go on to the new standard of XaAES.What new standard you ask.... chicken and egg...it will not happen if you guys keep on saying 40 year old standard is the standard.New programs should not just implement stuff... like 3 arrows.... but bring to the group for discussion.
Hey... the 3 arrows means so and so can we do something in AES ?
I know the fun that we all had the last 40 years when we were developing. That was the old cowboy town days where every maverick do whatever he wants as TOS only running 1 application (ok, i am not counting the ACC) and you can have your own nifty GUI doing your own widget and stuff. But now in multitasking where several applications are running, you should try to not show off your 3 arrows or $ or %% or whatever char.As a user, I want it to look similar.
And of course wants to have newer looking and cleverer GUI.
May be the whole rework job is needed, not just a band-aid.
my 2 cents....
On Saturday, 17 August 2024 at 09:55:32 pm SGT, Lon Pursell <not...@gi...> wrote:
Here's my take. The original code inserted the indicator into the string exactly like atari's code does with the exception it was off by 1. This could of been fixed with an extremely minimal fix to attach_menu() and detach_menu(). That's what I was expecting. However, an executive decision was made to completely rework it so the indicator was superimposed on top of the menu entry with the "assumption we might need an image in the future". This makes it harder to comply with Atari's rules, plus more overhead, two vdi calls for an assumption that isn't proven. This fundamental change should of been discussed before it was implemented. There would of been pushback from me and possibly others. i'm not mad at anyone, I just wish there was more discussion and communication before big changes are made.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <freemint/freemint/pull/369/c22...@gi...>
|
|
From: Thorsten O. <ad...@th...> - 2024-08-17 17:51:54
|
On Samstag, 17. August 2024 19:41:04 CEST Miro Kropáček wrote: > I have just fixed a stupid bug in QED and I can't propagate it back to the > snapshots. Hm, seems the deploy step was not run at all: https://github.com/freemint/ freemint/actions/runs/10434067283/job/28896512441 |
|
From: Miro K. <mir...@gm...> - 2024-08-17 17:41:23
|
On Thu, 25 Jul 2024 at 16:29, Thorsten Otto <ad...@th...> wrote: > 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.) > It seems the button is available also for 'freemint' but it doesn't deploy and upload the artifact to your server. I have just fixed a stupid bug in QED and I can't propagate it back to the snapshots. -- http://mikro.atari.org |
|
From: Thorsten O. <ad...@th...> - 2024-08-17 12:16:09
|
On Samstag, 17. August 2024 14:01:17 CEST Jo Even Skarstein wrote: > What is the > correct way to detect the presence of this feature? If the "video" > parameter is removed in the future I would want the videomode selector > to support both. I think there is no reliable way of detecting whether xaaes uses the old name (video =) or the new name (mode =), since both are usually commented out. It should be safe however to simply write both entries, in the worst case you get a warning about an unknown variable in xa_boot.log. The changes were introduced in 3223f88c432f07b5572d225904659b7d97143c0f, and later documented in https://github.com/freemint/freemint/commit/ ee484c1c45e64cb2487273825d65ddb6e7109e59 |
|
From: Jo E. S. <jo...@on...> - 2024-08-17 12:01:38
|
I'm about to release a new version of the VanillaMiNT screenmode selector, now with SuperVidel-support. But I see that there's now a new (to me at least!) way of specifying video mode in XaAES. What is the correct way to detect the presence of this feature? If the "video" parameter is removed in the future I would want the videomode selector to support both. Jo Even |
|
From: Thorsten O. <ad...@th...> - 2024-08-16 07:46:01
|
On Freitag, 16. August 2024 09:15:11 CEST Miro Kropáček wrote: > once it is available and tested with our patches New major gcc versions are released about once a year, so i would expect that to happen around May 2025. If you really want to test that before that release, you would have to create a branch from the current master with our patches, but then you will mostly likely have lots of merge conflicts everytime you try to merge updates to the master branch into it. Seems we also have to be careful with newer releases now, as the bug with fold-mem-offset has shown. gcc developers refuse to revert improvements even if they have been proven to generate wrong code in some cases, and even if it does not work after several attempts of fixing it. See https://gcc.gnu.org/ bugzilla/show_bug.cgi?id=113357 Also i don't think that this new attribute will be very useful for the mint kernel, as it mostly has an effect when compiling everything with runtime array bounds checking. |
|
From: Miro K. <mir...@gm...> - 2024-08-16 07:15:34
|
Hi, this sounds incredibly useful and I'd argue it is a great reason why to upgrade kernel builds to GCC 15 also for us, once it is available and tested with our patches, so we can start using it: https://people.kernel.org/gustavoars/how-to-use-the-new-counted_by-attribute-in-c-and-linux . Of course, it wont be so easy, see e.g. https://github.com/freemint/m68k-atari-mint-gcc/issues/41 or https://github.com/freemint/m68k-atari-mint-binutils-gdb/issues/12 for examples of what kind of risks to expect. -- http://mikro.atari.org |
|
From: Mark D. <mdu...@at...> - 2024-08-09 14:00:59
|
Hello all, I noticed this: https://www.ebay.com/itm/186620082849 Says it has an MMU and 64MB of RAM. With a custom developed shield for sound and video it might make a nice tiny firebee like machine with emutos and freemint ported to it. Thanks, Mark |
|
From: WongCK <won...@ya...> - 2024-08-09 09:26:52
|
Thanks for the hints, will try them. On Friday, 9 August 2024 at 01:16:37 pm SGT, Thorsten Otto <ad...@th...> wrote: On Freitag, 9. August 2024 05:49:59 CEST WongCK via Freemint-discuss wrote: > So wat am I missing ?? You need to use the % register prefix on all register names when using the mintelf toolchains. Also note that this toolchain does not prepend a '_' to external names, so something like bsr _c_dispatch will most likely produce a link error. _______________________________________________ Freemint-discuss mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Thorsten O. <ad...@th...> - 2024-08-09 05:16:09
|
On Freitag, 9. August 2024 05:49:59 CEST WongCK via Freemint-discuss wrote: > So wat am I missing ?? You need to use the % register prefix on all register names when using the mintelf toolchains. Also note that this toolchain does not prepend a '_' to external names, so something like bsr _c_dispatch will most likely produce a link error. |
5 messages has been excluded from this view by a project administrator.
