How To Code The 9860 In Assembler
#1
Posted 31 May 2007 - 09:38 AM
This topic is intended to collect information about programming the SH3 processor in assembler and using the calculators
full capabilities. Links, tips and code snippets are welcome.
I don't want this programming to be a secret only a few can do. Though the concerns of code stealing are valid I would like to
ask anyone to give credit where credit is due and this does not only mean when you use someones code but also when you
use information that were discovered by someone else. Don't be so stingy with credit! It costs you nothing, but returns you respect
and more information that could be usefull in the future.
For a starter: The SH3 is a pretty wicked architecture with its delayed branching/jumping and its strange move commands.
But here is a good read to get into it:
http://www.elenota.p...0317_sh_3sm.pdf
I already found out, that the assembler as does support the SH3 CPU. Here is the link to documentation and download:
http://john.ccac.rwt...hen.de:8000/as/
I also tried to write a disassembler but due to the strange nature of the CPU it is quite difficult to calculate branches and follow the program flow. For now it can only decode a single instruction. You enter the 16-bit hex code and it returns you the corresponding command.
It also tries to deode binary files but it is not very successfull as soon as it comes to branchin / jumps
If there is interrest in it I can publish it (including the sources).
Also I will try to write a headder creator during the next few days so that you can upload your files to the calculator. The headdermaker included with the SDK requires some strange files not needed in my opinion.
So let the games begin! Please help us in creating the best add ins possible.
(even if you don't use external assemblers, the inline assembler would also be nice to get to work, but it doesnt seem to want to work at the moment... the #pragma inline_asm (function) statement does not seem to work with the SDK )
... hope to hear from all of you soon...
#2
Posted 31 May 2007 - 01:36 PM
I don't want this programming to be a secret only a few can do. Though the concerns of code stealing are valid I would like to
ask anyone to give credit where credit is due and this does not only mean when you use someones code but also when you
use information that were discovered by someone else. Don't be so stingy with credit! It costs you nothing, but returns you respect
and more information that could be usefull in the future.
I'll make this deal with you: I probably have figured out much more about the fx-9860 than anyone else in the community. I'll make everything I know public (how to write in assembly, LCD, serial ports, memory, etc.), under the condition, that if anything is derived from my work than it's to be added to the EPSILON hardware project. For example, if grayscales are created from my notes about the LCD when I make it public, then I have the right to add it to the EPSILON project. The EPSILON project still will remain free for anyone to use in their projects, games and programs. I would also like that when EPSILON is made open-source, I would like to ask for developers to help me out. That's all I ask. This is the best idea I could only come up with that I would think satisfy all us.
I might as well do this. At least I can be remembered for doing something good and contributing something really big (Hopefully, I don't want to be forgotten.....). But first, I must get community approval from all of you on my idea. Why do you guys think?
#3
Posted 31 May 2007 - 02:06 PM
I am for it. All my code has always been and will always be published. I can also discover all this myself (or at least lots of it) but it would take
needless much time.
I would wait for vanhoas reply since he seems to be the only one at present who is interested in programming the 9860 seriously.
In the meantime (to the others interested):
using "as" you can write the folowing "sample" program:
CPU SH7700 SEGMENT code rts nop
this does nothing but return cleanly to the main menu. It is compiled with the folowing commands (after downloading "as"):
as filename.asm
p2bin filename.p
then you just have to add the header. I might publish a "header creator" today or at latest on saturday.
Please everyone respect kucalc and the great work he has done. Make it possible for the community to create great programs by working
together and giving credit. Don't steal sources but use them and give credit and respect and let others use your works too!
I'm an admin here and as such I have some special privileges. And if it is the only way to bring some activity and creativity back to the forum
then I do now anounce the folowing:
If I every find anyone deriving work from EPSILON, or kucalcs discoveries (that he is about to present) without giving the sources AND/OR giving
credit then this one shall be banned from the forum for 1 week. If I find the same offense done again the ban will last 1 month. And at a third time
the ban will be a 9 month ban.
If kucalc presents his work here he does so under a license (nothing else are the conditions he tells and he does this rightfully because he spent the time and it is HIS work) and this needs to be respected. If it is not by pure respect then I will surely enforce it!
#4
Posted 31 May 2007 - 02:33 PM
All of my addins source for fx-9860 have ben public.
The things I know about "fx9860's hardware programing" is changing the speed of calc and SH3Timer:
http://pv-s1600.da.ru/doc/SH7705V1.ZIP SH7705V1.PDF :
9.4.1 Frequency Control Register (FRQCR)
The frequency control register (FRQCR) is a 16-bit readable/writable register used to specify whether a clock is output from the CKIO pin, the on/off state of PLL circuit 1, PLL standby, the frequency multiplication ratio of PLL circuit 1, and the frequency division ratio of the internal clock and the peripheral clock. Only word access can be used on FRQCR. As for the combination of the clock rate, refer to table 9.3, Possible Combination of Clock Modes and FRQCR Values.
The combinations listed in table 9.3 should only be set on FRQCR.
15 to 13 ? All 0 R Reserved
These bits are always read as 0. The write value should always be 0.
12 CKOEN 1 R/W Clock Output Enable
Specifies to output a clock from the CKIO pin or to fix the CKIO pin low when software standby is canceled (after an interrupt before STATUS1 becomes low and STATUS0 becomes low). The CKIO pin is fixed low during STATUS1 = low and STATUS0 = high, when the CKOEN bit is cleared to 0. Therefore, the malfunction of an external circuit because of an unstable CKIO clock in releasing software standby mode can be prevented. In clock operating mode 7, the CKIO pin is in the input state regardless of this bit.
0: Fixes the CKIO pin low in software standby mode.
1: Outputs a clock from the CKIO pin.
11, 10 ? All 0 R Reserved
These bits are always read as 0. The write value should always be 0.
9 STC1
8 STC0
Frequency Multiplication Ratio
00: ? 1 time
01: ? 2 times
10: ? 3 times
11: ? 4 times
7, 6 ? All 0 R Reserved
These bits are always read as 0. The write value should always be 0.
5 IFC1
4 IFC0
Internal Clock Frequency Division Ratio
Specify the frequency division ratio of the internal clock with respect to the output frequency of PLL circuit 1.
00: ? 1 time
01: ? 1/2 time
10: ? 1/3 time
11: ? 1/4 time
3, 2 ? All 0 R Reserved
These bits are always read as 0. The write value should always be 0.
1 PFC1
0 PFC0
Peripheral Clock Frequency Division Ratio
Specify the frequency division ratio of the peripheral clock with respect to the output frequency of PLL circuit 1.
00: ? 1 time
01: ? 1/2 time
10: ? 1/3 time
11: ? 1/4 time
And I also have the address of VRAM of fx-9860 (the vaule is different between PC and calc). I dont have the calc so i'm not so interesting in finding others...
#5
Posted 31 May 2007 - 02:39 PM
Requiring exclusive rights to your discoveries, is a bit selfish (_I think_). _If_ you want to make the software 'open source', it should be possible for others to fork the project, but they must /of course/ credit the original source. Denying commercial use is also understandable.
A great thing would be to keep the development of new software open to the community, to let others understand and be able to contribute more easily than they can with a blob of a binary library. Don't think that I don't appreciate or respect your work, kucalc - my point is that more progress will be made if source code or documentation is released
http://xfer9860.sourceforge.net/doc/
#6
Posted 31 May 2007 - 02:45 PM
Thanks for your replies (and for the code and the explanation vanhoa!)
Also I didn't know about your site Andreas. Would you like to be added to the link section of casiocalc.org?
Thanks a lot for your replies. I hope we will soon have set the differences aside and begin making the greatest
programs for the 9860 ever seen (*enthusiastic*)
#7
Posted 31 May 2007 - 02:55 PM
Sure, but just add the link to the documentation. No need to link to the project (http://xfer9860.sourceforge.net/) quite yet, as it is barely functional and is based on stuff not yet in the documentation.Also I didn't know about your site Andreas. Would you like to be added to the link section of casiocalc.org?
Edit: I also think that the number one priority except from hacking the hardware/OS, is making a decent CAS.
#8
Posted 31 May 2007 - 03:02 PM
#9
Posted 31 May 2007 - 03:03 PM
http://ix.ipn.ru/cas...velop/sh3_h.zip
Next post I may talking more about SH3 Timers. (3 total)
#10
Posted 31 May 2007 - 03:43 PM
#11
Posted 31 May 2007 - 03:54 PM
#12
Posted 31 May 2007 - 04:22 PM
#13
Posted 31 May 2007 - 04:47 PM
Though I must admit, that the SH3 assembler code is quite ... well ... queer ...
(they have delayed jumps and some really strange commands ...)
#14
Posted 31 May 2007 - 05:32 PM
I prefer programming in assembly to C and I have some experience with different assembly languages but after having a look at the SH3, I have to confirm your impression.
#15
Posted 31 May 2007 - 07:22 PM
@ huhm_n: nice to see you back!!! (off topic but I'm curious): do you intend to continue mlc2 on afx one of this day...
ps: nice to see that people will work "hand in the hand" (don't know if this expression exist in english)
#16
Posted 01 June 2007 - 02:10 AM
*Sigh* I think I am the only person who can help you huhn_m. I don't think anyone else knows how to program the fx-9860 in assembly. But I can make that change also...
I'll make this deal with you: I probably have figured out much more about the fx-9860 than anyone else in the community. I'll make everything I know public (how to write in assembly, LCD, serial ports, memory, etc.), under the condition, that if anything is derived from my work than it's to be added to the EPSILON hardware project. For example, if grayscales are created from my notes about the LCD when I make it public, then I have the right to add it to the EPSILON project. The EPSILON project still will remain free for anyone to use in their projects, games and programs. I would also like that when EPSILON is made open-source, I would like to ask for developers to help me out. That's all I ask. This is the best idea I could only come up with that I would think satisfy all us.
I might as well do this. At least I can be remembered for doing something good and contributing something really big (Hopefully, I don't want to be forgotten.....). But first, I must get community approval from all of you on my idea. Why do you guys think?
Kucalc I'm really glad hearing you are going to open the source for your code-... AT LEAST . I think you should take your time and read some of the open source licenses. Some of the license has as one of it's requirements to add credits to the original writer I think BSD is one of those.
Anyway I'm glad to hear your decistion, and count with me if you need something (if I can make my time hehe, I have all the finals now )
Cheers,
Manuel
/*JOKE
PD: Hey I want my part of the credit too . I helped you a bit with your startings into sh3 assembler, after all who was the one who disturbed you in the MSN while you were trying to achieve something?
*/
#17
Posted 01 June 2007 - 02:44 AM
Thanks.
-->
A great thing would be to keep the development of new software open to the community, to let others understand and be able to contribute more easily than they can with a blob of a binary library. Don't think that I don't appreciate or respect your work, kucalc - my point is that more progress will be made if source code or documentation is released [/quote]
I don't think you understood what I said earlier. I said EPSILON will become open-source. You can "fork" new projects from it, but what I'm asking is that you give credit (cite your sources) and if something is accomplished off my notes that I have the right to also include it in EPSILON so the EPSILON project can live on.
[quote name='Manuel Naranjo' post='40850' date='May 31 2007, 07:10 PM']Kucalc I'm really glad hearing you are going to open the source for your code-... AT LEAST . I think you should take your time and read some of the open source licenses. Some of the license has as one of it's requirements to add credits to the original writer I think BSD is one of those.
Anyway I'm glad to hear your decistion, and count with me if you need something (if I can make my time hehe, I have all the finals now )[/quote]
I'll take some look at some licenses or I can use the good ol' "kucalc License".
[quote name='Manuel Naranjo' post='40850' date='May 31 2007, 07:10 PM']/*JOKE
PD: Hey I want my part of the credit too . I helped you a bit with your startings into sh3 assembler, after all who was the one who disturbed you in the MSN while you were trying to achieve something?
*/[/quote]
Lol, ok sure.
Well then, I start the "The fx-9860 Bible" project. It's a document that contains everything I know about the fx-9860, not just the CPU, but accessing the DD, key input, memory, etc.
#18
Posted 01 June 2007 - 01:24 PM
0000: 14 Bytes 0xAAAC 0xBDAF 0x9088 0x9A8D 0x0CFF 0xEFFF 0xEFFF - Actuall Headder 000E: 11 Bytes ? - Copy Protection 0015: 07 Bytes 0x00h - Filler (?) 0020: 01 Bytes @ (0x40h) - Indicates beginning of Name 0021: 8 Bytes * - Name (needs to be equal to file name without the .g1a) 0020: 2 Bytes 0x00h - Filler 002B: 1 Byte Number of eActivity Strips (0-4) 002C: 4 Byte 0x00h - Filler 0030: 10 Bytes ??.??.???? - Version 003A: 02 Bytes 0x00h - Filler 003C: 14 Bytes ????.????.???? - Date (YYYY.MMDD.HHMM) 004A: 02 Bytes 0x00h - Filler (?) 004C: 68 Bytes * - Bitmap (for menu)If eStrip 1 is enabled (count >=1) then the folowing, else everything mentioned here 0x00
0090: 16 Bytes - Name 1 00A0: 20 Bytes - 0x00 Filler 00B4: 44 Bytes - Small Bitmap (eBitmap 1)
If eStrip 2 is enabled (count >=2) then the folowing, else everything mentioned here 0x00
00E0: 16 Bytes - Name 2 00F0: 20 Bytes - 0x00 Filler 0104: 44 Bytes - Small Bitmap (eBitmap 2)
If eStrip 3 is enabled (count >=3) then the folowing, else everything mentioned here 0x00
0130: 16 Bytes - Name 3 0140: 20 Bytes - 0x00 Filler 0154: 44 Bytes - Small Bitmap (eBitmap 3)
If eStrip 3 is enabled (count >=3) then the folowing, else everything mentioned here 0x00
0180: 16 Bytes - Name 4 0190: 20 Bytes 0x00 - Filler 01A4: 44 Bytes - Small Bitmap (eBitmap 1)
The rest is again valid for all files:
01D0: 4 Bytes 0x00 - Filler 01D4: 8 Bytes * - Name 01DC: 20 Bytes 0x00 - Filler 01F0: 4 Bytes - Filesize (Total) 01F4: 12 Bytes 0x00h - Filler (?)
Thats everything I figured out. Except the copy protection everything is fine
just replace the AAAC in the header with ACAC (in the very beginning) and this prevents the "copy protection error".
Don't ask me how this stupid protection works
#19
Posted 01 June 2007 - 02:21 PM
i know, i know ... i doublepost ...
Here is the add in creator:
This program creates headers for binary programs for the FX-9860.
The G1A files created by the program should be valid
(though they not 100% conform to the casio standard) and are loaded
by FA-124 and also transfered to the calc.
The program takes binary files as created by the assembler "as" and the
included tool "p2bin" as input and outputs the G1A file after asking for some
information like the version or the programs name.
HOWEVER! The icon editor is not yet implemented. All icons are just made
black. I'll try to do the icon editor this evening or tomorrow
Have fun and report bugs in the forum
it is ? 2007 by huhn_m. Sources will be included in the version with the icon editor!
#20
Posted 01 June 2007 - 08:12 PM
Function numbers seem to be given through the R0 register. For example i think the folowing should be valid:
Function Number: 0x146 (R0) Function Description: Set Pixel to VRAM Function Arguments: r4 := x r5 := y r6 := 1 = black / 0 = whiteThis is a complete functions description. The trick is now to get the sources of the 0x80010070 location so that we can disassemble
the operationg system functions and get REAL direct hardware access.
The same parameters are valid for setting the pixel on the DD (driver), but the function number is 0x147.
For setting both at the same time the function number is 0x148.
Do you want me to document all those functions? It should not be too difficult .... But the main goal is to get THEIR source code, so
we can get hardware access.
#21
Posted 01 June 2007 - 09:47 PM
Finding out what makes them work is the interesting part. When that is done - we can make our own open implementation, and focus more on documenting that.
#22
Posted 02 June 2007 - 08:01 AM
The Operatingsystem Functions seem to reside at 0x80010070 hex.
Function numbers seem to be given through the R0 register. For example i think the folowing should be valid:Function Number: 0x146 (R0) Function Description: Set Pixel to VRAM Function Arguments: r4 := x r5 := y r6 := 1 = black / 0 = whiteThis is a complete functions description. The trick is now to get the sources of the 0x80010070 location so that we can disassemble
the operationg system functions and get REAL direct hardware access.
The same parameters are valid for setting the pixel on the DD (driver), but the function number is 0x147.
For setting both at the same time the function number is 0x148.
Do you want me to document all those functions? It should not be too difficult .... But the main goal is to get THEIR source code, so
we can get hardware access.
I dont think so. look at the disassembled code and see this at the address of _Bdisp_PutDisp_DD:
_Bdisp_PutDisp_DD: D2D1: mov.l @(H'004,pc),r2; D002: mov.l @(H'008,pc),r0; 422B: jmp @r2 ; 0009: nop ; 8001: mov.b r0,@(H'1,r0);r0++ 0070: ???? ; 0000: ???? ; 0028: clrmac ;
after execute 422B, it jumped to the address 0x80010070:
D202: mov.l @(H'008,pc),r2; 4008: shll2 r0 ; 002E: mov.l @(r0,r2),r0; 402B: jmp @r0 ;
then it jumped to 0xA0036534, this is in the ROM address (I think ROM adress (the OS address) started from 0xA0000000)...
If I have the FX-9860's ROM image, I can validate this and may know what is at 0xA0036534 (0x00036534)...
__________________________________________________
You should take a look at, you will see the way to test a key fast.
_Bkey_GetKeyTableInfo 003004e0: .... 0030053C: _KeyCodeConvert 0030053c: ... 003005B4: _Hkey_Check_Key_SDK:;<!--this is the main check key function--> 0030063c: ... 00300768: _IsKeyDown:;<!--This is not the function you need to point much--> 00300768: 4F22: sts.l pr,@-15 ; 0030076A: 7FFC: add #H'FFFFFFFC,r15;r15-=3 0030076C: 63F3: mov r15,r3 ;r3=r15 0030076E: BEE5: bsr H'1DCA ; 00300770: 2F36: mov.l r3,@-r15 ; 00300772: 7F04: add #H'04,r15 ;r15+=4 00300774: 63F0: mov.b @r15,r3 ; 00300776: 633C: extu.b r3,r3 ; 00300778: 4311: cmp/pz r3 ; 0030077A: 8B03: bf H'006 ; 0030077C: 84F1: mov.b @(H'1,r15),r0; 0030077E: 600C: extu.b r0,r0 ; 00300780: 4011: cmp/pz r0 ; 00300782: 8903: bt H'006 ; 00300784: 7F04: add #H'04,r15 ;r15+=4 00300786: 4F26: lds.l @r15+,pr ; 00300788: 000B: rts ; 0030078A: E000: mov #H'00,r0 ; 0030078C: BF56: bsr H'1EAC ; 0030078E: 64F3: mov r15,r4 ; 00300790: 7F04: add #H'04,r15 ; 00300792: 4F26: lds.l @r15+,pr ; 00300794: 000B: rts ; 00300796: 0009: nop ;
#23
Posted 02 June 2007 - 08:22 AM
Maybe that could mean that the rom image does only contain the system wrappers (like the casio libraries) while
the "real" functions of the system are not updateable (and with this also not destroyable?!)
Also this could enable us to improve the OS by rewriting its routines and redirecting the calls to own programs.
Now that would be nice We would just need to patch the $10070 handlers
Can you pm me your mail adress? then I can mail you the os image ...
(btw. how did you get the code from 80010070? The memory viewer and disassembler of the SDK do not seem to show them?!?)
I could also get a "real" rom image if we could initiate communication from within an assembler program...
#24
Posted 02 June 2007 - 09:09 AM
I used a very basic way to get them:
1. Create a new file test.txt in the sd card (which will be saved in the SDCard folder) Loop 2. Read 2 bytes: tmp=*(unsigned short*)(0x80010070+2*i) 3. write tmp to test.txt Until i++>=size 4. Close test.txt 5. Open test.txt with a text editor :P
#25
Posted 02 June 2007 - 09:25 AM
(mail sent!)
#26
Posted 02 June 2007 - 01:03 PM
Hi huhn_m, great to see you know how to do all this.. assembly stuff
Like many of the others, I'm still trying to wrap my head around C
Nice work though!
Alias
#27
Posted 02 June 2007 - 01:13 PM
ROM:00000000 add #-1, r4 ROM:00000002 add #1, r7 ROM:00000004 cmp/hs r5, r7 ROM:00000006 bf h'FFFFFFEC ROM:00000008 mov.l @r15, r3 ROM:0000000A add r5, r4 ROM:0000000C mov r4, r0 ROM:0000000E sub r3, r0 ROM:00000010 add #4, r15 ROM:00000012 mov.l @r15+, r12 ROM:00000014 rts ROM:00000016 mov.l @r15+, r14
The code corresponds to 0x36534 in the OSUpdate image i sent you,
*edit* I think the bf (branch) is wrong, because I started extracting at A0036534 and itseems to jump backwards but since there is not "before" it just wraps arround the adresses. I'll use the OSImage and provide better code asap.
#28
Posted 02 June 2007 - 05:03 PM
I have to OS image.
....
I could also get a "real" rom image if we could initiate communication from within an assembler program...
huhn_m, the OS image I sent you is the real image. Trust me.
Anyways, I added more to the wiki: fx-9860 Hardware Wiki
I added a assembly equivalent of the KEYBIOS and also take a look at the Display Driver page I wrote.
#29
Posted 02 June 2007 - 05:24 PM
________________________________________________________________________________
___________
How to get the asm source of a function in fx9860G_library.lib?
First start a new project, and make sure u use that function before compile.
Open <Your project dir>\Debug\FXADDINror.map
You will see a mapping list, look like:
SECTION START END SIZE ALIGN ... FILE=filebios 00302090 003027bf 730 _BfileMCS_GetFileHandle 00302090 6e func ,g * _Bfile_CloseFile 003020fe 6e func ,g * _BfileMCS_HandleCheck 0030216c 40 func ,g * _MCSFile_InitAll 003021ac 3c func ,g * _Bfile_ReadFile 003021e8 e8 func ,g * _Bfile_WriteFile 003022d0 de func ,g * _Bfile_SeekFile 003023ae 6a func ,g * _Bfile_OpenMainMemory 00302418 42 func ,g * _Bfile_OpenFile 0030245a 6 func ,g * _Bfile_GetMediaFree 00302460 cc func ,g * _Bfile_GetFileSize 0030252c 7a func ,g * _Bfile_CreateMainMemory 003025a6 84 func ,g * _Bfile_CreateFile 0030262a 16 func ,g * _Bfile_CreateDirectory 00302640 8 func ,g * _Bfile_RenameMainMemory 00302648 6a func ,g * _Bfile_DeleteMainMemory 003026b2 6a func ,g * _Bfile_DeleteFile 0030271c 40 func ,g * _Bfile_DeleteDirectory 0030275c 64 func ,g * FILE=keybios 003027c0 00302b03 344 _GetKeyWait 003027c0 40 func ,g * _Bkey_GetKeyTableInfo 00302800 5c func ,g * _KeyCodeConvert 0030285c 78 func ,g * _END$270 0030289a 0 none ,l * __Delay 003028d4 88 func ,g * _Hkey_Check_Key_SDK 0030295c 12c func ,g * _IsKeyDown 00302a88 30 func ,g * _IsKeyUp 00302ab8 4c func ,g * FILE=timer 00302b04 00302c03 100 _GetSDKLibraryVersion 00302b04 6 func ,g * _SetTimer 00302b0a 54 func ,g * _KillTimer 00302b5e 44 func ,g * _Sleep 00302ba2 62 func ,g *
And then, you will have its start address and its length, that's enouph to get the source...
#30
Posted 03 June 2007 - 09:36 AM
Just don't know if I have time today and tomorrow. But tuesday is definately 9860 day
by the way I have the folowing theory:
The r15 register (seen for example in the key bios) seems to point to an downwards growing stack.
I think this, because often data is written to it in the folowing form:
STS.L pr,@-r15
what means, that the value in the register is decremented and then the pr register is written to the position in memory
indicated by this value. When a program ends the pr register is often then restored by writing:
LDS.L @r15+, pr
This gets the value from the memory position pointed at by r15 and then increments the value in r15.
This seems like the classic "stack" to me...
Could someone please confirm that I'm not completly wrong with this theory?
#31
Posted 03 June 2007 - 11:05 AM
mov.l r12, @-r15 ; decrease SP, push r12 to stack mov.l @r15+, r12 ;pop value back into r12, increase SP ; it might be sufficient to only use "mov", as these instructions seem to default to handling long's (32 bit)
Are parameters for C-functions passed through the stack or through registers (I'm betting on stack)?
#32
Posted 03 June 2007 - 11:08 AM
well, I tried with set pixel, and the parameters were passed through registers. (see the function example some posts above)
#33
Posted 03 June 2007 - 11:23 AM
mov.l r4, @(h'10,r15)
The h'10 is a 5 bit value, but only 4 bits are allowed! (MOV.L Rn,@(disp4:Rm) == 0001nnnnmmmmdddd)
Is th?s already multiplied by 4 (because of the long word)?
#34
Posted 03 June 2007 - 11:40 AM
MOV.L Rm,@(disp,Rn) Rm → (disp ? 4 + Rn)
#35
Posted 03 June 2007 - 12:21 PM
The thing is ACTUALLY the DISP value is multiplied by 4 and has 4 bits. But here the DISP value is already bigger than possible because it has 5 bits.
As I understood the docs the value (here $10) is multiplied by 4. I think the description is a little incrorrect.
#36
Posted 03 June 2007 - 02:42 PM
Just don't know if I have time today and tomorrow. But tuesday is definately 9860 day [/quote]
Ok, cool.
-->
[quote name='huhn_m' post='40908' date='Jun 3 2007, 04:08 AM']well, I tried with set pixel, and the parameters were passed through registers. (see the function example some posts above)[/quote]
Yes, I think it starts off at R4 then continues on (R5 then R6 then R7....).
#37
Posted 28 January 2008 - 05:41 PM
(waking of the topic)
i wonder wether someone know of the opcodes of the sh3 asm?
#38
Posted 28 January 2008 - 06:09 PM
#39
Posted 30 January 2008 - 04:13 PM
i didn't take the time to check out since the link is broken, but with your tip i was able to find a new link on planete casio, here it is (if womeone else is intersted in it):
http://documentation...0317_sh_3sm.pdf
(kucalc: are you still developping mlc?)
#40 Guest_asm_*
Posted 04 July 2009 - 09:04 PM
Indeed, the disassembler has already multiplied the displacement by four.I also do not get the folowing command:
mov.l r4, @(h'10,r15)
The h'10 is a 5 bit value, but only 4 bits are allowed! (MOV.L Rn,@(disp4:Rm) == 0001nnnnmmmmdddd)
Is this already multiplied by 4 (because of the long word)?
The binary code should read: 0001 | 1111 | 0100 | 0100 (Code |R15| R4 | Displacement)
Note: The assembler will automatically divide your displacement by four (longword) or two (word).
Max. disp. f. long: H'3C Max. disp. f. word: H'1E Max. disp. f. byte: H'0F
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users