gnupic: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(


Previous by date: 20 Sep 2000 11:51:10 -0000 Re: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(, Scott Dattalo
Next by date: 20 Sep 2000 11:51:10 -0000 Re: Future of SIL?, Francisco Rodrigo Escobedo Robles
Previous in thread: 20 Sep 2000 11:51:10 -0000 Re: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(, Scott Dattalo
Next in thread:

Subject: Re: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(
From: Wojtek Zabolotny ####@####.####
Date: 20 Sep 2000 11:51:10 -0000
Message-Id: <20000920134418.A1104@wzab.nasz.dom>

On Tue, Sep 19, 2000 at 09:11:05PM -0500, Scott Dattalo wrote:
> As you can see, my version did not change portc to 0x20. Hmm. What inlude file
> are you using?
>

I downloaded the gpsim-0.20.4.tar.gz, length 436885
the md5sum is: 567fa74ab68a10e0d297ab2cf59cbf02
(I get it through the link at www.gnupic.org/simulators)

I had to do some "cosmetic" changes to get it compile in Debian/Linux:

1) change #include <eXdbm/eXdbm.h>
   into #include <eXdbm.h>    
   everywhere
2) change the detection of eXdbm in configure.in
-  AC_CHECK_HEADER(eXdbm/eXdbm.h,,[
+  AC_CHECK_HEADER(eXdbm.h,,[ 
-  AC_CHECK_LIB(eXdbm,eXdbmInit,,[
+  AC_CHECK_LIB(eXdbm,main,,[                                                    
3) explicitly add the linking of readline library in /gpsim/Makefile.am
-gpsim_LDADD = ../src/libgpsim.la ../cli/libgpsimcli.la ../gui/libgui.la @GTK@ @GDK@ @GLIB@ -lstdc++ @X_LDFLAGS@ @Y_LDFLAGS@ @LIBREADLINE@
+gpsim_LDADD = ../src/libgpsim.la ../cli/libgpsimcli.la ../gui/libgui.la @GTK@ @GDK@ @GLIB@ -lstdc++ @X_LDFLAGS@ @Y_LDFLAGS@ -lreadline                        

then just ran the "deb-make", and "fakeroot dpkg-buildpackage"

I use : gtk+extra_0.99.10-2
	 exdbm_1.0b2-2
	(sources downloaded from "woody" and recompiled in "potato")

All the changes have nothing to do with the "core" gpsim functions...
Is it possible, that the gpsim-0.20.4.tar.gz, I've downloaded, is not the
right one?

> Note that this program has floating inputs. Unlike a real pic device which would
> oscillate itself to death, gpsim floating inputs will read as zeroes. So if you
> change the tris register to make an I/O an input, this line will float low. Just
> so this is clear, let's look at the code:
> 

I know that the 6 and 7 bits of PORTC are floating, but it can cause just
the following results of BSF PORTC,5 , when initial value is 0x3f:
0x3f, 0x7f, 0xbf 0xff. However the value read from PORTC is 0x3f, so the
floating pins are assumed to be zeroes...
It does not explain the phenomenon of zeroing of bits 0..4 ...

I'm interested if I'm the only one who experience this problem?
Are there any other Debian/Linux "potato" users on i>=386 platforms, who 
use gpsim and do not observe that problem?
-- 
			Greetings
			Wojciech Zabolotny
			http://www.ise.pw.edu.pl/~wzab

http://www.freedos.org  Free DOS for free people!

Previous by date: 20 Sep 2000 11:51:10 -0000 Re: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(, Scott Dattalo
Next by date: 20 Sep 2000 11:51:10 -0000 Re: Future of SIL?, Francisco Rodrigo Escobedo Robles
Previous in thread: 20 Sep 2000 11:51:10 -0000 Re: Bug in simulation of BSF for in/out ports still present in 0.20.4 :-(, Scott Dattalo
Next in thread:


Powered by ezmlm-browse 0.20.