RE: [Rcxemul-discussion] Update - 12th Oct 2002

[David E. <d.a...@du...>]

The best way for me to debug is to run through to the portion of code
(the RCX code) that is not being executed properly (or not as I would
expect). I then step through an instruction at a time, using Kekoa
Proudfoot's ROM description as a guide. I can check to make sure all
variables, etc. are being set as they should be. If not, it can be
narrowed down to an opcode implementation. If I'm doing something wrong
in my implementation of the emulator, it should also be fairly obvious
that the fault is there.

It may also be that something else is required in order to make this
part work (something that hasn't been implemented yet, like 8-bit
timers).

Hopefully that made sense... :)

> -----Original Message-----
> From: rcx...@li... 
> [mailto:rcx...@li...] On 
> Behalf Of Andy Gombos
> Sent: 13 October 2002 01:12
> To: rcx...@li...
> Subject: Re: [Rcxemul-discussion] Update - 12th Oct 2002
> 
> 
> You can't run the emulator portion (the part that recieves 
> messages), then attach a debugger to it so you can see what 
> is going on?  In my JNI tests (not exactly the same thing, 
> but the only difference is a socket connection instead of a 
> JVM controlled connection), I start the Java app with 
> Eclipse, with a breakpoint set before the important native 
> code occurs (but after the library is loaded/connected to), 
> then open Visual Studio.NET, attach the debugger to my 
> running (but stopped at the breakpoint) Java app, and I can 
> step back and forth between C++ and Java through their 
> respective debugger windows.
> 
> In your instance (since it sounds like 2 C apps), attach a 
> debugger to each end, and watch control flow around.
> 
> 
> ----- Original Message -----
> From: "David Edwards" <d.a...@du...>
> To: <rcx...@li...>
> Sent: Saturday, October 12, 2002 5:21 PM
> Subject: [Rcxemul-discussion] Update - 12th Oct 2002
> 
> 
> > Hi all.
> >
> > I'm still plodding along! I've implemented much of the serial 
> > communications, which wasn't too easy. I had to learn a lot about 
> > sockets in Unix, so it took a while.
> >
> > The system now uses a communications protocol to accept 
> commands from 
> > outside the system. I've only implemented one or two 
> messages - enough 
> > to get things running. So far I can send a message to put a 
> byte into 
> > the serial receive register, a message to set the state of 
> a port, and 
> > one to write byte data to a supplied memory location. However, it 
> > means that stepping through the code instruction by 
> instruction isn't 
> > really possible now. I poll for incoming messages every 250 
> > instructions, and time out after a short (10ms) period. 
> This doesn't 
> > seem to slow the system down too much.
> >
> > So I now need a method of debugging, so I'm attempting to build a 
> > breakpoint system. Breakpoints will be handled using the 
> > communications protocol. I'm working this way so that an external 
> > interface can be written (I'm going to use Java) to act as 
> a debugging 
> > environment.
> >
> > I've hacked the firmware download code (rcx_comm.c and rcx_comm.h) 
> > from lejos to allow a whole message to be sent to the 
> emulator. When 
> > each byte is sent the appropriate interrupt is dispatched, but from 
> > there it's difficult to work out what is happening (because I can't 
> > step through yet). In theory, a transmit interrupt should be 
> > dispatched but it isn't being. I'll know more about why when I can 
> > step through.
> >
> > That's about it for now... You've been a great audience! Dave.
> >
> > PS I'm thinking about using a WikiWeb for the RCXEmul 
> website. Anyone 
> > have any experience setting one of these up?
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Rcxemul-discussion mailing list 
> > Rcx...@li...
> > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Rcxemul-discussion mailing list 
> Rcx...@li...
> https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
>