Omnimaga
Calculator Community => Casio Calculators => Topic started by: AngelFish on March 20, 2011, 11:21:37 pm
-
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.
-
Why not just use actual routines for floating point and such? Unless you have some newer SuperH code in particular that you want to port.
-
I might have something along those lines planned... <_<
-
Hmm, well, does the processor support illegal instruction exceptions? I think that would be the best solution rather than interpreting code.
-
It does support general illegal instruction exceptions. However, I'm not sure if FPU codes trigger those. I should probably check.
-
Well, if you're making it interpreted anyways, why not just make an interpreted language of your own? Just a thought.
-
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.
-
I had an idea to take this one step further. Instead just porting an interpreter for SH3E instructions, how about adding functionality for the SH4 instruction set. SH3 opcodes work on the SH4, but the SH4 just adds some more fpu calculations along with also some graphics acceleration based codes. documentation is here http://documentation.renesas.com/eng/products/mpumcu/rej09b0318_sh_4sm.pdf
-
Emulating graphics chips in software sucks :P
That'd actually be a very useful thing, though. If I ever decide to actually try this, then those would be a necessity.
-
Emulating graphics chips in software sucks :P
That'd actually be a very useful thing, though. If I ever decide to actually try this, then those would be a necessity.
That reminds me.
I should start work on my openGL port to Casio Basic. With slow math and drawing commands I wonder how may frames per hour (or day :P) will I get. I should also get going on that BASIC 8 color bmp viewer. It might take a few hours to render though. But seriously we need a new BASIC interpreter. Not a full blown one with every command, but just the important math and graphics ones with maybe a few new bitmap commands too.
-
This particular picture took 15 minutes to render in Casio-BASIC:
(http://img.removedfromgame.com/imgs/0-DispCap1.png)
I think you'd be lucky to get frames per month... :P
-
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*
-
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.
-
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?
-
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?
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
The slowdown is part of the OS since the BASIC language is part of the OS, but just like you said, it's possible to fix it without a new OS - but it's still the OS's fault that drawing is slow.
also: I like quote pyramids.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
The slowdown is part of the OS since the BASIC language is part of the OS, but just like you said, it's possible to fix it without a new OS - but it's still the OS's fault that drawing is slow.
also: I like quote pyramids.
Yeah, they are kinda fun aren't they. So, we need either AXE or KOS for prizm calcs now.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
The slowdown is part of the OS since the BASIC language is part of the OS, but just like you said, it's possible to fix it without a new OS - but it's still the OS's fault that drawing is slow.
also: I like quote pyramids.
Yeah, they are kinda fun aren't they. So, we need either AXE or KOS for prizm calcs now.
And maybe PrizmSuite too? ;D
-
I say the first thing is just to complete the calc's documentation. It's quite possible that we could gems embedded in the OS that could aid us, or inhibit us.
I have no idea what the status is on this -- but that fact that we can't really use and compile a C program for it yet shows more work must be done.
-
I didn't know that casio-basic was so slow....
Since I do not know much about Casio calculators, I have a little question: can you run assembly on the prism?
This might be a stupid question, and I probably can google it, but for some reason its fun to ask :)
-
Since I do not know much about Casio calculators, I have a little question: can you run assembly on the prism?
Yes, but Casio has not released an SDK, so we're still exploring what's possible to do. Running assembly code has been possible since January this year.
-
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?
I think something else would have to be used, because it would cause confusion between CasioKingdom website/forums and KnightOS.
And I'm sure the calc can draw stuff fast enough. I hope it's faster than in the Insight demo, though, otherwise if we can only get 30-60 FPS with 20 moving squares then I bet we'll be limited in graphic intensive games.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
The slowdown is part of the OS since the BASIC language is part of the OS, but just like you said, it's possible to fix it without a new OS - but it's still the OS's fault that drawing is slow.
also: I like quote pyramids.
Yeah, they are kinda fun aren't they. So, we need either AXE or KOS for prizm calcs now.
And maybe PrizmSuite too? ;D
Err.. Working on a temporary assembler for Qwerty.55 before I can work on that. And that reminds me. Can anyone please explain how instructions that branch work. I'm interested in calculating the displacements. Qwerty.55 gave me some test code, but I still can't figure out how many bytes back stuff should be. For example, what looks like it should be -6 bytes back is -4, or -5, or stuff like that.
-
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?
lol, KOS for Casio calcs. As in a new OS instead of the one that comes with the calc.
It would probably take a very long time until it becomes possible to make a third-party OS.
When we blame the OS, we really mean the Basic language. It's definitely possible to do faster stuff without a whole new OS, as we saw on the TI-83+.
The slowdown is part of the OS since the BASIC language is part of the OS, but just like you said, it's possible to fix it without a new OS - but it's still the OS's fault that drawing is slow.
also: I like quote pyramids.
Yeah, they are kinda fun aren't they. So, we need either AXE or KOS for prizm calcs now.
And maybe PrizmSuite too? ;D
Err.. Working on a temporary assembler for Qwerty.55 before I can work on that. And that reminds me. Can anyone please explain how instructions that branch work. I'm interested in calculating the displacements. Qwerty.55 gave me some test code, but I still can't figure out how many bytes back stuff should be. For example, what looks like it should be -6 bytes back is -4, or -5, or stuff like that.
I don't know much about the SH3, but try using PC+2 (or PC-2?) instead of PC when calculating stuff.
-
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.
Actually, drawing something like this could probably be done *faster* than an 8x calc. But yeah, that was a simple pixel based loop to draw those lines. It might have been a bit less than 15 minutes though. I went off and wrote a good portion of a paper in the time it took to finish. Here's the program:
ClrGraph
AxesOff
0→C
For 4→E To 6
For 1→A To 2^E
For 1→B To 2^E
Blue PxlOn A,B+C
Next
Next
2^E+10+C→C
Next
I have no idea what the status is on this -- but that fact that we can't really use and compile a C program for it yet shows more work must be done.
You can indeed compile C for it.
-
I wonder if it's recalculating 2^E each loop iteration?
-
Isn't there a line or rectangle drawing command?
-
I wonder if it's recalculating 2^E each loop iteration?
It didn't go much faster when I explicitly defined the number of pixels and the Prizm does pretty well with math, so that's probably not it.
Also, there is a line drawing command, but it uses a line multiple pixels wide and you don't have pixel level control over it. It's like the [Thick] Line routine on the 8x series.
-
How thick is the line? 3-5 pixels? I wonder if there are any syscalls for lines.
-
Err.. Working on a temporary assembler for Qwerty.55 before I can work on that. And that reminds me. Can anyone please explain how instructions that branch work. I'm interested in calculating the displacements. Qwerty.55 gave me some test code, but I still can't figure out how many bytes back stuff should be. For example, what looks like it should be -6 bytes back is -4, or -5, or stuff like that.
Well time to test my knowledge on SH3. The reason why you probably got the wrong result is that because the SH3 has an execution pipeline that processes multiple instructions at once. When referencing the PC in an instruction, the PC is equal to the address of the current instruction plus 4. Also because the address of instructions is always a multiple of 2, the given address must be &'d with $FFFFFFFE. This ensures that the address is always even. And I believe you already know that when given a displacement you multiply that by 2.
And if I got this all wrong, that would explain why branching statements cause bugs right now on my emulator. :P
-
And it also explains why I still haven't figured it out. Okay, so let me look....
So Qwerty.55 gave me this:
Loop:
MOV.W @R1,R4
ADD $FF,R1
ADD $FF,R3
TST R2,R2
BF/S Loop
MOV.W R4,@-R2
and said it compiled into:
6411
71FF
73FF
2228
8FFA
2245
The 8FFA being the BF/S statement. So FA == -6 right? So that's per instruction, meaning 12 bytes back, or 6 instructions back. So, from the 6411 to the 8FFA is 8 bytes. Okay, and 4 bytes ahead makes it 12. I see. Well that's not stupidly complicated. I just kinda had to put that out there in writing and I guess it made sense.
I still don't see why you &'d $FFFFFFFE though. Wouldn't it already be even no matter what? Considering if you reference the number of instructions with displacements. IE. Function B references to go back to Function A. Function A and B are both on an even displacement. Function B references A, which is, let's say, 5 instructions back. Since you multiply it by two to get the bytes, you always get an even number of bytes back, and instructions always start at even numbers. So yeah, why did you & $FFFFFFFE?
-
@Graphmastur, that is because BSRF, JMP, and JSR use registers to find their address, meaning there is the possibility of an odd value being passed. But now that I think about that, the &ing with $FFFFFFFE is not needed to be done on an assembler. Only needed on disassemblers and emulators.
btw the way, how is progress going on your assembler. Because for me I'm starting to lose track of all my hex code and I don't think I'm ever going to figure out that Kpit GNU tools thing. I'd rather just use a command line assembler.
-
Well, the temporary, ie not PrizmSuite, one is going well. I'm trying to finish it asap.
-
Sounds good. Next week I have spring break and will have lots of time for coding. One thing that I want to make is an IDE designed for SH3 asm. Features I want to include are highlighting the word and long word sections for data and code, making it easier to set up displacements for jumps and MOV instructions. Also I want to do warnings for when the label used in an instruction is out of range, an illegal instruction is used (such as if a jump is used after a delayed branch), and when two instructions that when used in tandem will take extra clock cycles (such as accessing the MAC after a multiply instruction or using a register that was written to from memory in the last instruction). And just maybe some support on doing self-modifying code. ;)