rcxemul-discussion — RCX Emulation discussion list

Re: [Rcxemul-discussion] simulator

[Jochen H. <Hoe...@In...>]

Hello Stef,

> hi Jochen,
> 
> it's a pitty that I'm a windows user and can not see what you've produced.
> I'm very interested, so let me know when you've some screenshots on a 
> website !

There's a small hello world screenshot on the webpage now.  It doesn't
look very impressive, but if you consider that a standard brickOS
kernel and helloworld.lx were uploaded to the device via the simulated
infrared communication there is a lot going on behind the scenes.

> I've build a "logical" simulator that has the RCX with standard firmware 
> as a device. Users can add any device to the simulator by building a DLL 
> in any language they like. I'm programming for windows, otherwise we 
> maybe could merge,( I only support standard firmware)

I think it shouldn't be too hard to port to windows.  It uses sockets
to communicate with firmdl, the tcl/tk GUI, and the debugger.  And it
uses one select call to check for input and sleep.  Everything else
should work without modifications under windows.

I wonder whether the concepts match.  To simulate in real time I count
the cycles and each peripheral can request to be woken up after a
specified amount of cycles.  If I understand the description of SAL it
gives every device for each cycle the chance to do some calculations.

  Jochen

-- 
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

[Rcxemul-discussion] simulator

[Stef <s.m...@ma...>]

hi Jochen,

it's a pitty that I'm a windows user and can not see what you've produced.
I'm very interested, so let me know when you've some screenshots on a 
website !

I've build a "logical" simulator that has the RCX with standard firmware 
as a device. Users can add any device to the simulator by building a DLL 
in any language they like. I'm programming for windows, otherwise we 
maybe could merge,( I only support standard firmware)
The simulator is just released a couple of weeks ago in the 
JAL-community. This week it will be released in XCSB and PIC communities.
I haven't released it yet in the RCX-community, because I'm waiting for 
the developer of Bricxcc to implement a few changes, so the simulator 
can be directly controlled from Bricxcc.

here are some links

mainpage of the simulator
   http://oase.uci.kun.nl/~mientki/PIC/JALss/JALss.htm

RCX device description
   http://oase.uci.kun.nl/~mientki/PIC/JALss/JALss_RCX_devices.htm

RCX demo descriptions
   http://oase.uci.kun.nl/~mientki/PIC/JALss/JALss_RCX_demo.htm

All the above links can change, so for the future use only my main PIC 
page and look for JALss
   http://pic.flappie.nl

Hoping to see some of your work,
best regards,
Stef Mientki

[Rcxemul-discussion] My own RCX Emulator

[Jochen H. <Hoe...@In...>]

Hello rcxemul developers,

Recently I thought, it would be nice to have an RCX emulator similar
to the Palm OS Emulator.  Unfortunately I made the mistake of not
searching the web if something like that exists, but started
programming immediately.  Well it was an interesting experience
anyway.

So now after a bit more than a week I have my own running Lego RCX
emulator that can already firmdl and run brickOS.  It needs linux, a
binary image of the ROM named rom.bin (use objdump to convert srec to
binary), and a special version of firmdl to load brickOS (I included
the modified rcxtty.c source).  It is mostly undocumented and still a
bit buggy.  Feel free to ask questions.

I'm not sure whether merging is an option, but maybe we can learn from
each other.  I have put a copy at the following URL with my current
sources and waiting for your feedback.

http://csd.informatik.uni-oldenburg.de/~hoenicke/rcx/

  Jochen

-- 
Jochen Hoenicke, University of Oldenburg, 26111 Oldenburg, Germany
Email: hoe...@in...  Tel: +49 441 798 3124

RE: [Rcxemul-discussion] Strange things afoot

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

Finally figured it out!

A bug in my bit operation instructions meant that instead of changing a
bit in the byte at a specified memory address, it would read a word from
this memory address and use that word as the address of the byte to
alter. It just so happened that at that moment, 0xA00A was in the word
at that memory address, so it cleared a bit in the byte at 0xA00A. Hence
0x1D became 0x15. The offending instruction was in a periodic update of
the LCD.

My next job is to work out if the firmware is being executed. If it is,
I'll need to have a look at the lejos code to work out what should
happen after it has been downloaded.

RE: [Rcxemul-discussion] Strange things afoot

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

The byte in question does get set to 0x1D as it should. But at some
point between then and the end of the download it is being set to 0x15.
I'm attempting to narrow it down by outputting the value of the program
counter whenever that value is changed. I should at least be able to see
what function it is being altered in.

