Atari Jaguar Homebrew Project – Update (Weeks 1 – 4)

In order to keep from killing myself with backlogged posts regarding my various projects I will be lumping the work I’ve done so far into logical single posts. All future updates will get their own weekly updates (I promise 🙂 ).

Weeks 1 – 4 had me dealing with two foundational topics, 1. Setting up a tool chain for writing software for the Jaguar and 2. Learning the ins and outs of the Motorola 68000 along with its assembler language. Lets first take a look at some of the tools I am using, how to get them, and my experiences with them.

The tools I am using is actually a collection of tools (including the linker VLink, C compiler VBCC, and an open source assembler based on the original Jaguar assembler (MAC) called SMAC) that appear to be in common use in the homebrew community. These tools are provided on Michael Hill’s website (http://www.hillsoftware.com/?page_id=14) and has versions for OSX, Windows XP/Vista/7 and Linux. Other helpful downloads, such as development docs and technical documentation, can also be found there. As for documentation, I am using the official development docs Atari released after the Jaguar failed commercially. Michael Hill’s site also offers those docs.

As for running the software I write, I had originally planned to purchased a flash cart and run my software directly on an Atari Jaguar. The board I have purchased and expected to use is the SkunkBoard v3 provided by Goat Store Publishing (http://www.goatstorepublishing.com/). Unfortunately, the producers of the board had run into some issues acquiring the components necessary to produce the boards, and as such delayed the ship dates for the boards from February 16th to sometime in May 🙁 Due to this delay, I have fallen back to using an emulator for running my software. The emulator, Virtual Jaguar(http://icculus.org/virtualjaguar/), is the most accurate emulator available but has also been noted for having some differences in execution between it and actual hardware. While I would greatly wish to run my software on actual hardware, finances and forces outside my control have limited me to software emulation. I have gotten many of the pre-packaged demos Atari released with their SDK to compile and run on the emulator, so I am confident that my simple programs should run on the emulator with little issue. Once I do get the SkunkBoard, I intend to experiment with the Jaguar even further.

Now onto the Motorola 68000 (aka the 68k). Most of my research has been focused on 3 sources, The Motorola 68000 User’s Manual (http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf), a 68k assembly reference I found online (http://www.scribd.com/doc/418461/Easy-Motorola-68k-Reference), and The 68000 microprocessor : architecture, programming, and applications by Michael A. Miller (ISBN: 0675205220). With these resources, I began reading up on how the processor worked and what features the language offered.

In order to more easily acquaint myself with the language I decided to write a few simple math functions. I wrote a function for calculating the cross product for a 2D vector, the dot product of a 2D vector, and an implementation of the Taylor series Sine function. The first two functions came along easily. Calculating the Taylor series Sine function introduced a very interesting limitation. The 68k processor offers 8 32-bit Data Registers and 8 32-Bit Address Registers. With the cross product and the dot product, I never ran into much issue storing the products and sums i was calculating. Furthermore, I did not need to implement any sort of fractional value representation for these functions to prove they worked. With the Taylor series function, I had to deal with both issues.

To deal with fractional values, I used a fixed point notation where 4 bits were allocated for fractional value expression and the other 28 bits were available for whole number representation. The reasoning for this split was to ensure I had a high enough ceiling for the large values the Taylor series function produced with its factorial calculations while giving me the minimal number of bits necessary for expressing a meaningful range of fractional values. Sadly, despite my tweaking of the bit separation of the fixed point value, I had found that after only 3 or 4 iterations through my function, bits would get pushed out of its containing register when the factorial values were calculated and the resulting division would often be small enough that my lack of fractional precision would skew my calculations further. I never did get the function properly working (as it was only an exercise and I would probably use a table to store precomputed sin values in actual production), but still came up with a couple neat ideas for trying to mitigate my bit issue. Beyond values shifting out of the register, some of the operations (mul and div in particular) had limitations with the bit width of the values in question. The mul operator requires 2 16-bit values for its factors and computed a 32-bit factor. However, often I was finding that my values were wider than 16-bits. To get around this, I wrote a small sub-routine that would take the 2 32-bit factors, split them into 2 sets of 2 16-bit factors such that the first pair would be the 16 high bits of the two original factors, shifted right by 16 and the second pair of factors was the low 16 bits of each factor, whose high 16 bits were zeroed out. Each pair was multiplied together using the built in mul operator, the product of the first pair was shifted left 16 and bitwise anded with the product of the second pair. I felt this was rather clever myself 🙂 The issue I have with the div operator was the fact that the operator takes a 32-bit dividend and a 16-bit divisor. Often I found myself with a 32-bit divisor. To solve this issue, I implemented a Shift and Subtract algorithm (http://courses.cs.vt.edu/~cs1104/BuildingBlocks/divide.030.html).

All in all, this series of exercises gave me a great reason to acquaint myself with the various operators offered by the 68k while simultaneously putting me face to face with some of the 68k’s relevant limitations. Next time I will discuss how input is handled by the Atari Jaguar.

Cheers and have a good one Internet,
Sam Bushman

Leave a Comment