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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

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

rcxemul-discussion