> The error is repeatable. I tried again and exactly the same 
> byte was written incorrectly as 0x15. When the emulator 
> receives a packet, for debugging purposes I output the data 
> in the packet, and it does indeed read 0x1D for that 
> particular message.
> 
> I'm attempting to get a dump of the instructions that are 
> executed for that byte to see if anything odd is happening 
> there. Specifically, I want to look at whether it's 
> attempting to write 0x1D or 0x15 to memory.
> 
> > 0x1D may be written to the socket, but are you sure that is
> > what is coming out of the other end of the pipe?  Let's say 
> > you slightly corrupt your memory (I haven't looked at the 
> > code, so I don't know how you allocate memory and control 
> > it), and this corruption is apparent only on this byte, 
> > producing (since the program/rom is running through the same 
> > sequence each
> > time) a reproducable error in the socket memory buffer only 
> > on this byte.
> > 
> > Assuming the socket recieve buffer is not corrupted, the
> > firmware buffer the final byte is added to may be.  Again, I 
> > haven't looked at the code or been able to get the firmware 
> > to download, so you may be printing out all recieved bytes.
> > 
> > This is why I hate straight C.
> > 
> > ----- Original Message -----
> > From: "David Edwards" <d.a...@du...>
> > To: <rcx...@li...>
> > Sent: Friday, October 18, 2002 7:22 PM
> > Subject: [Rcxemul-discussion] Strange things afoot
> > 
> > 
> > > I'm hot on the trail of the reason why the firmware won't
> > unlock. I've
> > > discovered that the last time I tried it, there was only
> > one byte in
> > > the entire firmware transferred wrongly. This put the
> > checksum off by
> > > 8:
> > >
> > > Expected
> > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A
> > >
> > > Observed
> > > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A
> > >
> > > Note that we have 1D in the expected firmware image, and 15 in the
> > > observed. I have no idea why! I've traced through the 
> tons of debug 
> > > information that I have and I'm still at a loss. 0x1D is 
> definitely 
> > > the value that gets transmitted by the firmware downloader, 
> > but 0x15
> > > is being written.
> > >
> > > I'm going to try again to see if it's the same byte that
> > gets written
> > > wrongly. If it is, I'm going to have to trace the receive
> > handler for
> > > that particular byte to see why it's not getting set correctly.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > Access Your PC Securely with GoToMyPC. Try Free Now
> > > https://www.gotomypc.com/s/OSND/DD
> > > _______________________________________________
> > > Rcxemul-discussion mailing list 
> > > Rcx...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> Rcxemul-discussion mailing list 
> Rcx...@li...
> https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now 
https://www.gotomypc.com/s/OSND/DD
_______________________________________________
Rcxemul-discussion mailing list Rcx...@li...
https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion

RE: [Rcxemul-discussion] Strange things afoot

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

The error is repeatable. I tried again and exactly the same byte was
written incorrectly as 0x15. When the emulator receives a packet, for
debugging purposes I output the data in the packet, and it does indeed
read 0x1D for that particular message.

I'm attempting to get a dump of the instructions that are executed for
that byte to see if anything odd is happening there. Specifically, I
want to look at whether it's attempting to write 0x1D or 0x15 to memory.

> 0x1D may be written to the socket, but are you sure that is 
> what is coming out of the other end of the pipe?  Let's say 
> you slightly corrupt your memory (I haven't looked at the 
> code, so I don't know how you allocate memory and control 
> it), and this corruption is apparent only on this byte, 
> producing (since the program/rom is running through the same 
> sequence each
> time) a reproducable error in the socket memory buffer only 
> on this byte.
> 
> Assuming the socket recieve buffer is not corrupted, the 
> firmware buffer the final byte is added to may be.  Again, I 
> haven't looked at the code or been able to get the firmware 
> to download, so you may be printing out all recieved bytes.
> 
> This is why I hate straight C.
> 
> ----- Original Message -----
> From: "David Edwards" <d.a...@du...>
> To: <rcx...@li...>
> Sent: Friday, October 18, 2002 7:22 PM
> Subject: [Rcxemul-discussion] Strange things afoot
> 
> 
> > I'm hot on the trail of the reason why the firmware won't 
> unlock. I've 
> > discovered that the last time I tried it, there was only 
> one byte in 
> > the entire firmware transferred wrongly. This put the 
> checksum off by 
> > 8:
> >
> > Expected
> > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A
> >
> > Observed
> > 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A
> >
> > Note that we have 1D in the expected firmware image, and 15 in the 
> > observed. I have no idea why! I've traced through the tons of debug 
> > information that I have and I'm still at a loss. 0x1D is definitely 
> > the value that gets transmitted by the firmware downloader, 
> but 0x15 
> > is being written.
> >
> > I'm going to try again to see if it's the same byte that 
> gets written 
> > wrongly. If it is, I'm going to have to trace the receive 
> handler for 
> > that particular byte to see why it's not getting set correctly.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > Access Your PC Securely with GoToMyPC. Try Free Now 
> > https://www.gotomypc.com/s/OSND/DD
> > _______________________________________________
> > Rcxemul-discussion mailing list 
> > Rcx...@li...
> > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now 
https://www.gotomypc.com/s/OSND/DD
_______________________________________________
Rcxemul-discussion mailing list Rcx...@li...
https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion

