OOO i get you now.... That would be even better, but has more inherent difficulties than you may think.
IMHO it would probably be better to write an interpreter for .asm files that have already been compiled. Let me just say no matter how it is done, this will be no easy feat.

Eh, an ASM intepreter doesn't seem all that bad... only 26 instructions to implement and you've got the entire capabilities of the mc pretty much dealt with.

i guess. But you also have model the effects of all the registers. Still a far less daunting task then a C interpreter.

If you realy want to simulate the pic you should take a look at gpsim from the gnupic project.

http://www.dattalo.com/gnupic/gpsim.html

It should make Rob's job a lot easier.

oh yea i forgot all about gpsim.

Please elaborate on what you believe these difficulties may be.

This sort of thing is done all the time in the embedded software world. It is essentially the equivalent of porting code from one processor/board to another, which is one of the advantages of using a higher-level language like C.

I am no expert on the subject, so correct me if i am wron but it is my understanding that it would be quite hard to make PIC asm run on an x86 protected mode architecture while running windows/linux at the same time. The x86 architecture is soo entirely different from PICs. How would that work? It just seems alot easier t ome to emulate a pic just like rob did with the Basic Stamp. I can uinderstand maybie porting from for examply HC11 to PIC but to x86? Maybie im misunderstandin or missing something here but thats my $.02 Besides when you already have something like gpsim to work off of why bother?


[edit] Wait scratch all of that.... I see what you are saying now. Compile the C code to run on x86. I for some reason thought that you meant try to convert PIC asm to x86 asm. I see now. (feels liek idiot) {/edit}:eek:

You're missing the point. The idea is you would take the C code you wrote for your robot, and compile it with an x86 compiler. The result would be x86 assembly, which would be assembled into an x86 binary. This binary would be linked in (.dll or whatever) to RoboEmu at runtime. There is no PIC assembly involved here at all. No simulator to write or anything. All RoboEmu would have to do is provide the necessary symbols (functions and variables) for your RC code to link against that would otherwise be provided by the (theoretical) IFI libraries.

If you read the end of my post you would have realized that i finally figured that out.:)
or maybie you just replied bofore i added the "edit"

No problem... it's easy to overlook the fact that C code should be able to be compiled and run on any target, as long as all the necessary functions are provided.

I thought MPLAB allowed for limited simulation of codes. I guess I really should reinstall it.

As a quick fix, I have definately already considered doing the compile for x86 thing. It would make life SO easy. However, this would imply that people would have a C compiler on hand and that they would be able to re-compile every time they want to test new code. Personally, this sounds tedious to me. On the other hand, it's probably the easiest solution.

Well, I think that would be the best thing to do... just cause of the time you will save, and January isn't too awful far away. I think you could just write up a simple tutorial, and package it all together. It shouldn't take too much longer either though. So I say go with it to save time. Just my $.02

If it's possible, maybe you could use gcc. That way you could include the compiler as part of the package. And as far as having to recompile it every time, you could probably have your GUI do it automatically, so when someone opens their C file it automatically compiles it into a library. The RC code should be simple enough that it should compile in a matter of seconds.

The thing is that you'll need a linker, and a compiler at least. But that is a good idea. I'm sure there's a way to pass parameters to the program through calls or some sort like that.