Omnimaga
Calculator Community => Casio Calculators => Topic started by: Munchor on January 16, 2011, 07:34:40 am
-
I just made a GUI Disassembler for the Casio Prizm, the first GUI disassembler for the Prizm actually :w00t:
Below is a link for the setup.exe for Windows Users, but also the .pyw file for Linux/Mac OS users or even Windows Users looking for portability. Whoever decides to use this .pyw file will need Python and wxPython installed in their computers.
What can I say? I'll try to release a new version as soon as possible with an About Box, a Link to Omnimaga Forums and Support for reading .g3a files. All these 3 features are really easy to make, but I just don't have the time at the moment.
The source code may be public, but any release on the Net without my authorization is not allowed.
Also, this is a disassembler, not a detokenizer, so only Assembly files are supported.
But it's also quite good to have a Disassembler (even though it is quite basic) a few days after the Prizm was released.
Downloads:
Setup - http://www.megaupload.com/?d=T76Q1EK0 (http://www.megaupload.com/?d=T76Q1EK0)
.exe - www.davidgom.co.cc/PrizmDisassembler.zip (http://www.davidgom.co.cc/PrizmDisassembler.zip)
Sorry for megaupload link, but I can't host it at my website at the moment, only the .zip. Would I be able to upload it to Omnimaga Downloads, though?
EDIT: I really recommend the .pyw file (install Python 2.6 and wxPython), it's much faster than the others.
EDIT 2: I really forgot to, but special thanks to JosJuice, for helping me with databases, no About Box in this version, but in the next one you'll be credited.
-
YOu didn't mention at all about xlrd. Can you not do this without some excel database? (If memory serves, that is what xlrd does)
-
YOu didn't mention at all about xlrd. Can you not do this without some excel database? (If memory serves, that is what xlrd does)
Agreed - running this in Ubuntu gives:
~/TICalc$ python Prizm*
Traceback (most recent call last):
File "Prizm Disassembler.pyw", line 3, in <module>
import xlrd
ImportError: No module named xlrd
~/TICalc$
A suggestion is to use a "dictionary" to do all of the matching.
http://tibasicdev.wikidot.com/forum/t-184793/python-ti83-basic-converter (http://tibasicdev.wikidot.com/forum/t-184793/python-ti83-basic-converter)
Also, Undo/Redo doesn't work.
Finally... if you make a disassembler, one of the usual practices is to make it CLI only as not everyone wants a GUI tacked on. (I love wxPython, but it takes a nasty amount of space... :P)
-
Oh sorry, that was from Assemblex code, just remove it. Sorry :S You can edit the code! Right Click>>Edit.
-
Update: Fixed a little bugs.
def getG3Adata(event):
dlg = wx.FileDialog(self, "Choose a file", self.dirname, "", 'g3a Files (*.g3a)|*.g3a', wx.OPEN)
if dlg.ShowModal() == wx.ID_OK:
self.filename=dlg.GetFilename()
self.dirname=dlg.GetDirectory()
# Open the file, read the contents and set them into
# the text edit window
filehandle=open(os.path.join(self.dirname, self.filename),'r')
filehandle.close()
self.SetTitle('Assemblex - '+self.filename)
hexvalues = open(self.filename, "rb").read().encode("hex")
hexProgram = fill(hexvalues,16)
hexProgramData = hexProgram[28672:(len(hexProgram)-4)]
hexProgramUpperData = hexProgramData.upper()
self.inputText.SetValue(self.inputText.GetValue() + hexProgramUpperData)
Is this OK for reading .g3a files? I'm not sure about the size of header, but I think it is $7000, or 28672. Is that right?
Thanks
-
Yes, the header is $7000 bytes large. There's also a four-byte area at the very end of the file that you should skip.
-
Sorry about multiple posts ahead of time, if there are any. I'm just going to lump everything together in one post:
1) BSL, I think there's a problem with branch adresses in your disassembler. It keeps jumping to the middle of Longwords.
2) I finally got my Prizm today and my god are the math functions fast. I couldn't even measure the time of individual functions(they took less than a sec on 1000 iteration loops) and the integral function is 3-4x faster than a TI-84+ SE with a really complicated equation. I see a ton of potential in the platform if we get something like Axe built.
-
Sorry about multiple posts ahead of time, if there are any. I'm just going to lump everything together in one post:
1) BSL, I think there's a problem with branch adresses in your disassembler. It keeps jumping to the middle of Longwords.
2) I finally got my Prizm today and my god are the math functions fast. I couldn't even measure the time of individual functions(they took less than a sec on 1000 iteration loops) and the integral function is 3-4x faster than a TI-84+ SE with a really complicated equation. I see a ton of potential in the platform if we get something like Axe built.
I think your right with this potential. Although the ARM on the nspire can reach higher clock speeds than the SH3 some instructions, such as division, can take over 100 clock cycles while the SH3 and its RISC architecture can do the same instruction in only one cycle.
-
Sorry about multiple posts ahead of time, if there are any. I'm just going to lump everything together in one post:
1) BSL, I think there's a problem with branch adresses in your disassembler. It keeps jumping to the middle of Longwords.
Yes, I know - I am fixing that now: Both the data movement and branch instructions, the rest look good.
I may add data references so that the disassembler skips over this as data.
I might add more command line options too.
-
Yes, the header is $7000 bytes large. There's also a four-byte area at the very end of the file that you should skip.
Then I'm almost releasing a file that reads .g3a files. .g3a files are the only Assembly ones? If there are more I'd like to make my disassembler support them :D
Also, anybody already tried disassembling OSs and stuff on my Disassembler?
-
.g3a files are the only files that contain assembly code, with the exception of OS update files. No OS update files have been released, so we don't know anything about that file type. We haven't been able to dump the OS from the calc either.
-
Sorry about multiple posts ahead of time, if there are any. I'm just going to lump everything together in one post:
1) BSL, I think there's a problem with branch adresses in your disassembler. It keeps jumping to the middle of Longwords.
2) I finally got my Prizm today and my god are the math functions fast. I couldn't even measure the time of individual functions(they took less than a sec on 1000 iteration loops) and the integral function is 3-4x faster than a TI-84+ SE with a really complicated equation. I see a ton of potential in the platform if we get something like Axe built.
I think your right with this potential. Although the ARM on the nspire can reach higher clock speeds than the SH3 some instructions, such as division, can take over 100 clock cycles while the SH3 and its RISC architecture can do the same instruction in only one cycle.
Actually, the division instruction on the SH3 only divides 1 bit. To divide a 32-bit number, you have to execute the instruction 32 times. Dividing 1 bit in ARM takes about 3 cycles, I think (since it doesn't have a dedicated instruction for it). It's not such a huge difference.
-
http://pastebin.com/vA5yVgj5
My disassembler reads this (http://pastebin.com/GQKA7EmL) as the Hexadecimal code of Convert.g3a. Hum, the function is the following:
def getG3Adata(event):
dlg = wx.FileDialog(self, "Choose a file", self.dirname, "", 'g3a Files (*.g3a)|*.g3a', wx.OPEN)
if dlg.ShowModal() == wx.ID_OK:
self.filename=dlg.GetFilename()
self.dirname=dlg.GetDirectory()
# Open the file, read the contents and set them into
# the text edit window
filehandle=open(os.path.join(self.dirname, self.filename),'r')
filehandle.close()
self.SetTitle('PRIZM Disassembler - '+self.filename)
hexvalues = open(self.filename, "rb").read().encode("hex")
hexProgram = fill(hexvalues,16)
hexProgramData = hexProgram[57344:(len(hexProgram)-4)]
self.inputText.SetValue(self.inputText.GetValue() + hexProgramData)
Is it correct? Any ideas?
-
Here is version 002 of the command line disassembler.
Fixed the data transfer and branch instructions, also included data and code references during
disassemby, thanks to python's dictionary [or hash in perl].
To disassemble a whole file: c:\> sh3_disass.py Geometry.g3a 7000 > Geometry.S
To disassemble in a range: c:\> sh3_disass.py Geometry.g3a 7000 7100 > Geometry_7000_7100.S
Here is an example of the output:
00007000: MOV.L R14,@-R15
00007002: STS.L PR,@-R15
00007004: ADD $FC,R15
00007006: MOV.L R4,@R15
00007008: MOV.L @($07*4+PC),R3 = #00300034
0000700A: JSR @R3
0000700C: MOV R5, R14
0000700E: MOV.L @($07*4+PC),R1 = #0038DF00
00007010: MOV $01, R6
00007012: MOV $00, R4
00007014: JSR @R1
00007016: MOV R6, R5
00007018: MOV.L @($05*4+PC),R7 = #0033767C
0000701A: EXTU.W R14,R5
0000701C: MOV.L @R15,R4
0000701E: ADD $04,R15
00007020: LDS.L @R15+,PR
00007022: JMP @R7
00007024: MOV.L @R15+,R14
00007026: 0000 ?
00007028: .data 00300034 dword ref:7008
0000702C: .data 0038df00 dword ref:700E
00007030: .data 0033767c dword ref:7018
00007034: MOV.L @($0D*4+PC),R7 = #0038FE4C
00007036: MOV $00, R6
00007038: MOV.L @($0D*4+PC),R4 = #0038FE50
0000703A: BRA $7042
0000703C: MOV.L @R7,R2
0000703E: MOV.L R6,@R2
00007040: ADD $04,R2
00007042: ;code ref: 703A
00007042: MOV.L @R4,R5
00007044: CMP/HS R5,R2
-
Nice stuff!
-
Mine already reads .g3a files, but disassembling them will return weird results until PRIZM Assembly is discovered :S
-
One question: Why aren't you using IDA Pro Advanced (http://www.hex-rays.com/idapro/overview.htm) for this?
Simply open the add-in file and select SH3B as the processor type.
A cracked version is available here (v5.5): no.links2piratedprograms.plz
Offset 0x7000..0x7044 with IDA:
ROM:00007000 loc_7000: ; DATA XREF: ROM:0009DFFC
ROM:00007000 ; ROM:0009E17C
ROM:00007000 mov.l r14, @-r15
ROM:00007002 sts.l pr, @-r15
ROM:00007004 add #-4, r15
ROM:00007006 mov.l r4, @r15
ROM:00007008 mov.l dword_7028, r3 ; h'300034
ROM:0000700A jsr @r3
ROM:0000700C mov r5, r14
ROM:0000700E mov.l dword_702C, r1 ; h'38DF00
ROM:00007010 mov #1, r6
ROM:00007012 mov #0, r4
ROM:00007014 jsr @r1
ROM:00007016 mov r6, r5
ROM:00007018 mov.l dword_7030, r7 ; h'33767C
ROM:0000701A extu.w r14, r5
ROM:0000701C mov.l @r15, r4
ROM:0000701E add #4, r15
ROM:00007020 lds.l @r15+, pr
ROM:00007022 jmp @r7
ROM:00007024 mov.l @r15+, r14
ROM:00007024 ; ---------------------------------------------------------------------------
ROM:00007026 .align 4
ROM:00007028 dword_7028: .data.l h'300034 ; DATA XREF: ROM:00007008
ROM:0000702C dword_702C: .data.l h'38DF00 ; DATA XREF: ROM:0000700E
ROM:00007030 dword_7030: .data.l h'33767C ; DATA XREF: ROM:00007018
ROM:00007034 ; ---------------------------------------------------------------------------
ROM:00007034 mov.l dword_706C, r7 ; h'38FE4C
ROM:00007036 mov #0, r6
ROM:00007038 mov.l dword_7070, r4 ; h'38FE50
ROM:0000703A bra loc_7042
ROM:0000703C mov.l @r7, r2
ROM:0000703E ; ---------------------------------------------------------------------------
ROM:0000703E
ROM:0000703E loc_703E: ; CODE XREF: ROM:00007046
ROM:0000703E mov.l r6, @r2
ROM:00007040 add #4, r2
ROM:00007042
ROM:00007042 loc_7042: ; CODE XREF: ROM:0000703A
ROM:00007042 mov.l @r4, r5
ROM:00007044 cmp/hs r5, r2
-
Please don't post links to cracked versions.
-
We aren't using it because no one should have to download illegally obtained software just to look at their Prizm or participate in discussions of it. The whole point of developing more disassemblers is to *avoid* having to use commercial software. Indeed, that's the whole point of Gnu.
-
What both users above said. I don't want to get in trouble with my web hosting provider. Also I don't trust pirated softwares anymore because several contains viruses that only gets detected one year later (like a time bomb). However, we shouldn't have to pay to develop softwares IMHO so the community will write freeware tools to do so.
When TI decided to make people pay for the TI-83 Plus SDK in the early 2000s, people just ported TASM and Devpac8x to the 83 Plus to develop for free. Later, TI made the SDK free, though.
Anyway welcome here.
-
Simply open the add-in file and select SH3B as the processor type.
Offset 0x7000..0x7044 with IDA:
ROM:00007000 loc_7000: ; DATA XREF: ROM:0009DFFC
ROM:00007000 ; ROM:0009E17C
ROM:00007000 mov.l r14, @-r15
ROM:00007002 sts.l pr, @-r15
ROM:00007004 add #-4, r15
ROM:00007006 mov.l r4, @r15
ROM:00007008 mov.l dword_7028, r3 ; h'300034
ROM:0000700A jsr @r3
ROM:0000700C mov r5, r14
ROM:0000700E mov.l dword_702C, r1 ; h'38DF00
ROM:00007010 mov #1, r6
ROM:00007012 mov #0, r4
ROM:00007014 jsr @r1
ROM:00007016 mov r6, r5
ROM:00007018 mov.l dword_7030, r7 ; h'33767C
ROM:0000701A extu.w r14, r5
ROM:0000701C mov.l @r15, r4
ROM:0000701E add #4, r15
ROM:00007020 lds.l @r15+, pr
ROM:00007022 jmp @r7
ROM:00007024 mov.l @r15+, r14
ROM:00007024 ; ---------------------------------------------------------------------------
ROM:00007026 .align 4
ROM:00007028 dword_7028: .data.l h'300034 ; DATA XREF: ROM:00007008
ROM:0000702C dword_702C: .data.l h'38DF00 ; DATA XREF: ROM:0000700E
ROM:00007030 dword_7030: .data.l h'33767C ; DATA XREF: ROM:00007018
ROM:00007034 ; ---------------------------------------------------------------------------
ROM:00007034 mov.l dword_706C, r7 ; h'38FE4C
ROM:00007036 mov #0, r6
ROM:00007038 mov.l dword_7070, r4 ; h'38FE50
ROM:0000703A bra loc_7042
ROM:0000703C mov.l @r7, r2
ROM:0000703E ; ---------------------------------------------------------------------------
ROM:0000703E
ROM:0000703E loc_703E: ; CODE XREF: ROM:00007046
ROM:0000703E mov.l r6, @r2
ROM:00007040 add #4, r2
ROM:00007042
ROM:00007042 loc_7042: ; CODE XREF: ROM:0000703A
ROM:00007042 mov.l @r4, r5
ROM:00007044 cmp/hs r5, r2
The thing is, we need to know PRIZM Assembly to make a disassembler. PRIZM Assembly is not the same as all SH3 Assembly, AFAIK. Not every machines with the same processor work the same way, I guess. Also, I believe it won't take much time for Qwerty and other Prizm hackers to start coding Asm :D
-
I tried making a new app. I'm not sure if it actually worked, but it was less tragic than the last one. The goal was to wait several seconds/minutes then return to the OS. When running the screen went blank for about 15 seconds and then the calc went to the setup screen. I believe there was a ram reset, but the target/PC screen never showed up. Here is the code and actual app.
File size: 29180
00007000: MOV.L @($01*4+PC),R15 = #FFFFFFFF
00007002: DT R15
00007004: BF $7002
00007006: RTS
00007008: .data ffffffff dword ref:7000
-
I am not sure you can use RTS to get back to the OS.
Disassemble the small Conv.g3a - there is only one RTS (at $7068) and its the applications subroutine.
Also as a note it makes sense that application file offset 0x7000 in memory has the PC value of 0x300000
then the program subroutine addresses match. The OS calls seem to be at > 0x80000000 .
The only reason I left out the register values in the disassembler is that I did not know there initial values.
Now it looks like I will include them in the next version.
-
I am not sure you can use RTS to get back to the OS.
Disassemble the small Conv.g3a - there is only one RTS (at $7068) and its the applications subroutine.
That makes sense... I remember that on the TI-83+/84+, programs are exited using RET, but apps have to be exited by using a certain OS call.
-
Small Update:
> Optimizations;
> Changed appearance slightly;
> Added 'About Box' to credit me, JosJuice and Goplat;
> Added link to Omnimaga 'Casio Prizm Discussion' forum;
> Added 'Load .g3a' option.
I still need to get authorization from administrator to link to Omnimaga (like I did with Assemblex), but I am in a rush now, so any admin could just answer in this topic.
-
How do you run it from Command line?
-
How do you run it from Command line?
You don't. I could, however, make a script to make it CMD, if someone wants to, but I don't really see why since GUI is much better.
-
It seems like the .g3a reading still tries to read part of the header. And, um... disassembling doesn't seem to work at all.
-
It seems like the .g3a reading still tries to read part of the header. And, um... disassembling doesn't seem to work at all.
Of course not, PRIZM Assembly is not known yet, none can make a Disassembler, it only reads the Hex. Part of the header? Can you say how many bytes?
EDIT: I have found a file explaining SH3 Assembly, I'll make it read Hex ASAP:
-
Scout, SH3 Assembly *is* known. I've explained why Enii is used instead of regular hex on IRC three times already.
-
It seems like the .g3a reading still tries to read part of the header. And, um... disassembling doesn't seem to work at all.
Of course not, PRIZM Assembly is not known yet, none can make a Disassembler, it only reads the Hex. Part of the header? Can you say how many bytes?
Prizm assembly is known - it's pretty the same thing as other devices that use the SH3. Writing a disassembler is possible, but probably hard.
You need to skip 1686.5 more bytes of the header.
-
It seems like the .g3a reading still tries to read part of the header. And, um... disassembling doesn't seem to work at all.
Of course not, PRIZM Assembly is not known yet, none can make a Disassembler, it only reads the Hex. Part of the header? Can you say how many bytes?
Prizm assembly is known - it's pretty the same thing as other devices that use the SH3. Writing a disassembler is possible, but probably hard.
You need to skip 1686.5 more bytes of the header.
Well, do you have Conversion.g3a? If you could tell me what is the header of that file, I could know if I'm doing it right or wrong :S
-
Turns out the app I ran did not refresh my ram. Are we sure though that the proc is not 58Mhz because the app I created ran twice as fast I suspected it to on a 29Mhz proc.
-
I agree with going CLI. It's not quite an IDE, just a disassembler. :)
(Besides, the GUI code was a copy and paste from http://www.wellho.net/resources/ex.php4?item=y207/wx03_02.py (http://www.wellho.net/resources/ex.php4?item=y207/wx03_02.py), which is a big no no. :P)
On the plus side, CLI does have pluses, including the ability to focus on core stuff! :)
(You should really understand disassembly before writing this utility... :P)
That said, I've went and beautified and converted it to a library.
For those who wish to use it (in the future, it's in a terrible state), simply do:
import prizmdisasm # (this may be shorter in the future)
# do anything you want to get done here, including data fetching/manipulation
prizmdisasm.getG3Adata(datavar) # Only if you use a G3A
prizmdisasm.disassemble(asmdata) # Disassemble it!
That's it! :) As said above, the GUI is removed, so you don't have to worry about wx being installed.
P.S. - you guys should combine your efforts (bsl and Scout) and make a unified disassembler! :) For bsl, I'd advise you to use a dictionary to pull values so that it's easy to modify code, plus making it more organized. ;)
EDIT: also, here's the help (and how to get the help):
~$ python prizmdisasm.py -h
PRIZM Disassembler v1.0.1 CLI and Library
=========================================
Usage: prizmdisasm.py [option(s)] ... [inputfile]
General options:
-o, --output=[outfile] Specify output file to write to.
Disassembly options:
-t, --type=[type] Specify the input file type.
Type can be 'hex', 'bin', 'enii', or 'g3a'.
-s, --distype=[distype] Specify the disassembly type.
Help/About:
-h, --help Get help! :) (Shows this help)
-w, --webhelp Go to PRIZM hacking site for more info/help! :)
-c, --credits Who made this awesome program? :D
(This also shows the license of this program.)
-
I just checked it out, it's cool but since you used my code, but don't forget to use the last version of it:
http://pastebin.com/DiySnjCK (http://pastebin.com/DiySnjCK)
It's also much faster!
-
I have an idea, but I'm not sure if it is going to work. Unlike the TI 83+ the Prizm has its lcd directly mapped to memory. One screen image on the Prizm takes up 166 kilobytes. What I don't know though is where all this data is. I'm assuming that the Prizm doesn't have more than 1 megabyte of ram. What this means that if I do a few writes to memory I might be able to find where the plotscreen is. This could also really screw up my Prizm too. What I will do is up to one megabyte every 160 kilobytes I will send 32 bytes of one color. Every segment seperated 160 kilobytes will also be a different color. Hopefully when (if) :P I get a small line on my screen, I will be able to determine the general memory location. Then later I can narrow that down. to an exact location :-\
-
I have an idea, but I'm not sure if it is going to work. Unlike the TI 83+ the Prizm has its lcd directly mapped to memory. One screen image on the Prizm takes up 166 kilobytes. What I don't know though is where all this data is. I'm assuming that the Prizm doesn't have more than 1 megabyte of ram. What this means that if I do a few writes to memory I might be able to find where the plotscreen is. This could also really screw up my Prizm too. What I will do is up to one megabyte every 160 kilobytes I will send 32 bytes of one color. Every segment seperated 160 kilobytes will also be a different color. Hopefully when (if) :P I get a small line on my screen, I will be able to determine the general memory location. Then later I can narrow that down. to an exact location :-\
Sounds like a good idea... But also a dangerous one. Let's hope it works - knowing how to write to the LCD would be very helpful.
-
z80man I certainly hope the screen content is not stored in the Flash memory. At the speed the draw commands and pxl-tests run, I am worried. O.O
-
z80man I certainly hope the screen content is not stored in the Flash memory. At the speed the draw commands and pxl-tests run, I am worried. O.O
If it was, even the OS menus would be incredibly slow. It doesn't make sense to store something like the current picture of the screen in Flash - RAM is intended for temporary storage like this.
-
What if drawing home screen text just involved changing a tiny portion of the screen memory, though? Could that be faster?
-
What if drawing home screen text just involved changing a tiny portion of the screen memory, though? Could that be faster?
No, and we're not trying to change the "homescreen", we're trying to find where the ram is that the screen is mapped to. In the TI-83/84 series, the LCD has it's own ram, which is why it is so slow. Besides, writing this way would actually be faster because there are fewer sections because the memory is larger.
-
Do you guys already have a clue on how large the actual RAM chip is? On the GII calculators it is 512k.
Simon told me once you can check this via the FA-124 communication protocol and the Prizm's 3-pin port still has to support most of this.
-
Do you guys already have a clue on how large the actual RAM chip is? On the GII calculators it is 512k.
Simon told me once you can check this via the FA-124 communication protocol and the Prizm's 3-pin port still has to support most of this.
We don't know anything about RAM other than that there's 61 KB user RAM.
-
What if drawing home screen text just involved changing a tiny portion of the screen memory, though? Could that be faster?
Actually, it wouldn't be faster. The reason drawing to the homescreen seems faster is because the OS handles all of the messy text location, but in actuality drawing to the homescreen means that you still have to change the same bits in the LCD RAM to get the same image.
-
If you've used the picture plot app and maually flip through through one of the animation pictures, the screen updates quite quickly.
-
If you've used the picture plot app and maually flip through through one of the animation pictures, the screen updates quite quickly.
Even with many colours?
-
Well, the picture files are limited in color. There appears to be a color palette in the file that determines what will be displayed. Judging by the contrast, I'd say it's limited to 256 colors.
-
Even if the image format is limited to 8 bit color, it still has to be written in 16 bit in the LCD ram. So this probaly means that the screen image is located in ram and not rom. For the LCD drawing test I'm starting at $B4000000 because that was where the lcd ram for the fx-9860g was located.
-
Well, the picture files are limited in color. There appears to be a color palette in the file that determines what will be displayed. Judging by the contrast, I'd say it's limited to 256 colors.
Maybe I'm reading the wrong way, but no monochrome?
-
It would be possible to write a program to display monochrome images, but it would have to convert 1 to $FFFF and 0 to $0000 due to the way the lcd ram is set up.
Edit: forgot colors are reversed on the Prizm. $0000 is black and $FFFF is white
-
It would be possible to write a program to display monochrome images, but it would have to convert 1 to $FFFF and 0 to $0000 due to the way the lcd ram is set up.
So, it's not pre-included. That sucks, I love monochrome!
-
Well a monochrome to 16 bit converter would be really easy to make even on SH3 asm. Also I believe that bmp file formats are supported but I need to double check that.
-
Here is version 003 of the CLI SH3 disassembler.
Added more of the necessary code references, for the purposes here.
Added command line options(-s (start),-e (end),-p (sets pc at the start)):
Default values:
-p=300000 program counter setting
-s=7000 file start disassembly at 7000
-e=eof end dissassembly at end of file
So the default :
C:\>sh3_disass_003.py -s 7000 -p 300000 Geometry.g3a > Geometry.S
is the same as
C:\>sh3_disass_003.py Geometry.g3a > Geometry.S
If you dont want the crc check(4 bytes) at the end of the file you use:
:\>Prizm>sh3_disass_003.py -e -4 Geometry.g3a > Geometry.S
Also added some register bookkeeping.
I am speculating here: if you know the fx9860g ROM syscalls you already know the Prizm syscalls:
Prizm 80020070
fx9860g 80010070
I added comments to syscalls in the disassembler:
0038D110: MOV.L @($01*4+PC),R2 = #80020070
0038D112: MOV.L @($02*4+PC),R0 = #00001E56
0038D114: JMP @R2 = #80020070 ; syscall(1E56)
0038D116: NOP
0038D118: .data 80020070 dword ref:38D110
0038D11C: .data 00001e56 dword ref:38D112
0038D120: ;code ref:370C38
0038D120: MOV.L @($01*4+PC),R2 = #80020070
0038D122: MOV.L @($02*4+PC),R0 = #0000015E
0038D124: JMP @R2 = #80020070 ; syscall(15E)
0038D126: NOP
0038D128: .data 80020070 dword ref:38D120
0038D12C: .data 0000015e dword ref:38D122
0038D130: ;code ref:355C10
0038D130: MOV.L @($01*4+PC),R2 = #80020070
0038D132: MOV.L @($02*4+PC),R0 = #00000168
0038D134: JMP @R2 = #80020070 ; syscall(168)
0038D136: NOP
-
I was disassembling some code a little while ago and I noticed the fundamental problem of all disassemblers: Differentiating data and code. When you write to the WDT register, there's a very specific method of access which must be used. I managed to find a section of code that was clearly writing to the register, but it was listed as code and not data. Not a bug, just a difficulty.
-
WDT, is that the countdown timer for after you change the clock multiplier. Becuase I think I remember seeing that in some hardware documentation for the SH3
-
It's a general timer counter (Watchdog Timer Counter Register, WDTCR). One of its uses is to count the time during clock stabilization. You can use it whenever you're doing something that absolutely needs to have a way to quit.
-
bsl, your disassembler doesn't support output files larger than 128 MB. I found it out the hard way :P
-
What kind of ASM file is 128 MB large, though? O.O
-
The Prizm OS binary is about 12 MB. The disassembled version becomes much larger - two bytes in the binary is equal to one row of text in the disassembly.
-
I see. I guess I didn't realize ASM source could get this large. Plus I am used to 500-1000 KB OSes. :P
-
bsl, your disassembler doesn't support output files larger than 128 MB. I found it out the hard way :P
I would not believe everthing it dissasembles beyond a certain output size.
Its a simple linear top-down disassembler, which means it will do things it should't - like
disassembling data instead of leaving it as data.
You have to disassemble small blocks instead and identify subroutines.
I will think of some way to make this easier.....
I have yet to finish the rest of the transfer instructions, up till now I put in enough just too look at add-ins
-
It's not such a big problem since it's a RISC processor, right? All instructions are the same size, so I think it'd be fine to show both the hex data and the instruction mnemonics at the same time.
-
I wonder if the hex equivalent would be similar to the hex equivalent of z80 ASM?
-
The Prizm OS binary is about 12 MB. The disassembled version becomes much larger - two bytes in the binary is equal to one row of text in the disassembly.
You don't exactly need those 5 MB of $FFFF :P
-
Wait, do you imply the OS is filled with 5 MB of $FFFF's? ???
-
Give or take.
-
If it's not OS storage space a program could be written to add this as user space.
-
Give or take.
What does Give or take mean? ???
/me is confused...
If it's not OS storage space a program could be written to add this as user space.
inb4 OS update that uses that space. D:
-
Give or means that it could be 5 MB plus a few MB or Minus a few MB. I'm not sure exactly how much space is actually taken up by it.
-
Ah ok. I was more shocked at how much useless stuff is stuffed in the OS. X.x
We could use that stuff to store data, but then if Casio releases a new OS that uses it... (like TI did with OS 2.55MP)
-
I suspect it actually does have a purpose, such as SafeRAM or something.
-
Even on the fx-9860G the RAM backup is only 128k (twice the user RAM, written alternately). So I guess, it's just unused.
For instance, the fx-9750GII is sold without add-in capability, meaning there is about 1.9 MB of unused flash memory!
But luckily, we made it run add-ins. ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
-
Bsl, would it be possible to add an option for endian-ness? For example, C:Users\>sh3_disass.py -p 0 -s 100 -e -4 -n 1 file.txt > filedump.txt would disassemble in little endian mode. -n 0 would disassemble in big endian mode.
-
Sure, but I simply use -n to toggle the endianness.
This is a minor update - fixed the MOV.W @($%s*2+PC) instruction so it reports correctly.
Added python style hex/ascii dump to the output - makes ascii/unicode strings easier to identify:
003000E6: '\xe4\x01' MOV $01, R4
003000E8: 'J\x0b' JSR @R10 = #300154
003000EA: 'f\xb3' MOV R11, R6
003000EC: '\x7f\x04' ADD $04,R15
003000EE: '/\xe6' MOV.L R14,@-R15
003000F0: '{\x01' ADD $01,R11
003000F2: '\xe7 ' MOV $20, R7
003000F4: '\xe5\x05' MOV $05, R5
003000F6: '\xe4\x01' MOV $01, R4
003000F8: 'J\x0b' JSR @R10 = #300154
003000FA: 'f\xb3' MOV R11, R6
003000FC: '\x7f\x04' ADD $04,R15
003000FE: '/\xe6' MOV.L R14,@-R15
00300100: '{\x01' ADD $01,R11
Whats next ?
Disassembling large files like prizm3064 requires more interaction with the user.
As JosJuice found out you quickly run out of memory filling out the dictionaries in the program.
So saving that to a file and adding another option to the program is in order.
Reloading this saved mapping file simply tells the program as it disassembles the next pass whether its in code,data or reverse endianness (or other commands suggested) very similar to IDA's idc file , but not the same.
A user can edit this file in Textpad , run the disassembler in another window and use other utilities like sorting, already
found on Windows/*NIX to make it more interactive.
I will have to give it more thought.
-
Nice bsl!
I also have to say that if anyone wants to take up my Disassembler, go ahead, I don't wanna learn PRIZM Assembly :D
-
bsl, I noticed a bug in your disassembler. I'm still using version 3, so you may have fixed this already, but...
When I was disassembling the OS, it didn't properly parser 0x4F43 as an instruction. As it turns out, that's the opcode for STC SPC, @-R15, which is a perfectly understandable instruction given the context.
-
Change the 2 to a 4 for the third nibble on line 674:
if nib1 == '4' and nib3 == '4' and nib4 == '3':
print "STC.L SPC,@–R%d" % (int(nib2,16)) # 4n43
return
Looks like I am going to work on version 005 during the next week.
-
Thanks :)
-
Reupload of version 4, because the old file was deleted when Omni was gone.
-
THanks :)