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
106
« on: March 04, 2011, 04:00:32 pm »
I attached the current version of insight (see directory projects\insight\insight.g3a). The source and the tools to build the g3a are included, too. Only one exception: the BIN-directory of the legacy CASIO fx-9860 SDK, which is needed, is not included. EDIT: New version: http://ourl.ca/9205/182330version 1.01 removed.
107
« on: March 04, 2011, 10:48:40 am »
...but are add-ins made by the community still always appearing at the same place all the time in the menu? No. I just loaded a second copy of insight.g3a to my Prizm, using the filename insigh2.g3a and it appeared as additional item in the menu. Different filenames give different menu items, as it is with the legacy systems.
108
« on: March 03, 2011, 11:47:42 pm »
Could you also add to the C development tutorial Kristaba started earlier. There isn't enough detail to show how to set up your Prizm coding environment.
Yes. Good idea. The thread is worth to be continued. I will post my results concerning the G3A-building there. BTW: I like the mentioning of Andreas B. in this thread. Three years ago, he turned me into the right direction, concerning fx-9860G analysis. One of the most disciplined programmers I ever met. Alas, he's occupied with other things now. @cfxm We could include the insight-discussion in the same thread. I will use insight as example code for the SDK-considerations.
109
« on: March 03, 2011, 03:50:17 am »
Can you upload a version of the "toy" here, please?
Sure. As far as the restrictons of this site allow. Sure. A bit of quality assurance is still to do. I hope this weekend. BTW: you should have the BIN-directory of the old fx-9860 SDK at hand!
110
« on: March 03, 2011, 03:44:40 am »
Simon, how do you figure out all of this stuff? Do you use Insight?
As it is good cybernautical practice (GCP), I made a backup of the OS to my PC and then I started reading it. Sometimes I use insight to verify certain assumptions on-calc.
111
« on: March 03, 2011, 03:38:47 am »
@Simon Lothar I have a question. Where do you get this program http://ourl.ca/8207/177640 
Are you kidding? I wrote it!  To be serious. This version of insight is a toy, written from scratch in assembler. I hope I will soon release the C++ version incl. source and some maybe interesting additional tools (f. i. a syscall library).
112
« on: March 03, 2011, 02:25:32 am »
Hmm... I wonder why the OS even addresses a low backup battery issue then.
The message can be found at 0x801094E0 for all those who are interested.
Very probably they reused a lot of source-code of the legacy systems, contaminated by some code pieces, which are not used by the Prizm OS. BTW: the battery is still monitored using the MPU's AD-Converter channel A. But the address of ADC_ADDRA is 0xA4610080, hence it is neither a 7705- nor a 7200-register. The functionality seems to be similar, if not identical compared to the ADC of the 7705/7200. In legacy systems with backup battery , the ADC-channel C has been used, to monitor the backup-battery. The Prizm's GetBatteryVoltage syscall shows no signs of accessing channel C.
113
« on: February 26, 2011, 03:34:29 am »
Someone PMed and asked me to provide for a syscall tutorial.
I don't know, how detailed it has to be. So, the short form for a start.
F. i. GetKey, the blocking keyboard read function:
interface: int GetKey( int*keycode );
For details of GetKey refer to fx-9860G Libraries.pdf, which is included in the fx-9860G SDK.
On the fx-CG the underlying syscall is 0x0EAB.
Implementation as inline code for the use in assembler:
add #-4, r15 ; create local workspace
mov.l #h'0EAB, r0 ; 0x0EAB waits, until a key is pressed (blocking)
mov.l #h'80020070, r2
jsr @r2
mov r15, r4 ; pass the parameter *keycode
mov @r15, r4 ; copy keycode* to r4 for further processing
add #4, r15 ; free local workspace
Implementation as assembler-function for the use in C/C++:
.export _GetKey
_GetKey:
mov.l #h'0EAB, r0
mov.l #h'80020070, r2
jmp @r2 ; mind the difference between jsr (see above) and jmp!
nop ; edited
Mind to precede the function name with an underscore. When calling from out of C/C++ the underscore must be omitted.
If you use a syscall inside of an assembler program, you have to setup the parameter-frame yourself.
The C/C++-compilers provide for that automatically.
The parameter passing in SuperH systems is documented in f. i. SHC Manual.PDF, which is included in the fx-9860G SDK.
If you want to build a syscall library, the following MACRO could be of help:
.MACRO BIOS_JUMP FUNO, SYSCALLNAME, TAIL=nop
.export \SYSCALLNAME'
\SYSCALLNAME'
mov.l #h'\FUNO, r0
mov.l #H'80020070, r2
jmp @r2
\TAIL'
.ENDM
; so your minimum syscall library source needs one line per syscall only
BIOS_JUMP 0EAB, _GetKey
BIOS_JUMP 18F9, _PrintXY
BIOS_JUMP 0272, _Bdisp_AllCr_VRAM
BIOS_JUMP 025F, _Bdisp_PutDisp_DD
BIOS_JUMP 1348, _WordToHex
the interfaces:
void PrintXY( int x, int y, char*string, int mode, int color );
x and y in text-cursor coordinates;
the first two chars of *string are ignored (the reason of which will be unravelled later, hopefully)
mode (bit-field) = 1: writes the string in reverse
mode (bit-field) = 0x20: does not overwrite the background
color=0: black; color=1: blue; color=2: green; color=3: cyan; color=4: red; color=5: magenta; color=6: yellow; color=7: none
void Bdisp_AllCr_VRAM( void );
void Bdisp_PutDisp_DD( void );
void WordToHex( unsigned short value, unsigned char*buffer );
value: value to convert into a displayable 4-char hex-string
buffer: buffer to receive the string (size 5)
The use of PrintXY inside of an assembler source is a bit complicated:
mov.w #h'00, r5
mov.l r5, @-r15 ; the 5th parameter has to be passed on the stack
mov #4, r5 ; y
mov.l #XTEST, r6 ; this would be the pointer to a string
mov #5, r4 ; x
mov.l #h'18F9, r0
mov.l #h'80020070, r2
jsr @r2
mov #h'00, r7 ; deletes the background
add #4, r15 ; readjust the stack due to the 5th parameter
; example source: this code has been assembled, linked and successfully run on a fxCG 20!
.MACRO BIOS_JSR FUNO, TAIL=nop
mov.w #h'\FUNO', r0
mov.l #h'80020070, r2
jsr @r2
\TAIL'
.ENDM
LOCAL_WORKSPACE .EQU h'1000
program_entry:
; start of a minimum syscall tutorial example
mov.l r14, @-r15 ; the amount of registers to push onto the stack depends on the requirements of the function
; always be sure to push any of R8..R14, which the function uses.
mov.l r13, @-r15
mov.l r12, @-r15
sts.l pr, @-r15
; pr should be pushed in every subroutine, even, if it does not bsr or jsr.
; the day will come, when you implement some bsr and jsr inside of the function and you forget to push pr
mov.l #-LOCAL_WORKSPACE, r3
add r3, r15
; at first clear the VRAM
BIOS_JSR 0272
; transfer the VRAM to the display driver (though it is not necessary in this case, 0EAB provides for that, too)
BIOS_JSR 025F
main_loop:
; now wait for key-input (blocking)
add #-4, r15 ; create a local workspace
mov r15, r4 ; setup the function's parameter: pointer to keycode
BIOS_JSR 0EAB
mov @r15, r13 ; save the keycode for later use
add #4, r15 ; free the local workspace
; now you have to decide, what do do
; first we need a bit of workspace
add #-h'10, r15
mov r15, r12 ; save the pointer to that workspace for a rainy day
; initialize the workspace (don't care, skip it while reading)
mov r12, r5
mov.l #h'01010101, r0
mov.l r0, @r5
add #4, r5
mov #0, r0
mov.l r0, @r5
add #4, r5
mov.l r0, @r5
add #4, r5
mov.l r0, @r5
; now let's convert keycode to something displayable
mov r12, r5
add #2, r5 ; we have to skip two bytes because of a special feature of syscall 18F9
mov r13, r4 ; fetch the previously saved keycode
BIOS_JSR 1348 ; syscall WordToHex
; let's display the keycode
mov.w #h'01, r5
mov.l r5, @-r15 ; color
mov #1, r5 ; y
mov.l r12, r6
mov #h'00, r7 ; deletes the background
mov #1, r4 ; x
BIOS_JSR 18F9
add #4, r15 ; adjust the stack for the 5th parameter
add #h'10, r15 ; free the workspace
bra main_loop
nop
; though this program won't ever quit, the proper finalization code is appended anyhow, as reference.
; BTW: h'0EAB is aware of the MENU-key, so it is not necessary to quit the program with the RESTART button
mov.l #LOCAL_WORKSPACE, r3
add r3, r15
lds.l @r15+, pr
mov.l @r15+, r12
mov.l @r15+, r13
rts
mov.l @r15+, r14
; end of a minimum syscall tutorial example
114
« on: February 25, 2011, 04:02:26 pm »
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)
I could not verify this, sry. What I found is the following: the keyboard matrix is represented by the word-registers h'A44B0000, h'A44B0002, h'A44B0004, h'A44B0006, h'A44B0008, h'A44B000A. Every single bit seems to be directly connected to a key. So there is no matrix-scanning any more. Every byte represents a row (exception as always: AC/ON). Another great benefit compared to the legacy systems: you can detect any key-combination at a time! I will add a keyboard-port-view-option in the next version of insight.g3a to visualize the key-to-bit relation. EDIT: On th fx-9860 there are the contacts (P103) and (P104) (on the PCB), which are integrated in the keyboard matrix. They are used to invoke some diagnostic mode and the os update. On the fxCG's PCB we have the contacts (1), (2) and (3). These are integrated in the keyboard as well. F. i. (3) invokes the os update. (1) = h'0800 (port h'A44B000A) (2) = h'0400 (port h'A44B000A) (3) = h'0200 (port h'A44B000A) BTW: (P301) does not seem to be integrated in the keyboard.
115
« on: February 25, 2011, 01:08:38 am »
Ok, so it look like the 7720/7721 architecture...
A very important and valuable hint, THX. Perhaps they changed to the 7720, because it contains a LCD-controller... BTW a correction: of course, the RTC base-address is h'A413FEC0. I missed a little add #-h'1C....
117
« on: February 20, 2011, 09:38:24 am »
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.
118
« on: February 20, 2011, 08:11:44 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.
119
« 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.
120
« on: February 19, 2011, 09:08:28 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. Then, do you progressed about the keyboard mapping comprehension?
I wrote a FastGetKey for fx9860... What I know is, that the keyboard-scanning is very similar to the legacy-systems, the matrix-codes are very similar, maybe identical. But I suspect, they do not use port A, B, M any more, but one of the customized (hence undocumented) ports. At present I'd rather rely on GetKeyWait as non-blocking keyboard reader. The KeyMapper syscalls 0x0E96 and 0x0E97 transfer matrixcodes to keycodes. And finally, I don't understand what the syscall you call "GetVRAMBackgroundAddress" is. There are two VRAM? So what is copied to DD when "VRAMtoDD" is called?
The VRAMBackgroundAddress is an address inside of the VRAM. It is the address, where the background-image is copied to (immediately below the header-status-line). F. i. if you open the main menu item "Program" you see the green image of a laptop in the background. This image starts at VRAMBackgroundAddress. VRAMtoDD transfers the whole 0x28800 VRAM to the display driver. I'll rename it to "Bdisp_PutDisp_DD".
|
Show Posts