Author Topic: PRIZM Disassembler (Read 34319 times)

JosJuice · « **Reply #30 on:** January 19, 2011, 11:26:00 am »

Quote from: Scout on January 19, 2011, 11:21:35 am

Quote from: JosJuice on January 19, 2011, 11:19:20 am
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.

Munchor · « **Reply #31 on:** January 19, 2011, 11:29:01 am »

Quote from: JosJuice on January 19, 2011, 11:26:00 am

Quote from: Scout on January 19, 2011, 11:21:35 am
Quote from: JosJuice on January 19, 2011, 11:19:20 am
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

z80man · « **Reply #32 on:** January 19, 2011, 07:42:08 pm »

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.

alberthrocks · « **Reply #33 on:** January 20, 2011, 03:54:47 pm »

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, which is a big no no.

)

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...

)

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:

Code: [Select]

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):

Code: [Select]

~$ 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.)

Munchor · « **Reply #34 on:** January 20, 2011, 03:57:06 pm »

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

It's also much faster!

z80man · « **Reply #35 on:** January 20, 2011, 05:41:37 pm »

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)

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 $:-\$

JosJuice · « **Reply #36 on:** January 21, 2011, 01:31:12 am »

Quote from: z80man on January 20, 2011, 05:41:37 pm

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) 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.

DJ Omnimaga · « **Reply #37 on:** January 21, 2011, 01:34:51 am »

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.

JosJuice · « **Reply #38 on:** January 21, 2011, 01:37:09 am »

Quote from: DJ Omnimaga on January 21, 2011, 01:34:51 am

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.

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.

DJ Omnimaga · « **Reply #39 on:** January 21, 2011, 02:19:24 am »

What if drawing home screen text just involved changing a tiny portion of the screen memory, though? Could that be faster?

jnesselr · « **Reply #40 on:** January 21, 2011, 07:34:40 am »

Quote from: DJ Omnimaga on January 21, 2011, 02:19:24 am

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.

fxdev · « **Reply #41 on:** January 21, 2011, 07:57:52 am »

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.

JosJuice · « **Reply #42 on:** January 21, 2011, 11:20:10 am »

Quote from: cfxm on January 21, 2011, 07:57:52 am

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.

AngelFish · « **Reply #43 on:** January 21, 2011, 11:25:21 am »

Quote from: DJ Omnimaga on January 21, 2011, 02:19:24 am

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.

z80man · « **Reply #44 on:** January 21, 2011, 03:21:33 pm »

If you've used the picture plot app and maually flip through through one of the animation pictures, the screen updates quite quickly.

Author Topic: PRIZM Disassembler (Read 34319 times)

JosJuice

Re: PRIZM Disassembler

Munchor

Re: PRIZM Disassembler

z80man

Re: PRIZM Disassembler

alberthrocks

Re: PRIZM Disassembler

Munchor

Re: PRIZM Disassembler

z80man

Re: PRIZM Disassembler

JosJuice

Re: PRIZM Disassembler

DJ Omnimaga

Re: PRIZM Disassembler

JosJuice

Re: PRIZM Disassembler

DJ Omnimaga

Re: PRIZM Disassembler

jnesselr

Re: PRIZM Disassembler

fxdev

Re: PRIZM Disassembler

JosJuice

Re: PRIZM Disassembler

AngelFish

Re: PRIZM Disassembler

z80man

Re: PRIZM Disassembler