Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - SimonLothar

Pages: 1 2 3 [4] 5 6 ... 9
46
Casio Calculators / Re: [PRIZM] Font hacks
« on: February 11, 2012, 11:22:01 am »
The fonts are stored in the flash

f.i.
8045E972                 .data.w 0               ; ................
8045E974                 .data.w 0               ; ................
8045E976                 .data.w h'F80           ; ....*****.......
8045E978                 .data.w h'1FC0          ; ...*******......
8045E97A                 .data.w h'1EC0          ; ...*******......
8045E97C                 .data.w h'1E00          ; ...****.........
8045E97E                 .data.w h'7FC0          ; .*********......
8045E980                 .data.w h'7FC0          ; .*********......
8045E982                 .data.w h'1E00          ; ...****.........
8045E984                 .data.w h'1E00          ; ...****.........
8045E986                 .data.w h'1E00          ; ...****.........
8045E988                 .data.w h'1E00          ; ...****.........
8045E98A                 .data.w h'1E00          ; ...****.........
8045E98C                 .data.w h'7FC0          ; .*********......
8045E98E                 .data.w h'7FC0          ; .*********......
8045E990                 .data.w 0               ; ................
8045E992                 .data.w 0               ; ................

So I think you have to write the flash, if you want to change them.
That seems to be no problem...technically.
Alas, when developing flash writing routines, the calculator enters a world of hurt, sometimes. :angel:
Unavoidable, due to human failure. :banghead:
Hence you need secure recovery procedures.
As far as I am concerned, I have not started this project for the prizm. Not yet.
But though I walk through the valley of deep darkness, I fear no harm...
up to now I resurrected every single one of my beloved fx-guinea-pigs, which has been killed in action. ;D

47
Casio Calculators / Re: Prizm IO Hardware - What is known?
« on: February 10, 2012, 11:36:48 am »
Quote
...Do you plan any update of your documents / SDK?
Have been occupied with the GII-2. Prizm-Hardware (except the display, of course) and GII-OS. Kinda missing link. Most interesting. Had to update pfxRecover. THX to cfxm, who never seems to loose patience while testing. I have to tidy up the news. Than I will add it to the documentation.

