gnupic: Thread: Re: [gnupic] gpsim

Scott,

Same result. If I slowly widen the breadboard it crashes just after the exposure on the 18f252.
I am able to extend in the vertical. There are a couple of Linux machines at work that run Red
Hat Enterprise with older GTK's. Also have a disk with Fedora Core 6 that I havn't been using.

George

-------------- Original message -------------- 
From: "Scott Dattalo" ####@####.#### 

> On Fri, 2007-01-12 at 23:00 +0000, ####@####.#### wrote: 
> > Scott, 
> > 
> > I have 2.8.20 
> 
> Hmm. I have no idea why this would be failing for you (since gtk 2.8.20 
> works for me). However, I do think there's something bogus in the graphic 
> LCD. I just check in some code that renders the graphic LCD in its own 
> window. This behavior is now identical to the text LCD. 
> 
> I added a '#define IN_BREADBOARD 0' to the graphic LCD code. If this is 
> changed to 1 then the LCD is rendered in the breadboard window (like it 
> used to be). At the moment, it is set to 0 
> 
> George, can you try this new code and let me know how it works? 
> 
> Thanks, 
> Scott 
> 
> 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: ####@####.#### 
> For additional commands, e-mail: ####@####.#### 
> 

####@####.#### wrote:
> Scott,
>
> Same result. If I slowly widen the breadboard it crashes just after the exposure on the 18f252.
> I am able to extend in the vertical. There are a couple of Linux machines at work that run Red
> Hat Enterprise with older GTK's. Also have a disk with Fedora Core 6 that I havn't been using.
>   
George,

Do you see the LCD rendered in the breadboard or out of the breadboard. 
The change I made will cause gpsim to render the LCD outside of the 
breadboard. There will be a component in the breadboard window that 
represents the LCD, but this just shows the I/O pins and their names.

BTW, when you rebuild the LCD code, you'll have to 'make install' it 
too. Otherwise, gpsim will be picking up the old copy of the LCD module.

Scott

Scott,

I see some red arrows to the right of the 18f452 then crash. I have been doing fresh make/installs.
Does gpsim work with cygwin?
George

-------------- Original message -------------- 
From: Scott Dattalo ####@####.#### 

> ####@####.#### wrote: 
> > Scott, 
> > 
> > Same result. If I slowly widen the breadboard it crashes just after the 
> exposure on the 18f252. 
> > I am able to extend in the vertical. There are a couple of Linux machines at 
> work that run Red 
> > Hat Enterprise with older GTK's. Also have a disk with Fedora Core 6 that I 
> havn't been using. 
> > 
> George, 
> 
> Do you see the LCD rendered in the breadboard or out of the breadboard. 
> The change I made will cause gpsim to render the LCD outside of the 
> breadboard. There will be a component in the breadboard window that 
> represents the LCD, but this just shows the I/O pins and their names. 
> 
> BTW, when you rebuild the LCD code, you'll have to 'make install' it 
> too. Otherwise, gpsim will be picking up the old copy of the LCD module. 
> 
> Scott 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: ####@####.#### 
> For additional commands, e-mail: ####@####.#### 
> 

####@####.#### wrote:
> <snip>
> Does gpsim work with cygwin?
>   
Gpsim works as a native Win32 application. See
http://gpsim.sourceforge.net/gpsimWin32/gpsimWin32.html

You can download snapshot setups from:
http://gpsim.sourceforge.net/snap.php

Borut

Scott,

An update on my graphical lcd problem. I loaded gpsim and friends on a Red Hat Enterprise 4 system. No crash but the lcd display hasn't changed after 3 hours of running gpsim. Looks like
a random pattern of dots.

George

-------------- Original message -------------- 
From: "Scott Dattalo" ####@####.#### 

> On Fri, 2007-01-12 at 23:00 +0000, ####@####.#### wrote: 
> > Scott, 
> > 
> > I have 2.8.20 
> 
> Hmm. I have no idea why this would be failing for you (since gtk 2.8.20 
> works for me). However, I do think there's something bogus in the graphic 
> LCD. I just check in some code that renders the graphic LCD in its own 
> window. This behavior is now identical to the text LCD. 
> 
> I added a '#define IN_BREADBOARD 0' to the graphic LCD code. If this is 
> changed to 1 then the LCD is rendered in the breadboard window (like it 
> used to be). At the moment, it is set to 0 
> 
> George, can you try this new code and let me know how it works? 
> 
> Thanks, 
> Scott 
> 
> 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: ####@####.#### 
> For additional commands, e-mail: ####@####.#### 
> 

####@####.#### wrote:
> Scott,
>
> An update on my graphical lcd problem. I loaded gpsim and friends on a Red Hat Enterprise 4 system. No crash but the lcd display hasn't changed after 3 hours of running gpsim. Looks like
> a random pattern of dots.
>   
This is good news (better than crashing at least!) The random dots are 
what the display will show when it's first powered. If your gpsim 
configuration script is correct (which it should be if you're using the 
example), then patterns of lines and icons will get drawn. If you're not 
seeing these, try forcing the LCD to repaint itself. You can do this by 
either resizing the window or by simply hiding the LCD with another 
window and then re-exposing it.

