Grx September 1999

grx@gnu.de

5 participants
9 discussions

Re: Grx Problems with linux-X11
by Hartmut Schirmer 07 Jan '00

07 Jan '00

2nd try ... ---------- Forwarded Message ---------- Subject: Re: Grx Problems with linux-X11 Date: Thu, 30 Dec 1999 22:21:45 +0100 From: Hartmut Schirmer <hartmut.schirmer(a)arcormail.de> On Thu, 30 Dec 1999, DAANEN Vincent wrote: >Hi > I'm using grx23 with djgpp and all goes fine but, with linux, I meet >a problem > The problem is that GrSetColor don't seem to work : > - we define 1024x768x256 mode => pseudo color in 8 bits > - next we set the colors : for (i=0;i<256;i++) GrSetColr(i,i,i,i); : >we should have a gray-level color table from black (i=0) to white (i=255) > > but when I display an image of the gray-levels, I obtain colored >colors (green red,blue yellow...) > > Can someone tell me what to do to obtain my gray-level color table >using THIS WAY > Thanks Well, normally GRX wonŽt allocate all available colors under X11. Using the option ŽprivcmapŽ forces GRX to use a full 256 color map. You can either set the GRX20DRV environment variable to Žxwin::privcmapŽ or call GrSetDriver( "xwin::privcmap") Hartmut

2 3

Fwd: GRX copyright assignment to FSF
by Hartmut Schirmer 03 Jan '00

03 Jan '00

Third try to get this out ... ---------- Forwarded Message ---------- Subject: GRX copyright assignment to FSF Date: Thu, 30 Dec 1999 22:51:44 +0100 From: Hartmut Schirmer <hartmut.schirmer(a)arcormail.de> Hi Andris, hi Ulrich, both of you contributed major major parts to the GRX library. Before we can assign the GRX graphics lib to the FSF we need you principle agreement about this step. So far Csaba Biegl, Hartmut Schirmer, Michael Goffioul and Michal Stencl as major contibutors agreed in principle. Andris Pavenis and Ulrich Leodolter need to agree before assignment can be done. Andris and Ulrich, please send a note about your opinion to the GRX mailing list (grx(a)gnu.de) me (hartmut.schirmer(a)arcormail.de) Richard Stallman (rms(a)gnu.org) If Andris&Ulrich agree in principle about assigning GRX to the FSF Richard will send us the right papers to sign. To anyone who contributed to GRX and isnŽt listed as major contributor will need to sign a disclaimer. IŽll contact you after all major contributors agreed. Thanks to all of you and a happy new year Hartmut

2 1

(no subject)
by Leonardo Alejandro Bustos Wallace 27 Sep '99

27 Sep '99

Hi! I worked some years whith Borland C 3.0, and now I change with gcc compiler. The problem that I have is to install the grx libraries. I compile the grx23 librearies, but when I wrote C:\djgpp\contrib\grx23\src>make -f makefile.dj2 ... utils/shiftscl.c: In function '_GR_shift_scanline': utils/shiftscl.c:48: Invalid 'asm' statement: utils/shiftscl.c:48: fixed or forbidden register 2 (cx) was spilled for class CREG. utils/shiftscl.c:102: Invalid 'asm' statement: utils/shiftscl.c:102: fixed or forbidden register 2 (cx) was spilled for class CREG. make.exe[1]: *** [utils/shiftscl.o] Error 1 C:\djgpp\contrib\grx23\src>_ Of the rest, I do it well I think.(twice) Can someone help me ? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Mailing list archive available online
by Anja Drewitz 27 Sep '99

27 Sep '99

Hello, now you can access the grx and grx-announce mailing list archives via the world wide web: http://www.gnu.de/archive/wilma.cgi/grx http://www.gnu.de/archive/wilma.cgi/grx-announce Currently, the archive dates back to June 1999 only. We are going to put earlier messages online, too, as time permits. (Note: I mentioned the grx-announce archive is mentioned for sake of completeness only as it contains no messages yet.) Best wishes, Anja

1 0

Bug report
by Josu Onandia 09 Sep '99

09 Sep '99

