I was playing around on Casio's Manager Plus free trial for the Prizm when I noticed some new functions. When exploring the memory management app I came across an option to import and export files from your computer. Curious as ever I took the latest build of Insight and sent it to the emulator. To my surprise it showed up on the main menu correctly and even more surprising it ran somewhat correctly. This is significant because it was previously believed that this emulator was of the OS only and not the actual hardware. There were a few discrepancies such as during the transparency test when a picture is supposed to be loaded and a few other minor glitches. One thing to note is that it is not a perfect emulation in that it is obvious that Casio modified the original OS to work for this emulator. Functions such as the battery are disabled. Most functions are around the same speed as the real Prizm with a few being faster such as screen drawing.

Issues that I did have with it was that multiple key presses are not supported which led the gif clip I took to end because I could not press the on button and 0 at the same time. Other things is that not being a full emulator means that we cannot upload new OS's the same way, but that could be possible via changing the data files. Interesting things that this provides us is a file called CPU73050.dll which contains the emulation code for the undocumented Super H CPU being used in the Prizm. It is essential now that we do are best to dissemble the code and document as much as we can. I do want to note that my Prizm emulator project Spectrum has not died as there is much to be improved upon, but it is not my top priority right now. This will though provide a good testing bed for the time being.

Steps to run emulator (No Prizm needed, but you do need a PC or wine)
1. Go to https://edu.casio.com/freetrial/download.php/fx-cgm_90d_1.00_2.zip and download Manager Plus
2. Install the Manager Plus free trial
3. Download the latest build of Insight provided at the bottom of this post courtesy of Simon Lothar
4. Run the Manager Plus
5. Using the arrow keys navigate to Memory app or just press alpha F
6. Press F3 to import and export files
7. Press F1 to import
8. Find Insight.g3a on the new explorer window and press OK
9. Press F1 to save
10. Press exit to exit (duh)
11. Press menu to return to the main menu
12. Find the Insight app then press EXE
13. Do whatever you want here (I advise not going into the keyboard ports function as that requires multiple key presses to exit from. I would suggest playing around with the DD and VRAM demos along with WriteGraph. Syscalls is locked by default and can only be unlocked by building the Inisight code with removed comments.
14. Use this to play Prizm games if you don't have a Prizm  ;D

Steps for creating animated GIF's in calc capture
1. Start up calcCapture
2. Press Configuration
3. Select New
4. Type Prizm as the name of the emulator
5. Start the Manager Plus software
6. Select FX-CG10/20 MANAGER PLUS (90 DAY TRIAL) - [EMULATOR MODE] - KEYLOG1 as the window title or something similar to this
7. Press Capture
8. set width as 384, height as 216, top as 217, and bottom as 54, adjust as necessary based off the bottom window
9. back on the original screen select no borders and 256 colors
10. Select capture type as animation
11. write an image file name
12. Press activate then capture to begin
13. Upload your screenies ;D

As I've said on Omni, this is looking very good, now we can has screenshots!

Wow, great job on finding this! Maybe now I can write some Prizm programs...

THis is awesome!!!

This is amazing! Super job on finding this, z80man! I will definitely be trying this out very soon, and the great side-effect is we can have better animated screenshots! I worry they're going to be hugenormous, though.

Edit: So I gave this a try, but I'm told something about copy protection when I try to import oblitr8.g3a.

I got the same error with Merth's Default heart thing. I wonder if it is a issue with how Tari's mkg3a is making the addin's, maybe he has something in the header that is triggering the copy protection on the emulator.

I had the same issue too when I tried to upload some programs of mine. In fact based off my tests so far no program made with gcc has been able to be loaded onto the emulator
But a program I wrote from scratch in hex a long time ago was able to be uploaded. using that I was able to trigger a ram clear which gave the error screen then restarted the emulator on the menu screen, skipping the normal configurations done during start up.

And did that force the emulator to accept your GCC program? Or when it restarted it still had the program?

It still had the app afterwards, but I still couldn't get a gcc program to work yet. I have a feeling that it has nothing to do with the compiler code, but something that is different in the headers.

Yeah that is exactly what I was thinking, could you maybe take a look at them and see if you see anything different that would be causing that issue?

Don't you guys know? You just have to clear the CopyProtected bit in the program header! This bit is right next to the Evil bit.

/me ducks


EDIT: if anyone is unfamiliar with the "evil" bit: http://tools.ietf.org/html/rfc3514

Kerm, does it send fine to your real calc? I wonder why it would work in one place but not the other.

I checked the difference between minesweeper (which works) and a simple test program that I had on hand and I realized that the program name was all messed up. I was using variables in my compiling batch file without realizing that the full path name was being passed to mkg3a. Even when I fixed the name the error still occurred. And both sets of security bytes were formated in the same way.

Looking at the headers of some of the binaries produced by Simon's SDK showed that the Copy Protection bytes were completely different on them and yet it still sent fine. This makes me wonder if we are missing something here on how those should be calculated.

Edit: Ok so I have figured out how those two bytes are actually calculated. 0x000E should be the lowbyte of the inverted filesize (0x13) minus 0x41, and 0x0014 should be that same low byte minus 0xB8. I will update the wiki and copy this post to Tari's mkg3a thread.

Edit2: As soon as my Prizm wiki account is made I shall update the g3a page so that future people will not have this issue.

Obliterate is having fun being tested on my real Prizm. It's happy drawing gradient backgrounds and cool Trebuchet-inspired projectiles.

Edit: Great job catching this! I hope that if Tari has some free time tomorrow I'll be able to accelerate Obliterate development with some emulator-based testing tomorrow! Although by the time you do all the importing and everything, it's only marginally faster than testing on a real calculator.

Prizm wiki updated with new information.

Because this emulator has its own set of issues I'm not canceling my own project yet. Because I'm pretty busy right now I doubt I'll be able to post a new build until around early June. With that build incorporating the full instruction set, a screen, keyboard, and maybe some of the Super H peripherals. I'm still not sure how many peripherals are needed to run the OS yet.

This is very interesting. A while ago, I discovered the issue that the mini-SDK and wiki were different when it came to those bytes... But I was dead sure that we were right and Simon was wrong. I didn't know why Simon's add-ins still worked on the Prizm, though... Thanks for proving me wrong.

Does the actual (non-emulator) Prizm not care about the bytes? If it doesn't care, I'm really starting to wonder how different the OS in the emu is from the real calc...

The non-emulator Prizm does indeed not care about the bytes, since I can easily load the GCC-compiled programs I've written onto my Prizm.

Hell you can load anything you want on the real Prizm. The emulator only excepts Casio .g1*, .g2*, and .g3* files that are formatted perfectly. I do though want to try replacing the built in rom file with one from my Prizm to see if that will work.