The Jaguar source code thread

[a31chris]

In memory of Curt Vendel.

Without his contributions the Atari community and the Jaguar community would not be what it is today. Among his uncountable charities, Jaguar cartridge and CD encryption would not exist.

Curt we are eternally grateful and will miss you. Your shadow will always loom large over the entire Atari community. RIP my friend.
:::::::::::::::::

Here I will put all the sources that I can link to, zip up and attach or whatnot. Let's start.

Fight For Life sources

JagDoom sources

AvP sources (no art assets)

Ripping AvPs art assets

HoverStrik UL source

Non jag source codes of interest.
These are general sources of interest others have asked about

MK3/FF7/Resident Evil sources
http://www.3do.cdinteractive.co.uk/view ... =21&t=3828

Tomb Raider (OpenLara)
https://github.com/XProger/OpenLara

Descent 1-2
https://archive.org/details/gamesourcecode

Magic Carpet 2
https://github.com/turican0/remc2

Lotus STE(Atari STE racing game)
https://github.com/jonathanopalise/lotus-ste

Attachments below are all dead. Source codes for Jaguar games listed below can now be downloaded in a bundle here:
Game sources

Tool bundle can be found at bottom of tool source list.

JagDoomSource.zip

JagDoom source, provided by Carl Forhan. Readme and licensing agreement included in zip.

(306.72 KiB) Downloaded 492 times

Checkered Flag Rev9 Sources 10-18-94.zip

(4.66 MiB) Downloaded 566 times

Cybermorph.zip

(1.37 MiB) Downloaded 564 times

Crescent Galaxy.zip

Trevor McFur in the Crescent Galaxy

(185.19 KiB) Downloaded 580 times

CLUB.zip

Near as I can tell this is Club Drive

(2.72 MiB) Downloaded 508 times

Atari Jaguar Alien vs.zip

Alien vs Predator source code. I don't think it contains graphics assets. Interesting notes to John and Purple. Also notes about a monster editor.

(639.71 KiB) Downloaded 537 times

B2K_SRC2.ZIP

Breakout 2k sources

(1.38 MiB) Downloaded 471 times

Tools source codes

jagenc2.zip

Jaguar Cartridge encryption files

(190.62 KiB) Downloaded 462 times

jagcdenc2.zip

CD encryption files

(98.87 KiB) Downloaded 461 times

JWARN.zip

GPU asm wait state detector

(12.05 KiB) Downloaded 580 times

2600 Emulator.zip

(324.33 KiB) Downloaded 561 times

POLYTOOL.zip

I'm not sure what this is. Your guess is probably as good as mine.

(105.81 KiB) Downloaded 550 times

HOVERR.zip

HoveRR 3d rendering package. This is not HoverStrike. It seems to be another version of the Atari SDK 3D engine. Most likely the branch off Eric Smith refers to in his notes where he 'produced versions of the renderer
optimized for large polygons' such as Hoverstrike uses.

(582.61 KiB) Downloaded 559 times

RENDER.zip

Stock Atari SDK 3D renderer. Latest files are from September '95.

(519.71 KiB) Downloaded 550 times

TRI.H.zip

tri.h and Triinter.h. Reported 'missing' files from the renderer source.

(2.27 KiB) Downloaded 482 times

Jaz Tools.zip

(771.43 KiB) Downloaded 507 times

Jpeg Sources.zip

(511.51 KiB) Downloaded 497 times

Jag Util Sources.zip

(161.41 KiB) Downloaded 520 times

Development.zip

Random Jag development files

(2.61 MiB) Downloaded 538 times

Misc Jag files.zip

Cinepak, audio engines. Mid '95

(60.13 KiB) Downloaded 515 times

Jim Elliots disk.zip

Jim Elliot's disk. Programming files for Jaguar from may 95. See below for more info.

(354.08 KiB) Downloaded 477 times

Development tool sources listed above are now bundled here:
Tool sources

And the rest of the CD files(includes The Graphics Gems Collection)
All The Rest

[a31chris]

