Page 1 of 1

The Jaguar source code thread

Posted: Sun Apr 27, 2014 6:40 pm
by a31chris
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

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

MK3/FF7/Resident Evil sources

Tomb Raider ... ommentary/

Descent 1-2

Magic Carpet 2

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.
JagDoom source, provided by Carl Forhan. Readme and licensing agreement included in zip.
(306.72 KiB) Downloaded 282 times
Checkered Flag Rev9 Sources
(4.66 MiB) Downloaded 311 times
(1.37 MiB) Downloaded 309 times
Trevor McFur in the Crescent Galaxy
(185.19 KiB) Downloaded 316 times
Near as I can tell this is Club Drive
(2.72 MiB) Downloaded 302 times
Atari Jaguar Alien
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 310 times
Breakout 2k sources
(1.38 MiB) Downloaded 258 times
Tools source codes
Jaguar Cartridge encryption files
(190.62 KiB) Downloaded 255 times
CD encryption files
(98.87 KiB) Downloaded 248 times
GPU asm wait state detector
(12.05 KiB) Downloaded 325 times
(324.33 KiB) Downloaded 305 times
I'm not sure what this is. Your guess is probably as good as mine.
(105.81 KiB) Downloaded 297 times
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 310 times
Stock Atari SDK 3D renderer. Latest files are from September '95.
(519.71 KiB) Downloaded 304 times
tri.h and Triinter.h. Reported 'missing' files from the renderer source.
(2.27 KiB) Downloaded 269 times
(771.43 KiB) Downloaded 302 times
(511.51 KiB) Downloaded 285 times
Jag Util
(161.41 KiB) Downloaded 299 times
Random Jag development files
(2.61 MiB) Downloaded 312 times
Misc Jag
Cinepak, audio engines. Mid '95
(60.13 KiB) Downloaded 298 times
Jim Elliots
Jim Elliot's disk. Programming files for Jaguar from may 95. See below for more info.
(354.08 KiB) Downloaded 264 times
Development tool sources listed above are now bundled here:
Tool sources

Re: The Jaguar source code thread

Posted: Fri May 30, 2014 3:53 pm
by a31chris
Regarding the JagDoom source code Chilly Willy wrote: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.
Regarding possible JagDoom optimizations Chilly Willy wrote: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.

Re: The Jaguar source code thread

Posted: Mon Jun 09, 2014 6:46 pm
by a31chris
Concerning the Atari Rendererer Gorf wrote: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.

Re: The Jaguar source code thread

Posted: Tue Feb 16, 2016 9:55 pm
by a31chris
New updates to the first post in this thread.

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.
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"

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"

RealPixels/ II.5 Greg Ward, "Real Pixels"

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"

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"

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

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

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
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 above

Re: The Jaguar source code thread

Posted: Wed Feb 17, 2016 8:24 pm
by a31chris
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.

Currently a dead lonk . Locatable in above bundles.

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.

I think Eric Smith was having the Jaguar build Toruses to test triangle drawing speed while he worked on improving things.

Currently a dead link. Locatable in above bundles.



Code: Select all

// mkbnd.c - utility to convert 3d studio (*.asc) text files into *.inc source files
I am going to actually include the entire Zip of the 'jaguar' directory I found this in. It was in an unsearched directory buried deep. There is another implicit in the BIN directory that's a TTP file. I'm assuming that's ST. Plus some other late files that are in TTP format. I'll let someone else look at it who has an ST. Also an encryption 'ENTEST' folder for testing encryption? It seems to be the same date as the standard encryption tools already out there. I have a suspiscion that this is another Eric Smith directory.

Currently a dead link. Should be parable in the above bundles.

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. Will see if these are the files Mike is looking for. They are timestamped around September 94 though. Kinda old. Since they are in the same related family of files I am putting them together in one zip. Interesting that they were nowhere near each other and its dumb luck I stumbled across MKBND. I will touch base with Mike Fulton and see if this is what he was looking for.


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.

Re: The Jaguar source code thread

Posted: Tue Feb 23, 2016 11:26 pm
by a31chris
Random files:
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

I started messing with the SIZE program trying to get it to compile. It needed files I had to hunt for through old Atari files but I got it all together. So here it is the complete directory in full in case anyone is interested.

Currently dead link

Now it just has errors which look mostly related to old versus new C standards.
msg-3107-0-69299800-1456444433_thumb.jpg (11.48 KiB) Viewed 6223 times
This program has historic value so it would be interesting to see it up and running and doing it's thing regardless.
Truthfully I am not even sure what this program does. Is it some kind of disassembler?

Re: The Jaguar source code thread

Posted: Thu Mar 10, 2016 2:44 am
by 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
; 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.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ... t=4638916

Re: The Jaguar source code thread

Posted: Sun Jul 14, 2019 5:57 am
by a31chris
All downloads have disappeared from the forum Aaargh.. what is going on over here.