Re: [Rcxemul-discussion] Strange things afoot

[Andy G. <gom...@ea...>]

0x1D may be written to the socket, but are you sure that is what is coming
out of the other end of the pipe?  Let's say you slightly corrupt your
memory (I haven't looked at the code, so I don't know how you allocate
memory and control it), and this corruption is apparent only on this byte,
producing (since the program/rom is running through the same sequence each
time) a reproducable error in the socket memory buffer only on this byte.

Assuming the socket recieve buffer is not corrupted, the firmware buffer the
final byte is added to may be.  Again, I haven't looked at the code or been
able to get the firmware to download, so you may be printing out all
recieved bytes.

This is why I hate straight C.

----- Original Message -----
From: "David Edwards" <d.a...@du...>
To: <rcx...@li...>
Sent: Friday, October 18, 2002 7:22 PM
Subject: [Rcxemul-discussion] Strange things afoot


> I'm hot on the trail of the reason why the firmware won't unlock. I've
> discovered that the last time I tried it, there was only one byte in the
> entire firmware transferred wrongly. This put the checksum off by 8:
>
> Expected
> 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A
>
> Observed
> 0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A
>
> Note that we have 1D in the expected firmware image, and 15 in the
> observed. I have no idea why! I've traced through the tons of debug
> information that I have and I'm still at a loss. 0x1D is definitely the
> value that gets transmitted by the firmware downloader, but 0x15 is
> being written.
>
> I'm going to try again to see if it's the same byte that gets written
> wrongly. If it is, I'm going to have to trace the receive handler for
> that particular byte to see why it's not getting set correctly.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> Access Your PC Securely with GoToMyPC. Try Free Now
> https://www.gotomypc.com/s/OSND/DD
> _______________________________________________
> Rcxemul-discussion mailing list
> Rcx...@li...
> https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion

[Rcxemul-discussion] Strange things afoot

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

I'm hot on the trail of the reason why the firmware won't unlock. I've
discovered that the last time I tried it, there was only one byte in the
entire firmware transferred wrongly. This put the checksum off by 8:

Expected
0xA000 77 79 1E 11 1E 88 1E 00 0D 42 1D 20 47 1E 6E 6A 

Observed
0xA000 77 79 1E 11 1E 88 1E 00 0D 42 15 20 47 1E 6E 6A 

Note that we have 1D in the expected firmware image, and 15 in the
observed. I have no idea why! I've traced through the tons of debug
information that I have and I'm still at a loss. 0x1D is definitely the
value that gets transmitted by the firmware downloader, but 0x15 is
being written.

I'm going to try again to see if it's the same byte that gets written
wrongly. If it is, I'm going to have to trace the receive handler for
that particular byte to see why it's not getting set correctly.

RE: [Rcxemul-discussion] Update on serial comms

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

Another quick update on serial comms.

I did a quick hack that allowed me to turn verbose debug information on
while the emulator was running, and dumped the final few instructions
after the firmware download to a file.

The message that the download program sends to unlock the firmware is
accepted, and the unlock firmware opcode is executed. It detects the
string that identifies the firmware as valid. However, the checksum
calculated during the unlocking process differs from the one calculated
during download. It expects to see 0xCA4A but actually sees 0xCA3E. I
don't know which of these is valid. It will probably require a bit of
experimentation.

RE: [Rcxemul-discussion] Debugger

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

Hi.