Doom is rather interesting - the rendering is split into stages, each one triggering the next. After a few stages, the variables in ram aren't needed anymore, so the 68000 is allowed to continue running the game logic in parallel to the later stages of the GPU code finishing the rendering. Once you're down to columns and spans (the two graphical operations done in Doom rendering), the GPU starts sending operations to the BLITTER. Funny enough, the 68000 handles all the OP setup for each frame after the GPU finishes the last stage. Having the GPU load later stages of code to work on a problem is very similar to how the RSP works in the N64 - since there is only 4KB of instruction ram in the RSP, the "microcode" is split into sections which are loaded into instruction ram as needed. Given how efficient loading the GPU local ram is, having GPU code load itself in stages could have easily been used by more games than just Doom. It probably would have become standard if the Jag had lasted in the marketplace.

Doom on the Jaguar divides the task of running the game between the 68000 and the GPU, with each being roughly able to run at the same time. The 68000 runs nearly all the game logic, while the GPU runs nearly all the rendering code. Remember that Carmack himself worked on this code. The rendering code had to be broken into NINE SEGMENTS of 4K each. The 68000 runs all the game logic, starts the first GPU segment, then waits until the third segment is done. By that time, the rendering has finished using the game variables that will be changed by the game logic (player position, etc). The 68000 then starts on the next tick worth of game logic. Each GPU segment interrupts the 68000 to blit the next segment into local ram, with the last segment triggering the 68000 to build the next OP list. The GPU uses the blitter as it goes where it can for drawing. If the 68000 finishes the game logic before the rendering is done, it must wait on the rendering. So the 68000 has one spot where it always waits, and another spot it MIGHT wait. It's possible the GPU might finish the rendering before the 68000 finishes the game logic (for example, your nose right up against a plain wall), and so it has one place it MIGHT wait as well.

[a31chris]

The problem with the Atari renderer that is in source form is that it is loaded with a lot of 68k code. Not only that, the renderer itself is poorly written in the fact that it not only uses 16 bit values to work with, but it also uses the matrix instuctions and that it was written to draw one model at a time as opposed to building a list of polygons to rip through, as it should. So for every model you want to draw per frame, it processes each one through all the set up....very inefficient. A good renderer would consider ALL models per frame, build a list of polies and then render them using 32 bit values and instead of the matrix multiply instructions which take WAY too much setup, it should use the MAC instructions which would better handle 32 bit values. Something the MMULT instruction can't do.

What Scott (JagMod) did to speed up the renderer is get rid of the 68k code all together, eliminate all the blits of the code to GPU local and put them in to one big chunk. The other issue with the Atari renderer is it has the GPU stopped completely while the blitter keeps loading in vertices to the RAM. What should be happening is that the verts should be out in main and keep the GPU running at all times. OR use a small portion of the local to have the blitter move the verts to WHILE the GPU is constanly processing them or at least doing something else while waiting for the blitter to load the next set.

A big problem besides the 68k running way too much is the fact that the GPU is constantly waiting in a tight loop for the blitter to finish moving the data.....a ton of wasted cycles right there. JagMod had a small sample code where the GPU never stops working and got well over 80,000 blits PER FRAME using this method. This was a first attempt too.

I maintain that we have not seen anywhere near the true ability of the Jaguar's 3D capabilities just based on these serious flaws of coding inefficiencies. Just about every game uses this piss poor method of GPU waiting and over use of the 68k.

[a31chris]

Also included is Atari's 'Graphics Gems' collection of source codes from the magazine/articles of that time. One of which they actually adapted to work with the Jaguar was implicit.c and can be found in the source bundles.(Root directory of development folder)

[Looked] into this implicit.c program and this is actually a fascinating piece of software. It was written 30 years ago by someone at Xerox PARC, the famous research lab. The function declaration syntax is super old-school K&R C which I recognize but have never worked on anything that actually used this syntax. 

This program allows you to provide any function which takes a 3 dimensional point location as input and returns a Yes/No answer which specifies whether the point is In or Out of the shape, and from this function it generates lists of points and triangles which lie on the surface of that shape and can be used for 3D rendering.  There are functions included for a sphere, and torus, and a 3-point blob. It's nicely documented and seems to be well written.

Also all the anti aliasing seen in HoverStrike I am convinced came from the graphics gems collection.

Snippets from these descriptions:

Graphics gems

