Last modified on 2011-06-07 01:54:00 GMT. 0 comments. Top.

Well, the past two month or so have been very busy for me. I have been finishing up Project MDI with Dan Morrison (of which I will elaborate more on in a later post, continuing my research into the Atari Jaguar, and graduating from college. On top of all this I am now working at an internship ay Yost Engineering in Portsmouth, OH. Now that things have settled down for a bit, its time to catch up on these post. Now on to the Jaguar!

I would like to start my discussion of the Jaguar’s graphics system by providing a high level overview of the components of the system along with a brief description of what role each component plays. The graphics system on the Atari Jaguar is a unique one. All of the Jaguar’s graphics processors reside on a common chip nicknamed “Tom”. Tom houses three different processors:

– The Object Processor

– The Graphics Processor

– The Blitter

These processors are all connected on two different buses. The common 64-bit Processor Bus is controlled by the CPU when it is the bus master. The 32-bit (16-bit data/16-bit address) I/O bus is used for writing to internal registers and memory. Each of the three processors carry out specific tasks for producing images for the television.

The Object Processor acts as a Sprite Engine of sorts. Using an internal list of image “objects”, the Object Processor writes pixels to a line buffer. These objects represent chunks of video data in memory that may be scaled, translated, and even conditionally drawn. This processor is used predominately for displaying sprites on the screen. The structure of the “objects” the object processor may draw makes quickly drawing sprites to a variety of locations on the screen very simple and side steps the necessity of worrying about a screen buffer.

The Graphics Processor is a sophisticated math processor. With the ability to do dedicated matrix, multiplication, division, and some general computation operations, the Graphics Processor is the backbone of the Jaguar’s 3D capabilities. Some posts on the various Jaguar homebrew forums have indicated that software hacks are possible that allow the Graphics Processor to execute code in main system memory (as opposed to Tom’s dedicated memory space). Such a feat allows for much faster executing programs, as the Graphics Processor can perform complex math operations much more efficiently than the 68k and runs at twice the clock speed! This hack shall be a research topic for a future date.

The Blitter performs two crucial roles. Firstly, the Blitter handles any large, block data copying/modification operations needed for graphical effects. Filling in depth buffers, copying image buffers, and simple post process effects are examples of such tasks. The Blitter has several commands at its disposal for doing comparisons of pixel data and modifications to said data. The second task is partly due to the nature of the Blitter and partly a bug in the Jaguar’s hardware design. The Jaguar was originally designed to allow the DSP (“Jerry”) chip, Graphics Processor, and Blitter to all temporarily increase their system bus priority over all other processors on the system to allow for quick, high priority data transfers/operations. Sadly, this feature is bugged and when the necessary bits are set to allow for such an increase in priority, results are unpredictable. As such the Blitter, in its nature of copying large chunks of data, is the system’s only DMA. This can be potentially problematic as the Blitter has the 2nd lowest bus priority (with the CPU under normal operation having the lowest bus priority).

As stated before, the Blitter can be used for creating depth buffers. This feature when used in conjunction with the Graphics Processor makes 3D image generation on the Jaguar possible. One future research topic I have with the system is to design a simple engine to do real time 3D on the Jaguar. At such time, I will elaborate and dig deeper into how these processors accomplish this.

Well, that sums up my quick, 1,000 mile overview of the Atari Jaguar’s graphics system. Next time I will be discussing the Object Processor in detail. For now, cheers and take care internet!

Last modified on 2011-02-21 07:23:02 GMT. 0 comments. Top.

This time around I have been looking into how specifically input is detected by the Atari Jaguar. Before discussing HOW input is handled by the Jaguar, it seems proper to explore some of the devices used for input. Below is an image of the standard Atari Jaguar controller:



The standard controller features 3 face buttons, a “start” button, a “select” button, a 4 way directional pad, and a 12 button number pad. This makes for 21 buttons in total that must be considered.

The Jaguar featured 2 controller ports on the front of the unit, allowing for 2 controllers to be connected out of the box. A 4 player multi-tap was also released to allow for up to 4 players per console controller port, thus allowing for a maximum of 8 controllers.



Other controllers were also planned, but never released commercially (with the exception of a modified version of the original controller that added 3 additional face buttons that were remaps of existing number pad buttons). Because of this, the extent of my study is to write code to successfully poll an original controller for its current input and interpret the data I get back. Now that the expected types of input devices have been discussed, lets look at how input is requested in software.

Input handling for the Jaguar can be separated into two steps:

1. Request the current input from 1 subsection of 1 specific controller on each console controller port (meaning two total subsections are requested).

2. Read the state of the requested input from mapped memory.

First tackling the first step, requests for input state are written to the JOYSTICK register, which is a 16-bit wide register starting at memory address $F14000. Most individual bits on this register serve some sort of purpose for the input polling process:

Bits 0 – 3: An address of sorts indicating what “row” and what controller on port 1 we wish to get input for.

Bits 4 – 7: An address of sorts indicating what “row” and what controller on port 2 we wish to get input for.

Bit 8: Enables/Disables audio output system wide. High = Audio enabled. Low = Audio disabled.

Bits 9 – 14: Unused

Bit 15: Signals that input should now be polled. High = enable polling.

When looking at how input is queried for, one can make some observations. Firstly, the system allows a programmer to poll 2 controllers simultaneously. This is an interesting side detail for me personally, but I can easily imagine how (especially in multi-player games) one could optimize input handling with such a feature. As for the concept of a “row”, the Atari Jaguar breaks up each controller into 4 rows. Each row corresponds to a group of 6 buttons. What buttons correspond to what row is consistent from controller to controller regardless of port. This means that in order to get the entire state of a single controller, 4 separate polls must be made. Below is a graphic detailing this segmentation of buttons by row:



As for addressing a specific row for a specific controller, the Jaguar documentation offers this table as a reference for a 2-player configuration:

Standard 2-Player Controller Addressing Matrix Outbits Bits 3 – 0 Bits 7 – 4 Port Row 0111 X 1 3 1011 X 1 2 1101 X 1 1 1110 X 1 0 1110 X 2 3 1101 X 2 2 1011 X 2 1 0111 X 2 0

Please take note that ports 1 and 2’s addresses mirror each other when addressing the same row. I’m not real sure WHY this is the case, as the bits that are written to already denote the intended port, but it still makes a difference.

Anyhow, now armed with the knowledge of how to address a specific row/controller and where to write the request, all that is left to do is construct our intended message and write it! Lets say we wish to get the state of row 0 from both ports 1 and 2 while keeping the audio enabled (why control of the audio was placed here is also not immediately obvious to me), we can express this by ORing together several values that represent our intention:

1000 0000 0000 0000 = $8000 ;This will enable our request

0000 0001 0000 0000 = $0100 ;This will enable the audio on the system

0000 0000 0111 0000 = $0070 ;This will set up the system to read row 0 on port 2

0000 0000 0000 1110 = $000E ;This will set up the system to read row 0 on port 1

—————————————- ;OR the whole thing together..

1000 0001 0111 1110 = $817E ;and we get the value to write to JOYSTICK

Now that we’ve written our value to JOYSTICK, we need to get the input data back. How we do this is by reading not one, but TWO registers. Our old pal JOYSTICK will store some of our data, while another register called JOYBUTS (address $F14002) is another 16-bit wide register. As far as receiving data goes, this table indicates what bits represent what buttons based on a specific row being requested. Bits referred to with a B followed by a number refers the the JOYBUTS register at the bit matching the number. Bits referred to with a J followed by a number refers the the JOYSTICK register at the bit matching the number.

Bit Row 0 Row 1 Row 2 Row 3 B0 Port1 – Pause Port1 – C1 Port1 – C2 Port1 – C3 B1 Port1 – A Port1 – B Port1 – C Port1 – Option B2 Port2 – Pause Port2 – C1 Port2 – C2 Port2 – C3 B3 Port2 – A Port2 – B Port2 – C Port2 – Option J8 Port1 – Up Port1 – * Port1 – 0 Port1 – # J9 Port1 – Down Port1 – 7 Port1 – 8 Port1 – 9 J10 Port1 – Left Port1 – 4 Port1 – 5 Port1 – 6 J11 Port1 – Right Port1 – 1 Port1 – 2 Port1 – 3 J12 Port2 – Up Port2 – * Port2 – 0 Port2 – # J13 Port2 – Down Port2 – 7 Port2 – 8 Port2 – 9 J14 Port2 – Left Port2 – 4 Port2 – 5 Port2 – 6 J15 Port2 – Right Port2 – 1 Port2 – 2 Port2 – 3

If a bit is of the value 0, then the button is pressed. A stored value of 1 indicates that the button is not being pressed.

Some of the more astute readers out there may have noticed references made to a C1, C2, and C3. These bits, instead of referencing buttons on the controller, are used to identify the type of controller being used (well, C2 and C3 are). Despite reading and re-reading the section of the documentation dealing with input handling, I could not find a use for C1. C2 and C3 may be compared to the chart below to identify the controller currently connected to the port in question:

C2 C3 Controller Identification 0 0 Reserved 0 1 Bank Switching Controller (Analog Joystick, VR Helmet, Racing Wheel) 1 0 “Tempest” Rotary Controller 1 1 “Standard” Jaguar Controller or No Controller

This covers some of the bits contained within JOYSTICK and JOYBUTS, but what do the other bits do? Well, I’m glad I asked, because here’s the answer!

JOYBUTS

Bits 0 – 3: See B0 – B3 in the chart above.

Bit 4: Identifier of video hardware. 1 = NTSC, 2 = PAL.

Bits 5 – 7: Reserved

Bits 8 – 15: Ignored

JOYSTICK

Bit 0: Cartridge EEPROM output data. (Not sure what this means, other than apparently output from the EEPROM. No further detail was given 🙁 )

Bits 1 – 7: Ignored

Bits 8 – 15: See J8 – J15 in the chart above.

So there we have handling simple input on the Atari Jaguar. As the controller identification table above indicates, the Jaguar was designed to handle more complicated controllers known as “Bank Switching” controllers. Since I am kinda cramming to get all my project info up on this site before GDC 2011, I will be omitting handling those controllers and the 4-Player Team Tap for now. Once my other projects are online, I will revisit this post and add that information. Its very interesting, but not terribly relevant to my goals, as I own no “Bank Switching” controllers. I will end this post today with a quick code snippet I wrote to confirm my understanding of input handling. The following is written in 68k asm and lacks any of the bootstrap code needed to initialize the system.

;The following demo is set up such that the program will loop polling for input.

;If UP is pressed, Data Register 0 (d0) will have the hex value 0xDEADBEEF

;written to it and the program will enter an infinite loop.

;If DOWN is pressed, Data Register 4 (d4) will have the hex value 0xDEADBEEF

;written to it and the program will enter an infinite loop.

.text

.globl ___sam

.extern _DrawString

.include “jaguar.inc” ___sam:

;Get input from row 0 of port 1 (I write f for port 2 because I don’t care about port 2)

lea JOYSTICK,a0

move.w #$81fe, (a0)

;Check if UP is being pressed on controller 1.

move.l #0, d1 ;Make sure our storage register is clear

move.w (a0), d1 ;Copy the contents of JOYSTICK to d1

move.l d1, d5 ;Copy the data of d1 into d5 so d1’s data remains undisturbed during the comparison

and.w #256, d5 ;Checking if J8 is 0

cmp #0, d5

;If so, write $DEADBEEF to d0 and go to infiLoop

beq UpLoop

;Check if DOWN is being pressed on controller 1.

move.l d1, d5 ;Since d5 no longer stores the value of JOYSTICK, re-copy it over

and.w #512, d5 ;Checking against J9

cmp #0, d5

;If so, write $DEADBEEF to d4 and go to infiLoop

;else, branch to __sam

beq DownLoop

bra ___sam UpLoop:

move.l #$DEADBEEF, d0

bra UpLoop DownLoop:

move.l #$DEADBEEF, d4

bra DownLoop

.end

Cheers and have a good one Internet,

Sam Bushman

Last modified on 2011-02-21 04:10:21 GMT. 0 comments. Top.

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

Last modified on 2011-02-20 07:54:40 GMT. 0 comments. Top.

This being my first post regarding this project it seems appropriate to first discuss my goals, motivations, and guidelines for this project. My motivation for this project is two fold.

Firstly, being a child of the late 80’s and 90’s, I have a nostalgic interest in the 16-bit and 32-bit era home game consoles. I personally had grown up with a Super Nintendo and a Sega Genesis in my household. Many of those experiences are what led me to pursue game development in the first place. Anyhow, this nostalgic feeling towards that age of console gaming has always given me an itch to write software for one of these home consoles. I’ve wanted to write such software so I may 1. be able to say I had accomplished a task similar to that which has inspired me and 2. learn how these old consoles work. Programming predominately for a PC, using high level languages such as C++, Python, and Java, and having resources such as countless libraries, convenience functions, and a full featured operating system had left me with a lack of understanding as to how exactly code, assets, and content were loaded and utilized on these machines.

Secondly, I needed another class for my final semester at Shawnee State University in order to remain full time 🙂 Due to a combination of having recently acquired an Atari Jaguar, discovering a very active homebrew Jaguar community (along with numerous postings of the development documentation), and my shortage of classes it seems awful convenient to spend 3 credit hours researching the Atari Jaguar and seeing what I could get out of it. Thankfully my professor, Jason Witherell, is a very busy man and easy going. As such, he was more than willing to act as the faculty supervisor for this “independent study” and give me the space and freedom to define the “class” and set my own rules and deadlines.

In short, my overall goal for this study is to research how the Atari Jaguar operates, create an effective tool chain for writing/building software on a PC and executing the built binary on a live Jaguar console. As far as deadlines go, I have broken up the 15 week semester (plus one week of finals) into 4 main categories along with a comprehensive deliverable at the end of the semester.

Weeks 1 – 4: Establish the tool chain, research the assembler language used, learn the ins and outs of the Motorola 68000 processor (The main CPU of the Jaguar).

Weeks 5 – 7: Research how input is handled and write tested convenience functions for polling controller input.

Weeks 8 – 11: Research the graphics hardware and implement a variety of common 2D graphical effects (e.g.: sprite blitting, rotation, scaling, maybe scrolling).

Weeks 12 – 15: Research Audio on the system. Ultimately get an audio asset created on the PC to play on the system.

Week 16: Make a simple PONG game to pull all the concepts together. Also give a presentation of my conclusions and lessons learned.

Future post will detail my weekly progress along with any interesting topics I may run into along the way. For those that may be fantastically interested in any elaboration on this class, you may view the syllabus I wrote for it here: https://docs.google.com/document/d/1bpRXwyLEAhyxMjSh5o2uBS85YItBSpT2NEA4QsB1WuI/edit?hl=en&authkey=CNSroLsN.

Cheers and have a good one Internet,

Sam Bushman