If your only exposure to math is undergrad level calculus, numerical analysis, and probability, you probably don't want to start out with computer science by reading The Art of Computer Programming. This is not an easy set of books. They're also not the hardest books out there in computer science, but they definitely expect some kind of background in discrete math and algorithm analysis. I would start with an easier book, maybe Introduction to Algorithms (CLRS), which is also mathematical and treats its topic formally, but is designed for undergraduate students without previous background in the field. You should also get a more solid background in discrete math—topics such as combinatorics, recursion, Big O, number theory—as well as linear algebra. Knuth co-authored another book called Concrete Mathematics that might help with that.
Working through CLRS and Concrete Mathematics is probably enough to start TAoCP. The first thing you should do is work through the math in Volume 1 of The Art of Computer Programming. Knuth covers several of the topics in combinatorics and discrete math that will reappear in later volumes. However, he typically doesn't spend a ton of time introducing you to the math he uses. He doesn't assume you know everything, but he does dive in pretty quickly. I would solve a bunch of the easier exercises in each topic to get a grasp on it, and leave the harder exercises for a cold winter's evening.
As for MIX, I wouldn't even bother with it. Programming in assembly language is not a terribly useful skill today, and modern assembly languages look nothing at all like MIX because it was designed before CPU architectures had standardized, before everyone was using 32-bit (or 64-bit) binary computers and it was sometimes desirable to support decimal computers or computers with kooky word sizes. In recognition of this, Knuth created MMIX, a more modern-styled assembly language, and he's now porting all the MIX code in earlier books to MMIX. I would just ignore the fake assembly code completely. I found that trying to remember MIX's idiosyncrasies was an impediment to learning the high-level ideas behind algorithm; the pseudocode and the prose were much more helpful. If you want to learn about low-level programming, go learn about computer architecture, and maybe learn some MIPS or ARM assembly, but do it separately from your studies of algorithms; it's a huge topic in its own right, and you won't do yourself any service by trying to learn both at the same time.
If, however, you insist on learning MIX or MMIX, you can hunt down one of the simulators that let you actually run the code, and learn it like you would any other programming language: by figuring out what it can do and solving some simple exercises. (IIRC, the book even has some MIX exercises that you can complete.) Again, though, I wouldn't. As much as I love the books, they were created in an earlier time, and some parts haven't aged well. MIX is one of those things.
