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
(11) |
Sep
|
Oct
|
Nov
|
Dec
|
|
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. |
|
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 |
5 messages has been excluded from this view by a project administrator.
