MaxCoderz

Ah well, no offense, but you're really reinventing the wheel here, using factoradic numbers is very easy and efficient and guarantees that you will in fact test every possible permutation and never more than once If you really want to continue this way I will try to think of an answer, but I have to...

You can use brute force no matter how you store your node-order, it just affects the speed.

Personally, I would use factoradic numbers for a brute force search (because they take less bookkeeping, and you can can increment them to get the next permutation)

That animation doesn't look exactly right to me - it seems as though the ball initially accelerates off the ground

That assumes your page is known at compile time or you use SMC, and if you go down that road you could just as well do: SwapAppPages: in (6),a label_hack = $ + 1 xor 69^69 (Your applicationg page ^ the other page) out (6),a ret Just write the correct value into label_hack when your app starts..

"How much" is it started? Do you even have an OS? If you have an OS, well, I don't know then, but if you're booting straight into your code.. IIRC it starts up in real mode (which should be its only mode) with paging disabled at the address 0xFFFFFFF0 (if it's anything like a x86 with a nu...

It's all about a paper-like thingy whatever it is that I wrote, not for any specific purpose unless it didn't fail as much as I thought it did.. (unlikely.. ) So, I know I failed epically, I bet some of the "facts" in it are not even true, that's why I would really appreciate it if some of...

I suspect it's some value left on the bus that gets messed around with a bit or something like that..

No, the reason for it is that the application executes from the same place as that it would be changing, and there is no atomic "change page and jump" so it would go wrong in either of 2 ways: 0) it would change the page first, but then it would end up at some random location and crash 1) ...

I can't find my USB cable anymore, otherwise I would test it as well. But that would be on a TI-84+ and you already tested that, so I wouldn't have added that much anyway. Unless it differs per model of course.

Hm ok, I compared it to: DE_Times_A: ; HL = DE × A LD HL, 0 ; Use HL to store the product LD B, 8 ; Eight bits to check _loop: RRCA ; Check least-significant bit of accumulator JR NC, _skip ; If zero, skip addition ADD HL, DE _skip: SLA E ; Shift DE one bit left RL D DJNZ _loop RET (asm in 28 days, ...

So, now for a little cc analysis. * one iteration of the old version takes 45 or 51 cc's (unless it is the last, then it's 5 less) * (3*X)-3 cc's are added in the new version where X is the number of iterations * 45*(8-X) cc's are saved where X is the number of iterations * in the worst case, X=8 an...

Amazing that I never thought of this before, but in a multiplication you can actually stop after the operand that you are shifting out to test the bits becomes zero (not when , but after , very important difference) because you will never add anything to the result from that point onwards. It makes ...

How would I set that up with latenite/brass? Just add it in the build file?

Oh I already did it the "hard" way (CFF Explorer, manually edited the flags)
But it didn't help - it's running as 32bit process but I still get the error

edit: doh didn't think of that, will fix brass now..

edit2: Ok we have a win!
thanks

Hm 64bit, would that break it? I suppose it could..
edit: would it be fixed if I ran LateNite in 32bit mode?
edit2: no that didn't work..