gnupic: Thread: gpsim CVS Source Forge problems

Mainly for Ralf...

I've got a bunch of things ready to check in to CVS, but I'm getting time out
errors... Ralf - Have you done any CVS updates lately? If not could you try one?


Changes for CVS:
1) Fixed the rest of those false parse errors
2) Re-wrote the way cli passes stimulus information to the simulator. Before,
the cli would collect all of the information about a stimulus before passing it
to the simulator. Now, as each piece of information is parsed, it's immediately
sent to the simulator. There was no reason to keep an intermediate copy...
3) TMR1 now updates. It turned out that the TMR1 was working correctly, but
would only update its value when it rolled over. And when it rolls over it's
zero. So TMR1 was just staying zero all of the time...

Also for Ralf - 
I'm getting an occasional core dump in gui_regwin.c . In activate_sheet_cell(),
this line:

  regnumber = rw->row_to_address[row]+column;

is producing a value of 0xffffff for regnumber when the row and column are
zero. I think what's happening, (but I don't see exactly how) is that the
activate_sheet_cell callback is invoked before row_to_address has been
initialized with the proper data. To fix the problem, I return if regnumber is
too large. I'm not sure if the core dump is specifically related to what I
observed or not...

Scott

On Mon, 19 Jun 2000, you wrote:
>Mainly for Ralf...
>
>I've got a bunch of things ready to check in to CVS, but I'm getting time out
>errors... Ralf - Have you done any CVS updates lately? If not could you try one?

It works for me, have you checked that the CVS_RSH variable is set?

>Also for Ralf - 
>I'm getting an occasional core dump in gui_regwin.c . In activate_sheet_cell(),
>this line:
>
>  regnumber = rw->row_to_address[row]+column;
>
>is producing a value of 0xffffff for regnumber when the row and column are
>zero. I think what's happening, (but I don't see exactly how) is that the
>activate_sheet_cell callback is invoked before row_to_address has been
>initialized with the proper data. To fix the problem, I return if regnumber is
>too large. I'm not sure if the core dump is specifically related to what I
>observed or not...

I'll see what I can find. I think some of this code is changed in
cvs, but probably not this thing. 

 / Ralf

On Mon, 19 Jun 2000, Ralf Forsberg wrote:

> On Mon, 19 Jun 2000, you wrote:
> >Mainly for Ralf...
> >
> >I've got a bunch of things ready to check in to CVS, but I'm getting time out
> >errors... Ralf - Have you done any CVS updates lately? If not could you try one?
> 
> It works for me, have you checked that the CVS_RSH variable is set?

Ah damn - bone head mistake on my part. 

CVS has been updated

------

I broke something in the gui. I can't even bring up the register window for a
16c71. When I bring one up for a 16c84, I get this:

Gtk-WARNING **: gtk_signal_disconnect_by_func(): could not find handler
(0x402A3624) containing data (0x816B360)

Do you have any idea what's going on here? 

To demonstrate this, start gpsim with no arguements and then instantiate a
p16c71 and try to open the register window.

I poked around just a little, and noticed that the register window will draw the
first row of registers before a processor is even selected. The 'row_to_address'
array has bad data (for mapping) in it at this point. I'm not sure if this is
problem... 

BTW,There have been a whole lot of changes in the now-gui portion of gpsim. It
could be that I broke something there that's causing havoc in the gui.

Scott

On Mon, 19 Jun 2000, you wrote:
>
>I broke something in the gui. I can't even bring up the register window for a
>16c71. When I bring one up for a 16c84, I get this:
>
>Gtk-WARNING **: gtk_signal_disconnect_by_func(): could not find handler
>(0x402A3624) containing data (0x816B360)
>
>Do you have any idea what's going on here? 

I don't get the warning with the p16c84.

gpsim_get_register_memory_size() seems to return 0 in
RegWindow_new_processor(). for the p16c71, which makes it break. 

(btw scott, did you get a mail from me on the 17:th?. It may not have
made it through)

 / Ralf

On Mon, 19 Jun 2000, Ralf Forsberg wrote:


> gpsim_get_register_memory_size() seems to return 0 in
> RegWindow_new_processor(). for the p16c71, which makes it break. 

Fixed and in CVS.

Scott