Author Topic: Casio Prizm documentation (Read 234493 times)

z80man · « **Reply #420 on:** February 19, 2011, 10:40:53 am »

Quote from: SimonLothar on February 19, 2011, 09:08:28 am

Quote from: Kristaba on February 19, 2011, 08:06:49 am
Firstly, what do you know about the G3A header checksum...it's the last information I need for my G3A wrapper
It's the last information I do not know either. But I experienced, that it is not essential. I assembled a little memory-viewer-G3A and did not care about this field. The G3A works without any problems. But anyhow, I like to know how this value is computed, too.

Good thing you are speaking to the right person on cracking the g3a header. The 16 bit crc checksum (well I believe its a crc) only calculates the 32 bit modular checksum at address 0x0020. Now I have not yet cracked the crc yet, but I did crack the modular checksum. How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum. But to get by the crc you can use one of the checksums previously written by Casio in one of the three apps. I would first like to apologize on slacking off on my app signer program, but I have been busy lately. How it works though is it compares the modular checksum between your app and a prewritten one. If your app has a lower checksum, then the app signer first divides the checksum of the prewritten app minus the checksum of your app by $FF. It then adds X number of $FF to safe areas in the header that were previously $00. The signer then finds the modulus between the prewritten app minus your app by $FF. It then adds the result to one byte that was $00 originally. If your app has a greater checksum, then the signer divides as usual, but then turns X number of $FF bytes to $00 and the modulus is is subtracted from a $FF byte. There is also full documentation for this on the Prizm wiki http://wiki.prizmwiki.co.cc/wiki/Main_Page

JosJuice · « **Reply #421 on:** February 19, 2011, 01:55:17 pm »

Quote from: z80man on February 19, 2011, 10:40:53 am

How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum.

Isn't the CRC checksum ignored too when creating the 0x0020 checksum?

Goplat · « **Reply #422 on:** February 19, 2011, 04:05:05 pm »

I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.

JosJuice · « **Reply #423 on:** February 19, 2011, 04:06:29 pm »

Seems more like a grey-and-white icon to me. I wonder why it's missing in one app... Maybe this icon and the localized names that are before it are used for backward compatibility?

bsl · « **Reply #424 on:** February 19, 2011, 04:57:56 pm »

Found the fx9860g ROM in the fx9860g OS upgrade, now finding prizm syscalls
should be easy (assuming they used the same compiler)

Code: [Select]

sh3_disass.py  -s 10070 -e 10080 -p 80010070 ISSetupFile.SetupFile3 

80010070: d202 ..  MOV.L @($02*4+PC),R2 = #801B0130
80010072: 4008 @.  SHLL2 R0
80010074: 002e ..  MOV.L @(R0+R2),R0
80010076: 402b @+  JMP @R0 
80010078: 0009 ..  NOP
8001007A: 0000 ..  0000 ?
8001007C: 801b ..  .data 801b0130 dword ref:80010070

Goplat: Yes it is a small icon - the Geometry and PictPlot add-ins have one , but not the conversion add-in
Here is that icon for the Geometry add-in:

000290:   wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
0002b0:   wwwwwwwwwp...wwwwww..wwwwwwwwwww
0002d0:   wwwwwwwwp.....wwwww..wwwwwwwwwww
0002f0:   wwwwwwww..ww..wwwwp..wwwwwwwwwww
000310:   wwwwwwwp.wwww..wwwp..wwwwwwwwwww
000330:   wwwwwwwp.wwwwp.www....wwwwwwwwww
000350:   wwwwwww..wwwwp.www.wp.wwwwwwwwww
000370:   wwwwwww.wwww........p.wwwwwwwwww
000390:   wwwwwww.wwww........w.wwwwwwwwww
0003b0:   wwwwwww.wwww.w.ww...w..wwwwwwwww
0003d0:   wwwwwww.wwww.w.ww.w.wp.wwwwwwwww
0003f0:   wwwwwww..www.p.wp.w.wp.wwwwwwwww
000410:   wwwwwwwp.www.p.wp.w.ww.wwwwwwwww
000430:   wwwwwwwp.www...w..w.ww..wwwwwwww
000450:   wwwwwwww..ww..ww.ww.wwp.wwwwwwww
000470:   wwwwwwwwp.....wp........wwwwwwww
000490:   wwwwwwwwwp...wwp........wwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
0004b0:   wwwwwwwwwwww.wwwwww.wwwwwwwwwwww
000530:   wwwwwwwwwwww........wwwwwwwwwwww
000550:   wwwwwwwwwwww........wwwwwwwwwwww
000570:   wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