Hello, I'm evaluating the GRX library (a very good work, by the way) and I believe I've found two bugs. The function _GrBuildFont (file buildfnt.c) test the bit GR_FONTCVT_FIXIFY that way: if((cvt & GR_FONTCVT_FIXIFY) & fprop) and I believe it should look if((cvt & GR_FONTCVT_FIXIFY) && fprop) ---- Then the function cvtbitmap (same file) allocates a buffer (called 'work') but before the code reaches the FREE(work) sentence, the pointer 'work' is modified, and FREE crashes. I've solved this way: savework = work = ALLOC((size_t)i); .... .... // FREE(work); FREE(savework); End of bug report. I hope this information will be useful to you. Now a question: I'm trying to convert a proportional font into a fixed one: pFont = GrLoadFont("tms38"); pFontFix = GrBuildConvertedFont(pFont,GR_FONTCVT_FIXIFY,38,38,0,0); With the corrections above now it works, at least it doesn't crash, but the resulting font, when printed, looks very strange. Am I doing something wrong? Thanks. Josu

2 1

Re: grx23 under as-2.95
by pavenis＠lanet.lv 09 Sep '99

09 Sep '99

Sorry, pressed send button too early in previous mail) Now about patch. It seems to be Ok. I had to do the same when tried to build Allegro using recent binutils snapshot. Andris On 8 Sep 99, at 22:29, Ian Miller wrote: > Ahem. > > I'm using pretty much up to date binutils 2.95 > right now. I wouldn't recommend it unless it > doesn't matter to you much if your software > doesn't work. That said, they do seem to > work fine. However,... > > as 2.95 interprets a couple of GRX inline > assembler call instructions as > PC-relative and chokes on them. > as 2.81 interpreted them as absolute > calls, and this is evidently what the code > intends. > > The following simple patch, duplicated at > http://www.shelob.force9.co.uk/djgpp/grxasm.dif, > applies the * prefix to the call absolute > operands as the as 2.95 manual requires. > It works for me. > > IF IN DOUBT, DO NOT APPLY THIS PATCH > > Happy hacking, > Ian > -- > Ian Miller, Dorset, UK > > *** src/vdrivers/vesa_pm.orig.c Mon May 11 20:20:28 1998 > --- src/vdrivers/vesa_pm.c Wed Sep 8 21:41:52 1999 > *************** > *** 349,355 **** > static INLINE void PM_banking(short BX, short DX) { > __asm__ volatile ( > " pushal \n" > ! " call %3 \n" > " popal " > : /* no output */ > : "a" (0x4F05), "b" (BX), "d" (DX), > --- 349,355 ---- > static INLINE void PM_banking(short BX, short DX) { > __asm__ volatile ( > " pushal \n" > ! " call *%3 \n" > " popal " > : /* no output */ > : "a" (0x4F05), "b" (BX), "d" (DX), > *************** > *** 362,368 **** > " pushal \n" > " movw %%ax, %%es \n" > " movw $0x4f05, %%ax \n" > ! " call %3 \n" > " popal " > : /* no output */ > : "a" (es), "b" (BX), "d" (DX), > --- 362,368 ---- > " pushal \n" > " movw %%ax, %%es \n" > " movw $0x4f05, %%ax \n" > ! " call *%3 \n" > " popal " > : /* no output */ > : "a" (es), "b" (BX), "d" (DX), > > > > > >

1 0

Re: grx23 under as-2.95
by pavenis＠lanet.lv 09 Sep '99

09 Sep '99

