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: Helmut K. <hel...@is...> - 2018-04-28 07:41:56
|
Am 28.04.2018, 09:29 Uhr, schrieb Thorsten Otto: > On Samstag, 28. April 2018 09:00:17 CEST Helmut Karlowski via > Freemint-discuss > wrote: >> I have assigned Alt-F-shortcuts in the toswin2-rsc > > That does not help much if Toswin2 is not already on top. That's why I support the XaAES-shortcuts-solution. > Also ALT-F2 is imho > a bad choice, since those shortcuts are reserved by the window manager. I chose it because in mintty it's the same, but you can use what you want. What is the "window manager", the AES? |
|
From: Thorsten O. <ad...@th...> - 2018-04-28 07:30:36
|
On Samstag, 28. April 2018 09:00:17 CEST Helmut Karlowski via Freemint-discuss wrote: > I have assigned Alt-F-shortcuts in the toswin2-rsc That does not help much if Toswin2 is not already on top. Also ALT-F2 is imho a bad choice, since those shortcuts are reserved by the window manager. |
|
From: Helmut K. <hel...@is...> - 2018-04-28 07:00:37
|
Am 28.04.2018, 06:21 Uhr, schrieb WongCK via Freemint-discuss: I have assigned Alt-F-shortcuts in the toswin2-rsc. Now for example Alt-F2 opens a shell. Don't know if that would work with the official toswin2.7, if not: Ctrl-Alt-Space, cursor right, cursor down, Return would be the not so short shortcut. Toswin has to be top of course. The advantage of having those shortcuts in XaAES would be that you would not have to top something first. |
|
From: WongCK <won...@ya...> - 2018-04-28 04:21:14
|
I always have "toswin2 -l" in my xaaes.cfg so that it opens the bash shell for me on bootup, as I always uses command line to do stuff. It would be indeed nice to open another shell with key combo, I do it now via Joska excellent taskbar menus using mouse.
Most desktop allows you to define F-keys to open application. But then it is not ctrl-alt-T. Further more the desktop may just try to run another instance of the program and you probably asked if you want to run another instance by Mint. Probably not exactly what you want.
Toswin2 probably VA-protocol aware but what's the command to open another shell like how Taskbar does?I know it's in the source but I am too lazy... LOL
On Saturday, 28 April 2018, 8:50:43 AM GMT+8, Miro Kropáček <mir...@gm...> wrote:
On 28 April 2018 at 04:14, Peter Slegg <p....@sc...> wrote:
Even Function Key settings in Thing don't help. This is why I suggested
the ctrl-alt-T option.
Are you sure? Assigning a key for "toswin2.app -l" should do exactly what you want.
--
MiKRO / Mystic Bytes
http://mikro.atari.org------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Freemint-discuss mailing list
Fre...@li...
https://lists.sourceforge.net/lists/listinfo/freemint-discuss
|
|
From: Miro K. <mir...@gm...> - 2018-04-28 00:50:39
|
On 28 April 2018 at 04:14, Peter Slegg <p....@sc...> wrote: > Even Function Key settings in Thing don't help. This is why I suggested > the ctrl-alt-T option. > Are you sure? Assigning a key for "toswin2.app -l" should do exactly what you want. -- MiKRO / Mystic Bytes http://mikro.atari.org |
|
From: Peter S. <p....@sc...> - 2018-04-27 20:14:32
|
I always have TosWin2 running but only with the basic console open just to capture any messages. Oddly, there is no keyboard shortcut in TosWin2 to open the shell window, you have to use the menu. Even Function Key settings in Thing don't help. This is why I suggested the ctrl-alt-T option. Peter On Thu, 26 Apr 2018 23:41:13 , Helmut Karlowski via Freemint-discuss <fre...@li...> wrote: Am 26.04.2018, 03:02 Uhr, schrieb Miro KropÃíÄìek: > I don't know, is it really that needed? Many people run XaAES without the > Unix side, i.e. it would just open a black blank screen. And then others > could argue that they need App X or Y as a shortcut too. One could add for xaaes.cnf something like: Launch a program: xkey=k,launch,xy.prg,... In case of a text-program a toswin2-window would be opened. xkey=t,top,xyz Top client xyz (all windows). xkry=w,topw,bla Top top-window of client bla. That would be unrelated to any unix-things. Maybe something for next-years update ;) -Helmut ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Freemint-discuss mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freemint-discuss |
|
From: Helmut K. <hel...@is...> - 2018-04-26 21:53:13
|
Am 26.04.2018, 03:02 Uhr, schrieb Miro Kropáček: > I don't know, is it really that needed? Many people run XaAES without the > Unix side, i.e. it would just open a black blank screen. And then others > could argue that they need App X or Y as a shortcut too. > > Personally, I'm happy with having it as an entry in XaAES.cnf run entry. > > On Thu., 26 Apr. 2018, 3:53 am Peter Slegg, <p....@sc...> > wrote: > >> >> In other unix like OSes, ctrl-alt-T launches a terminal app. >> >> Does XaAES offer a similar feature to open the shell in TosWin2 >> or a similar app ? Is there something that can be configured ? >> >> >> >> Peter >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Freemint-discuss mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freemint-discuss >> -- |
|
From: Helmut K. <hel...@is...> - 2018-04-26 21:52:58
|
Am 26.04.2018, 03:02 Uhr, schrieb Miro Kropáček: > I don't know, is it really that needed? Many people run XaAES without the > Unix side, i.e. it would just open a black blank screen. And then others > could argue that they need App X or Y as a shortcut too. One could add for xaaes.cnf something like: Launch a program: xkey=k,launch,xy.prg,... In case of a text-program a toswin2-window would be opened. xkey=t,top,xyz Top client xyz (all windows). xkry=w,topw,bla Top top-window of client bla. That would be unrelated to any unix-things. Maybe something for next-years update ;) -Helmut |
|
From: Miro K. <mir...@gm...> - 2018-04-26 01:03:04
|
I don't know, is it really that needed? Many people run XaAES without the Unix side, i.e. it would just open a black blank screen. And then others could argue that they need App X or Y as a shortcut too. Personally, I'm happy with having it as an entry in XaAES.cnf run entry. On Thu., 26 Apr. 2018, 3:53 am Peter Slegg, <p....@sc...> wrote: > > In other unix like OSes, ctrl-alt-T launches a terminal app. > > Does XaAES offer a similar feature to open the shell in TosWin2 > or a similar app ? Is there something that can be configured ? > > > > Peter > > > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Freemint-discuss mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freemint-discuss > |
|
From: Peter S. <p....@sc...> - 2018-04-25 19:53:41
|
In other unix like OSes, ctrl-alt-T launches a terminal app. Does XaAES offer a similar feature to open the shell in TosWin2 or a similar app ? Is there something that can be configured ? Peter |
|
From: Vincent R. <vin...@fr...> - 2018-04-25 14:00:10
|
On 25/04/2018 à 06:30, Markus Fröschle wrote: > You still need to set NO_AKP_KEYBOARD (unless you have an Eiffel, that is). You are right. My next plan was to convert NO_AKP_KEYBOARD to something dynamically detected. But you know, laziness and other things to do... -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-04-25 07:14:23
|
2018-04-25 0:21 GMT+02:00 Vincent Rivière <vin...@fr...>: > > In case of FireTOS, the _CPU cookie reflects what the *emulated* CPU is > supposed to be. Maybe it should be the same for Ssystem(), that would make > sense. Then provide new *documented* way to add information for ColdFire, > which can't clash with any 680x0 values. > The information given by this system call is independent from the machine you're running the kernel on, so it can be a bit confusing. It's the option it was used to compile the kernel. If you're using a 060 kernel with FireTOS it will return 68060 but if you are using a 5475 kernel it will return a ColdFire kernel with isa_b instruction set. >From the documentation: "This is not the same as the _CPU cookie value. The _CPU cookie specifies the CPU physically present in the machine, while the S_OSCOMPILE indicates the processor type selected at the time when the system was compiled. In other words, running a 68000-compiled kernel will return a 0x00 here, even if the machine is running 68040 or something." |
|
From: Markus F. <mf...@mu...> - 2018-04-25 04:30:43
|
You still need to set NO_AKP_KEYBOARD (unless you have an Eiffel, that is). Am 25.04.2018 um 00:07 schrieb Vincent Rivière: > On 22/04/2018 at 07:13, Markus Fröschle wrote: >> Note that FreeMiNT works fine on other ColdFire boards (like the M5484 >> Evaluation Board) as well. >> >> It's just that it never found its way into the Makefile as specific >> target but requires manual fiddling with CONFIGVARS. > > I'm unsure what you mean... > Anyway, the official mintv4e.prg works fine with both FireBee (EmuTOS > and FireTOS) and ColdFire, this is why there is no specific support in > the Makefile. > And as it is unlikely to go out of RAM on such machines, it is OK to > put all features inside mintv4e.prg and then enable them at runtime > when proper hardware is detected. > > Finally, considering the above statement, it can explain why there is > no specific define to specify the current target... as current target > is just a CPU (ColdFire V4e) with support for any hardware. > |
|
From: Vincent R. <vin...@fr...> - 2018-04-24 22:21:50
|
On 23/04/2018 at 19:03, Thorsten Otto wrote: > The best thing would maybe to set the major cpu id to 1, as that, according to > the documentation, would indicate a non-m68k processor. That makes sense. Key point is: ColdFire is not 680x0. In EmuTOS for ColdFire, I have even removed the _CPU cookie, as it doesn't make sense on a non-680x0 CPU. But beware at something. The above is true for EmuTOS, where the CPU is pure ColdFire without any emulation. But with FireTOS, the situation is different. The ColdFire is *partially* available - user ColdFire instructions are available (not even fully true, as incompatible instruction such as move.b to stack are partially hacked to mimic 68000 behaviour) - but ColdFire supervisor instructions are not available at all, hidden by the CF68KLib (remember that *all* programs running on FireTOS actually run in user mode, even when they think they have switched to supervisor) In case of FireTOS, the _CPU cookie reflects what the *emulated* CPU is supposed to be. Maybe it should be the same for Ssystem(), that would make sense. Then provide new *documented* way to add information for ColdFire, which can't clash with any 680x0 values. -- Vincent Rivière |
|
From: Vincent R. <vin...@fr...> - 2018-04-24 22:07:58
|
On 22/04/2018 at 07:13, Markus Fröschle wrote: > Note that FreeMiNT works fine on other ColdFire boards (like the M5484 > Evaluation Board) as well. > > It's just that it never found its way into the Makefile as specific > target but requires manual fiddling with CONFIGVARS. I'm unsure what you mean... Anyway, the official mintv4e.prg works fine with both FireBee (EmuTOS and FireTOS) and ColdFire, this is why there is no specific support in the Makefile. And as it is unlikely to go out of RAM on such machines, it is OK to put all features inside mintv4e.prg and then enable them at runtime when proper hardware is detected. Finally, considering the above statement, it can explain why there is no specific define to specify the current target... as current target is just a CPU (ColdFire V4e) with support for any hardware. -- Vincent Rivière |
|
From: David G. <dga...@gm...> - 2018-04-24 18:42:47
|
I've just commit the additions to Ssystem( ). Major CPU ID will be 0x01 for the ColdFire processors. And the minor ID for the ColdFire will be: 0x00 for isa_a 0x01 for isa_a+ 0x02 for isa_b 0x03 for isa_c |
|
From: Peter S. <p....@sc...> - 2018-04-23 21:23:34
|
Has anyone tried SQLite3 from the Sparemint RPMs ? I can create and modify tables but want to open a db from a Windos application. It opens in the SQLite brower on Lubuntu and I can open it from FreeMint bash but any other commands fail: bash-4.3# sqlite3 dive_book_1.db SQLite version 3.2.2 Enter ".help" for instructions sqlite> .schema Error: unsupported file format I suspect some difference in the file versions but they are both SQLite3. The first few characters of the file look like this: SQLite format 3 Peter |
|
From: Peter S. <p....@sc...> - 2018-04-23 20:53:26
|
On Mon, 23 Apr 2018 22:49:52 , Thorsten Otto <ad...@th...> wrote: > On Montag, 23. April 2018 22:30:37 CEST Peter Slegg wrote: > > Perhaps wget or wget-ssl could be re-built to the latest stable version ? > > IIRC, i already tried, but it needs thread support. Another problem, when you > really want to use https, are the crypto libraries needed to decode the > stream. > I knew the ssl would make it tricky, I was hoping the wget-ssl would be a way in. Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 20:50:14
|
On Montag, 23. April 2018 22:30:37 CEST Peter Slegg wrote: > Perhaps wget or wget-ssl could be re-built to the latest stable version ? IIRC, i already tried, but it needs thread support. Another problem, when you really want to use https, are the crypto libraries needed to decode the stream. |
|
From: Peter S. <p....@sc...> - 2018-04-23 20:30:47
|
On Mon, 23 Apr 2018 22:11:44 , Thorsten Otto <ad...@th...> wrote: > On Montag, 23. April 2018 21:47:08 CEST Peter Slegg wrote: >> I wanted to use github but the old version of wget (1.9.1) we have doesn't >> support https > >I think you should be able to use plain http with github? Another option would >be to try curl instead, but i have to admit that i'm not sure whether that >version already supports https I was trying to use the wget option --no-check-certificate but 1.9 doesn't support it. I just discovered wget-ssl in the Sparemint RPMs but that doesn't support the option either. Perhaps wget or wget-ssl could be re-built to the latest stable version ? Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 20:12:03
|
On Montag, 23. April 2018 21:47:08 CEST Peter Slegg wrote: > I wanted to use github but the old version of wget (1.9.1) we have doesn't > support https I think you should be able to use plain http with github? Another option would be to try curl instead, but i have to admit that i'm not sure whether that version already supports https |
|
From: Peter S. <p....@sc...> - 2018-04-23 19:47:23
|
Hi, Since atariforge isn't accessible I have changed the sparemint-update script I use, for managing RPM's, to download from atari-source instead. I wanted to use github but the old version of wget (1.9.1) we have doesn't support https. Latest is wget is 1.19. Peter |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 17:03:10
|
On Montag, 23. April 2018 18:22:05 CEST David Gálvez wrote: > We have a system call that gives this information and now it's giving > it wrong for the ColdFire Maybe. But then it was wrong also before the patch i guess. The problem with OS_OSCOMPILE is that it can return only a 32bit value, so you won't be able to squeeze all the possible isa names/cpu types/whatever for coldfire into it. The best thing would maybe to set the major cpu id to 1, as that, according to the documentation, would indicate a non-m68k processor. And maybe the core version (mcf_v1 etc.) into the minor id. But i would leave the remaining bits out, after all all that information is not really very useful for applications, as it only tells how the kernel was compiled, but nothing about the running system. And it also does not guarantee that all the drivers for example were compiled the same way. |
|
From: David G. <dga...@gm...> - 2018-04-23 16:22:14
|
2018-04-23 17:26 GMT+02:00 Thorsten Otto <ad...@th...>: > > The information for the actual system should already be present in the _MCF > cookie. Using the compiler flags to setup similar information for the > compile-time options IMHO does not make much sense, as all the libraries are > only compiled for -mcpu=5475. > I don't want to enter in if it makes sense or it doesn't make sense. We have a system call that gives this information and now it's giving it wrong for the ColdFire and I'd like to fix this. If I'm going to do it I'd like to have in mind future additions to the platform, perhaps support for the 54455 with a different instruction set (ISAC) than the 5475. Probably those addition are unrealistic but you never know what this crazy people coding for old computers/systems will decide to do ;-) |
|
From: Thorsten O. <ad...@th...> - 2018-04-23 15:26:56
|
On Montag, 23. April 2018 16:33:05 CEST David Gálvez wrote: > First question. Should the ColdFire be included in this family or > should we add 0x01 value for the ColdFire family? I don' think so. The reason is the same as why FireTOS does not set the _CPU cookie: The ColdFire just does not fit into this "level" scheme. And actually it is not real 68000 compatible, so not setting the cookie at all follows the logic of other cookies like not setting _VDO when no st-compatible video is present. >We can give: >a) the ISA classification (isaa, isab, isac, etc...). >b) the CPU names as given in the "-mcpu=" option in GCC (52xx, 53xx, 54xx, >etc). >c) what it's called as micro-architecture by GCC (cfv1, cfv2, cfv3, cfv4, >etc). The information for the actual system should already be present in the _MCF cookie. Using the compiler flags to setup similar information for the compile- time options IMHO does not make much sense, as all the libraries are only compiled for -mcpu=5475. |
5 messages has been excluded from this view by a project administrator.
