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