The UnDisbeliever’s Development Log

Real life has taken it’s toll on my SNES projects.

I’ve decided that my Math Library is a bust, it is just too expensive and complex to implement. I realized this after I finished the Addition section of the library and realized it was 66 MB in size and uses 3.2 CPU seconds (on my Celeron M 1.4Ghz laptop) to load the library and 2.3 CPU seconds to execute the macro. It is just too annoying and complex to deal with.

I’ve set a goal to write at least three short or one long SNESdev.net wiki page/pages a week. Last weeks page was Accumulator Addition. This week I’m just going to work on some register pages.

For the moment, I’ve been studying for my send of semester exams. Exams start in a few hours and will last me until the 26rd, at which point I’ll have moved back in with the Parental Units. I will have finalized everything I need and have the next few stages of my SNES Development tutorial published.

Well this update features another small hit of bad news. I ran into a bit of scope creep. Well, not exactly; but that is what my Project Management Lecturer would probably call it.

My problem stems from the fact that I must type all the variable types a section of code interacts with. For example this is a small section of the code my python script reads;

  #args byte a, byte b, byte c
  #args byte a, sbyte b, byte c
  #args byte a, word b, byte c
  #args byte a, sword b, byte c
  #args byte a, long b, byte c
  #args byte a, slong b, byte c

 ** SNIP 187 LINES **

  #args slongfrac a, sword b, sfrac c
  #args slongfrac a, long b, sfrac c
  #args slongfrac a, slong b, sfrac c
    #index all,X,Y

    SEP #$20
    read8bitFrom typeof(a) a
    CLC
    ADC b

    convert8bitAccTo typeof(c) c
  #enda

The constant management of all these different arrangements is extremely daunting for me. Rereading some of my script input files, I am unable to determine why I assigned such a variable combination to a code section.

For the past few hours, I’ve been thinking on how to create a series of rules as to how the WLA-DX macro file should be generated, but still keeping some form of efficiently to the code. My new attempt will allow me to write a list of the different variables used for the section of code and get python to iterate through all the probable solutions.

For example, the above section of code, could be simplified as thus;

  #section
  #variable a byte, sbyte, word, sword. long, slong, frac, sfrac, longfrac, slongfrac
  #variable b byte, sbyte, word, sword. long, slong
  #variable c byte, sbyte, frac, sfrac
    #index all,X,Y

    SEP #$20
    read8bitFrom typeof(a) a
    CLC
    ADC b

    convert8bitAccTo typeof(c) c
  #ends

This would allow me to easily see what variables each section of code relates to, and prevent all this scope creep.

I just recently discovered that some of my Math Library macros only use two variables, and that my python script only works with macros that have three variables. I’m blaming my previous bount of annoyingly mindless assignments for not realizing this small problem.

I’ve currently rewritten the WLA-DX macro generator section of the python script to compensate. All that is left to do is update the parser to acept this change and to work on completing the Index Register handler.

I’ve also decided to add some more math macros to the math library, the new list is as thus:

• Addition
• Subtraction
• Multiplication
• Division
• Sine
• Cosine
• Square Root
• Square
• Absolute value of a variable
• Loading a fixed value into a variable.
• Converting one variable type to another.

If anyone has any suggestions as to what other kind of math macros I should add to the list, please let me know.

I believe that I will have this math library completed and fully tested in a week. From there I’ll start thinking about working on a Variable Width Font Library or something.

I’ve finally found some free time to once again work on my SNES Developments.

This week I am working on a simple SNES Mathematics library. This relies heavily on WLA-DX macros and .IF statements to allow me (and others who use it) to accurately preform the following operations:

• Addition
• Subtraction
• Multiplication
• Division
• Sine
• Cosine
• Square Root

This in itself is not interesting at all. The most interesting thing about this library is it not only simple to use, it also allows us to mix and match the following variables types in our expressions:

• byte (8 bit unsigned integer)
• sbyte (8 bit signed integer)
• word (16 bit unsigned integer)
• sword (16 bit signed integer)
• long (32 bit unsigned integer)
• slong (32 bit signed integer)
• frac (fx8.16 unsigned fixed point integer)
• sfrac (fx8.16 signed fixed point integer)
• longfrac (fx16.32 unsigned fixed point integer)
• slongfrac (fx16.32 signed fixed point integer)

In my attempts to make the syntax of this library as simple as possible, I played about with WLA-DX and it’s macro parsing. This is what I have come up with:

multiply sword a, byte b, sword c

This code would take the signed word a and multiply it by the unsigned byte b, storing it in the signed word c.

I’ve also begun to add support for the X/Y index registers. Allowing such code as:

divide word a, X, word b,X, word c

Because there are so many different ways to arrange the mathematical expressions, I will be using python to simplify the task for me. At the moment, I have a simple python script that reads a formatted page of 65816 assembly and generates the necessary WLA-DX macro expressions. I’m slowly adding in support for this script to automatically handle the X/Y index registers for me, so I do not have to type all that code 27 different types (that’s for every combination of X, Y and no Index offset for each of the three variables used).

Even with the help of python, there is still a quite a bit of code to write. Once I’ve got the logistics of the math library done, the rest should be simple.