Quote from: thepenguin77 on April 20, 2011, 05:24:29 pm

FloppusMaximus actually got a DMCA about his original flash unlock.

Are you serious? Also when was that? *wonders what was violated by unlocking flash*

Ok, so this is what I remember reading. It was not a DMCA, but it was pretty close. Of course I don't know the whole story (I was 9 when that was posted), so you'll have to get someone older to explain what really happened.

And since I had to go hand copy the link from my old computer, here is the topic that I've had favorited for over a year from which I figured out how to unlock flash. It's by floppusMaximus and you can see on page 2 how cautious everyone is getting. It's pretty vague on the details so it took me quite a while to figure out how to do it...

Yeah, sorry I didn't give you a more specific response. Flash stuff is more IRC talk anyways.

But don't forget, once you get flash unlocked, that's only half the battle. You still have the whole task of actually getting the modifications in the right place. A task during which I have destroyed about 200 wabbitemu OS's and about 10 real calculator OS's.

If you want an interrupt every 150 cycles. You would want to output a 9 with your timer speed being cpu / 16.

And to make sure it keeps going, you need to output to port $31 and maybe $32. The problem with outputting to $32 is that you are doing your interrupt so fast that those extra 20 clock cycles of output are going to add up quick. However, don't miss an interrupt or else $32 is going to loop to $FF.

So for code, this is my recommendation:
start:
ex af, af'
ld a, 3 ;3 because you want interrupts, and you want it to loop
out ($31), a
exx

;don't check for which interrupt caused
;only have timers enabled

;do something quick

exx
ex af, af'
ret
end:

And remember, keep the interrupt quick, you've already used 44 of your 150 t-states. Too many more and the real program is going to stop all together.

bcall(_closeEditEqu)

The edit buffer is probably open. If the hook intercepts from the homescreen then you need to close the edit buffer before you can do anything. When you are done, make sure to bcall(_jForceCMDNoChar) or else bad things will happen. Of course you'll have to watch for the cases where the hook is being run from a basic program, then you don't need to do bcall(_closeEditBuffer), and you most certainly don't what to do bcall(_jForceCMDNoChar)

Now, I've never actually played Ti-Boy (I should) but I know that the grayscale is not as good as it could be graphics wise. The reason why Ti-Boy can't get great grayscale is because it uses all of the cpu time emulating games. But I think I have found a way to make it work really nice.

For my Chess game, (which people have said has perfect grayscale,) I refresh the screen between 59-61 times per second. Of course the user adjusts this because every calculator is different. And 60 fps takes a pretty big toll, that's 50% of the cpu time. But, another option is to refresh the screen at 30 fps and still match the refresh rate. So essentially, write to the screen buffer, let it get displayed twice then update it again. This method gets some minor scan lines, but it's consistent; there's no flicker.

So to Calc84:
I don't know how you do your grayscale. But if you are using interrupts, make a two stage cycle. Using the crystal timers, make the first stage a static length of 172 at speed $40 (10923Hz) When this interrupt comes back, don't do anything. Then send out a second interrupt of user adjusted length default at 172. When that comes back, update the screen and repeat.

Of course I don't know if this sort of thing is feasible, but if it is, you'll have people talking about how good the grayscale looks . (If you get really desperate, you could even refresh at 20 fps, but I don't know how that would look)


Here's a demo to show what I'm talking about:
+ and - adjust delay, 2nd displays delay, and clear quits

There's room on the end of almost all the pages for code. The amount just varies by OS.

But I would say you are much better off just making an IM 2 interrupt that that ends with jp $0038. It has exactly the same benefits as IM 1 interrupts but it is OS version independent. The reason I say this is different OS's do different things down at $0038 and adding code there could be difficult.

Also a ninja for me. So here's my explanation.

Ok, I'll break this down all the way.

bcall(_OP2ExOP5) is actually bcall($4216) which is actually

rst 28h
.dw $4216

my previous bcall(killCalculator) is actually bcall($0083) which is actually

rst 28h
.dw $0083

When the calculator encounters the rst 28h, it goes to $0028, which takes the next two bytes and parses them.

If the next two bytes are in the $4000 - $7FFF range: It looks on page $1B/$3B/$7B for the location data.
If the next two bytes are in the $0000 - $3FFF range: It looks on the first page of the app that is running for the location data.

The data that it is looking for is going to have this format:
.dw address
.db page

So when bcall(_OP2ExOP5) is executed. The OS is going to look on page $7B at $4216 for the data, which happens to be (in 2.53) $C8, $1D, $00. So the calculator is now going to call $1DC8 on page 0.

When bcall(killCalculator) is executed. The OS is going to look at the current app page ($69) at $4083 for the data. Which might be: $00, $40, $01. So the calculator is now going to call $4000 on app page 1, (which might be $68).