The debugger wouldn't be for debugging programs (perhaps would be useful
when writing firmware). It's really to ensure the emulator is doing what
it should do. At the moment it's virtually impossible to do this without
generating hundreds of megabytes of text output (I currently output
every instruction as it is executed, with a bit of information about it
(such as register contents, memory contents, etc.)). That's all well and
good, but I have to check instructions after firmware has been
downloaded (takes 5 minutes or so).

The other alternative is to use the breakpoint functionality that is in
there, and do a hack which means that instructions are only output after
the breakpoint is reached. 

At the moment, I'm trying to figure out why the emulator isn't
responding to the 'unlock firmware' opcode, and it's proving extremely
difficult, hence the idea of a debugger....

> Debugging in a mixed code environment is going to be hard,
> since you can't use the JDI and related technologies on C 
> code.  Just attach a debugger (gdb most likely) to the 
> process.  Doing a Java version would require lots of 
> communications code, reporting about the next instruction to 
> be executed by the virtual processor, and then the Java app 
> sending a respose whether or not to execute that instruction.
> 
> ----- Original Message -----
> From: "David Edwards" <d.a...@nt...>
> To: <rcx...@li...>
> Sent: Thursday, October 17, 2002 9:49 AM
> Subject: [Rcxemul-discussion] Debugger
> 
> 
> > Hi.
> >
> > Is anyone interested in helping create a debugger (in Java) to
> > accompany
> my emulator? I'm getting to the point where I need to break
> into certain functions to see what's happening (specifically 
> to try to work out why no response is being generated when 
> unlock firmware is called).
> >
> > I plan on making "debug" a compilation option of the
> emulator to avoid
> unnecessary overhead.
> >
> > Any takers?
> >
> > Dave.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: viaVerio will pay you up
> to $1,000
> > for every account that you consolidate with us.
> > http://ad.doubleclick.net/clk;4749864;7604308;v?
> > http://www.viaverio.com/consolidator/osdn.cfm
> > _______________________________________________
> > Rcxemul-discussion mailing list 
> > Rcx...@li...
> > https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion
> 

Re: [Rcxemul-discussion] Debugger

[Andy G. <gom...@ea...>]

Doh!  I keep hitting reply and sending all the messages straight to David.
Here is my reply:

Debugging in a mixed code environment is going to be hard, since you can't
use the JDI and related technologies on C code.  Just attach a debugger (gdb
most likely) to the process.  Doing a Java version would require lots of
communications code, reporting about the next instruction to be executed by
the virtual processor, and then the Java app sending a respose whether or
not to execute that instruction.

----- Original Message -----
From: "David Edwards" <d.a...@nt...>
To: <rcx...@li...>
Sent: Thursday, October 17, 2002 9:49 AM
Subject: [Rcxemul-discussion] Debugger


> Hi.
>
> Is anyone interested in helping create a debugger (in Java) to accompany
my emulator? I'm getting to the point where I need to break into certain
functions to see what's happening (specifically to try to work out why no
response is being generated when unlock firmware is called).
>
> I plan on making "debug" a compilation option of the emulator to avoid
unnecessary overhead.
>
> Any takers?
>
> Dave.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Rcxemul-discussion mailing list
> Rcx...@li...
> https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion

[Rcxemul-discussion] Debugger

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

Hi.

Is anyone interested in helping create a debugger (in Java) to accompany my emulator? I'm getting to the point where I need to break into certain functions to see what's happening (specifically to try to work out why no response is being generated when unlock firmware is called).

I plan on making "debug" a compilation option of the emulator to avoid unnecessary overhead.

Any takers?

Dave.

RE: [Rcxemul-discussion] Update on serial comms

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

Quick update: the firmware appears to have downloaded! I did a memory
dump before running lejosfirmdl and the memory from 0x8000 to 0xCC00 is
filled with 0xFF. After the firmware download, it is filled with what
appears to be the binary image (the "Do you byte, when I knock?" string
is there). I am going to try to find some way to diff my image with the
lejos binary image.

Unfortunately, the firmware still won't unlock. The emulator isn't
responding to the unlock request for some reason. I'll look into it.

