From jce at seasip.demon.co.uk Sat Feb 4 18:15:33 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Sun, 5 Feb 2012 02:15:33 +0000 (GMT) Subject: [GEM Development] New video driver for Wang Professional Computer Message-ID: I've added a new driver to : one for the Wang Professional Computer, using the monochrome graphics card. I've only tested this under emulation, so it's quite possible that on a real Wang box it will do all sorts of weird things. There's a screenshot of it in action at . Just continuing my quest to get GEM running on obscure non-IBM-compatible 8086 boxes -- and, as a side-effect, gaining the ability to edit text files with WRITE.APP :-) -- John Elliott From rtdos at hotmail.com Sat Feb 4 18:36:22 2012 From: rtdos at hotmail.com (Wood Jeff) Date: Sat, 4 Feb 2012 19:36:22 -0700 Subject: [GEM Development] GEM Source Code Message-ID: Hey John, Can you re-post the link to D/L the GEM Source Code? Lost that email (thought I saved it). Sorry. Again, Thanks. Jeff http://www.rtdos.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.simpits.org/pipermail/gem-dev/attachments/20120204/9a4f0047/attachment.html From jce at seasip.demon.co.uk Sun Feb 5 14:26:05 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Sun, 5 Feb 2012 22:26:05 +0000 (GMT) Subject: [GEM Development] GEM Source Code In-Reply-To: from "Wood Jeff" at Feb 04, 2012 7:36:22 pm GMT Message-ID: > Can you re-post the link to D/L the GEM Source Code? Lost that email = > (thought I saved it). Sorry. Again, Thanks. The original source can be found at , and the source for the bits I've worked on can be found at . -- John Elliott From Dr.Kasten at t-online.de Sun Feb 5 14:37:56 2012 From: Dr.Kasten at t-online.de (M.Kasten) Date: Sun, 05 Feb 2012 22:37:56 -0000 Subject: [GEM Development] GEM Source Code Message-ID: <1RuAiV-0aa3O40@fwd01.aul.t-online.de> Dear Wood Jeff, you can find it here: http://sourceforge.net/projects/opengem/ Greetings, Michael Kasten -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.simpits.org/pipermail/gem-dev/attachments/20120205/643a56e0/attachment.html From jce at seasip.demon.co.uk Sun Feb 5 15:42:48 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Sun, 5 Feb 2012 23:42:48 +0000 (GMT) Subject: [GEM Development] New video driver for Wang Professional Computer In-Reply-To: from "John Elliott" at Feb 05, 2012 2:15:33 am GMT Message-ID: Apologies for spamming with updates, but I've now completed a second GEM driver for the Wang PC -- this time, for the 4-colour 640x225 video card. As before, both drivers can be downloaded from . The inevitable screenshot is at . At the moment, I don't see any prospect of support for the third type of Wang video card; it's based around two NEC 7220 GDCs, which I have no experience with, and which QDAE does not emulate. -- John Elliott From rtdos at hotmail.com Sun Feb 5 17:00:26 2012 From: rtdos at hotmail.com (Wood Jeff) Date: Sun, 5 Feb 2012 18:00:26 -0700 Subject: [GEM Development] GEM Source Code In-Reply-To: References: from "Wood Jeff" at Feb 04, 2012 7:36:22 pm GMT, Message-ID: Thanks Michael and John. ----- Jeff http://www.rtdos.com > To: gem-dev at simpits.org > Date: Sun, 5 Feb 2012 22:26:05 +0000 > From: jce at seasip.demon.co.uk > Subject: Re: [GEM Development] GEM Source Code > > > Can you re-post the link to D/L the GEM Source Code? Lost that email > > (thought I saved it). Sorry. Again, Thanks. > > The original source can be found at > , and the source for the bits I've > worked on can be found at . > > -- > John Elliott > _______________________________________________ > 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/20120205/455dd360/attachment.html From topcatdrc at yahoo.com Mon Feb 6 08:44:37 2012 From: topcatdrc at yahoo.com (Thomas Clayton) Date: Mon, 6 Feb 2012 08:44:37 -0800 (PST) Subject: [GEM Development] GEM Source Code In-Reply-To: <1RuAiV-0aa3O40@fwd01.aul.t-online.de> Message-ID: <1328546677.94010.YahooMailClassic@web181516.mail.ne1.yahoo.com> Jeff might want to start here: http://opengem.sourceforge.net/ :-) Tom C --- On Sun, 2/5/12, M.Kasten wrote: From: M.Kasten Subject: [GEM Development] GEM Source Code To: gem-dev at simpits.org Date: Sunday, February 5, 2012, 4:36 PM Dear Wood Jeff, you can find it here: http://sourceforge.net/projects/opengem/ Greetings, Michael Kasten -----Inline Attachment Follows----- _______________________________________________ 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/20120206/8dc126de/attachment.html From jce at seasip.demon.co.uk Fri Feb 24 13:02:51 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Fri, 24 Feb 2012 21:02:51 +0000 (GMT) Subject: [GEM Development] Today I Learned Message-ID: ... that the support for palette changes in just about every GEM driver I'm aware of is buggy. What happens is: the RGB table is held in the driver data segment, so each workstation (graphics context) has its own RGB table. This means that changes made by vs_color() in one workstation won't be picked up by others. You can see this happen by loading two copies of PALETTE.ACC, opening them both, making a change in one, and then clicking on the same colour in the other one. Since there is only one screen and only one palette, I'd expect a vs_color in one workstation to be reflected if there's a vq_color in another. I'd be interested to learn whether this is the case in Atari GEM; the documentation here can be read as implying it. -- John Elliott From topcatdrc at yahoo.com Sat Feb 25 11:48:17 2012 From: topcatdrc at yahoo.com (Thomas Clayton) Date: Sat, 25 Feb 2012 11:48:17 -0800 (PST) Subject: [GEM Development] Today I Learned In-Reply-To: Message-ID: <1330199297.89434.YahooMailClassic@web181514.mail.ne1.yahoo.com> Hi John, First, just for clarification, " ? ... that the support for palette changes[,] in just about every GEM driver I'm aware of[,] is buggy. " Secondly, some questions. For 16 color (or colour(?), in UK English) modes, I thought there was one, and only one, set of 16 for ALL computers - not JUST versions of GEM. Those 16 were THE same established ones for TI-99/4a, Apple II's., IBM CGA, EGA, and VGA, AND Macintoshes. (It was something like "native" choices. They MIGHT not LOOK the same (or be) BUT the video chip WOULD BE making THE same assignments for ANY system.) It was when one 'went to' 256 colors that "variety" became an "issue". Is THIS what you're commenting upon? There wasn't A standard 'palette'. There IS, now, one - well, for 216 (6-cubed) colors - derived from web-page 'universality'. This, BTW, has been why I had been curious about SciTech Software's UniVESA (from back in the day) AND PC-GEM. (It would require 512KB, if not 1MB, V-RAM.) I had hoped to put you in contact (maybe I did, briefly) with (name escapes me) at SciTech (though he seemed to ONLY want to converse about the latest 32-bit 'incarnation': the universal SNAP driver (for Windows, for Linux and, my beloved, "OS/3"). They have (he has) since SOLD all that to some Canadian company and moved back to Australia (AFAIK). ( ___? Benton?? When I come across his name again, I'll post it.) SNAP (and UniVESA?) was, I thought, ?some what? open-source. Anyway, the 'dream' was 216 standardized colors and 40 "I don't care" values to make up a deeper (256) color palette for PC-GEM that would allow an 'Arachne-like' app for GEM to be built. And, then, there are all those graphics app.s ... that could use them, also. :-) Sincerely, Thomas Clayton who still thinks in terms of a DRi PCGEMDOS - OR OS/O (O for Original) or OS/1. 'nough for now. --- On Fri, 2/24/12, John Elliott wrote: From: John Elliott Subject: [GEM Development] Today I Learned To: gem-dev at simpits.org Date: Friday, February 24, 2012, 3:02 PM ? ... that the support for palette changes in just about every GEM driver I'm aware of is buggy. ? What happens is: the RGB table is held in the driver data segment, so each workstation (graphics context) has its own RGB table. This means that changes made by vs_color() in one workstation won't be picked up by others. You can see this happen by loading two copies of PALETTE.ACC, opening them both, making a change in one, and then clicking on the same colour in the other one. ? Since there is only one screen and only one palette, I'd expect a vs_color in one workstation to be reflected if there's a vq_color in another. I'd be interested to learn whether this is the case in Atari GEM; the documentation here can be read as implying it. -- John Elliott _______________________________________________ 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/20120225/49a63090/attachment.html From jce at seasip.demon.co.uk Sat Feb 25 14:25:01 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Sat, 25 Feb 2012 22:25:01 +0000 (GMT) Subject: [GEM Development] Today I Learned In-Reply-To: from "Thomas Clayton" at Feb 25, 2012 11:48:17 am GMT Message-ID: > For 16 color (or colour(?), in UK English) modes, I thought there was one, = > and only one, set of 16 for ALL computers - not JUST versions of GEM. Those= > 16 were THE same established ones for TI-99/4a, Apple II's., IBM CGA, EGA,= > and VGA, AND Macintoshes. (It was something like "native" choices. They MI= > GHT not LOOK the same (or be) BUT the video chip WOULD BE making THE same a= > ssignments for ANY system.) > > It was when one 'went to' 256 colors that "variety" became an "issue". Is T= > HIS what you're commenting upon? No. This behaviour is present in any driver where the red/green/blue assignments of the colours onscreen can be changed. For example, EGA 640x200 mode has a palette of 16 colours and all 16 can be displayed on the screen. But because the EGA has palette registers of a sort, it's possible to use vs_color() to make all red pixels on the screen go green with one function call: WORD rgb[] = { 0, 1000, 0 }; vs_color(vdi_handle, RED, rgb); The problem is that if this change is made by one program, and a second program then asks 'what RGB values does the RED pen have?' the values returned will be { 1000, 0, 0 } not { 0, 1000, 0 }. -- John Elliott From topcatdrc at yahoo.com Mon Feb 27 09:24:06 2012 From: topcatdrc at yahoo.com (Thomas Clayton) Date: Mon, 27 Feb 2012 09:24:06 -0800 (PST) Subject: [GEM Development] Today I Learned In-Reply-To: Message-ID: <1330363446.20548.YahooMailClassic@web181520.mail.ne1.yahoo.com> John, ?I understand, I hope. I'm thinking that the function-call will (would) have to be made "lower" in the system, so ALL windows would see the same palette. This implies some fundamental programming changes with-in GEM. (Now, let me show my ignorance: this would be changing the call from the AES to the VDI ?? ) Thomas Clayton --- On Sat, 2/25/12, John Elliott wrote: From: John Elliott Subject: Re: [GEM Development] Today I Learned To: gem-dev at simpits.org Date: Saturday, February 25, 2012, 4:25 PM > For 16 color (or colour(?), in UK English) modes, I thought there was one, > and only one, set of 16 for ALL computers - not JUST versions of GEM. Those>? 16 were THE same established ones for TI-99/4a, Apple II's., IBM CGA, EGA,>? and VGA, AND Macintoshes. (It was something like "native" choices. They MI> GHT not LOOK the same (or be) BUT the video chip WOULD BE making THE same a> ssignments for ANY system.) > > It was when one 'went to' 256 colors that "variety" became an "issue". Is T> HIS what you're commenting upon? ? No. This behaviour is present in any driver where the red/green/blue assignments of the colours onscreen can be changed. For example, EGA 640x200 mode has a palette of 16 colours and all 16 can be displayed on the screen. But because the EGA has palette registers of a sort, it's possible to use vs_color() to make all red pixels on the screen go green with one function call: ??? WORD rgb[] = { 0, 1000, 0 }; ??? vs_color(vdi_handle, RED, rgb); ? The problem is that if this change is made by one program, and a second program then asks 'what RGB values does the RED pen have?' the values returned will be { 1000, 0, 0 } not { 0, 1000, 0 }. -- John Elliott _______________________________________________ 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/20120227/fb6d63fc/attachment-0001.html From jce at seasip.demon.co.uk Mon Feb 27 11:48:43 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Mon, 27 Feb 2012 19:48:43 +0000 (GMT) Subject: [GEM Development] Today I Learned In-Reply-To: from "Thomas Clayton" at Feb 27, 2012 9:24:06 am GMT Message-ID: > I'm thinking that the function-call will (would) have to be made "lower" in= > the system, so ALL windows would see the same palette. This implies some = > fundamental programming changes with-in GEM.=20 > > (Now, let me show my ignorance: this would be changing the call from the AE= > S to the VDI ?? ) It's not quite as far-reaching as that. What it involves is rewriting all the video drivers, so that they store the palette values in their code segment (which is common to all programs) rather than their data segment (which gets duplicated every time a program opens a new graphics workstation). -- John Elliott From Dr.Kasten at t-online.de Mon Feb 27 13:59:13 2012 From: Dr.Kasten at t-online.de (M.Kasten) Date: Mon, 27 Feb 2012 21:59:13 -0000 Subject: [GEM Development] VM DOS Message-ID: <1S28ar-2BRPX60@fwd19.aul.t-online.de> Dear members, i?ve got two DRI disks: "VM DOS System Ver. 4.1a" and "VM DOS Application Ver. 4.1a". Can anyone give me more information about this OS ? M.Kasten -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.simpits.org/pipermail/gem-dev/attachments/20120227/ba1d8a05/attachment.html From topcatdrc at yahoo.com Mon Feb 27 15:37:00 2012 From: topcatdrc at yahoo.com (Thomas Clayton) Date: Mon, 27 Feb 2012 15:37:00 -0800 (PST) Subject: [GEM Development] VM DOS In-Reply-To: <1S28ar-2BRPX60@fwd19.aul.t-online.de> Message-ID: <1330385820.92682.YahooMailClassic@web181515.mail.ne1.yahoo.com> Michael, I'll be interested in what THE answer to this one is! I'd guess VM = Virtual Memory so .. a DOS that swaps out to disk - a hard disk drive, we hope :-)? otherwise it would be SLlOooooow. :-(? Thomas Clayton BTW, IF no definite answer, here, try the DRI group on Yahoo!. Also, thanks for FINDing the things you do! --- On Mon, 2/27/12, M.Kasten wrote: From: M.Kasten Subject: [GEM Development] VM DOS To: gem-dev at simpits.org Date: Monday, February 27, 2012, 3:58 PM Dear members, i?ve got two DRI disks: "VM DOS System Ver. 4.1a" and "VM DOS Application Ver. 4.1a". Can anyone give me more information about this OS ? M.Kasten -----Inline Attachment Follows----- _______________________________________________ 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/20120227/d454b3fc/attachment.html From topcatdrc at yahoo.com Tue Feb 28 09:45:07 2012 From: topcatdrc at yahoo.com (Thomas Clayton) Date: Tue, 28 Feb 2012 09:45:07 -0800 (PST) Subject: [GEM Development] Today I Learned Message-ID: <1330451107.55116.YahooMailClassic@web181515.mail.ne1.yahoo.com> John, > What it involves is rewriting all the video drivers, > so that they store the palette values ... . Wouldn't THAT be MORE far-reaching? !:-| Also, I'm amazed at your knowledge of _just_where_ GEM places _what_ within its 'guts'! Besides someone RE-reading the source code (from scratch, as it were); is there any place these things _are_ documented? In other words, IF we were to "loose" John Elliot, where could the "rest of us" (<-- to steal a phrase!) find out about these things that YOU know? Sincerely, Thomas Clayton --- On Mon, 2/27/12, John Elliott wrote: From: John Elliott Subject: Re: [GEM Development] Today I Learned To: gem-dev at simpits.org Date: Monday, February 27, 2012, 1:48 PM > I'm thinking that the function-call will (would) have to be made "lower" in= >? the system, so ALL windows would see the same palette. This implies some? = > fundamental programming changes with-in GEM.=20 > > (Now, let me show my ignorance: this would be changing the call from the AE= > S to the VDI ?? ) ? It's not quite as far-reaching as that. What it involves is rewriting all the video drivers, so that they store the palette values in their code segment (which is common to all programs) rather than their data segment (which gets duplicated every time a program opens a new graphics workstation). -- John Elliott _______________________________________________ gem-dev mailing list gem-dev at simpits.org http://www.simpits.org/mailman/listinfo/gem-dev From jce at seasip.demon.co.uk Tue Feb 28 14:58:34 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Tue, 28 Feb 2012 22:58:34 +0000 (GMT) Subject: [GEM Development] Today I Learned In-Reply-To: from "Thomas Clayton" at Feb 28, 2012 9:45:07 am GMT Message-ID: > > John, > > > What it involves is rewriting all the video drivers, > > so that they store the palette values ... . > > Wouldn't THAT be MORE far-reaching? !:-| From my point of view, no, because all the code's in one directory, and I'd just have to do the fix once, copy it into the other affected drivers, and type 'make'. Moving code from the AES to the VDI or vice versa would require editing two separate projects, and updating them in sync. > Besides someone RE-reading the source code (from scratch, as it were); > is there any place these things _are_ documented? > In other words, IF we were to "loose" John Elliot, where could the "rest of= > us" (<-- to steal a phrase!) find out about these things that YOU know? You'd have to make do with comments in the code and the mailing list archives. I think there's a lot of GEM knowledge in the Atari world, but you have to be selective about which bits apply to PC-GEM. -- John Elliott From jce at seasip.demon.co.uk Wed Feb 29 17:18:45 2012 From: jce at seasip.demon.co.uk (John Elliott) Date: Thu, 1 Mar 2012 01:18:45 +0000 (GMT) Subject: [GEM Development] Updated Apricot drivers Message-ID: Against the vanishingly rare possibility that anyone but me is interested in GEM drivers for the Apricot Portable or F-Series computers: has reconstructed source for the Apricot Portable / F-Series drivers I've been able to find. It also has updated versions that fix the rendering bugs I've mentioned previously (see the screenshots at ). has FreeGEM versions of the same drivers, based on the GEM/3 driver tree. The Portable and F-Series drivers are the ones I've mentioned before, that generate code on the fly for lines and bit blits. So, for example, if you wanted to draw a line on the screen, the driver would create a subroutine to draw that specific line, and then run it. Whether it actually boosts performance I couldn't say, but someone must have had a lot of fun coding it. -- John Elliott From lproven at gmail.com Wed Feb 29 17:34:47 2012 From: lproven at gmail.com (Liam Proven) Date: Thu, 1 Mar 2012 01:34:47 +0000 Subject: [GEM Development] Updated Apricot drivers In-Reply-To: References: Message-ID: On 1 March 2012 01:18, John Elliott wrote: > ?Against the vanishingly rare possibility that anyone but me is interested > in GEM drivers for the Apricot Portable or F-Series computers: > > has reconstructed source for the > Apricot Portable / F-Series drivers I've been able to find. It also has > updated versions that fix the rendering bugs I've mentioned previously > (see the screenshots at ). > > has FreeGEM versions of the same > drivers, based on the GEM/3 driver tree. > > ?The Portable and F-Series drivers are the ones I've mentioned before, that > generate code on the fly for lines and bit blits. So, for example, if you > wanted to draw a line on the screen, the driver would create a subroutine > to draw that specific line, and then run it. Whether it actually boosts > performance I couldn't say, but someone must have had a lot of fun coding > it. Impressive stuff, John. Nice work. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Tel: +44 20-8685-0498 ? Cell: +44 7939-087884