Mail Archives: djgpp/2000/04/13/15:29:43
Eli Zaretskii wrote:
> On Wed, 12 Apr 2000, Andrew Hakman wrote:
>
> > I think the problem I was having must be with the emulation library.
>
> Are you sure your libemu.a is from DJGPP v2.03? If not, please
> upgrade.
Yes, the zip file is DJDEV203.zip right? Just downloaded it a couple weeks ago.
>
>
> > When I don't include it (do a normal compile without linking in the
> > library) and run and external 387 emulator, it works.
>
> I'm not sure I understand what exactly do you mean by ``external 387
> emulator''. Is it emu387.dxe supplied with DJGPP?
This is a seperate .EXE that you start from you autoexec.bat before anything else
loads
>
>
> > Now I just need to
> > find the full version of a 387 emulator so I don't have to press keys on
> > all the slave computers everytime I boot them up.
>
> What do you mean by ``full version'' of an emulator?
This is a shareware version, so it nags you every time it starts, (you have to
press a key twice to get rid of the message and continue booting), and then it
only runs for 20 minutes.
>
>
> DJGPP comes with emu387.dxe which is automatically loaded by an
> application if the FPU processor is unavailable. Alternatively, you
> could install WMEMU (get v2misc/wmemu21b.zip from SimTel.NET), which
> is a better emulator, but it is distributed under the GNU GPL
> license.
So if I just throw emu387.dxe in the same directory as the .EXE, will it
automatically pick it up, or is there a few lines that need to be added to the
code. If I recall correctly, there is mention of this in the FAQ, and I will go
and look at it right away.
>
>
> > Right now I have q87
> > (incase anybody knows where I can get, or has the full version).
>
> The only pointer to q87 known to me is http://www.weblane.com/quickware.
> I have no experience with that emulator.
Yeah, that's the only address I could find for the company as well (I thought
maybee they would give me a full version since it is old, hardly anybody uses
386's anymore, and it is for a school project), but it doesn't exist anymore. I
originaly found it on some university's "Operating System Tools" page.
>
>
> > The lines of code that were actually causing the page fault (I tracked
> > them down with LOTS of COUTs) were:
> >
> > packet_buffer.packets[packet_buffer.buffer_pos].data1=recieve_packet.data1;
> >
> >
> > packet_buffer.packets[packet_buffer.buffer_pos].data2=recieve_packet.data2;
> >
> >
> > packet_buffer.packets[packet_buffer.buffer_pos].data3=recieve_packet.data3;
> >
> > I don't see anything wrong with these, and neither does a 486 or q87.
>
> Are you sure all the variables in these lines have valid addresses?
How could I go about testing/finding these addresses? That very well could be the
problem, but in that case, wouldn't it page fault all of the time since it is
accessing out of range memory?
Andrew
- Raw text -