48
Casio Calculators / Re: Prizm IO Hardware - What is known?
« on: February 09, 2012, 11:48:32 am »
See fx_calculators_SuperH_based_10.chm
(http://ourl.ca/8207/238670).

Try topic: fx-CG20...Registers, MPU...Accessing the 3pin serial lines directly

That's what I found.
 

49
Casio Calculators / Re: Prizm C Q&A thread
« on: November 03, 2011, 02:23:59 am »
Why don't we have access to screen border?
You have. See syscalls 0x02A4 to ox02AA (especially 0x02AA).

50
Casio Calculators / Re: Prizm Useful Routines -- post here!
« on: September 07, 2011, 12:42:13 pm »
In Simon's random routine he used a static seed to contribute to the result which increased randomness.
I did not invent the random routine you referred to. It uses the same algorithm as the one of the old CASIO SDK or the hitachi compiler's libraries (I only translated it to C). Therefor I think you are right. The randomness must be well balanced.

51
Casio Calculators / Re: Prizm C Q&A thread
« on: September 05, 2011, 04:11:31 pm »
What LCD controller does it use?
Obviously a customized one, but similar to some renesas LCD controllers:
http://ourl.ca/8207/232704
Some additional information is gathered in
fx_calculators_SuperH_based_10.chm

52
Casio Calculators / Re: Prizm File I/O Problems
« on: September 05, 2011, 04:07:13 pm »
If Bfile_OpenFile_OS and Bfile_CreateEntry_OS, which you use, are based on the corresponding syscalls, you have to use a short array to pass the filename.
You could use
syscall 0x1DDC: void Bfile_StrToName_ncpy( unsigned short*dest, const unsigned char*source, int n );
to copy a string constant into a short array.
Refer to fx_calculators_SuperH_based_10.chm: the BFile syscall section for details.
I am surprised, that the compiler does not complain about:
Bfile_OpenFile_OS("\\\\fls0\\city.pcc", 0x03);


53
Casio Calculators / Re: [SDK] IsKey too slow...
« on: August 31, 2011, 10:55:47 am »
No said about the Prgm Syscall! With a friend we could use your function to make  function like FastKeyDOwn. But why sometimes the calculator show me an reboot? (On sdk, error FFFFFF8)
Post the source, please.

54
Casio Calculators / Re: Prizm C Q&A thread
« on: August 31, 2011, 08:44:49 am »
You could use the following syscalls:

write a pixel to VRAM:
0x0263
void Bdisp_SetPoint_VRAM( int x, int y, unsigned short color );

directly draw a pixel:
0x026B
void Bdisp_SetPoint_DD( int x, int y, unsigned short color );

read the keyboard (blocking):
0x0EAB
int GetKey( int*key );

read the keyboard (non-blocking):
0x12BF 
int GetKeyWait_OS(int*column, int*row, int type_of_waiting, int timeout_period, int menu, unsigned short*keycode );

These are only examples for a start.

It is possible to read the keyboard-registers directly, to gain speed, if necessary.
Or you can write to VRAM by simple memory-write-operations.
I recommend the use of syscalls as much as possible.
Especially there are some drawing-syscalls, which save a lot of source code and coding time.



55
Casio Calculators / Re: Casio Prizm documentation
« on: August 27, 2011, 06:08:09 pm »
Same here, I get a "Navigation to webpage was cancelled" error.
Usually this is a security problem.
If the CHM-file resides on a local drive, move the chm-file from the download directory to a directory with sufficient access rights.
If the CHM-file resides on a network drive, the following registry value could be missing
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions
DWORD-value MaxAllowedZone = 1



56
Casio Calculators / Re: Casio Prizm documentation
« on: August 27, 2011, 06:39:54 am »
It seems to be reasonable to publish "fx_calculators_SuperH_based.chm" here, separated from the "mini SDK".

Version 10 removed.
broken link to Version 11 removed.

new: http://ourl.ca/8207/311914

57
Casio Calculators / Re: [SDK] IsKey too slow...
« on: August 20, 2011, 06:38:00 am »
I want to find anything to avoid using IsKeyXX functions, there are really too slow.
If you inspect the syscall documentation included in my Prizm mini SDK, you will find the legacy syscall
0x06C4 int Keyboard_PRGM_GetKey( TBCDvalue*result );
Perhaps it is fast enough.

If not:

I used the following code as fast non-blocking keyboard read a long time ago (before I decided to use Keyboard_PRGM_GetKey)
It demonstrates the register-based keyboard read on the legacy systems.

Code: [Select]
void delay( void ){
int i;
  for (i=0;i<5;i++){};
}

//
int CheckKeyRow( int row ){
int result=0;
short*PORTB_CTRL=(void*)0xA4000102;
short*PORTM_CTRL=(void*)0xA4000118;
char*PORTB=(void*)0xA4000122;
char*PORTM=(void*)0xA4000138;
char*PORTA=(void*)0xA4000120;
short smask;
char cmask;

  smask = 0x0003 << ((row%8)*2);
  cmask = ~( 1 << (row%8) );
  if (row<8){
// configure port B as input, except for the "row to check"-bit, which has to be an output.
    *PORTB_CTRL = 0xAAAA ^ smask;
// configure port M as input; port M is inactive with row < 8                                                        
    *PORTM_CTRL = (*PORTM_CTRL & 0xFF00 ) | 0x00AA;
    delay();
    *PORTB = cmask;    // set the "row to check"-bit to 0 on port B
    *PORTM = (*PORTM & 0xF0 ) | 0x0F;    // port M is inactive with row < 8
  }else{
    *PORTB_CTRL = 0xAAAA;  // configure port B as input; port B is inactive with row >= 8
// configure port M as input, except for the "row to check"-bit, which has to be an output.
    *PORTM_CTRL = ((*PORTM_CTRL & 0xFF00 ) | 0x00AA)  ^ smask;
    delay();
    *PORTB = 0xFF;    // port B is inactive with row >= 8 (all to 1)
    *PORTM = (*PORTM & 0xF0 ) | cmask;  // set the "row to check"-bit to 0
  };
  delay();
  result = ~(*PORTA);   // a pressed key in the row-to-check draws the corresponding bit to 0
  delay();
  *PORTB_CTRL = 0xAAAA;
  *PORTM_CTRL = (*PORTM_CTRL & 0xFF00 ) | 0x00AA;
  delay();
  *PORTB_CTRL = 0x5555;
  *PORTM_CTRL = (*PORTM_CTRL & 0xFF00 ) | 0x0055;
  delay();

  return result;
}


58
Casio Calculators / Re: Casio Prizm documentation
« on: August 04, 2011, 12:51:28 pm »
A few more datasheets: http://www.trulydisplays.com/tft/index.html
The R61526 and R61580 have a backlight control unit.
These findings give additional clues to understand the LCD controller of the Prizm.
The R61526 and the R61581 are completely new developments (2010). Their register patterns do not fit.
Though, the manuals could help to understand the way of modern LCD controllers.
The R65180 and the R61505 are intermediate developments (2009).
Their register numbers are a bit different to these of the R61509 (R61524), but the register descriptions match
and "used bits patterns" match too (especially in case of the gamma-control registers).

59
Casio Calculators / Re: Casio Prizm documentation
« on: August 03, 2011, 03:29:40 am »
The Prizm's LCD controller:
the renesas R61509 register pattern is a subset of the Prizm LCD controller's register set. On receiving a "Device code read (R000h)", the controller identifies itself as "renesas R61524", a manual of which could not be found yet. Moreover the term "renesas R61524" not even gives any response on the web. I fear this one is customized again. Luckily the manual of the renesas R61509 is available and covers most aspects of the Prizm LCD controller. Though, the R61509 has no backlight support. Hence some registers (f. i. h'5A1 or h'5A2) are not covered in the R61509 documentation. The renesas R61517 is a type with backlight control and would fit better. The are a lot of responses on the web, when "renesas R61517" is queried. :D But I could not find a manual yet. :(

60
Casio Calculators / Re: Compiling stuff for Prizm
« on: July 29, 2011, 07:32:20 am »
Here are more unconfirmed calls.
The sprintf routine is not a syscall, so its OS dependent.
I will try this myself in a couple weeks, it looks too useful even if its not sprintf.(vsprintf ?)
Code: [Select]
MMU_FlushCache?               0011
Disp_Manage?                  0276
Disp_Save?                    0278
Disp_GetPtr?                  027A
Num_UintToBCD                 0577
Num_BCDToUint                 0578
strlen?                       060D
strcpy?                       060E
strcat?                       060F
is_comma                      07BD
Bkey_GetkeyTableInfoJumpFunc  0EAE
Expressions_OpcodeToStr?      1291
LocalizeStringID              12FD or 12FC
MCS_DirtypeToItemtype?        1549
MCS_ItemtypeToDirtype?        154A
MCS_OpenAlphaMemItem??        1553
NextOPcodePRGM                1749
MCS_Flush                     1845
Send38k                       198A
Receive38k                    198B
OpenCloseComPort38k           198C
Battery_IsLow?                1e72
GetIntPtrContent?             1E7D
GetdatatablePtr?              1E80
SetAppName?                   1E9E

sprintf??? -- non-syscall  --> (OS1.01:0x80309604, OS1.02:0x803093A0), use function pointer   

I could verify most of your assumptions.
Exceptions:
Disp_Manage?                  0276 (Bdisp_Fill_DD(color,mode), directly draws one of three predefined color-filled rectangles)
Disp_Save?                    0278 (Bdisp_Fill_DD_1(color) calls Bdisp_Fill_DD(color,1))
Disp_GetPtr?                  027A (Bdisp_Fill_VRAM_2(color) calls Bdisp_Fill_VRAM(color,2))
Bkey_GetkeyTableInfoJumpFunc  0EAE (verified, returns the pointer to some keycode table)
MCS_Flush                     1845 (checks the six MCS backup areas in the flash for some yet unknown purpose)
Send38k                       198A (verified, serves both commands Send and Send38k)
Receive38k                    198B (verified, serves both commands Receive and Receive38k)
GetdatatablePtr?              1E80 (returns the number of installed languages)


Pages: 1 2 3 [4] 5 6 ... 9