> -----Original Message-----
> From: rcx...@li... 
> [mailto:rcx...@li...] On 
> Behalf Of David Edwards
> Sent: 16 October 2002 01:34
> To: rcx...@li...
> Subject: [Rcxemul-discussion] Update on serial comms
> 
> 
> I've managed to get serial comms working (albeit very 
> flakily). The emulator will receive messages and seems to 
> deal with most of them appropriately. I have hacked the lejos 
> firmware downloader so that it will communicate with the 
> emulator, and so far the emulator has successfully replied to 
> a request to see if it's alive, and has worked its way (very 
> slowly) through the download of the firmware image.
> 
> I haven't verified that the firmware has been successfully 
> downloaded - I need a better debugging framework to do this. 
> The download fails when it attempts to unlock the firmware. 
> No reply is received from the emulator. Again, I need a 
> better way of debugging to find out why.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up 
> to $1,000 for every account that you consolidate with us. 
> http://ad.doubleclick.net/clk;4749864;7604308;> v?
> 
http://www.viaverio.com/consolidator/osdn.cfm

_______________________________________________
Rcxemul-discussion mailing list Rcx...@li...
https://lists.sourceforge.net/lists/listinfo/rcxemul-discussion

[Rcxemul-discussion] Update on serial comms

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

I've managed to get serial comms working (albeit very flakily). The
emulator will receive messages and seems to deal with most of them
appropriately. I have hacked the lejos firmware downloader so that it
will communicate with the emulator, and so far the emulator has
successfully replied to a request to see if it's alive, and has worked
its way (very slowly) through the download of the firmware image.

I haven't verified that the firmware has been successfully downloaded -
I need a better debugging framework to do this. The download fails when
it attempts to unlock the firmware. No reply is received from the
emulator. Again, I need a better way of debugging to find out why.

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

[Andy G. <gom...@ea...>]

Oh, then I think I misunderstood the problem.  I thought you couldn't debug
the emulator portion while using breakpoints on the RCX code portion, but it
seems you handled that just fine.  *sigh* I'll do anything to get away from
writing this AP Biology lab report due Monday.  Programming is so much more
enjoyable, especially when I am almost done with a project.

----- Original Message -----
From: "David Edwards" <d.a...@du...>
To: <rcx...@li...>
Sent: Saturday, October 12, 2002 8:41 PM
Subject: RE: [Rcxemul-discussion] Update - 12th Oct 2002


> 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
> >
>
>
>
> -------------------------------------------------------
> 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

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
> 

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

[Andy G. <gom...@ea...>]

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

[Rcxemul-discussion] Update - 12th Oct 2002

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

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?

RE: [Rcxemul-discussion] Progress

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

I've pursued the matter of the virtual IR tower further and it's not as
easy as it appears. The problem is that (in the Unix version, for
example) isatty() is called to verify that data can be sent to the
device. It seems that serial/USB behaviour is not formally specified so
each OS does it differently.

So for now it looks like I'm going to have to hack around with the
download code. I can create a generic firmware downloader fairly easily,
but it becomes more difficult with the actual program download. As far
as I'm aware each RCX firmware handles this in its own way, so I'd need
to come up with code for each one.

I'm still hoping inspiration strikes and I figure out a way of doing it
like I originally intended.

> Well, there hasn't been too much in the last few weeks. I'm 
> officially on vacation, so I'm attempting to spend time on 
> boring things like relaxation. ;)
> 
> However, I've got network comms sorted with the emulator. It 
> will listen on port 6561 (for now) and when it receives a 
> datagram packet, it will print it to the screen (along with 
> the IP address of the originator). It only checks every 250 
> iterations (I'm planning on working out a better value for 
> this - I've tested with 2500 and the messages still get
> through) and uses the Unix select() function, so only blocks 
> for a given time (10ms in my case - it's about as low as it 
> goes). Hopefully it won't create too much of a performance hit.
> 
> The next thing to do is to create a virtual IR tower to act 
> as a relay between the firmware download application. I would 
> like to do this without modifying the download code in any 
> way... This way I can assure that any firmware can be downloaded.
> 
> However, I have no clue how to do this in C! I'm working with 
> the cygwin environment, so Unix rules apply. If anyone knows 
> how I can do this, I would appreciate any help I can get!
> 
> That's about it for now, apart from a consistent crash I'm 
> getting when stepping through code. I'm working on fixing 
> that, but for the moment I've disabled this feature. I also 
> need to change the interrupt routines so that only the high 
> priority interrupts are accepted when in sleep mode.
> 
> Dave.
> 
> 
> 
> -------------------------------------------------------
> 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
> 

[Rcxemul-discussion] Progress

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

Well, there hasn't been too much in the last few weeks. I'm officially
on vacation, so I'm attempting to spend time on boring things like
relaxation. ;)

