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

Pages: 1 ... 5 6 [7] 8 9 ... 108
91
ASM / Re: IDA Pro
« on: September 13, 2013, 11:33:22 pm »
Congratulations on your purchase of IDA pro (lolz)

Anyways, here's a step by step for you. I'm running 5.2, but I assume everything is about the same. I'm also going to assume you want to dissassemble programs (and not the OS):
1. Close out of any windows so you just have the plain IDA screen
2. File>Open your program
3. Change processor type to Z80 Processors: Z80
4. Ram Section: start 0x8000 size 0x8000. Rom Section: start 0x0000 size 0x8000 (this isn't super important)
5. Loading address: 0x9d95
6. File Offset: If you're using a .8xp 0x004c. If you somehow have a raw binary, 0x0000 or maybe 0x0002

That will set IDA up like the calculator. The data starts at 9d95. Most likely you can press C on line 9d95 and you'll be set.

A few notes:
  • none of the ram addresses are mapped, so use this
  • bcalls don't work obviously, if you see rst 28h, go to the line of code after it and press D twice then look up the address in that link
  • you can probably not make a rom section if you get really annoyed at how tiny the scroll bar is


Have fun! (IDA is actually a lot of fun (if you're into that kind of thing))

Edit:
    If you're dissassembling an app, it's way harder. Let me know if you are. You can't just set the loading address to 0x4000, you'll have to modify the file first.

92
News / Re: Faster Flash Access for the 83+/84+
« on: September 12, 2013, 04:27:07 pm »
Update : I can confirm that resending an OS (2.43) and reapplying all my patches except this one fixes the issue with Axe.

Glad to hear. I'll have to figure out what's wrong.

93
News / Re: Faster Flash Access for the 83+/84+
« on: September 10, 2013, 10:44:58 am »
I am now fairly sure that this patch has at least one negative side effect. I have reports from two users of this patch that, with it installed, scrolling to errors from Axe results in garbage being displayed, corruption of RAM, and possibly other issues (now that I'm testing it again in Wabbitemu, the OS will not boot after the issue occurs). After a short amount of testing, it appears that the error can be triggered not just by instant error scrolling from Axe, but also from DoorsCS. The OS version may or may not matter; both users who reported the issue use 2.43.


I was pm'ing a guy for a while about stuff like this, and the best thing I can come up with is that this patch exceeds the maximum read/write speed of flash. He tried several different OS's and he always had the same problem. The only thing I could blame at that point was his hardware.

94
News / Re: 84+/SE Boot Pages Modified
« on: September 07, 2013, 07:15:13 pm »
I think the only way for TI to prevent any such hacking would be to remove the Asm command and Flash APP support on new models, but since they're popular due to all the programs for them, I doubt that TI would be able to afford to do that, not to mention they might have left ASM support intact on those calcs just so that the TI-Nspire lockdown pills are easier to swallow for us.

I honestly don't think TI could ever lock us out of the 84 line. We just know too much. No one has ever actually looked for vulnerabilities in the 84+, but I'm sure they exist. We have full OS dissassemblies that include every system call and we know the hardware better than they probably do.

You know, now I kind of want to do this. Run asm code in a non-standard way.

95
Yepp, this was a pretty nice piece of work. Though, it had to be pretty thorough to fool some of the people that it did. :)

I made one mistake and critor found it. I didn't add an extra little bit to the OS that TI usually does.

we need zstart for the CSE!
* Sorunome pokes thepenguin

Not a chance. (At least not by me) I hardly have enough time to update zStart let alone make a new one. And besides, I don't have a CSE.

96
I completely forgot how much work I put into this stupid thing. I was looking through the patch file yesterday, and there are 28 independent patches that were applied to the OS. I even designed basically my own bcall system to implement all of the weird "features".

(If you're wondering, it actually worked backwards in that it jumped to a specific routine based on the calling address, not an argument passed by the caller.)


Edit:
    1500th post. I suppose this is a fitting place.

97
ASM / Re: Patching the OS
« on: September 04, 2013, 09:43:07 am »
Well, you may have titled the page improperly because you don't actually need to patch the OS. But when the time finally comes and you want to patch the OS, I did in fact make a patcher. (Physically patching the OS sucks. It takes so much code to make such a small change, even if you know exactly what you want to change).

And while we're at it, I might as well link to my guide on hooks since this information is available literally nowhere.

98
TI Z80 / Re: zStart - an app that runs on ram clears
« on: August 28, 2013, 08:06:05 pm »
Well, I guess now I have to update it.

99
TI Z80 / Re: Thepenguin77's Utilities
« on: August 24, 2013, 03:59:27 pm »
It'd be better for the man himself to answer, but I *think* all of these should work on either model. I don't see a reason why any of theses programs would require the extra ram. There are in fact very few programs that do.

Exactly right. I've actually never made a program that used more ram than what the calculators currently have. I mean, honestly, what are you going to do on the calculator that requires more than like 20kb of ram?

100
TI Z80 / Re: zStart - an app that runs on ram clears
« on: August 22, 2013, 12:47:48 pm »
Feature request: when editing archived programs, they don't get rewritten back to archive if nothing is changed.

Bug report: launching an application from the Omnicalc quick apps menu doesn't register the context switch, resulting any temporary edit copy of archived programs hanging around until the application exits. As the issue occurs under Omnicalc's control, I'll understand if this isn't really fixable, though. It's not a fatal flaw anyways.

The first one seems really easy and obvious.

The second, will probably be a little tough, but I'll try to figure out how it works.

101
TI Z80 / Re: zStart - an app that runs on ram clears
« on: August 16, 2013, 11:20:09 am »
Oops, I'll fix this soon. I should probably add this thread to my watched list.

102
TI Z80 / Re: ZSpeak - Z80 Speech Synthesizer
« on: August 12, 2013, 07:12:21 pm »
This is one of those projects I've always wanted to make but never did.

At first I was very impressed by the size of your sound samples (they are very small) but after listening to the example I feel like you could probably use a bit more data. ;D Did you ever think of trying to use actual sound samples for the letters? This would of course make the file size much bigger, but I think you could probably make a pretty nice sounding bot.

103
ASM / Re: Non-Standard gBuf Ideas
« on: July 21, 2013, 04:08:18 pm »
Ok, I finished it:
Code: [Select]
#define DWAIT in a, ($10) \ or a \ jp m, $-3

copySetup:
        di
        ld hl, $9900
        ld de, $9901
        ld bc, $100
        ld (hl), $98
        ldir
       
        ld a, $C3
        ld ($9898), a
        ld hl, interrupt
        ld ($9899), hl

        ld a, $99
        ld i, a
        im 2

        xor a
        out (03), a ;don't use halt

        ld a, $A0 ;64 t-state timer
        out ($30), a
        ret

; hl is the buffer to use
interruptCopy:
        nop
        ld a, $C9
        ld (interruptCopy), a ;safeguard against running twice
        ld e, $20
       
nextColumn:
        DWAIT
        ld a, e
        out ($10), a
        cp $2E
        jr nz, notDoneYet
        xor a
        ld (interruptCopy), a
        ex af, af'
        exx
        ret ;returns with interrupts disabled
notDoneYet:
        inc e
        DWAIT
        ld a, $80
        out ($10), a
        ld bc, 64*256+$11
        ld a, 3
        out ($31), a ;this is 3*64 = 192 t-states per write
        out ($32), a ; you can refine this, but 192 is probably good
        ex af, af'
        exx
        ei
        ret

interrupt:                      ;19 + 10
        ex      af, af'         ;4
        exx                     ;4
        out     ($31), a ;11 a = 3
        outi                    ;16
        jr      z, nextColumn   ;7
        exx                     ;4
        ex      af, af'         ;4
        ei                      ;4
        ret                     ;10
                                ;93 total

First of all, this only works in 15 MHz. It is actually worse in 6 MHz mode than the regular methods. To use this, call copySetup once, and then call interruptCopy whenever you need to update the screen. It won't let you run it again if it's still updating the screen (this would be bad) so that's good. The only downside is that you can't use interrupts (including getCSC) and you can't use HALT.

104
ASM / Re: Non-Standard gBuf Ideas
« on: July 18, 2013, 05:01:20 pm »
Well, if we're going to keep talking about what's possible. What about this lcd update routine: (This would be the very core of the routine)

Code: [Select]
interrupt:                      ;19
        ex      af, af'         ;4
        exx                     ;4
        out     ($31), a        ;11 a = 3
        outi                    ;16
        jr      z, nextColumm   ;7
        exx                     ;4
        ex      af, af'         ;4
        ei                      ;4
        ret                     ;10
                                ;83 total

I don't feel like actually making the rest of the routine, but this will allow you to update the LCD in around 65,000 t-states in 15MHz mode. (I think it normally takes around 130,000). Also, with a few tweaks, you could make this into a grayscale routine. But I think the coolest part about this thing is that it runs in the background. Essentially you start the lcd update and your code continues to run while this thing interrupts in (rather frequently) and writes another byte to the screen.

A quick calculation shows that this could probably update grayscale using only 30% of the processor time when it usually takes 50%.

105
TI Z80 / Re: zStart - an app that runs on ram clears
« on: June 24, 2013, 01:15:12 pm »
Hey guys: I made a java version of level8, and would like to share it (It requires that you compile the generated z80 source yourself, though, just to be warned.

All of this must be done in one folder: Just compile ("javac IConvert.java"), use "java IConvert" to run, and enter your complete picture filename (including extension). It can be any type, any size, and can have any number of shades. It will generate an all-blue bmp called "saved.bmp" and also create a z80 source file called <pictureNameMinusExtension>.z80 Just compile with SPASM or the like, and you're done!

Well that's pretty cool. Just curious, do you have your own use for this or did you just make it because you could?

Pages: 1 ... 5 6 [7] 8 9 ... 108