NXT Emulator, how hard would it be?

[nxtboyiii]

Hi,
How hard would it be to make an NXT emulator, that just emulates touch sensors, NXT buttons, and the NXT screen?
If it is not, then why is it not already made?

[inxt-generation]

Hi,
How hard would it be to make an NXT emulator, that just emulates touch sensors, NXT buttons, and the NXT screen?
If it is not, then why is it not already made?

I have no idea how hard it would be. However, RobotC comes with a built in emulator. You can choose to download the program to a "virtual NXT", and run code on the computer. RobotC forums member "miki" wrote a library for RobotC that can emulate motor and sensor commands. I've never heard of any other emulators for the NXT. I know that Mario Ferrari wrote a couple for the RCX.

If you want to try the RobotC one, you can get a 30-day free trial.

Does this answer your question?

[nxtboyiii]

Hmm... Well I meant an emulator that could run .rxe files that had the layout of NXT Screen utility.

[inxt-generation]

Hmm... Well I meant an emulator that could run .rxe files that had the layout of NXT Screen utility.

I wouldn't know, then. I've never heard of any that can do that.

I imagine it would be kinda difficult to make one. But, I don't know how hard, as I have limited experience with computer programming.

[nxtboyiii]

Well, I haven't really programmed much either, so.... yeah.

[mcsummation]

The problem of emulators of real-time, sensor sensitive systems: you usually have to provide a real-time script that the "sensors" to execute. Those things are usually really tough to write. As an example, back in the Gemini/Apollo days, the Mission Support systems at NASA in Houston had almost as many people working on the simulators as we did working on the actual Mission Support computers. The early ones took 2 tightly coupled main frames just to generate the data needed to simulate the world and a single mainframe to process the data they generated. The scripts were huge with entire control rooms just to make things look "real". (I worked in the trajectory predication part of the Mission Support systems and my job was easier than my compatriots in the simulation systems.)

You might want to look at ARM7 emulators. There is as least one. But, I don't believe it emulates the AVR processor.

[afanofosc]

It would be relatively easy to write an emulator that only emulated touch sensors, nxt buttons, and the nxt lcd screen. What should this emulator do when you run an RXE that tries to use hardware/firmware features other than simple touch sensors, buttons, and the LCD screen?

John Hansen

[haydenstudios]

Oh, this is a very interesting idea. I'm with John here, it probably wouldn't be too hard.

What should this emulator do when you run an RXE that tries to use hardware/firmware features other than simple touch sensors, buttons, and the LCD screen?

I guess that was mostly for nxtboyiii to answer, but it would probably be ideal to assign certain keyboard buttons to hardware emulation functions like motors and more advanced sensors.

But this would be awesome if you were making a video game for the NXT and wanted to save NXT battery power by testing it on your computer.

[nxtboyiii]

Well it would be good because, if you needed a quick test you could use it or use it for NXT games. Also it could support grayscale like on the NXT (Like what WabbitEmu (A calculator emulator) does.). So you could record the screen in grayscale and post it online.

So, it that was made, that would be really awesome.

[tcwan]

Hi,
How hard would it be to make an NXT emulator, that just emulates touch sensors, NXT buttons, and the NXT screen?
If it is not, then why is it not already made?

Well, there are two parts to this puzzle:
First, an ARM processor (instruction) emulator, and second the I/O (sensor) emulator.

For emulating the ARM processor, I guess one starting point is QEMU. Google found at least one project which had AT91SAM7 support (I haven't tried it before): http://gitorious.org/qemu-at91sam7/pages/Home

However, hooks will need to be developed to emulate the I/O devices, since the processor emulator won't know what to do when a particular address is accessed. There are two ways to do this, one is to emulate at the lowest level (i.e., I/O address register emulation), which allows you to execute the NXT firmware image as is, the other is by using virtualized drivers to override calls to the particular device driver with new calls which performs the I/O emulation directly. This would probably involve hacking the NXT firmware source to come up with an emulation-based version.

For I/O address register emulation, you're basically recreating the hardware peripheral device as a software module, e.g., reading the I/O address register returns values that the actual hardware peripheral device will return, whereas virtualized drivers can access the host PC I/O routines directly (e.g., a touch sensor virtualized driver can possibly perform a keyboard input to read a keypress as the touch sensor input).

I guess the difficult part is the I/O emulator, since it is somewhat specific to the microcontroller (AT91SAM7) and platform (NXT) that is being emulated.
It is a challenging project