However, I've got network comms sorted with the emulator. It will listen
on port 6561 (for now) and when it receives a datagram packet, it will
print it to the screen (along with the IP address of the originator). It
only checks every 250 iterations (I'm planning on working out a better
value for this - I've tested with 2500 and the messages still get
through) and uses the Unix select() function, so only blocks for a given
time (10ms in my case - it's about as low as it goes). Hopefully it
won't create too much of a performance hit.

The next thing to do is to create a virtual IR tower to act as a relay
between the firmware download application. I would like to do this
without modifying the download code in any way... This way I can assure
that any firmware can be downloaded.

However, I have no clue how to do this in C! I'm working with the cygwin
environment, so Unix rules apply. If anyone knows how I can do this, I
would appreciate any help I can get!

That's about it for now, apart from a consistent crash I'm getting when
stepping through code. I'm working on fixing that, but for the moment
I've disabled this feature. I also need to change the interrupt routines
so that only the high priority interrupts are accepted when in sleep
mode.

Dave.

[Rcxemul-discussion] Serial comms

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

The serial comms aspect is complicated, but not too complicated. I am
thankful for that! It seems most of the work has to be done by software
so I don't have to worry about it.

As far as I can tell, it works like this:

The download program sends a character to the tower. The tower sends it
to the RCX's IR port. The IR port decodes this, and frames the data in
such a way that the SCI (serial comms interface) can understand it.

The SCI (the thing I have to implement) monitors the receive data line
(Rx), and when it detects a start bit, it fills up an 8-bit register. It
then checks this for parity, etc. and if it all checks out, it puts it
into the received data register, and calls an interrupt.

The problems I can see:

1. Getting the download program to send to my fake IR tower. I've had a
look at the code that lejos uses for download, and it seems that if I
can do some fakery and get RCXTTY=fakeir to output to somewhere I can
also read from, I can use unaltered download code. I don't know enough
about this area to do anything yet; I'm going to ask around at work to
see if anyone knows how to do it.

2. Working out how to frame the data, and in what format it is
transmitted by the tower. Hopefully it's a straight translation.

It looks like after every character is sent by the download code, it
waits for a reply. This is a good thing because I don't have timing to
worry about.

I'll have a go this week, and post here with an update.

Dave.

[Rcxemul-discussion] Another update

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

I know it was quick, but I decided to implement the interrupt for the
on/off switch. When the CPU hits the software sleep state (i.e. ROM has
finished initialising), I generate the interrupt. It then calls a bit of
code (looks like it tidies up the IRQ input) then returns to normal
program execution.

I've followed it through on Kekoa's ROM description and it's following
all the paths it should do. It's getting into the firmware update
function, and tomorrow I'm going to have a look at what's happening in
there. I presume if it's the first time the function has run, it will
wait for firmware to be downloaded.

Unfortunately this is going to make it more difficult to get a valid
firmware image in without using the serial port. The only way to do it
would be to go in and alter the memory to fool it into thinking that the
firmware has been downloaded.

On the bright side, if I had a sound module working, I'm pretty sure it
would have beeped twice! ;)

RE: [Rcxemul-discussion] Update 13/09/02 - the epic tale of my recent shenanigans

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

Hi Brian.

> Hi, David. Epic is right! That's quite complex stuff but it 
> sounds like you're conquering it all. Is all this going to 
> have a physical 3d/2d environment that the RCX emulator runs 
> in? If so, do you have a plan on what it'll look like and how 
> you'll develop it?

This could be *way* in the future, but I envision being able to
interface it with something like Rossum. There would be a Java UI (which
looks like the RCX) with clickable buttons and updating LCD. These will
be read from the information generated by looking at certain registers
(which function as I/O lines). The emulator would sit and run in its own
little world, oblivious to the fact that it is being used as an RCX. I
can't give any estimates on how fast this thing will run just yet... I
am reckoning it will be pretty slow to start with! Once it works I'll
start optimising.

To be honest, I could have something running reasonably soon because
most of the work is done by ROM using the H8's instruction set (which I
have finished implementing). Some of the things (like serial
communication) aren't entirely necessary. I just need to come up with a
way of getting a program into the right place in memory without using
the IR tower. I'm going to have a look at how lejos stores the program
soon.

The buttons simply trigger external interrupts which aren't difficult to
simulate. All that happens when an interrupt is generated is that the
program execution vectors to a location in memory. Interestingly, the
interrupt vectors for the RCX are copied to external memory, so you can
write your own interrupt handlers. The on/off button is the interesting
one for me at the moment. I can't wait to see what happens when the RCX
is in the powered on state.

