After a discussion about x86 emulation and WINE on #omnimaga, I became curious about the possibility of an emulation layer to provide additional functionality to Prizm programs by replacing missing hardware like the FPU and potentially other higher level functions.

Here's the basic conceptual framework I came up with:

• All Assembly/C programs would go through a low level interpreter. This interpreter would be interrupt based and would copy a section of code into a buffer.
  
• The buffer would be terminated with a Sleep instruction so that if the code finished executing the buffer, the processor would halt until the next interrupt fired in a few milliseconds.
• When the interpreter detected something like an FPU instruction code, it would handle the instruction by replacing it with a call to a library routine.

This raises some obvious points, like the slowdown inherent in interpreted programs, but I don't think that's a serious problem, since most applications aren't speed critical enough for that to be a problem. Such an interpreter would also operate very low in the system, so it could probably be accomplished in only a few hundred cycles. You could also replace the interrupt/Sleep idea with a call to the interpreter so that it automatically calls the interpreter upon finishing. That would leave the interrupts open for modification by the program, as long as it doesn't modify itself to overflow the buffer.

Anyway, just a thought.

I might have something along those lines planned... 

It does support general illegal instruction exceptions. However, I'm not sure if FPU codes trigger those. I should probably check.

Because it's much more difficult to interpret a high level language like BASIC than to interpret Assembly. Something like Java would be possible, but porting a virtual machine would be a nightmare.

Emulating graphics chips in software sucks

That'd actually be a very useful thing, though. If I ever decide to actually try this, then those would be a necessity.

This particular picture took 15 minutes to render in Casio-BASIC:



I think you'd be lucky to get frames per month... 

There is no way that took 15 minutes to render.  There's just... What the heck.  Okay, so is this the OS or hardwares' fault?  That's actually on the calc, right?  Could you show a video of that.  Maybe put a camera over it, and host a livestream or something? *shrugs*

It's the OS, no doubt about it. Drawing something like this in asm is probably about as fast as on an 8x calc.

Quote from: JosJuice on March 21, 2011, 09:31:16 am

Quote from: graphmastur on March 21, 2011, 09:24:37 am

There is no way that took 15 minutes to render.  There's just... What the heck.  Okay, so is this the OS or hardwares' fault?  That's actually on the calc, right?  Could you show a video of that.  Maybe put a camera over it, and host a livestream or something? *shrugs*

It's the OS, no doubt about it. Drawing something like this in asm is probably about as fast as on an 8x calc.

Wow. So, CKOS or what?

EDIT: IE: Casio-Knight OS or what?

What do you mean?