Graphics Gems
___________________________________________________________
File Name Archive # Description
-----------------------------------------------------------
2DClip 1 2D Clipping: A Vector-Based Approach
2DClip/Makefile 1 Makefile
2DClip/bio.c 2 Basic operations
2DClip/box.h 1 BOX definition
2DClip/clip.c 2 Clipping routines
2DClip/cross.c 4 Intersection calculation
2DClip/line.h 1 Major definitions
AALines 1 Rendering Anti-Aliased Lines
AALines/00README 1 Information about AALines Gem
AALines/AALines.c 4 Code to render an anti-aliased line
AALines/AALines.h 1 Symbols & globals
AALines/AAMain.c 1 Calling routine
AALines/AATables.c 4 Initialization of tables and frame buffer
AALines/FastMatMul.c 5 Fast routines to multiply 4x4 matrices
AALines/LongConst.h 1 High-precision constants
AALines/Makefile 1 Makefile
AALines/utah.c 3 Interface to Utah Raster Toolkit
AALines/utah.h 1 Declarations for URT interface
AAPolyScan.c 4 Fast Anti_aliasing Polygon Scan Conversion
Albers.c 3 Albers Equal-Area Conic Map Projection

Graphics Gems II

xlines.c I.2 Mukesh Prasad, "Intersection of Line Segments"

Peano/ I.7 Ken Musgrave, "A Peano Curve Generation Algorithm"
Makefile
main.c
mapply.c
peano.c
types.h

Hilbert.c I.8 Douglas Voorhies, "Space-Filling Curves and a Measure of Coherence"

dither/ II.3 Spencer W. Thomas and Rod G. Bogart, "Color Dithering"
dither.3
dither.c

RealPixels/ II.5 Greg Ward, "Real Pixels"
color.c
color.h
colrops.c
header.c
rasterfile.h
ra_pr24.c
resolu.c

rotate8x8.c II.6 Sue-Ken Yap, "A fast 90-Degree Bitmap Rotator"

inv_cmap/ III.1 Spencer W. Thomas, "Efficient Inverse Color Map Computation"
inv_cmap.3
inv_cmap.c

quantizer.c III.2 Xiaolin Wu, "Efficient Statistical Computations for Optimal Color Quantization"

Graphics Gems III

File or Gem
Directory Number Author and Title of Gem
--------- ------ -----------------------

I. Image Processing

