That is probably the best method (reading it a few times). You won't absorb everything at first, but as you get practice and you learn something new, it will eventually all get absorbed
Aww, I was going in the completely crazy direction...
Spoiler For Spoiler:
{a,b,c}={m2-n2,2mn,m2+n2} From there I did: 200=m2-n2+2mn+m2+n2 Which simplifies to: 200=m2+2mn+m2 200=2m2+2mn 100=m2+mn 100=m(m+n)
That told me that m and n had to be less than 10. I got nowhere. Then I realised that the result was not likely to be a primitive Pythagorean Triple. So I took the prime factors of two hundred: 200=23*52 I divided by the highest factor (5) and got 40 20=m(m+n)
So m had to be less than sqrt(20). That got me to m=4, n=1. So: {a,b,c}={m2-n2,2mn,m2+n2} {a,b,c}={42-12,2*4*1,42+12} {a,b,c}={16-1,8,16+1} {a,b,c}={15,8,17}
That gives us 15+8+17=40, so multiply those by 5 and you get: {a,b,c}={75,40,85}
Well, ironically, I have always seen 11 as a pretty number because it reminds me of a mix of rational and irrational concepts (B=11) as well as a mix of the colors black and white. Anywho, I am trying to think of my calcy's name. I'm thinking Brika or Bri for short. (Pronounced bree-kuh)
Yeah, I don't see the necessity, either. Is it hardware that does that? I know there is a memory map mode that doesn't do this...
I believe it mostly has to do with how the chip is set up for flash and ram. In one memory map mode, you have page 0 in 0000-3FFF, some flash page in 4000-7FFF, a ram page (82 I think) in 8000-BFFF, and ram page 0 (81 or 80, I can't remember) in C000-FFFF.
Yeah, in the second memory map mode, page 0 is in 0000-3FFF and if page x is in 4000-7FFF, then x+1 is in 8000-BFFF and then whatever other page you load goes into C000-FFFF (at least I believe that is how it works... I haven't experimented with it yet )
You know, I have a question. Why is it that the filesize of an App on the computer is always several times bigger that what it will actually be on the calc?
Because there's more stuff on the computer than there is on the calc. There's header stuff for the app and more. I don't know why it would be several times bigger, though.
It is because the data in the App is stored as hexadecimal instead of bytes, so it should be over twice the size of the actual code. There are about 9 or 10 bytes (I forget) before the actual hex data and then I think there are either 16 or 32 bytes of code following (32 or 64 hex digits).
Ah, usually using bcalls is slow, so I try to make routines that replace them. As an example, the horizontal commands can run over 10000 times in a second at 6MHz EDIT: And I stress "usually" because some cases aren't too bad. Also, the faster horizontal command can execute over 14 000 times in a second
Show Posts