Scott

Scott,

Updating the display shows a continuous redraw of a wedge shape being drawn. 

Also, the GUI "RUN" button appears to have no effect.

I tried Fedora Core 6 without any success.

My laptop is a Toshiba Satellite P105-S6024 with an Intel 945GM graphics chip. I
have been unable to use the prescribed driver, i810, and instead use the vesa. I am
able to execute a GTK based robot simulator.
  
George

-------------- Original message -------------- 
From: Scott Dattalo ####@####.#### 

> ####@####.#### wrote: 
> > Scott, 
> > 
> > An update on my graphical lcd problem. I loaded gpsim and friends on a Red Hat 
> Enterprise 4 system. No crash but the lcd display hasn't changed after 3 hours 
> of running gpsim. Looks like 
> > a random pattern of dots. 
> > 
> This is good news (better than crashing at least!) The random dots are 
> what the display will show when it's first powered. If your gpsim 
> configuration script is correct (which it should be if you're using the 
> example), then patterns of lines and icons will get drawn. If you're not 
> seeing these, try forcing the LCD to repaint itself. You can do this by 
> either resizing the window or by simply hiding the LCD with another 
> window and then re-exposing it. 
> 
> Scott 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: ####@####.#### 
> For additional commands, e-mail: ####@####.#### 
> 

> Scott,
>
> Updating the display shows a continuous redraw of a wedge shape being
> drawn.

That's correct! To see the icons, you'll need to set a break point toward
the bottom of glcd_test.asm. Look just after the calls to
LCD_RefreshDisplay. The  "wedge" shape is actually code to test the line
drawing algorithm. I repeatedly draw a line starting from 0,0 down to x,32
and let x run from 0 to 100. (Remember that are several things being
tested here: one is the Assembly code for doing the graphical stuff. The
other is the C++ code that implements the model of the graphical LCD. And
finally, there is the test of making sure everythings connect correctly.)

> Also, the GUI "RUN" button appears to have no effect.

Hmm. This is undoubtedly an artifact of some experimentation I'm doing
with clocking the processors externally. I'm not sure if you've followed
some of the recent gpsim threads, but I'm working on a new clocking
mechanism. The code thus far passes all regression tests, so I left the
experimental code turned on. If it's important to turn it off, then you
can comment out the line '#define CLOCK_EXPERIMENTS' in src/clock_phase.h.
BTW you can use hot keys to initiate a run.

With the focus on the source browser, pressing 'r' will initiate run.
Similary, 's' will single step. The numbers 1 through 9 will step 1 to 9
times. Also, <ESC> will halt a running simulation.


> I tried Fedora Core 6 without any success.

I'm not sure what you mean by no success. I think it's working now, it's
just a matter of interpreting the results.

Scott

I am having success on a Red HaT Enterprise system, not my laptop with Fedora Core 5/6.
I tried the "step" with a number and it seems to perform one instruction.

George

-------------- Original message -------------- 
From: "Scott Dattalo" ####@####.#### 

> > Scott, 
> > 
> > Updating the display shows a continuous redraw of a wedge shape being 
> > drawn. 
> 
> That's correct! To see the icons, you'll need to set a break point toward 
> the bottom of glcd_test.asm. Look just after the calls to 
> LCD_RefreshDisplay. The "wedge" shape is actually code to test the line 
> drawing algorithm. I repeatedly draw a line starting from 0,0 down to x,32 
> and let x run from 0 to 100. (Remember that are several things being 
> tested here: one is the Assembly code for doing the graphical stuff. The 
> other is the C++ code that implements the model of the graphical LCD. And 
> finally, there is the test of making sure everythings connect correctly.) 
> 
> > Also, the GUI "RUN" button appears to have no effect. 
> 
> Hmm. This is undoubtedly an artifact of some experimentation I'm doing 
> with clocking the processors externally. I'm not sure if you've followed 
> some of the recent gpsim threads, but I'm working on a new clocking 
> mechanism. The code thus far passes all regression tests, so I left the 
> experimental code turned on. If it's important to turn it off, then you 
> can comment out the line '#define CLOCK_EXPERIMENTS' in src/clock_phase.h. 
> BTW you can use hot keys to initiate a run. 
> 
> With the focus on the source browser, pressing 'r' will initiate run. 
> Similary, 's' will single step. The numbers 1 through 9 will step 1 to 9 
> times. Also, will halt a running simulation. 
> 
> 
> > I tried Fedora Core 6 without any success. 
> 
> I'm not sure what you mean by no success. I think it's working now, it's 
> just a matter of interpreting the results. 
> 
> Scott 
> 
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: ####@####.#### 
> For additional commands, e-mail: ####@####.#### 
>