*snip discussion of communicating*
 
> This will be really strange in a simulated environment. I 
> don't envy having to create that.

The comms issue is a thorny one indeed. I need something that isn't too
bulky otherwise it will become bogged down very quickly. If you imagine
that over 100,000 instructions per second are being executed, it would
be very costly to output all the output states each time. So I'm going
to have to output them only when one changes. How to do this is going to
require some thought.

The best thing about this project for me is that I am enjoying it! Other
projects I've worked on have gotten bogged down in tedium, but this one
is constantly rewarding. You can't imagine the joy when I realised that
my 16-bit free running timer had been set up to generate an interrupt
every 1 millisecond! ;)

I'll keep sending updates to the list whenever I do something
significant.

Dave (who needs to learn how to write shorter emails!)

Re: [Rcxemul-discussion] Update 13/09/02 - the epic tale of my recent shenanigans

[Brian B. <bba...@mt...>]

Hi, David. Epic is right! That's quite complex stuff but it sounds like
you're conquering it all. Is all this going to have a physical 3d/2d
environment that the RCX emulator runs in? If so, do you have a plan on what
it'll look like and how you'll develop it?

> Now, an interesting (but complicated problem). I want to be able to
> create a fake IR tower application that takes output from the
> firmware/program download applications (lejosfirmdl and lejos) and
> communicates it to the serial port of the RCX. The serial port is quite
> complex and it's going to take me some time to implement. Add to that
> the fact that I don't have a clue how to interface these things! It
> would be ideal if I could do it without having to modify the firmware
> download code too much (e.g. just set RCXTTY=fakeir or something). Also,
> I don't know the best way of interfacing. Some ideas:
>
> 1. Sockets. Cygwin does sockets similarly to Unix, so I could create a
> message-based protocol to transfer information to and from the emulator.
> This could also be used when updating the state of the emulator. It
> would enable a UI to run in another language (e.g. Java) and even on
> another machine.
>
> 2. Some other convoluted way such as pipes or shared memory. Shared
> memory wouldn't be too bad, but I don't have a clue about it and whether
> it's portable. That way I wouldn't have to deal with the overhead of
> processing messages.

This will be really strange in a simulated environment. I don't envy having
to create that.

> So, that's about where I am. Congratulations if you read this far! Now
> I'll tell you how to compile and run the thing!
>
> Step 1. Obtain latest code from CVS.
>
> Step 2. Put it all in a directory.
>
> Step 3. Compile it.
> a) gcc -o emul.exe *.c       will do it.
> b) gcc -DRCX_DEBUG -o emul.exe *.c      will give you a version
> with debug info (recommended).
> c) gcc -DRCX_DEBUG -DRCX_DEBUG_REGISTERS -o emul.exe *.c    will
> give you a version with some registers output as well. Not all that
> useful.
>
> Step 4. Get a ROM and RAM image.
> a) ROM: Kekoa's page has info on how to get this.
> http://graphics.stanford.edu/~kekoa/rcx/. I don't know how safe it is to
> do this, but all it does is install a new firmware that reads the ROM
> and outputs it in S-record format.
> b) firmware (RAM): The file bin\lejos.srec in the lejos
> distribution should do it. It doesn't actually use the firmware, but it
> has to be there for the thing to work.
>
> Step 5. Run it!

Impressive.

> Type: emul -f lejos.srec -r rom.srec -d
>
> This assumes your firmware is called lejos.srec and your ROM is called
> rom.srec. The -d signifies that you want debug mode. There are 4 levels
> of output and the following flags control them:
>
> -d (or --debug): highest level - output most (recommended)
> -q (or --quiet): don't output very much
> -v (or --verbose): about half way
>
> If you don't put a flag it defaults to between -q and -v.
>
> Other flags:
>
> -f (or --ram): followed by the firmware image
> -r (or --rom): followed by the rom image
> -h (or --help): output some help info
>
> It compiles under my installation of cygwin using gcc. I don't know if
> it will compile for anyone else; it would be nice if someone lets me
> know if they can get it to run.
>
> In the actual application, pressing return will execute the next
> instruction. Pressing d (followed by return) will dump the memory to
> screen, and b will output it to a file (in binary format).
>
> Phew! That's about it for now...
>
> Dave.
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/2002
>
>
>
>
> -------------------------------------------------------
> 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

[Rcxemul-discussion] Update 13/09/02 - the epic tale of my recent shenanigans

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