AngelFish · « **Reply #425 on:** February 19, 2011, 05:07:49 pm »

Quote from: Goplat on February 19, 2011, 04:05:05 pm

I notice that wiki claims that 0x0290-0x058F is garbage, but it's actually a small (64x24) black-and-white icon.

Well, some of the information on the wiki is outdated.

z80man · « **Reply #426 on:** February 20, 2011, 01:38:43 am »

Quote from: JosJuice on February 19, 2011, 01:55:17 pm

Quote from: z80man on February 19, 2011, 10:40:53 am
How that works is that every byte is added to a tally except for the four bytes at 0x20 and the last four bytes which are a copy of the checksum.
Isn't the CRC checksum ignored too when creating the 0x0020 checksum?

Actually no which makes calculating the crc even harder.

SimonLothar · « **Reply #427 on:** February 20, 2011, 04:48:58 am »

Maybe the following ones are interesting.

But be careful with these syscalls! If you write large files, the calc seems to hang, if you do not implement progress indicators. One of my testcodes wrote a 1 MB file, which took a few minutes. Resetting the calc while writing the storage memory could lead to funny results, possibly leaving the calc or at least the storage memory in a world of hurt. Backup is recommended.

syscall 0x1DAE : int Bfile_CreateEntry_OS( const unsigned short*filename, int mode, int*size );
Creates either a file or a directory in storage memory.
To create a file call 0x1DAE with size pointing to the required file size and mode = 1.
To create a directory call 0x1DAE with size = nil and mode = 5.
The length of filename must be less than h'10A, else the function returns errorcode -3.
The filename has to start with "\\fls0\" or "\\crd0\". Else errorcode -5 is returned (wrong device).
On the fx-CG20 a new file seems to be filled with zeros instead of 0xFF.

syscall 0x1DA3 : int Bfile_OpenFile_OS( const unsigned short*filename, int mode );
Opens a file in storage memory and returns either a HANDLE or an errorcode. Errorcodes are < 0.
mode:
_OPENMODE_READ 0x01 (not yet verified on the fx-CG20)
_OPENMODE_READ_SHARE 0x80 (not yet verified on the fx-CG20)
_OPENMODE_WRITE 0x02 (verified on the fx-CG20)
_OPENMODE_READWRITE 0x03 (not yet verified on the fx-CG20)
_OPENMODE_READWRITE_SHARE 0x83 (not yet verified on the fx-CG20)

syscall 0x1DA4: int Bfile_CloseFile_OS( int HANDLE );
Closes an open file in storage memory.

syscall 0x1DAF: int Bfile_WriteFile_OS( int HANDLE, const void *buf, int size );
Writes to an open file in storage memory.

JosJuice · « **Reply #428 on:** February 20, 2011, 07:07:43 am »

Interesting. This allows us to do stuff with file, right? I don't understand how you're supposed to read the data that's in files...

SimonLothar · « **Reply #429 on:** February 20, 2011, 08:11:44 am »

Quote from: JosJuice on February 20, 2011, 07:07:43 am

I don't understand how you're supposed to read the data that's in files...

It is
syscall 0x1DAC: int Bfile_ReadFile_OS( int HANDLE, void *buf, int size, int readpos );

I omitted this, because I have not verified it, yet.

SimonLothar · « **Reply #430 on:** February 20, 2011, 09:38:24 am »

Quote from: Kristaba on February 16, 2011, 12:56:22 pm

It would be annoying the Prizm processor isn't like a 7705, and I don't understand why Casio would do that

