From jem at archivalladolid.org Thu Jan 1 17:04:52 2009 From: jem at archivalladolid.org (=?iso-8859-1?Q?Jos=E9_Emilio_Mori_Recio?=) Date: Fri, 2 Jan 2009 02:04:52 +0100 Subject: [GEM Development] More about GEM not going forward... More comments? Message-ID: <20090102010516.AFFFA328014@ns2.simpits.org> Hello again. Some comments, specially to Michael Bernstein. After Michael's message, I'm somewhat confused about the GEMWiki. I believed it was created in order to help people (specially this list's people) which would like to begin GEM developing and to provide a useful way to share information, and that it was a common efort of several people (not only one person), which means that people felt that there was a need for a wiki. Maybe things have changed and that's why the primary wiki isn't fixed... but I don't think we should just let it die, until the freegem.net domain expires (only eight days from now, by the way, if the whois is correct... I don't know if Owen is aware of that...). Like Owen, I would like to hear from its maintainer Rob. And also from Shane Coughlan about OpenGEM 7. Personally I feel that as long as there's several people involved in the project, the wiki could be useful, the same way this mailing list is currently still useful. David Johnson has explained which was his starting point... a further explanation of that could be very useful in the wiki, for newcomers: the current documentation, as far as I've read, lacks something of a "Developing HOWTO". Talking about what to do with GEM... obviously, nothing related to day-by-day work and modern PCs. But I have several ideas: making some (very) old PCs useful again, programming practice, and a "historic work" of preservation (apart from being a toy, etc.). Also very important, GEM is connected to FreeDOS, a project still in active development, and both projects could benefit of one another. I don't think GEM should evolve into multitasking, higher resolutions or other "modern" things... running with 640Kb is a "feature", not a problem, if we consider that it means those old PCs will still be able to run it, and that's good, I think. Or, if there's such an evolution, a 640Kb-version should co-exist. Anyway, I'll take a look to Michael's documentation, and we'll see in the future... If PC-GEM is really finished, or more precisely, Shane Land announces that he won't do any further developing/web updating, and/or Rob won't fix the wiki (really hoping neither of those will happen), maybe people like David Johnson, Shane Gough and others, also with my help, could coordinate to create and maintain a wiki and/or a common web which would keep track of all their/our possible new developing, and to centralize GEM information and links for the "external" visitor who wants to know something about GEM. As I said, I can help with the web hosting, MySQL, MediaWiki, eventual HTML/PHP coding, etc. Anyway, what I would like is to read news from the maintainers, to really know what things are like and what we should do next. Best regards, // Jos? Emilio Mori Recio - http://www.gui.uva.es/~jem \\ || Administrador Inform?tico, Arzobispado de Valladolid y Archivo || \\ Miembro 088 del Grupo Universitario de Inform?tica, Valladolid // From goughsw at gmail.com Fri Jan 2 03:41:43 2009 From: goughsw at gmail.com (Shane Gough) Date: Fri, 2 Jan 2009 21:41:43 +1000 Subject: [GEM Development] Fwd: More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> References: <20090102010516.AFFFA328014@ns2.simpits.org> <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> Message-ID: <7da8e8830901020341j36a4478fkeb475b62dba7e6d8@mail.gmail.com> Hi all, After reading the most recent message from Jose it strikes me that people are here for very different reasons. I've become interested in GEM more for nostalgic reasons - I'm currently running GEM in virtual machines (under Sun's VirtualBox on Windows and Linux, Parallels on OS/X). GEM was very rare in my environment, I only ever saw a few installations. Once Windows 3.1 came out it seemed to dissapear altogether. Looking at the implementation of FreeGEM/OpenGEM is an interesting experience - how it manages to do what it does in the minimal resources available (something that wasn't available at the time it was in production use). I really can't see any modern situation where GEM would be in anyway useful as more than an interesting toy. That said, it's a fun environment to relive your past (or to see where modern GUI's and systems came from). There are a few interesting projects I'd like to play with on top of GEM: 1/ An application framework for Object Pascal or C++ (both Turbo Pascal 5.5 and Turbo C++ 1.01 are available from the Borland Museum for free download). 2/ An implementation of TinyPy (http://www.tinypy.org) with a IDE for simple application development with GEM itself. Although TinyPy is a limited subset of Python that fits into 64K this would still be quite a push. 3/ I'd like to play around with alternative desktop implementations. I don't know enough about how the GEM desktop is implemented yet to know how easy or hard that would be. I'd like to see a more application oriented rather than file management oriented desktop. As for the implementation of GEM itself there is one thing I would like to play with - an implementation of the GEM API for Linux. I could see a number of single board systems with graphics support running an instance of GEM rather than X11 as the GUI. Any system that had kernel framebuffer support could potentially be a suitable host. All you would need is the Linux kernel, busybox for core utilities and GEM for the UI. Using a Linux kernel would give you support for networking, a wide range of file systems and multitasking. Anyway - read that as my introduction to the list :) If anyone knows of current projects similar to the ones I've described above please let me know. I'd be interested in contributing to an existing project rather than starting a new one. Regards, Shane From goughsw at gmail.com Fri Jan 2 08:49:51 2009 From: goughsw at gmail.com (Shane Gough) Date: Sat, 3 Jan 2009 02:49:51 +1000 Subject: [GEM Development] More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> References: <20090102010516.AFFFA328014@ns2.simpits.org> <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> Message-ID: <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com> Just a quick aside - I once saw an installation of GEM/X (licensed from DR by Siemens I guess, the 'About' window definitely said GEM/X though) with some custom apps to drive SIMATIC/S5 control systems. This was in the early 90's so my memory might be a bit faulty, but we did set the PC up to show some output from Apollo Domain workstations (re-badged as the Siemens WS30 range) via X. I was impressed by how snappy the output was compared to Windows of the same era. BTW: I've done some more research and found a list of GEM VDI & AES function calls accessible from software interrupts on the PC platform, now I'm trying to find suitable (low-level) document for the Atari version of GEM and make sure I can match one to the other. This is an excellent argument for the Wiki (one page per API call describing the differences between implementations would be great). Cheers, Shane From lyricalnanoha at usotsuki.hoshinet.org Fri Jan 2 10:07:47 2009 From: lyricalnanoha at usotsuki.hoshinet.org (lyricalnanoha) Date: Fri, 2 Jan 2009 13:07:47 -0500 (EST) Subject: [GEM Development] More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com> References: <20090102010516.AFFFA328014@ns2.simpits.org> <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com> Message-ID: On Sat, 3 Jan 2009, Shane Gough wrote: > BTW: I've done some more research and found a list of GEM VDI & AES > function calls accessible from software interrupts on the PC platform, > now I'm trying to find suitable (low-level) document for the Atari > version of GEM and make sure I can match one to the other. This is an > excellent argument for the Wiki (one page per API call describing the > differences between implementations would be great). Yeah. One aborted project of mine (because I didn't know enough about the systems) was a HLE emulator of the Atari ST I wanted to write and call "CrySTal" that would have translated ST GEM calls to PC GEM and TOS calls to MS-DOS, instead of running the ST ROMs. -uso. From zaojashin at yahoo.com Fri Jan 2 19:39:31 2009 From: zaojashin at yahoo.com (david johnson) Date: Fri, 2 Jan 2009 19:39:31 -0800 (PST) Subject: [GEM Development] gem-dev Digest, Vol 50, Issue 2 In-Reply-To: <8dd2d95c0812311916x5cdc8b95me45bb3648e2721c3@mail.gmail.com> Message-ID: <236553.62973.qm@web58607.mail.re3.yahoo.com> Thanks for the nice comment.? The port was fun to do. --- On Wed, 12/31/08, Michael Kerpan wrote: From: Michael Kerpan Subject: Re: [GEM Development] gem-dev Digest, Vol 50, Issue 2 To: gem-dev at simpits.org Date: Wednesday, December 31, 2008, 10:16 PM Wow. That BWBASIC port is impressive. In fact, it looks like its more or less trhe nicest version of BWBASIC around. As for a "use" for GEM, I was think of, perhaps, some sort of use for homebrew embedded projects. Chances are, GEM, running on some sort of FPGA-based 8086 clone could be a useful system for providing graphical services. Mike _______________________________________________ gem-dev mailing list gem-dev at simpits.org http://www.simpits.org/mailman/listinfo/gem-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.simpits.org/pipermail/gem-dev/attachments/20090102/661ab0da/attachment.html From Gerhard_Stoll at b.maus.de Sat Jan 3 10:33:00 2009 From: Gerhard_Stoll at b.maus.de (Gerhard Stoll) Date: Sat, 3 Jan 2009 19:33:00 +0100 Subject: [GEM Development] More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com> Message-ID: <200901031933.p55693@b.maus.de> > SIMATIC/S5 control systems I use this and WordPlus 1994 on a Siemens PG675. On this system was GEM 3.x. > find suitable (low-level) document for the Atari What do you mean with "low-level"? Gerhard From pcgem at mbernstein.de Sat Jan 3 02:04:53 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sat, 3 Jan 2009 11:04:53 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <240531.21101.qm@web58601.mail.re3.yahoo.com>; from zaojashin@yahoo.com on Wed, Dec 31, 2008 at 10:20:01AM -0800 References: <7da8e8830812310603j4f0099b0qa04b6522d1359330@mail.gmail.com> <240531.21101.qm@web58601.mail.re3.yahoo.com> Message-ID: <20090103110452.A31223@mbernstein.de> Hi david, > The easiest starting point that I have found it to use the Pacific-C > GEM bindings from John Elliott and the "text window" routine (tw.zip) > from Heniz Rath -- http://www.geocities.com/heinz_rath/ For the first step ok. But i would suggest to use Turbo C. You can download the old compilers from the museum from Borland for free. As a GEM library you can use my library from http://www.mbernstein.de from the download section. My library has the advantage, that the API is build after a standard set by DR (!) and Atari for portable GEM development. This API was published by the Gei? twins in the german book "Vom Anf?nger zum GEM-Profi". This book was a introduction in write GEM applications for both Atari ST and IBM-PC! I had taken a look at the "text window" from Heinz Rath because i liked the idea of a console window. For a first step ok. But i missed some features. There was no buffering for automatic redraw of the window. There was also no code present for handling of resizing. If you resize the window to a smaller size, the slider should be used and only the right parts of the text should be shown. But code for this feature was also not present. Best regards Michael From pcgem at mbernstein.de Sat Jan 3 15:50:32 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sun, 4 Jan 2009 00:50:32 +0100 Subject: [GEM Development] More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com>; from goughsw@gmail.com on Sat, Jan 03, 2009 at 02:49:51AM +1000 References: <20090102010516.AFFFA328014@ns2.simpits.org> <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> <7da8e8830901020849i13ca05a9i46fc3952d998201a@mail.gmail.com> Message-ID: <20090104005032.C7549@mbernstein.de> Hi Shane, > now I'm trying to find suitable (low-level) document for the Atari > version of GEM and make sure I can match one to the other. Ask me, if you need informations about Atari. The official document is the Atari Compendium (AC), which is not available in the web. Because there are not much online documents, Gerhard Stoll and i decided to publish TOS.HYP online and prepare this german hypertext for an additional english part. Peter West has translated most if this text to english. You can find the english version at http://toshyp.atari.org It should be no problem to match one to the other because they are for nearly all functions identical. If you use the official names, all names are identical. But you should not use the names from some old GEM applications. I found in the RCS early names with the prefix gsx. VDI started as a GKS (Grafisches Kern System) clone with the name GSX. > This is an excellent argument for the Wiki (one page per API call > describing the differences between implementations would be great). No, it is not a excellent argument for a Wiki but only a good. Yes, the structure of one page for one api call matches the structure of a Wiki. But this can also be done with HTML code by hand. The benefit of a Wiki ist not to have one pager per description but to give a group easy write access via web. But because there is no development to modify or enhance GEM, there is also no need of write access after the function description was made. I want not really argue against a Wiki. But i can show a faster way with less work. Because the functions in Atari GEM and PC-GEM are nearly identical and have the same names, it is more easy and faster to write a new top level file for a newa target for TOS.HYP. I am always wondering, why people would like to make there own copy in the web instead of linking end reuse parts. What is wrong on my way? Is it the fact, that you dont have your own copy? Or do i use the wrong words, Atari instead of PC-GEM? It?s GEM, it?s the same GUI, only a different version. I think, if someone really feel the need of a reference manual inside a Wiki, if he has the knowledge and if he has the time, a Wiki with a description af the API will stil exist. But it does not exist. So it lacks of some of the requierements. I have shown you a way to get the API description with very little work and can spend your rare time to start with other missing descriptions. BTW. i have a not finished GEM programming course. AES is present, VDI not and some parts need a bit rework of the descriptions. If there is interrest and someone would like to help with translation (my text is in german like all parts of my homepage) an can try to finish them. But it will be a part of my Atari programing site in the web. But it is no problem to use this course also for PC-GEM, because i cover only GEM on Atari ST without extensions like NVDI or N.AES. Best Regards Michael From pcgem at mbernstein.de Sat Jan 3 13:32:07 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sat, 3 Jan 2009 22:32:07 +0100 Subject: [GEM Development] More about GEM not going forward... More comments? In-Reply-To: <20090102010516.AFFFA328014@ns2.simpits.org>; from jem@archivalladolid.org on Fri, Jan 02, 2009 at 02:04:52AM +0100 References: <20090102010516.AFFFA328014@ns2.simpits.org> Message-ID: <20090103223206.A7549@mbernstein.de> Hi Jos?, > After Michael's message, I'm somewhat confused about the GEMWiki. Maybe there is a missunderstandung. I did not talk about a complete GEMWiki. I only point to the fact, that a GEM API reference is still available. A document can be created with very little effort and much faster than let people write a complete reference in a GEMWiki. > But I have several ideas: making some (very) old PCs useful again, I remember a old discussion about a possible way to extend PC-GEM and which was a low level PC. Are there realy still some XTs present which you want to use again? Or mean old PC a small Pentium? Nobody wants older PCs. So this is also more or less a toy or museum. > programming practice, Yes, nice idea. Because GEM is much smaller than windows, it is much more easy to understand. Someone could take a look at the basics of a GUI without the overhead of bid class librarys. Line Minix which was a small system, easy to understand the basics. > and a "historic work" of preservation (apart from being a toy, etc.). For this my words are right, PC-GEM is finished ;-) > I don't think GEM should evolve into multitasking, higher resolutions or > other "modern" things... running with 640Kb is a "feature", not a problem, Yes, but a feature nobody really needs at this days. You have nice ideas, But i think, it will never be much more than a toy for most of the people. If you want to spend time and work, do it. But dont expect, the world has waited for it. Best regards Michael Bernstein From pcgem at mbernstein.de Sat Jan 3 13:44:10 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sat, 3 Jan 2009 22:44:10 +0100 Subject: [GEM Development] Fwd: More about GEM not going forward... More comments? In-Reply-To: <7da8e8830901020341j36a4478fkeb475b62dba7e6d8@mail.gmail.com>; from goughsw@gmail.com on Fri, Jan 02, 2009 at 09:41:43PM +1000 References: <20090102010516.AFFFA328014@ns2.simpits.org> <7da8e8830901020339i2e77e9e8i366812cc71716cc@mail.gmail.com> <7da8e8830901020341j36a4478fkeb475b62dba7e6d8@mail.gmail.com> Message-ID: <20090103224410.B7549@mbernstein.de> Hi Shane, > I've become interested in GEM more for nostalgic reasons ... > > I really can't see any modern situation where GEM would be in anyway > useful as more than an interesting toy. Yes, more ore less also my opinion. > 1/ An application framework for Object Pascal or C++ (both Turbo > Pascal 5.5 and Turbo C++ 1.01 are available from the Borland Museum > for free download). For Turbo C i have a GEM library for download on my homepage. > 3/ I'd like to play around with alternative desktop implementations. I > don't know enough about how the GEM desktop is implemented yet to know > how easy or hard that would be. I'd like to see a more application > oriented rather than file management oriented desktop. I think, more or less it is like write a GEM application with the name desktop.app which is started by the AES. There are not much (or no?) differences between the desktop and any other application. > As for the implementation of GEM itself there is one thing I would > like to play with - an implementation of the GEM API for Linux. I > could see a number of single board systems with graphics support > running an instance of GEM rather than X11 as the GUI. My idea was to use Minix as the OS. But the idea comes a little late. With Minix3 Tanenbaum build a small Unix linle OS with X11 for small computers. Best regards Michael From zaojashin at yahoo.com Sat Jan 3 20:20:09 2009 From: zaojashin at yahoo.com (david johnson) Date: Sat, 3 Jan 2009 20:20:09 -0800 (PST) Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <20090103110452.A31223@mbernstein.de> Message-ID: <990890.89006.qm@web58604.mail.re3.yahoo.com> Hello Michael, I agree Turbo C works well as does djgpp and John's binding.?? As I am not a programmer, Heinz Rath's code was simple enough to give me enough confidence to try writing some programs.? So a pretty good first step for me.? I am currently interested in working with my port of 4tH to GEM and playing with that. Thanks for the note about your library and the reference and I'll definitely take a look (though I'll need to work on my German!) as I've still not really addressed the issues you raised.? Thanks, David Johnson --- On Sat, 1/3/09, Michael Bernstein wrote: From: Michael Bernstein Subject: Re: [GEM Development] GEM not going forward... Comments? To: "GEM Development" Date: Saturday, January 3, 2009, 5:04 AM Hi david, > The easiest starting point that I have found it to use the Pacific-C > GEM bindings from John Elliott and the "text window" routine (tw.zip) > from Heniz Rath -- http://www.geocities.com/heinz_rath/ For the first step ok. But i would suggest to use Turbo C. You can download the old compilers from the museum from Borland for free. As a GEM library you can use my library from http://www.mbernstein.de from the download section. My library has the advantage, that the API is build after a standard set by DR (!) and Atari for portable GEM development. This API was published by the Gei? twins in the german book "Vom Anf?nger zum GEM-Profi". This book was a introduction in write GEM applications for both Atari ST and IBM-PC! I had taken a look at the "text window" from Heinz Rath because i liked the idea of a console window. For a first step ok. But i missed some features. There was no buffering for automatic redraw of the window. There was also no code present for handling of resizing. If you resize the window to a smaller size, the slider should be used and only the right parts of the text should be shown. But code for this feature was also not present. Best regards Michael _______________________________________________ gem-dev mailing list gem-dev at simpits.org http://www.simpits.org/mailman/listinfo/gem-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.simpits.org/pipermail/gem-dev/attachments/20090103/b961bee2/attachment.html From dlormand at aztecfreenet.org Sun Jan 4 12:57:38 2009 From: dlormand at aztecfreenet.org (David Ormand) Date: Sun, 04 Jan 2009 13:57:38 -0700 Subject: [GEM Development] GEM not going forward... Comments? Message-ID: <496122C2.6020304@aztecfreenet.org> > I've seen this list has 91 members. I don't know how much interest is left > on the project for all of us, but I would like to know. Maybe there are some > people like me willing to help a bit with things that the rest currently has > no time to spent in, in order to relaunch the GEM project. I like DOS. It's simple, it's quick, you turn on the computer and DOS is _there_, you don't have to wait for anything much to load (unlike Linux). When you're done, you turn it off; you don't have to shutdown. Now that FreeDOS is mature, we're on more or less the same footing with Free software as Linux. The fact that the FreeDOS community is as active as it is indicates that DOS is _not_ dead. It is not just a hobby or nostalgia trip. But DOS doesn't have a GUI. I messed with SEAL, but SEAL is dead. GEOS/NewDeal was pretty cool, but it's closed-source. I looked at a few others, like MGUI or ozone or wxWindows on MGL/Snap, and of course Allegro, but most are mere graphical environments instead of actual GUIs, and the few GUIs are immature or stalled. GEM is the best there is; that's why it's the "official" GUI of the FreeDOS project. I like GEM; I loved programming in GEM on the Atari. I'd like to port/build a Bible program based on the Sword library (www.crosswire.org) on DOS. My problem with GEM is, of course, it's natively 16-bit, and has limited graphics capability (although 1024x768 is probably adequate for most anything). I like DJGPP/DPMI; it allows the use of libraries developed for Linux under DOS (like the Sword library, which I've built for DOS). It looks like there are GEM bindings for DJGPP, so I should be set. Now all I need is the time to play :) Too bad GEM can't be built as a 32-bit system with DJGPP. I suppose if it _could_, then it could also be built with GCC under Linux, and then GEM could be a lite alternative to X. Might get a bit more attention in the Linux community. From goughsw at gmail.com Sun Jan 4 21:45:44 2009 From: goughsw at gmail.com (Shane Gough) Date: Mon, 5 Jan 2009 15:45:44 +1000 Subject: [GEM Development] GEM on Atari Message-ID: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> Can anyone suggest a good emulator for the Atari ST series that I can use to test portability? I don't have a physical Atari so one that uses FreeMINT would be better. What development tools are available for Atari? >From some quick research there seem to be a number of AES implementations around - any recommendations? Thanks, Shane From alanh at fairlite.co.uk Mon Jan 5 01:13:12 2009 From: alanh at fairlite.co.uk (Alan Hourihane) Date: Mon, 05 Jan 2009 09:13:12 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> Message-ID: <1231146792.963.6.camel@jetpack.demon.co.uk> On Mon, 2009-01-05 at 15:45 +1000, Shane Gough wrote: > Can anyone suggest a good emulator for the Atari ST series that I can > use to test portability? I don't have a physical Atari so one that > uses FreeMINT would be better. What development tools are available > for Atari? > > >From some quick research there seem to be a number of AES > implementations around - any recommendations? Hi Shane, I've been thinking of doing this myself. I'm currently spending a fair amount of free time doing FreeMiNT work. So getting the latest GEM version on Atari would be a nice thing to do. So the best emulator would be Aranym. They package a full solution disk image on their site. Alan. From olivier.landemarre at utbm.fr Mon Jan 5 05:08:44 2009 From: olivier.landemarre at utbm.fr (Olivier Landemarre) Date: Mon, 05 Jan 2009 14:08:44 +0100 Subject: [GEM Development] GEM on Atari In-Reply-To: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> Message-ID: <4962065C.3010302@utbm.fr> Shane Gough a ?crit : > Can anyone suggest a good emulator for the Atari ST series that I can > use to test portability? I don't have a physical Atari so one that > uses FreeMINT would be better. What development tools are available > for Atari? > > >From some quick research there seem to be a number of AES > implementations around - any recommendations? > > Thanks, > Shane > Hello, the best probably is to use Aranym and get full dev image disk of Easymint You can find Aranym here: http://aranym.org/ And the full image of Easymint for Aranym here: http://atari.st-katharina-apotheke.de/home.php?lang=ge&headline=EasyMiNT&texte=easymint You can try why not ;-) replace XaAES by MyAES: http://myaes.lutece.net/ Regards Olivier From goughsw at gmail.com Mon Jan 5 05:45:49 2009 From: goughsw at gmail.com (Shane Gough) Date: Mon, 5 Jan 2009 23:45:49 +1000 Subject: [GEM Development] GEM on Atari In-Reply-To: <4962065C.3010302@utbm.fr> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> Message-ID: <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> Thanks to all :) I now have a running Atari emulator on all machines (Aranym does not like running remotely via X though - could be a libSDL problem). Next question is preferred C/C++ compiler for Atari? Preferably natively hosted (ie: runs on the Atari and generates code for the Atari). I've found references to a GCC implementation that should run under Aranym (and AFROS) - I'm downloading and about to try it out now. Suggestions relating to native Atari compilers and editors/IDE's would be very welcome. Is there a native Object Pascal (ie: Turbo Pascal 5.5 compatible) compiler for the Atari? Thanks, Shane From olivier.landemarre at utbm.fr Mon Jan 5 06:07:37 2009 From: olivier.landemarre at utbm.fr (Olivier Landemarre) Date: Mon, 05 Jan 2009 15:07:37 +0100 Subject: [GEM Development] GEM on Atari In-Reply-To: <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> Message-ID: <49621429.6040601@utbm.fr> Hello Shane > Thanks to all :) > > I now have a running Atari emulator on all machines (Aranym does not > like running remotely via X though - could be a libSDL problem). > > Next question is preferred C/C++ compiler for Atari? Actually this is GCC or PureC (commercial not uptodate) Take this Aranym image: http://atari.st-katharina-apotheke.de/download/easymint-1.70-aranym.tar.gz This is easymint package, all file need for dev are inside, gcc is old (2.95.3) but work You can wan't GCC 4.3.2 I know some people have compil it for Mint but I not find any official package for this, if you have Cygwin or Linux there is a cross compiler here with source code: http://vincent.riviere.free.fr/soft/m68k-atari-mint/ It work fine on Linux > Preferably > natively hosted (ie: runs on the Atari and generates code for the > Atari). I've found references to a GCC implementation that should run > under Aranym (and AFROS) - I'm downloading and about to try it out > now. Suggestions relating to native Atari compilers and editors/IDE's > would be very welcome. For edition use Qed with syntax colored, work fine, very good and simple, no IDE (I have done one in past but not work with recent version of GCC not very usefull now) > Is there a native Object Pascal (ie: Turbo > Pascal 5.5 compatible) compiler for the Atari? > Yes in past name Pure Pascal, this was commercial software. > Thanks, > Shane > _______________________________________________ > gem-dev mailing list > gem-dev at simpits.org > http://www.simpits.org/mailman/listinfo/gem-dev > > Olivier From goughsw at gmail.com Mon Jan 5 06:17:56 2009 From: goughsw at gmail.com (Shane Gough) Date: Tue, 6 Jan 2009 00:17:56 +1000 Subject: [GEM Development] GEM on Atari In-Reply-To: <49621429.6040601@utbm.fr> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <49621429.6040601@utbm.fr> Message-ID: <7da8e8830901050617v117008b7me782c1035692dedf@mail.gmail.com> Thanks very much Olivier, This might be a good argument for a Wiki - to collect this sort of information :) I know this is now all on the mailing list archives but a Wiki is much easier to navigate :) Regards, Shane From alanh at fairlite.co.uk Mon Jan 5 06:23:21 2009 From: alanh at fairlite.co.uk (Alan Hourihane) Date: Mon, 05 Jan 2009 14:23:21 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> Message-ID: <1231165401.963.14.camel@jetpack.demon.co.uk> On Mon, 2009-01-05 at 23:45 +1000, Shane Gough wrote: > Thanks to all :) > > I now have a running Atari emulator on all machines (Aranym does not > like running remotely via X though - could be a libSDL problem). > > Next question is preferred C/C++ compiler for Atari? Preferably > natively hosted (ie: runs on the Atari and generates code for the > Atari). I've found references to a GCC implementation that should run > under Aranym (and AFROS) - I'm downloading and about to try it out > now. Suggestions relating to native Atari compilers and editors/IDE's > would be very welcome. Is there a native Object Pascal (ie: Turbo > Pascal 5.5 compatible) compiler for the Atari? I have Gentoo running on FreeMiNT with all the latest tools and will be cutting a release soon. It has GCC 4.2.4 and 4.3.2 available. Alan. From goughsw at gmail.com Mon Jan 5 06:53:01 2009 From: goughsw at gmail.com (Shane Gough) Date: Tue, 6 Jan 2009 00:53:01 +1000 Subject: [GEM Development] GEM on Atari In-Reply-To: <1231165401.963.14.camel@jetpack.demon.co.uk> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> Message-ID: <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> Hi Alan, When you say 'Gentoo running on FreeMINT' what do you mean? I would have thought that Gentoo (being a Linux based OS) would run directly on the hardware - all it needs is a bootloader (complexity and requirements depend on the system - I know my older Macs need to boot into OS 7.x and then run a Linux Bootloader to start Linux - they can't boot into it directly). I'm not that interested in targeting Linux on Atari (ST/TT/Falcon) - I'm more interested in using the native TOS/VDI/AES calls on the GEM implementation for Atari. Once I get a real Atari (I set up eBay searches for it today) I wouldn't mind playing with Linux on the system though :) Regards, Shane From alanh at fairlite.co.uk Mon Jan 5 07:37:05 2009 From: alanh at fairlite.co.uk (Alan Hourihane) Date: Mon, 05 Jan 2009 15:37:05 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> Message-ID: <1231169825.963.17.camel@jetpack.demon.co.uk> On Tue, 2009-01-06 at 00:53 +1000, Shane Gough wrote: > Hi Alan, > > When you say 'Gentoo running on FreeMINT' what do you mean? I would > have thought that Gentoo (being a Linux based OS) would run directly > on the hardware - all it needs is a bootloader (complexity and > requirements depend on the system - I know my older Macs need to boot > into OS 7.x and then run a Linux Bootloader to start Linux - they > can't boot into it directly). I really mean GNU tools running directly on FreeMiNT, nothing to do with Linux at all. But most of the tools available via the SpareMiNT site are outdated now, so I thought I'd start with something newer. There's a team called Gentoo/Alt (or Gentoo/Prefix) which are porting Gentoo to other OS's, and I've based my work from that. > I'm not that interested in targeting Linux on Atari (ST/TT/Falcon) - > I'm more interested in using the native TOS/VDI/AES calls on the GEM > implementation for Atari. Once I get a real Atari (I set up eBay > searches for it today) I wouldn't mind playing with Linux on the > system though :) Me too :-) Alan. From pcgem at mbernstein.de Mon Jan 5 12:43:29 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Mon, 5 Jan 2009 21:43:29 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <990890.89006.qm@web58604.mail.re3.yahoo.com>; from zaojashin@yahoo.com on Sat, Jan 03, 2009 at 08:20:09PM -0800 References: <20090103110452.A31223@mbernstein.de> <990890.89006.qm@web58604.mail.re3.yahoo.com> Message-ID: <20090105214328.B25473@mbernstein.de> Hello David, > Thanks for the note about your library and the reference I pointed to my library, because it is set up after a standard defined by DR. The comments about the text windows from Heinz Rath are from the view of an experienced GEM programmer who wants to write complex GEM applications. > and I'll definitely take a look (though I'll need to work on my > German!) as I've still not really addressed the issues you raised.? I think, it should be possible to find the library in my download section without german knowledge. The disk on the main page will identify the link to the download section and the link itself contain the word download. Then the link with the word PC will go to all PC related stuff. And on the PC stuff site you can search for gemlib and get the sources for my lib. Note that not all functions are tested. If you find bugs or problems, you can contact me and i try to fix it. Best regards Michael From pcgem at mbernstein.de Mon Jan 5 12:24:32 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Mon, 5 Jan 2009 21:24:32 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <496122C2.6020304@aztecfreenet.org>; from dlormand@aztecfreenet.org on Sun, Jan 04, 2009 at 01:57:38PM -0700 References: <496122C2.6020304@aztecfreenet.org> Message-ID: <20090105212432.A25473@mbernstein.de> Hi David, > Too bad GEM can't be built as a 32-bit system with DJGPP. I suppose > if it _could_, then it could also be built with GCC under Linux, > and then GEM could be a lite alternative to X. Might get a bit > more attention in the Linux community. I think, it should not be impossible to build a 32-bit GEM. Pointers used in the API are pointer to a typedef struct. eg: EXTERN WORD appl_find( CONST BYTE FAR *ap_fname ); The same ist with the VDI. From the view of the application, it should bo no problem and the Atari GEM proves this. As far as i remember, the VDI drivers contains much assembler code which makes it difficult to make a port to a 32-Bit GEM. Maybe a look at EmuTOS (a free Atri TOS replacement) will help a little bit because most of its GEM part was written in C. I am afraid, a GEM for Linux will come a little bit late. Yes, it can be a nice lightweight GUI. But most small Linux systems with GUI have enoughr power for X and use X with a toolkit. Best regards Michael From lyricalnanoha at usotsuki.hoshinet.org Mon Jan 5 18:45:29 2009 From: lyricalnanoha at usotsuki.hoshinet.org (lyricalnanoha) Date: Mon, 5 Jan 2009 21:45:29 -0500 (EST) Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <20090105212432.A25473@mbernstein.de> References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> Message-ID: On Mon, 5 Jan 2009, Michael Bernstein wrote: > As far as i remember, the VDI drivers contains much assembler code > which makes it difficult to make a port to a 32-Bit GEM. Maybe a > look at EmuTOS (a free Atri TOS replacement) will help a little bit > because most of its GEM part was written in C. As I recall the VDI is strictly asm. :/ But the 68000 is a 32-bit CPU internally, like the 386SX, so there is technically a 32-bit GEM already >:P -uso. From goughsw at gmail.com Mon Jan 5 19:08:16 2009 From: goughsw at gmail.com (Shane Gough) Date: Tue, 6 Jan 2009 13:08:16 +1000 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <20090105212432.A25473@mbernstein.de> References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> Message-ID: <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> Hi Michael, > I think, it should not be impossible to build a 32-bit GEM. Pointers > used in the API are pointer to a typedef struct. eg: > > EXTERN WORD appl_find( CONST BYTE FAR *ap_fname ); > > The same ist with the VDI. From the view of the application, it should > bo no problem and the Atari GEM proves this. In PC-GEM at least the VDI parameters are treated as an array of WORD values and the corresponding C structures are all aligned on WORD boundaries. Is this the same on Atari GEM? For some 32 bit processors this is non-optimal and a portable 32 bit GEM would have to take that into account. > I am afraid, a GEM for Linux will come a little bit late. Yes, it can > be a nice lightweight GUI. But most small Linux systems with GUI have > enoughr power for X and use X with a toolkit. X is still fairly heavyweight. One application I thought of was a VDI driver that used a VNC framebuffer to provide a remote GUI on small systems that have no local display. Regards, Shane From dlormand at aztecfreenet.org Mon Jan 5 18:48:09 2009 From: dlormand at aztecfreenet.org (David Ormand) Date: Mon, 05 Jan 2009 19:48:09 -0700 Subject: [GEM Development] GEM on Atari Message-ID: <4962C669.2000901@aztecfreenet.org> > Next question is preferred C/C++ compiler for Atari? Preferably > natively hosted (ie: runs on the Atari and generates code for the > Atari). I've found references to a GCC implementation that should run > under Aranym (and AFROS) - I'm downloading and about to try it out > now. Suggestions relating to native Atari compilers and editors/IDE's > would be very welcome. Is there a native Object Pascal (ie: Turbo > Pascal 5.5 compatible) compiler for the Atari? I always used Sozobon C. It seemed to be more comprehensive than the other compilers. Available on the Atari FTP sites (if there are any left...) From olivier.landemarre at utbm.fr Tue Jan 6 03:50:46 2009 From: olivier.landemarre at utbm.fr (Olivier Landemarre) Date: Tue, 06 Jan 2009 12:50:46 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> Message-ID: <49634596.5070407@utbm.fr> Shane Gough a ?crit : > Hi Michael, > > >> I think, it should not be impossible to build a 32-bit GEM. Pointers >> used in the API are pointer to a typedef struct. eg: >> >> EXTERN WORD appl_find( CONST BYTE FAR *ap_fname ); >> >> The same ist with the VDI. From the view of the application, it should >> bo no problem and the Atari GEM proves this. >> > > In PC-GEM at least the VDI parameters are treated as an array of WORD > values and the corresponding C structures are all aligned on WORD > boundaries. Is this the same on Atari GEM? For some 32 bit processors > this is non-optimal and a portable 32 bit GEM would have to take that > into account. > At my know, this is not a problem. One important diffrence you can have trouble, is probably with RSC files, XaAES or MyAES as I know (for MyAES I'm sure), not support little endian RSC format (if you know how I could know, how recognize little to big endian RSC file I'm interesting, I could add this in MyAES) > >> I am afraid, a GEM for Linux will come a little bit late. Yes, it can >> be a nice lightweight GUI. But most small Linux systems with GUI have >> enoughr power for X and use X with a toolkit. >> > > X is still fairly heavyweight. One application I thought of was a VDI > driver that used a VNC framebuffer to provide a remote GUI on small > systems that have no local display. > Yes It's what I wan't to do, today problem is VDI that is not easy to write, if someone have already done this, please contact me! > Regards, > Shane > _______________________________________________ > gem-dev mailing list > gem-dev at simpits.org > http://www.simpits.org/mailman/listinfo/gem-dev > > Olivier From lproven at gmail.com Tue Jan 6 06:47:59 2009 From: lproven at gmail.com (Liam Proven) Date: Tue, 6 Jan 2009 14:47:59 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <1231169825.963.17.camel@jetpack.demon.co.uk> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> <1231169825.963.17.camel@jetpack.demon.co.uk> Message-ID: <575131af0901060647t401921bbnbd1b9330230958ab@mail.gmail.com> 2009/1/5 Shane Gough : > Hi Alan, > > When you say 'Gentoo running on FreeMINT' what do you mean? I would > have thought that Gentoo (being a Linux based OS) would run directly I think Alan is getting confused, and thus confusing the rest of us. Gentoo, as you say, is a Linux distribution: a complete OS based on the Linux kernel. You can't run that on MiNT. It's not possible in any useful way. However, one of Gentoo's distinctive features is Portage, a source-based packaging system, derived in inspiration at least from the FreeBSD Ports system. (The other BSDs - NetBSD and OpenBSD - use something similar. I don't know about DragonflyBSD and PC-BSD has its own, different binary packing system, as well as Ports.) It may be that someone is trying to implement Portage on Mint. That would be doable, although when I imagine the MiNT-based world is much slower-moving than that of x86 Free software, I don't see a lot of point. Secondarily, the point of Portage and of Gentoo in general is to compile from source on every machine. There are 2 reasons for this, neither of which apply on Atari & compatible hardware: [1] x86 PC hardware is fast enough that recompilation is quick [2] There is such a diversity of PC hardware - CPUs alone in a dozen families or more - that significant performance improvements can be got from compiling with specific optimisations for each individual machine. E.g., on Intel alone, processors include 386dx/386sx/486slc/486dx/486dx2/486dx4/Pentium 1/MMX/Pro/2/3/4/4HT/4 64-bit/4 64-bit HT/Core/Core2/Core2Quad/Atom/Core i7. That's 20 variants and I've not included 64-bit variants of everything since Core2. Add in buses, caches, chipsets, graphics chips, choice of Linux desktops, choice of version of GCC, choice of kernel, etc., and there are millions of permutations of PC. How many 68030-based ST-family machines are there? Half a dozen? So, with a small library of software, relatively slowly changing, on a small number of fairly fairly homogenous machines, where available processing power is so low that compilation will take hours, there really is no point in Portage that I can see. A free, open, GPL, binary-based packing system with automatic dependency resolution built in from day 1 at a deep level, though, would be a boon. That means APT, which is all that, and runs on both .deb packages with DPKG and .rpm packages with RPM. -- Liam Proven ? Profile: http://www.linkedin.com/in/liamproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AOL/AIM/iChat: liamproven at aol.com ? MSN/Messenger: lproven at hotmail.com Yahoo: liamproven at yahoo.co.uk ? Skype: liamproven ? ICQ: 73187508 From alanh at fairlite.co.uk Tue Jan 6 06:59:00 2009 From: alanh at fairlite.co.uk (Alan Hourihane) Date: Tue, 06 Jan 2009 14:59:00 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <575131af0901060647t401921bbnbd1b9330230958ab@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> <1231169825.963.17.camel@jetpack.demon.co.uk> <575131af0901060647t401921bbnbd1b9330230958ab@mail.gmail.com> Message-ID: <1231253940.14612.37.camel@jetpack.demon.co.uk> On Tue, 2009-01-06 at 14:47 +0000, Liam Proven wrote: > 2009/1/5 Shane Gough : > > Hi Alan, > > > > When you say 'Gentoo running on FreeMINT' what do you mean? I would > > have thought that Gentoo (being a Linux based OS) would run directly > > I think Alan is getting confused, and thus confusing the rest of us. No, I'm not getting confused, and certainly not trying to confuse the rest of you. > Gentoo, as you say, is a Linux distribution: a complete OS based on > the Linux kernel. Gentoo/Alt http://www.gentoo.org/proj/en/gentoo-alt/index.xml > You can't run that on MiNT. It's not possible in any useful way. > > However, one of Gentoo's distinctive features is Portage, a > source-based packaging system, derived in inspiration at least from > the FreeBSD Ports system. Right, which is what Gentoo/Alt is all about. > (The other BSDs - NetBSD and OpenBSD - use something similar. I don't > know about DragonflyBSD and PC-BSD has its own, different binary > packing system, as well as Ports.) > > It may be that someone is trying to implement Portage on Mint. That > would be doable, although when I imagine the MiNT-based world is much > slower-moving than that of x86 Free software, I don't see a lot of > point. I've ported Portage to FreeMiNT and it's working very well here. > Secondarily, the point of Portage and of Gentoo in general is to > compile from source on every machine. There are 2 reasons for this, > neither of which apply on Atari & compatible hardware: > > [1] x86 PC hardware is fast enough that recompilation is quick > [2] There is such a diversity of PC hardware - CPUs alone in a dozen > families or more - that significant performance improvements can be > got from compiling with specific optimisations for each individual > machine. E.g., on Intel alone, processors include > 386dx/386sx/486slc/486dx/486dx2/486dx4/Pentium 1/MMX/Pro/2/3/4/4HT/4 > 64-bit/4 64-bit HT/Core/Core2/Core2Quad/Atom/Core i7. That's 20 > variants and I've not included 64-bit variants of everything since > Core2. Add in buses, caches, chipsets, graphics chips, choice of Linux > desktops, choice of version of GCC, choice of kernel, etc., and there > are millions of permutations of PC. > > How many 68030-based ST-family machines are there? Half a dozen? There is a 68060, 68040, 68030, 68020, 68000 for Atari architectures, and that alone is reason enough for me to deal with. Secondly, the advent of cross-compilers makes it much more viable too. > So, with a small library of software, relatively slowly changing, on a > small number of fairly fairly homogenous machines, where available > processing power is so low that compilation will take hours, there > really is no point in Portage that I can see. Maybe from your point of view. > A free, open, GPL, binary-based packing system with automatic > dependency resolution built in from day 1 at a deep level, though, > would be a boon. That means APT, which is all that, and runs on both > .deb packages with DPKG and .rpm packages with RPM. Another, from your point of view. Alan. From lproven at gmail.com Tue Jan 6 07:21:08 2009 From: lproven at gmail.com (Liam Proven) Date: Tue, 6 Jan 2009 15:21:08 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <1231253940.14612.37.camel@jetpack.demon.co.uk> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> <1231169825.963.17.camel@jetpack.demon.co.uk> <575131af0901060647t401921bbnbd1b9330230958ab@mail.gmail.com> <1231253940.14612.37.camel@jetpack.demon.co.uk> Message-ID: <575131af0901060721t4fa242c1p356bc21b55bba253@mail.gmail.com> 2009/1/6 Alan Hourihane : > On Tue, 2009-01-06 at 14:47 +0000, Liam Proven wrote: >> 2009/1/5 Shane Gough : >> > Hi Alan, >> > >> > When you say 'Gentoo running on FreeMINT' what do you mean? I would >> > have thought that Gentoo (being a Linux based OS) would run directly >> >> I think Alan is getting confused, and thus confusing the rest of us. > > No, I'm not getting confused, and certainly not trying to confuse the > rest of you. > >> Gentoo, as you say, is a Linux distribution: a complete OS based on >> the Linux kernel. > > Gentoo/Alt > > http://www.gentoo.org/proj/en/gentoo-alt/index.xml But you didn't say Gentoo/Alt or Gentoo-Alt. You said just Gentoo! >> You can't run that on MiNT. It's not possible in any useful way. >> >> However, one of Gentoo's distinctive features is Portage, a >> source-based packaging system, derived in inspiration at least from >> the FreeBSD Ports system. > > Right, which is what Gentoo/Alt is all about. > >> (The other BSDs - NetBSD and OpenBSD - use something similar. I don't >> know about DragonflyBSD and PC-BSD has its own, different binary >> packing system, as well as Ports.) >> >> It may be that someone is trying to implement Portage on Mint. That >> would be doable, although when I imagine the MiNT-based world is much >> slower-moving than that of x86 Free software, I don't see a lot of >> point. > > I've ported Portage to FreeMiNT and it's working very well here. Good for you! >> Secondarily, the point of Portage and of Gentoo in general is to >> compile from source on every machine. There are 2 reasons for this, >> neither of which apply on Atari & compatible hardware: >> >> [1] x86 PC hardware is fast enough that recompilation is quick >> [2] There is such a diversity of PC hardware - CPUs alone in a dozen >> families or more - that significant performance improvements can be >> got from compiling with specific optimisations for each individual >> machine. E.g., on Intel alone, processors include >> 386dx/386sx/486slc/486dx/486dx2/486dx4/Pentium 1/MMX/Pro/2/3/4/4HT/4 >> 64-bit/4 64-bit HT/Core/Core2/Core2Quad/Atom/Core i7. That's 20 >> variants and I've not included 64-bit variants of everything since >> Core2. Add in buses, caches, chipsets, graphics chips, choice of Linux >> desktops, choice of version of GCC, choice of kernel, etc., and there >> are millions of permutations of PC. >> >> How many 68030-based ST-family machines are there? Half a dozen? > > There is a 68060, 68040, 68030, 68020, 68000 for Atari architectures, > and that alone is reason enough for me to deal with. Doesn't MiNT require an MMU? And if not - go on, how long to compile a full system on a 68000? 8?) > Secondly, the advent of cross-compilers makes it much more viable too. Does Portage help with that? >> So, with a small library of software, relatively slowly changing, on a >> small number of fairly fairly homogenous machines, where available >> processing power is so low that compilation will take hours, there >> really is no point in Portage that I can see. > > Maybe from your point of view. Well, go on then... How much active development is happening in the MiNT world? Is any ST-family machine powerful enough to run GNOME or KDE, say? >> A free, open, GPL, binary-based packing system with automatic >> dependency resolution built in from day 1 at a deep level, though, >> would be a boon. That means APT, which is all that, and runs on both >> .deb packages with DPKG and .rpm packages with RPM. > > Another, from your point of view. Well, yes, but then, I evaluate and review operating systems and tools, both for publication in about 20 different professional magazines, journals and websites, from the Inquirer to Personal Computer World and PC Magazine, and I recommend, build, install, support and train users on systems for hundreds of companies from 5-man small businesses to multinational banks and financial institutions; the biggest system I've supported so far has 38,000 users. So, you know, I'm not just an amateur fiddler. :?) And I've tried Gentoo and my conclusion was, basically, that it was a toy for "ricers". (Kids who customise their kit for no real purpose except benchmarking competitions.) Sorry. No offence meant, and I am not making any kind of personal comment, judgement, accusation, or anything of the kind against you. On the other hand, my considered professional opinion of Gentoo is that it wasn't worth the time or effort and that Portage was clever but really didn't offer anything genuinely useful for a home or professional Linux user on x86 hardware. For home users, in my opinion, Ubuntu is about the best there is. Fedora is a waste of time, unless you like playing with alpha-grade testing systems, and there's really no argument for Mandriva any more. Ulteo is starting to look promising, maybe. For enterprises, there's a case to be made for RHEL (possibly supplemented with CentOS) or SLES. Debian for the pros, Xandros is a viable corporate desktop, and frankly, that's about it. But if you're compiling FOSS apps for different models of ST, yes, I can see that Portage would be useful. The rest of the Gentoo userland, though, I would think would be *way* too heavyweight for an ST, even a maxed-out TT or Falcon, or even a Medusa or Milan - no? -- Liam Proven ? Profile: http://www.linkedin.com/in/liamproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AOL/AIM/iChat: liamproven at aol.com ? MSN/Messenger: lproven at hotmail.com Yahoo: liamproven at yahoo.co.uk ? Skype: liamproven ? ICQ: 73187508 From alanh at fairlite.co.uk Tue Jan 6 07:54:49 2009 From: alanh at fairlite.co.uk (Alan Hourihane) Date: Tue, 06 Jan 2009 15:54:49 +0000 Subject: [GEM Development] GEM on Atari In-Reply-To: <575131af0901060721t4fa242c1p356bc21b55bba253@mail.gmail.com> References: <7da8e8830901042145y757547f4nf38f65113826c09c@mail.gmail.com> <4962065C.3010302@utbm.fr> <7da8e8830901050545x1ce06b5av36abc7a815de482e@mail.gmail.com> <1231165401.963.14.camel@jetpack.demon.co.uk> <7da8e8830901050653o789c2110k89aecead521698d7@mail.gmail.com> <1231169825.963.17.camel@jetpack.demon.co.uk> <575131af0901060647t401921bbnbd1b9330230958ab@mail.gmail.com> <1231253940.14612.37.camel@jetpack.demon.co.uk> <575131af0901060721t4fa242c1p356bc21b55bba253@mail.gmail.com> Message-ID: <1231257289.14647.10.camel@jetpack.demon.co.uk> On Tue, 2009-01-06 at 15:21 +0000, Liam Proven wrote: > 2009/1/6 Alan Hourihane : > > On Tue, 2009-01-06 at 14:47 +0000, Liam Proven wrote: > >> 2009/1/5 Shane Gough : > >> > Hi Alan, > >> > > >> > When you say 'Gentoo running on FreeMINT' what do you mean? I would > >> > have thought that Gentoo (being a Linux based OS) would run directly > >> > >> I think Alan is getting confused, and thus confusing the rest of us. > > > > No, I'm not getting confused, and certainly not trying to confuse the > > rest of you. > > > >> Gentoo, as you say, is a Linux distribution: a complete OS based on > >> the Linux kernel. > > > > Gentoo/Alt > > > > http://www.gentoo.org/proj/en/gentoo-alt/index.xml > > But you didn't say Gentoo/Alt or Gentoo-Alt. You said just Gentoo! Maybe you didn't read the full thread before replying as I did mention it in a follow up email. > >> You can't run that on MiNT. It's not possible in any useful way. > >> > >> However, one of Gentoo's distinctive features is Portage, a > >> source-based packaging system, derived in inspiration at least from > >> the FreeBSD Ports system. > > > > Right, which is what Gentoo/Alt is all about. > > > >> (The other BSDs - NetBSD and OpenBSD - use something similar. I don't > >> know about DragonflyBSD and PC-BSD has its own, different binary > >> packing system, as well as Ports.) > >> > >> It may be that someone is trying to implement Portage on Mint. That > >> would be doable, although when I imagine the MiNT-based world is much > >> slower-moving than that of x86 Free software, I don't see a lot of > >> point. > > > > I've ported Portage to FreeMiNT and it's working very well here. > > Good for you! > > >> Secondarily, the point of Portage and of Gentoo in general is to > >> compile from source on every machine. There are 2 reasons for this, > >> neither of which apply on Atari & compatible hardware: > >> > >> [1] x86 PC hardware is fast enough that recompilation is quick > >> [2] There is such a diversity of PC hardware - CPUs alone in a dozen > >> families or more - that significant performance improvements can be > >> got from compiling with specific optimisations for each individual > >> machine. E.g., on Intel alone, processors include > >> 386dx/386sx/486slc/486dx/486dx2/486dx4/Pentium 1/MMX/Pro/2/3/4/4HT/4 > >> 64-bit/4 64-bit HT/Core/Core2/Core2Quad/Atom/Core i7. That's 20 > >> variants and I've not included 64-bit variants of everything since > >> Core2. Add in buses, caches, chipsets, graphics chips, choice of Linux > >> desktops, choice of version of GCC, choice of kernel, etc., and there > >> are millions of permutations of PC. > >> > >> How many 68030-based ST-family machines are there? Half a dozen? > > > > There is a 68060, 68040, 68030, 68020, 68000 for Atari architectures, > > and that alone is reason enough for me to deal with. > > Doesn't MiNT require an MMU? No. > And if not - go on, how long to compile a full system on a 68000? 8?) I don't do that, as I build on a 68060 for use on a 68000. > > Secondly, the advent of cross-compilers makes it much more viable too. > > Does Portage help with that? Yes, it does, considerably via the use of distcc. > >> So, with a small library of software, relatively slowly changing, on a > >> small number of fairly fairly homogenous machines, where available > >> processing power is so low that compilation will take hours, there > >> really is no point in Portage that I can see. > > > > Maybe from your point of view. > > Well, go on then... How much active development is happening in the > MiNT world? Is any ST-family machine powerful enough to run GNOME or > KDE, say? Does it really matter, heck this is the GEM mailing list remember. And GEM already runs happily on Atari ST's. I think getting OpenGEM running on them is a sane plan, so I fail to see what GNOME or KDE has to do with anything here. > >> A free, open, GPL, binary-based packing system with automatic > >> dependency resolution built in from day 1 at a deep level, though, > >> would be a boon. That means APT, which is all that, and runs on both > >> .deb packages with DPKG and .rpm packages with RPM. > > > > Another, from your point of view. > > Well, yes, but then, I evaluate and review operating systems and > tools, both for publication in about 20 different professional > magazines, journals and websites, from the Inquirer to Personal > Computer World and PC Magazine, and I recommend, build, install, > support and train users on systems for hundreds of companies from > 5-man small businesses to multinational banks and financial > institutions; the biggest system I've supported so far has 38,000 > users. > > So, you know, I'm not just an amateur fiddler. :?) > > And I've tried Gentoo and my conclusion was, basically, that it was a > toy for "ricers". (Kids who customise their kit for no real purpose > except benchmarking competitions.) > > Sorry. No offence meant, and I am not making any kind of personal > comment, judgement, accusation, or anything of the kind against you. > > On the other hand, my considered professional opinion of Gentoo is > that it wasn't worth the time or effort and that Portage was clever > but really didn't offer anything genuinely useful for a home or > professional Linux user on x86 hardware. > > For home users, in my opinion, Ubuntu is about the best there is. > Fedora is a waste of time, unless you like playing with alpha-grade > testing systems, and there's really no argument for Mandriva any more. > Ulteo is starting to look promising, maybe. > > For enterprises, there's a case to be made for RHEL (possibly > supplemented with CentOS) or SLES. Debian for the pros, Xandros is a > viable corporate desktop, and frankly, that's about it. > > But if you're compiling FOSS apps for different models of ST, yes, I > can see that Portage would be useful. The rest of the Gentoo userland, > though, I would think would be *way* too heavyweight for an ST, even a > maxed-out TT or Falcon, or even a Medusa or Milan - no? I read your furthur comments with a pinch of salt :-) Alan. From Gerhard_Stoll at b.maus.de Wed Jan 7 08:20:00 2009 From: Gerhard_Stoll at b.maus.de (Gerhard Stoll) Date: Wed, 7 Jan 2009 17:20:00 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> Message-ID: <200901071720.p56315@b.maus.de> > Is this the same on Atari GEM? For some 32 bit processors this is non- > optimal and a portable 32 bit GEM would have to take that into account. Mmh, I am don't know what you mean, but for many years I wrote a program and compile this sourcecode with Turbo C [1] for Atari und the same code with Turbo C for DOS (GEM/3) without any changes. There was only some small thing because the Atari-GEM or PC-GEM don't have some function. For Example: -------------------------------cut------------------------------- VOID beep (VOID) { if(ring_bell) { #if GEM & (GEM2 | GEM3 | XGEM) v_sound (vdi_handle, 550, 3); #else #if GEMDOS Bconout (2, BEL); #endif #endif } } -------------------------------cut------------------------------- Gerhard [1] Yes, there was a version from Turbo C for Atari from Borland. From pcgem at mbernstein.de Wed Jan 7 12:25:41 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Wed, 7 Jan 2009 21:25:41 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <49634596.5070407@utbm.fr>; from olivier.landemarre@utbm.fr on Tue, Jan 06, 2009 at 12:50:46PM +0100 References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> <49634596.5070407@utbm.fr> Message-ID: <20090107212540.B1985@mbernstein.de> Hi Olivier, > One important diffrence you can have trouble, is probably with RSC > files, XaAES or MyAES as I know (for MyAES I'm sure), not support little > endian RSC format (if you know how I could know, how recognize little to > big endian RSC file I'm interesting, I could add this in MyAES) This problem was still solved by DR. The had written a small program which can translate between big and little endian RCS files. The sources for this RCSCONF are part of the sources released under GPL by calderea. You can also find a version for Atari in the download sesction of my Homepage which i had compiled from this sources. A automatic detection would be much nicer. Otherwise you should always take care to use the right resource file. Best regards Michael From pcgem at mbernstein.de Wed Jan 7 12:14:07 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Wed, 7 Jan 2009 21:14:07 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com>; from goughsw@gmail.com on Tue, Jan 06, 2009 at 01:08:16PM +1000 References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> Message-ID: <20090107211406.A1985@mbernstein.de> Hi Shane, > In PC-GEM at least the VDI parameters are treated as an array of WORD > values and the corresponding C structures are all aligned on WORD > boundaries. Is this the same on Atari GEM? Yes. They must be word aligned because a 68000 can not read word (or double word) values from odd addresses. > For some 32 bit processors this is non-optimal and a portable 32 bit > GEM would have to take that into account. I expect no problem. The definition of the structs contains no infos about alignement. So the best "natural" alignement is used on a system. If you recompile your source on a different GEM system, the alignement of this system is used. But shouldd take this into account if your 32-bit GEM should also execute 16-bit GEM applications. Best regards Michael From Olivier.Landemarre at utbm.fr Thu Jan 8 01:34:37 2009 From: Olivier.Landemarre at utbm.fr (Olivier.Landemarre at utbm.fr) Date: Thu, 08 Jan 2009 10:34:37 +0100 Subject: [GEM Development] GEM not going forward... Comments? In-Reply-To: <20090107212540.B1985@mbernstein.de> References: <496122C2.6020304@aztecfreenet.org> <20090105212432.A25473@mbernstein.de> <7da8e8830901051908n4809fd30r1970c2d09370b79@mail.gmail.com> <49634596.5070407@utbm.fr> <20090107212540.B1985@mbernstein.de> Message-ID: <20090108103437.67354of8i22p25d9@webmail1.utbm.fr> "Michael Bernstein" a ?crit : > Hi Olivier, > >> One important diffrence you can have trouble, is probably with RSC >> files, XaAES or MyAES as I know (for MyAES I'm sure), not support little >> endian RSC format (if you know how I could know, how recognize little to >> big endian RSC file I'm interesting, I could add this in MyAES) > > This problem was still solved by DR. The had written a small program > which can translate between big and little endian RCS files. The sources > for this RCSCONF are part of the sources released under GPL by calderea. > You can also find a version for Atari in the download sesction of my > Homepage which i had compiled from this sources. > > A automatic detection would be much nicer. Otherwise you should always > take care to use the right resource file. Ok thanks so I will look in source code, on Atari part RSC file have extensions that are not in original (Atari extensions and Interface extension). Should quite easy to find. Thanks Olivier > > Best regards > Michael > _______________________________________________ > gem-dev mailing list > gem-dev at simpits.org > http://www.simpits.org/mailman/listinfo/gem-dev > From jem at archivalladolid.org Thu Jan 8 12:31:20 2009 From: jem at archivalladolid.org (=?iso-8859-1?Q?Jos=E9_Emilio_Mori_Recio?=) Date: Thu, 8 Jan 2009 21:31:20 +0100 Subject: [GEM Development] More about GEM's and wiki's future Message-ID: <20090108203212.0404F328014@ns2.simpits.org> Hello again. It's nice to see so many answers and comments in the last week. As a former Atari ST user, all the ST emulators, porting problems, etc. which have been mentioned in the last posts are interesting for me, but my time is limited, so... right now I want to concentrate in GEM/FreeGEM for PC. All the possibilities and themes opened here confirm, I think, that the wiki can still be very useful for documenting all those current and future developments, both in GEM-PC and GEM-ST. And even for the GEM API itself, because it's not "finished": as I've seen, there have been several additions to the GEM functions in the last versions of FreeGEM/OpenGEM, and they may not be the last. So, I agree with Michael that a wiki is harder to create and maintain than other kinds of documentation, but it has the advantage to be a unique and common place for the last up-to-date information and for fixing any possible mistakes that could be discovered in the future, even in the oldest information. Furthermore, I think it won't be too complicated to automate the process of converting, for example, the documentation for each GEM function to a wikipage. I can deal with that... if the wiki is fixed, of course. So, we're back to the problem, we don't have any news from the primary wiki maintainer, Rob. If he doesn't answer in a few more days, I would like to ask Owen to make wiki2 the primary wiki in order for all of us to use and expand it; thanks in advance. And also, sorry for the insistence... the freegem.net domain, where the wikis are, expires in two days, is everything OK with that? Once more, I offer my help for all these problems, if needed. Also, and sorry again: I'm very interested in knowing about Shane Land, as the main *-GEM devoloper in the last years (please correct me if I'm wrong in that), in order to know which would be the starting point for our new improvements (OpenGEM 5, 6, 7, "6 to 7"...) and whether he's still "active" in GEM development or not. If someone in this list knows something about him, please tell us... Looking forward to your answers, best regards, // Jos? Emilio Mori Recio - http://www.gui.uva.es/~jem \\ || Administrador Inform?tico, Arzobispado de Valladolid y Archivo || \\ Miembro 088 del Grupo Universitario de Inform?tica, Valladolid // From owen at owenrudge.net Thu Jan 8 13:05:02 2009 From: owen at owenrudge.net (Owen Rudge) Date: Thu, 08 Jan 2009 21:05:02 +0000 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <20090108203212.0404F328014@ns2.simpits.org> References: <20090108203212.0404F328014@ns2.simpits.org> Message-ID: <49666A7E.7070907@owenrudge.net> Hi Jos?, > So, we're back to the problem, we don't have any news from the primary wiki > maintainer, Rob. If he doesn't answer in a few more days, I would like to > ask Owen to make wiki2 the primary wiki in order for all of us to use and > expand it; thanks in advance. I should be able to do this if necessary, yes. > And also, sorry for the insistence... the > freegem.net domain, where the wikis are, expires in two days, is everything > OK with that? Yes, the domains shall be renewed. I own and run the web host that freegem.net is registered with, so I shall make sure it is renewed. ;) > Also, and sorry again: I'm very interested in knowing about Shane Land, as > the main *-GEM devoloper in the last years (please correct me if I'm wrong > in that), in order to know which would be the starting point for our new > improvements (OpenGEM 5, 6, 7, "6 to 7"...) and whether he's still "active" > in GEM development or not. If someone in this list knows something about > him, please tell us... Well, Shane hasn't posted since the end of September. I'm not sure if he's done much work on OpenGEM recently, but I daresay he'll reply when he has some time to read these e-mails. Regards, -- Owen Rudge http://www.owenrudge.net/ From pcgem at mbernstein.de Fri Jan 9 12:14:48 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Fri, 9 Jan 2009 21:14:48 +0100 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <20090108203212.0404F328014@ns2.simpits.org>; from jem@archivalladolid.org on Thu, Jan 08, 2009 at 09:31:20PM +0100 References: <20090108203212.0404F328014@ns2.simpits.org> Message-ID: <20090109211448.A10622@mbernstein.de> Hi Jos?, > All the possibilities and themes opened here confirm, I think, that the wiki > can still be very useful for documenting all those current and future > developments, both in GEM-PC and GEM-ST. For Atari exists a documentation which was the standard documentation for the complete TOS including GEM. Concerning Atari users there is no need of an additional place for GEM docu. Best regards Michael From jem at archivalladolid.org Sat Jan 10 05:20:38 2009 From: jem at archivalladolid.org (=?iso-8859-1?Q?Jos=E9_Emilio_Mori_Recio?=) Date: Sat, 10 Jan 2009 14:20:38 +0100 Subject: [GEM Development] More about GEM's and wiki's future Message-ID: <20090110132048.8494EC901A5@ns2.simpits.org> Hi again. About Michael's comments... You're right, the documentation in http://toshyp.atari.org/ is quite complete (just a few german translation problems) and I have seen that it includes FreeGEM additions, as does John Elliot's documentation (at www.seasip.info/Gem and OpenGEM SDK); and I have found more complete references on the web such as The Atari Compendium at www.fortunecity.com. But my question is: who will update, or how will they be updated if there are further improvements or corrections to make? I think that is the main advantage of the wiki as a primary reference place: it can be updated by many people and not just one web maintainer alone, which maybe at some time has no longer the time or the interest to do it. Not to forget other advantages: the changing information about existing, updated or new GEM software, tips for the beginner programmer, better navigation and search facilites, etc... all of which I think all of those webs lack of. But more important, I think that if the wiki currently exists (and, hopefully, will be updatable soon), it means that more people feels that it's useful. I don't know exactly how it was created, but I suppose the documentation was also available then, and anyway its advantages were considered. I'd like to read more opinions about this subject. Best regards, // Jos? Emilio Mori Recio - http://www.gui.uva.es/~jem \\ || Administrador Inform?tico, Arzobispado de Valladolid y Archivo || \\ Miembro 088 del Grupo Universitario de Inform?tica, Valladolid // From dennis at windows3.de Sat Jan 10 14:10:59 2009 From: dennis at windows3.de (Dennis Schulmeister) Date: Sat, 10 Jan 2009 23:10:59 +0100 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <20090110132048.8494EC901A5@ns2.simpits.org> References: <20090110132048.8494EC901A5@ns2.simpits.org> Message-ID: <1231625459.11248.7.camel@lcars> Hi, I don't see why there is so much pro/contra discussion about the wiki. In the meantime it could have already been fixed. :) A wiki usually is a good thing to tie the community together (similar to this list) and to provide information at a central location. Despite static HTML sites it fosters collaboration because many people can edit it. So what's the deal? Of course there's already plenty of very good documentation out there. And of course it's not in wiki format. So what? Why don't we just set up a wiki with general information like this: * What is GEM? * What can I do with it? * How do I install it? * Which versions are available? * Who's already doing what? * Where can I find development documentation? That last page would then just contain downloads and links to the already present documents. No big deal and no needless discussion. Though I'm glad that there is some discussion at all. :) Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis at windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 ? From owen at owenrudge.net Sat Jan 10 17:48:34 2009 From: owen at owenrudge.net (Owen Rudge) Date: Sun, 11 Jan 2009 01:48:34 +0000 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <1231625459.11248.7.camel@lcars> References: <20090110132048.8494EC901A5@ns2.simpits.org> <1231625459.11248.7.camel@lcars> Message-ID: <49694FF2.9090803@owenrudge.net> > So what's the deal? Of course there's already plenty of very good > documentation out there. And of course it's not in wiki format. So what? > Why don't we just set up a wiki with general information like this: Well, the wiki is set up. Assuming there's still no word from Rob any time soon, I'll make wiki2 the primary wiki and figure out how to unlock it, etc. Cheers, -- Owen Rudge http://www.owenrudge.net/ From dennis at windows3.de Sun Jan 11 12:31:04 2009 From: dennis at windows3.de (Dennis Schulmeister) Date: Sun, 11 Jan 2009 21:31:04 +0100 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <49694FF2.9090803@owenrudge.net> References: <20090110132048.8494EC901A5@ns2.simpits.org> <1231625459.11248.7.camel@lcars> <49694FF2.9090803@owenrudge.net> Message-ID: <1231705864.6741.1.camel@lcars> On Sun, 2009-01-11 at 01:48 +0000, Owen Rudge wrote: > Well, the wiki is set up. Assuming there's still no word from Rob any > time soon, I'll make wiki2 the primary wiki and figure out how to unlock > it, etc. That would be a good thing, imho. :) So thanks in advance. Yours sincerely, Dennis Schulmeister -- Dennis Schulmeister - Schifferstr. 1 - 76189 Karlsruhe - Germany Tel: +49 721/5978883 - Mob: +49 152/01994400 - eMail: dennis at windows3.de Now moved to the corridor: Hermes! (http://ncc-1701a.homelinux.net) Besides that: http://www.denchris.de - http://www.motagator.net/bands/65 ? From ben.jemmett at ukonline.co.uk Sun Jan 11 13:38:28 2009 From: ben.jemmett at ukonline.co.uk (Ben A L Jemmett) Date: Sun, 11 Jan 2009 21:38:28 +0000 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <49694FF2.9090803@owenrudge.net> References: <20090110132048.8494EC901A5@ns2.simpits.org> <1231625459.11248.7.camel@lcars> <49694FF2.9090803@owenrudge.net> Message-ID: <1231709908.496a66d496270@webmail.ukonline.net> Quoting Owen Rudge : > Well, the wiki is set up. Assuming there's still no word from Rob any > time soon, I'll make wiki2 the primary wiki and figure out how to unlock > it, etc. I've just poked Rob on IRC -- I know he's being kept rather busy these days so probably hasn't had a chance to read list e-mail for a while: [21:36:11] btw -- not sure if you've been keeping up on gem-dev lately -- a few people asking about the GEM wiki, Owen is planning to make his backup the primary in a few days unless you squawk otherwise :) [21:36:59] he's welcome to, really. I wish I had time to maintain the thing, but I don't :( So please do twiddle things are required! -- Regards, Ben A L Jemmett. http://flatpack.microwavepizza.co.uk/ ---------------------------------------------- This mail sent through http://www.ukonline.net From ben.jemmett at ukonline.co.uk Sun Jan 11 13:44:10 2009 From: ben.jemmett at ukonline.co.uk (Ben A L Jemmett) Date: Sun, 11 Jan 2009 21:44:10 +0000 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <1231709908.496a66d496270@webmail.ukonline.net> References: <20090110132048.8494EC901A5@ns2.simpits.org> <1231625459.11248.7.camel@lcars> <49694FF2.9090803@owenrudge.net> <1231709908.496a66d496270@webmail.ukonline.net> Message-ID: <1231710250.496a682ab3fcd@webmail.ukonline.net> Quoting Ben A L Jemmett : > So please do twiddle things are required! FFS. "as required", obviously. I need more coffee. -- Regards, Ben A L Jemmett. http://flatpack.microwavepizza.co.uk/ ---------------------------------------------- This mail sent through http://www.ukonline.net From pcgem at mbernstein.de Sun Jan 11 01:52:41 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sun, 11 Jan 2009 10:52:41 +0100 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <1231625459.11248.7.camel@lcars>; from dennis@windows3.de on Sat, Jan 10, 2009 at 11:10:59PM +0100 References: <20090110132048.8494EC901A5@ns2.simpits.org> <1231625459.11248.7.camel@lcars> Message-ID: <20090111105240.B29795@mbernstein.de> Hi Dennis, > I don't see why there is so much pro/contra discussion about the wiki. It seems, nobody really has seen, that i dont give contras against a wiki. Maybe because it is difficult for me to find the right words in english? I point only to the fact, that a developer API description is present and maybe need only a little additional work. To use this existing document will give you more time to write other documentations or write software, ... > * What is GEM? > * What can I do with it? > * How do I install it? > * Which versions are available? > * Who's already doing what? > * Where can I find development documentation? > > That last page would then just contain downloads and links to the > already present documents. No big deal and no needless discussion. This is the same what i suggest. You idea will reuse the existing development documentation and dont do the same work again and still focus to write additional documents. And thats exactly what i also want to do. But i have let it open how to publish this doku, wiki or something else. Best regards Michael From pcgem at mbernstein.de Sun Jan 11 01:40:42 2009 From: pcgem at mbernstein.de (Michael Bernstein) Date: Sun, 11 Jan 2009 10:40:42 +0100 Subject: [GEM Development] More about GEM's and wiki's future In-Reply-To: <20090110132048.8494EC901A5@ns2.simpits.org>; from jem@archivalladolid.org on Sat, Jan 10, 2009 at 02:20:38PM +0100 References: <20090110132048.8494EC901A5@ns2.simpits.org> Message-ID: <20090111104041.A29795@mbernstein.de> Hi Jos?, > You're right, the documentation in http://toshyp.atari.org/ is quite > complete (just a few german translation problems) and I have seen that it > includes FreeGEM additions, > > But my question is: who will update, or how will they be updated if there > are further improvements or corrections to make? toshyp is set under GPL from its origin author. It is written in a meta language (UDO) which gives you to possibility to generate many output formats like HTML, Atari ST-Guide, WinHelp, RTF, ... The sources are hosted in a CVS. So you dont have to ask the webmaster to make changes. You can ask for write accesss to the repository and than start to add changes. I think, there are not much people who want to change a programming reference. I give you a deep link into my homepage for a description how to access the CVS: http://atari.mbernstein.de/prog/projekte/mb_prj/tos_hyp/index.htm The text is in german, but i hope you can find the informations about how to access the CVS. I got the feeling, there is a misunderstanding. I dont speak about all aspects of documentation. I speak only about a API reference if i point t o exisiting docu which will help to spare time and work. Best regards, Michael From jem at archivalladolid.org Sat Jan 24 16:29:24 2009 From: jem at archivalladolid.org (=?iso-8859-1?Q?Jos=E9_Emilio_Mori_Recio?=) Date: Sun, 25 Jan 2009 01:29:24 +0100 Subject: [GEM Development] Proposal about the wiki... Message-ID: <20090125002939.D0241C901A6@ns2.simpits.org> Hi again, after some busy days... Well, I think it's useless to keep on the discussion about what the wiki should contain, when it hasn't even been fixed. So, the plan should be, first of all, wait for Owen to unlock the secondary wiki. I suppose it will happen in any moment, as we already know that Rob can't maintain the primary. I don't know if "wiki2" could also be renamed to "wiki", hiding the non-working primary wiki, but that should be the idea... And then, fill the wiki with the general information that Dennis has pointed... everything except for the full API programming reference, which should only be linked to. Then, we see if the wiki's being useful, how is GEM evolving by then, what the people thinks... and then we could think or discuss about including the reference or not. We'll wait and see. I hope everybody agrees... So, waiting for the wiki's unlock, best regards... // Jos? Emilio Mori Recio - http://www.gui.uva.es/~jem \\ || Administrador Inform?tico, Arzobispado de Valladolid y Archivo || \\ Miembro 088 del Grupo Universitario de Inform?tica, Valladolid // From rob at midworld.co.uk Sun Jan 25 14:41:46 2009 From: rob at midworld.co.uk (rob at midworld.co.uk) Date: Sun, 25 Jan 2009 22:41:46 +0000 Subject: [GEM Development] Proposal about the wiki... In-Reply-To: <20090125002939.D0241C901A6@ns2.simpits.org> References: <20090125002939.D0241C901A6@ns2.simpits.org> Message-ID: <20090125224146.GU21761@meurglys.midworld.co.uk> Good evening, (usual disclaimers, blah de blah, opinions are my own and nobody is obliged to agree with me) On Sun, Jan 25, 2009 at 01:29:24AM +0100, Jos? Emilio Mori Recio wrote: > Well, I think it's useless to keep on the discussion about what the wiki > should contain, when it hasn't even been fixed. This sounds worryingly managerial... > So, the plan should be, first of all, wait for Owen to unlock the secondary > wiki. I suppose it will happen in any moment, as we already know that Rob > can't maintain the primary. I don't know if "wiki2" could also be renamed to > "wiki", hiding the non-working primary wiki, but that should be the idea... I don't mind hosting the damn thing, I just can't actively maintain it. > And then, fill the wiki with the general information that Dennis has > pointed... There is a non-trivial amount of information just in people's heads. Possibly looking at a structure to enable people to dump their thoughts and ideas might be a bit more use to start with, as that's the most volatile of all? > everything except for the full API programming reference, which > should only be linked to. Why? Pretty much the entire target audience of GEM is developers at this stage in the game. That's the easy bit of the wiki or any documentation stuff. Ta, Rob (would love to have time&inclination to crack out EFGD again)