Hi all.

Things are slowly progressing, and I'm overcoming problems. I thought I
would detail what I've been doing and how to compile and run the thing.

So. In the last few weeks I've been working mainly on getting some
coherent debugging information. That's just about complete. I've only
got a couple of opcodes to update (some bit operations) and that will be
finished. Debug information is a compile-time option so you don't have
to have the overhead.

I've updated the memory functions to work with the 3 modes of the
H8/3292. Depending on the mode setting, requests to access certain
addresses will be redirected elsewhere. This is important because it
takes longer (for instance) to access external memory than it does
internal. Anyway, this seems to work. I haven't come across any problems
with it just yet.

The code's still a mess, but it's becoming more coherent as time goes
by. Whenever I return to a module already written, I am attempting to
tidy it up.

I've removed the 16-bit free running timer because it was firing too
often (it generates an interrupt). I need to get the clock
implementation done before then, and tables to work out how many CPU
cycles each instruction takes. When that's done, I can re-enable the
timer and it should fire off more regularly.

I discovered that during the ROM initialisation routines, the value
0x0120 is written to 0x8000. Why is this significant? The firmware entry
point is at 0x8000, meaning that even if the ROM routines got that far,
it would go into sleep mode. So, I either need to reload the firmware or
bite the bullet and write the serial port code.

I have ascertained that when running the emulator, it gets to a certain
point in the code and a sleep instruction is used. This sends the RCX
into software shutdown mode. This can only be woken up by a reset or a
high priority interrupt. One such interrupt is the on/off button. I plan
on implementing this interrupt soon, so I can see what happens if the
on/off button is pressed.

Now, an interesting (but complicated problem). I want to be able to
create a fake IR tower application that takes output from the
firmware/program download applications (lejosfirmdl and lejos) and
communicates it to the serial port of the RCX. The serial port is quite
complex and it's going to take me some time to implement. Add to that
the fact that I don't have a clue how to interface these things! It
would be ideal if I could do it without having to modify the firmware
download code too much (e.g. just set RCXTTY=fakeir or something). Also,
I don't know the best way of interfacing. Some ideas:

1. Sockets. Cygwin does sockets similarly to Unix, so I could create a
message-based protocol to transfer information to and from the emulator.
This could also be used when updating the state of the emulator. It
would enable a UI to run in another language (e.g. Java) and even on
another machine.

2. Some other convoluted way such as pipes or shared memory. Shared
memory wouldn't be too bad, but I don't have a clue about it and whether
it's portable. That way I wouldn't have to deal with the overhead of
processing messages.

So, that's about where I am. Congratulations if you read this far! Now
I'll tell you how to compile and run the thing!

Step 1. Obtain latest code from CVS.

Step 2. Put it all in a directory.

Step 3. Compile it.
	a) gcc -o emul.exe *.c       will do it.
	b) gcc -DRCX_DEBUG -o emul.exe *.c      will give you a version
with debug info (recommended).
	c) gcc -DRCX_DEBUG -DRCX_DEBUG_REGISTERS -o emul.exe *.c    will
give you a version with some registers output as well. Not all that
useful.

Step 4. Get a ROM and RAM image.
	a) ROM: Kekoa's page has info on how to get this.
http://graphics.stanford.edu/~kekoa/rcx/. I don't know how safe it is to
do this, but all it does is install a new firmware that reads the ROM
and outputs it in S-record format.
	b) firmware (RAM): The file bin\lejos.srec in the lejos
distribution should do it. It doesn't actually use the firmware, but it
has to be there for the thing to work.

Step 5. Run it!

Type: emul -f lejos.srec -r rom.srec -d

This assumes your firmware is called lejos.srec and your ROM is called
rom.srec. The -d signifies that you want debug mode. There are 4 levels
of output and the following flags control them:

-d (or --debug): highest level - output most (recommended)
-q (or --quiet): don't output very much
-v (or --verbose): about half way

If you don't put a flag it defaults to between -q and -v.

Other flags:

-f (or --ram): followed by the firmware image
-r (or --rom): followed by the rom image
-h (or --help): output some help info

It compiles under my installation of cygwin using gcc. I don't know if
it will compile for anyone else; it would be nice if someone lets me
know if they can get it to run.

In the actual application, pressing return will execute the next
instruction. Pressing d (followed by return) will dump the memory to
screen, and b will output it to a file (in binary format).

Phew! That's about it for now...

Dave.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/2002