Alas, they did.
F. i. the RTC base-address h'FFFFFEC0 has been changed to h'A413FEDC.
BTW:
syscall 0x02C1 : int RTC_GetTicks( void );
Returns the RTC-basecount in units of 1/128 s.

bsl · « **Reply #431 on:** February 20, 2011, 11:14:51 am »

I am nearly in a position to patch g1a files and convert to g3a files.
Does anyone have the source basic.c to sagarvaze's advanced basic add-in ?
The source would make patching easier.

Here is the link to the download:
http://casiokingdom.org/modules.php?name=Downloads&d_op=viewdownloaddetails&cid=29&lid=535&ttitle=Basic#dldetails

Kristaba · « **Reply #432 on:** February 20, 2011, 12:32:09 pm »

Quote from: SimonLothar on February 20, 2011, 09:38:24 am

F. i. the RTC base-address h'FFFFFEC0 has been changed to h'A413FEDC.

Ok, so it look like the 7720/7721 architecture, probably without the DSP capability : http://am.renesas.com/products/mpumcu/superh/sh7700/sh7721/sh7721_root.jsp
However, I know the keyboard is connected to :
"input" (column selection I guess) from PTP0 to PTP6 (7 column, similar to the fx9860 keyboard)
"output" (row?) from PTM0 to PTM5 and from PTN0 to PTN5 (12 row, similar to the fx9860 keyboard too)
But the 7720 haven't port N, so it's probably customized by Casio.

See if you find something in the OS code using the informations in the 7720/7721 datasheet :
Ports are A, B, C, D, E, F, G, H, J, K, L, M, P, R, S, T, U, V (*no* port I and N)
Ports Control Registers start at H’A405 0100 (2 bytes per port, PMCR is H'A405 0116 and PPCR is H'A405 0118)
Ports Data Registers start at H'A405 0140 (2 bytes per port, PMDR is H'A405 0156 and PPCR is H'A405 0158)

Maybe in the Prizm CPU the port N is simply between M and P using the same starting addresses, something like :
PMDR : H'A405 0156
PNDR is H'A405 0158
PPDR is H'A405 015A

I'll try to test a code using that on the Prizm emulator if I have some time, and if I have a working IsKeyDown I'll post a new message here.

JosJuice · « **Reply #433 on:** February 20, 2011, 01:00:09 pm »

I've updated the wiki and created a "Tools" page. It contains a list of useful programs.

I've also started on a Syscalls page, but I don't know a lot about syscalls... Hopefully someone else will add more info. Most of the article is just copypaste from SimonLothar's posts.

EDIT: I also added some more info about .g3a files.

Kristaba · « **Reply #434 on:** February 20, 2011, 06:46:26 pm »

I wrote a little G3A to test the performances of the Prizm's screen :
http://www.2shared.com/file/AMshOlW5/fps.html
(@DJ_Omnimaga : this version works now

)

In a loop, my application fill the VRAM with a color, print the FPS, and call PutDisp_DD().
According to Light_Spirit, the FPS is about 21, I guess PutDisp_DD() is FPS-killer, but I don't know if we could write our own VRAMtoDD really faster.
Oh, and important detail : you need to reset your calc (soft reset, whithout data lost) to quit fps.g3a

Author Topic: Casio Prizm documentation (Read 234493 times)

z80man

Re: Casio Prizm documentation

JosJuice

Re: Casio Prizm documentation

Goplat

Re: Casio Prizm documentation

JosJuice

Re: Casio Prizm documentation

bsl

Re: Casio Prizm documentation

AngelFish

Re: Casio Prizm documentation

z80man

Re: Casio Prizm documentation

SimonLothar

Re: Casio Prizm documentation

JosJuice

Re: Casio Prizm documentation

SimonLothar

Re: Casio Prizm documentation

SimonLothar

Re: Casio Prizm documentation

bsl

Re: Casio Prizm documentation

Kristaba

Re: Casio Prizm documentation

JosJuice

Re: Casio Prizm documentation

Kristaba

Re: Casio Prizm documentation