It shouldn't cause any issues as the grayscale is the same speed as the 83+'a time to draw a pixel. 4 level grayscale in an emu just means that there is a max of 4 shades of gray.

I'm currently setting it up as 4 level grayscale as that best matches with the current LCD timer. So how the grayscale works is that when the LCD routine parses over a pixel in the 84+'s LCD ram that is set to on it subtracts a number based off the current contrast from the Prizm's VRAM for the corresponding pixel. (That pixel being scaled of course to account for the Prizm's higher resolution). So every time the LCD routine is called that pixel would be subtracted until it reaches the minimum value. The inverse would be done for turning on a pixel. The 4 level grayscale limit is temporary until a new LCD routine is written that gives direct control over the LCD ram. For now the best frame rate I can achieve is limited at 24 fps which I believe would only give room for 4 grayscale levels.

Hi,

I am looking for someone who can make the Algebrator program work on the Casio Prizm Calculator.

Algebrator is a .exe file type. The prizm needs a .3ga file type. Here is the link to the program Algebrator http://www.algebrasolver.com. I have the algebrator program I can send to anyone willing to give it a try. The Algebrator program is 6.0 mb and does not need to be installed.

Sorry that's a bit much to be asking right now when Prizm dev is only just getting started. The program that you're pointing out seems to be like a CAS and would be extremely difficult to make right now with either C/C++ or asm. Yes we do have plans to some day implement a CAS this will take several months or even a year. Our current priorities are to make games

But I would suggest attempting this in BASIC as that has floating point support and make sure you try the equation solver app as it has some powerful functions.

I have both a Casio and a TI if you want me to test something. I don't have two TI's but I could borrow a friend's for a test.

Okay I like some of the changes you made, but I question the need for defining Java and Lua programs in the header as wouldn't those be in .class files and whatever format Lua is compiled to. The shell itself can detect .class files and can pass those onto the virtual machine for interpreting. There are also many features that the shell would have that would remove the need for a complex header. Really I thought this header was just for executable programs and every other file type would be handled just like windows does. In fact the idea was to model the shell around the Windows Explorer and how it handles files. And within the explorer would also be a terminal which would handle all of the operations the user does. This just like any computer would be hidden if the terminal is not open.

Other features which for the most part are not included as of now, but will be featured in later versions are:

Hooks: An example of where this could be used is if a .jpg file appears in the current directory. Instead of using the standard icon for .jpg files a hook could be triggered corresponding to either the shell itself or another program that has registered a .jpg hook with the shell. The .jpg handler could then return a icon that is a scaled down version of the actual image data. Other example could be in java where if the cursor is held over a .class file the .class handler could return information such as author and company to be displayed, this information being found by parsing that particular file. The last example is a right click hook. Now if you have Notepad++ installed on your computer whenever you right click on a file you will see the option "Edit with Notepad++" a similar feature could also be setup with hooks. As you see the possibilities are endless.

Terminal: Also known as a command line on Windows systems. You may not think of it much, but when you click on a cpp file on your computer, hidden from you the text "C:\Program Files (x86)\Notepad++\notepad++.exe C:\users\z80man\documents\myprogram.cpp" is being typed into the terminal (minus the z80man part ) The same thing would be done when opening a file or running a program from the shell. You even have the option to open the terminal yourself and type commands or too run your own batch files.

Libraries: Okay one of my biggest points has been cross-compatibility and backwards compatibility for the Prizm. Along with this has also been location independent code. When using multiple libraries in a program location independent code can pose issues when these are random, often user made libraries, that the shell has no prior knowledge about. To deal with this a set of shell calls are being developed that upon startup of a program, the program will pass the names of libraries and their given ID (this can be any number the programmer wishes and is not defined in the library, but in the program that way two libraries don't end up both having 42 as their ID) Then whenever a library call is made (which is done in the exact same manner as the OS syscalls are done except it is a different address) the stack is read for the ID number and the shell will then call the proper  routine from the proper library.

Compression: Because there is very limited space available in flash it is important that programs use as little space as possible. Part of this is handled through the powerful array of malloc() calls available so that the programmer does not have to have large areas of 0's in code.  this is also handled by the emphasis of runtime libraries which reduce redundant code. The other thing is to encourage compressed files and folders. An example of a compressed file would be jpg's for images as they are often almost a third smaller than their bmp counterparts. Now because handling jpg's can be difficult in code shell calls can be devised to return a pointer to a bmp after being passed a pointer to a jpg as an argument. An example of folders would be zip's tar.gz's tar.xz's and so on. To make things easier for the programmer shell calls to handle these folders would be required. 

Multi Tasking: This feature is still far off from being implemented  anytime soon, but the idea would allow the execution of multiple programs and opening of multiple files. The advantages could also be seen if a windowing system could be setup too.

Wobbly Windows: I make my case clear

Well I'm hoping it will. My current tests say that it will be running at full speed, but there could be hidden factors later on that would slow it down. Right now in order to achieve my current speeds I'm giving up a lot of size. For example every instruction has a version of it for each register because I don't want to waste time trying to figure out which register is being used.

From what I've seen, teachers generally tell students to stay away from Casios, because of the difficulty in getting students to understand using them.

I had that same problem when I tried to convince my school to upgrade to Prizm's. By greatest concern was that if TI decided to cancel the 83+ line my school would then require everyone to get to get regular nspire's or CX's.  I was reassured from my math department chair that Ti will not cancel the 84+ line anytime within the next 10 years, BS and that even if they did the school prefers TI calcs because they are more often used in college.

Quote from: Deep Thought on May 06, 2011, 11:25:01 pm

z80man has an avatar of a device that uses an SH3 processor

But looks like it's running a z80 game, so I guess it fits...

You'll notice TI's lovely puke-green display.

That's what the 84+ emulator for prizm will look like when it's finished. It is playing Link's Awakening on TI Boy. Oh and it's an SH4A without the fpu not an SH3. And an SH4A without an FPU is almost the exact same thing as an SH3 so yeah

here's a full size for your viewing pleasure