fastBitmap.c I.1 Tomas Moller, "Fast Bitmap Stretching" (doesn't compile)
comments: ANSI C

filter.c I.2 Dale Schumacher, "General Filtered Image Rescaling"

bitmap.c I.3 Dale Schumacher, "Optimization of Bitmap Scaling Operations"

rgbvary.c I.4 Bragg, "A Simple Color Quantization Pre-processor"
comments: ANSI C

contour.c I.6 Tim Feldman, "Generating Iso-Contours from a Pixmap"

scallops8.c I.9 Eric Furman, "A Fast Boundary Generator for Composited Regions"

II. Numerical & Programming Techniques

sqrt.c II.1 Steve Hill, "IEEE Fast Square Root"

alloc/ II.2 Steve Hill, "A Simple Fast Memory Allocator"
alloc.c
alloc.h

3d.c II.3 Steven Hanson, "The Rolling Ball"
defs.h

interval.C II.4 Jon Rokne, "Interval Arithmetic"
comments: C++

Graphic Gems IV

CONTENTS:

file or book chapter title and author
directory chapter
------------------------------------------------------------

I Polygons and Polyhedra

centroid.c I.1 Centroid of a Polygon
Gerard Bashein and Paul R. Detmer

convex_test/ I.2 Testing the Convexity of a Polygon
Peter Schorn and Frederick Fisher

ptpoly_weiler/ I.3 An Incremental Angle Point in Polygon Test
Kevin Weiler

ptpoly_haines/ I.4 Point in Polygon Strategies
Eric Haines

delaunay/ I.5 Incremental Delaunay Triangulation
Dani Lischinski

vert_norm/ I.6 Building Vertex Normals from an Unstructured Polygon
List
Andrew Glassner

collide.c I.8 Fast Collision Detection of Moving Convex Polyhedra
Rich Rabbitz

Full file descriptions and files can be found here:

Current dead link. These should all be locatable in the bundles in the first post

[a31chris]

These should all be locatable in the bundles found in the first post

Here are Eric Smith's notes for his 95 work schedule working on the Atari Jaguar. What he accomplished, what he planned etc.
Based on the notes about how he made a text viewer for black ICE/White Noise this points out that the LIB directory posted earlier is his.
To further cement that idea, he talks about Oberon testing, and Oberon files are in here. Yeah... maybe. OK his notes get more specific.

WEEKLY REPORT for Eric Smith
Week ending: 6/23/95


Hoverstrike CD
--------------
Implemented a dissolve routine in the
GPU to run during transitions (i.e.
while data is being loaded from CD).

Well this dissolve routine can be found in the LIB directory with a windows timestamp of being last modified at 6/16/95 at 8:23 am.

I believe that Eric Smith's notes can be somewhat considered a roadmap into the LIB directory and the Render/Hoverr development cycle. Also in this 'Jaguar' directory is one of the latest tri68k.c and blit.h files I can find. Only the jag2rend folder has a later file date.

NEW DISCOVERY

Code: Select all

// mkbnd.c - utility to convert 3d studio (*.asc) text files into *.inc source files

Looking further into the MKBND folder I could see that according to the makefile it was missing at least two files. So a CD search for those two filenames revealed that this is related to the BND2DML folder of files that's in the EP#4 development root directory.

BND2MDL README:

Code: Select all

Building Big Worlds:

To build a large (multi-piece) world, we need to link
bands together. This is done with the "band list".
Each band has a band list, which gives what other
bands need to be drawn and in what order. The bnd2mdl
program generates band lists (and other special band
information) from a "link" file.

[a31chris]

Random files:

Size.zip-
Written by Mike Fulton and Eric Smith
Last Modified: May11, 1995 (according to Windows timestamp. And that file in question claims it was last modified in Dec 94. lol. So who knows! )
Latest modify written about in the files remarks claims a date of 5/8/95.

This program should take a file name with or without extension
read in the .ABS or .COF and produce a list of equates for mac

msg-3107-0-69299800-1456444433_thumb.jpg (11.48 KiB) Viewed 16530 times

This program has historic value so it would be interesting to see it up and running and doing it's thing regardless.

Cubanismo has restored this and other utilities here

[a31chris]

Here is a couple personal notes that are interesting.

Also includes an jaguar.h hardware equates file that seems to be as late as it gets.

Code: Select all

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;	JAGUAR.INC  Hardware Equates for JAGUAR System
;
;	COPYRIGHT 1992-1995 Atari Computer Corporation
;	UNAUTHORIZED REPRODUCTION, ADAPTATION, DISTRIBUTION,
;	PERFORMANCE OR DISPLAY OF THIS COMPUTER PROGRAM OR
;	THE ASSOCIATED AUDIOVISUAL WORK IS STRICTLY PROHIBITED.
;	ALL RIGHTS RESERVED.
;
; Revision History:
; 9/19/94 - Consolidated several files into first master JAGUAR.INC (SDS)
; 2/16/95 - MF
; 4/24/95 - Added UART Error Control and Mask definitions (NBK)
; 5/16/95 - Added Asynchronous Serial/DAC Synonyms (SDS) 
; 8/08/95 - Fixed two Blitter LFU Equates, added ProController equates,
;           added blitter BLITMASK flag, removed MOD_MASK/DSPINT0,
;           removed private hardware register definitions.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

https://atariage.com/forums/topic/31156 ... t=4638916

[a31chris]

Putting faces to the names

Many of those whose work is featured in the above Atari source codes went on to work on the Nuon for VM labs. Here in their alumni page we can put faces to the names for the curious.

http://www.vmlabs.de/team.htm

Hans Martin Krober - Most of the Jaguar sound engine/tools. The HMK folder in the root of the development directory.

Ken Rose - BLACK ICE/WHITE NOISE 3D engine.

Jeff Minter - Tempest 2000, Defender 2000, Jag CD Virtual Light Machine.

John Mathieson - Designer of the Jaguar hardware.

Eric R Smith - Atari 3D demo renderer. Hoverstrike. LIB directory. Graphics Gems fan Implicit.c converter.