On 8 Sep 99, at 22:29, Ian Miller wrote: > Ahem. > > I'm using pretty much up to date binutils 2.95 > right now. I wouldn't recommend it unless it > doesn't matter to you much if your software > doesn't work. That said, they do seem to > work fine. However,... > > as 2.95 interprets a couple of GRX inline > assembler call instructions as > PC-relative and chokes on them. > as 2.81 interpreted them as absolute > calls, and this is evidently what the code > intends. > > The following simple patch, duplicated at > http://www.shelob.force9.co.uk/djgpp/grxasm.dif, > applies the * prefix to the call absolute > operands as the as 2.95 manual requires. > It works for me. > > IF IN DOUBT, DO NOT APPLY THIS PATCH > > Happy hacking, > Ian > -- > Ian Miller, Dorset, UK > > *** src/vdrivers/vesa_pm.orig.c Mon May 11 20:20:28 1998 > --- src/vdrivers/vesa_pm.c Wed Sep 8 21:41:52 1999 > *************** > *** 349,355 **** > static INLINE void PM_banking(short BX, short DX) { > __asm__ volatile ( > " pushal \n" > ! " call %3 \n" > " popal " > : /* no output */ > : "a" (0x4F05), "b" (BX), "d" (DX), > --- 349,355 ---- > static INLINE void PM_banking(short BX, short DX) { > __asm__ volatile ( > " pushal \n" > ! " call *%3 \n" > " popal " > : /* no output */ > : "a" (0x4F05), "b" (BX), "d" (DX), > *************** > *** 362,368 **** > " pushal \n" > " movw %%ax, %%es \n" > " movw $0x4f05, %%ax \n" > ! " call %3 \n" > " popal " > : /* no output */ > : "a" (es), "b" (BX), "d" (DX), > --- 362,368 ---- > " pushal \n" > " movw %%ax, %%es \n" > " movw $0x4f05, %%ax \n" > ! " call *%3 \n" > " popal " > : /* no output */ > : "a" (es), "b" (BX), "d" (DX), > > > > > >

1 0

Bug report
by Josu Onandia 08 Sep '99

08 Sep '99

Hi, I believe I've found a bug in GRX. Should I post it on this mailing list, or there is someone maintaining the library and I should send it directly to him? Thanks Josu

1 0

Fwd: Re: PowerPC
by Hartmut Schirmer 05 Sep '99

05 Sep '99

Hmm, from my mail logs it looks like this never made it to the list or to Josu. Sorry, Hartmut ---------- Forwarded Message ---------- Subject: Re: PowerPC Date: Fri, 30 Jul 1999 20:27:22 +0200 From: Hartmut Schirmer <hartmut.schirmer(a)arcormail.de> On Fri, 30 Jul 1999, Josu Onandia wrote: >Hi All, > >I suscribed to this list a month ago, and I don't see a lot of mouvement on >the list, so I wonder if GRX is actually being used. If so, perhaps someone >can help me. > >I'm evaluating the possibility of porting GRX to a PowerPC, precisely to a >MPC823, which has its own on-chip graphics system. I don't need all the >possibilities of GRX, with a 8 bits per pixel frame, and off-screen bitmaps >of 1 bit per pixel will be enough. > >Any help or suggestion would be very appreciate. Well, first tweak grx20.h and add #define GRX_VERSION_GCC_MPC823 -1 // Replace GCC by your compilers name, if your stuff gets included // a unique positiv number will be assigned by the GRX maintainers Now add #if defined(__GNUC__) && defined(???) // Add the right stuff here #define GRX_VERSION GRX_VERSION_GCC_MPC823 #endif Check the definition of GrColor a few lines later Now tweak src/include/libgrx.h for your system. If you checked all setting up to /* * global library data structures */ everything should be fine Now try to set up a makefile and leave out the fdrivers, vdrivers, setup and mouse subdirs. If the highlevel parts of GRX compile, try to compile the setup dir. If youŽre still lucky, continue with the ram8.c driver from the fdrivers subdir and the vdrivers/vtable.c file. If everything worked well, you now have a GRX that can do 256 Color graphics in memory. I donŽt think teherŽs currently a test that will check rhis setup. Would be nice if you could submit one ... That was the easy part. YouŽll have to add support the the vdrivers subdir so GRX knows how to setup graphics on your system. When done, add a driver in fdrivers for readpixel and drawpixel. The rest of the functionality can be taken from src/fdrivers/generic at first Try to compile the test subdir and check if things work well. Continue by adding more functions to the frame driver, adding more color modes, mouse and keyboard-support, ... Good luck, Hartmut PS: At first, second and third view, you shouldnŽt try to figure out what all those macros inside of GRX do --- ItŽs a really big mess but very flexible for optimizing GRX. readpixel/drawpixel should work fine with the usual peek and poke macros from mempeek.h

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

Grx September 1999