Jump to content

ROMs -n-such(JEP#4)


A31Chris

Recommended Posts

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

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. 

Later I will post the BIN in case anyone wants to DOS box it.

msg-3107-0-69299800-1456444433_thumb.jpg

SIZE.zip

Link to comment
Share on other sites

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.

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

PERSONAL.zip

PERSONAL.zip

Edited by A31Chris
Addition
Link to comment
Share on other sites

I do believe the Jaguar has more secrets than Santa's bag of goodies.  Always cool to see more stuff turn up about the console's history.

 

It amazes me how the Jaguar and the 7800 were both programmed on ST computers.  I wonder what Atari would have used for the 7800 if it remained under Warner's ownership?  I don't think the ST would have been thought about nor exist.

Link to comment
Share on other sites

On 12/1/2018 at 9:20 PM, kamakazi20012 said:

I do believe the Jaguar has more secrets than Santa's bag of goodies.  Always cool to see more stuff turn up about the console's history.

 

It amazes me how the Jaguar and the 7800 were both programmed on ST computers.  I wonder what Atari would have used for the 7800 if it remained under Warner's ownership?  I don't think the ST would have been thought about nor exist.

If I were in Jack Tramiel's shoes, here is what I would have done. I would have added 4 MB more RAM in the Jag. I would develop the software only on Atari and similar RISC-based computers, and more of the software titles for the Jaguar would have been produced. I would have used a killer marketing blitz, and since I am a graphic artist I might have done well. I would have released Black Ice/White Noise with the Nine Inch Nails soundtrack, and I would have made it easier to port ST and Falcon titles over to the Jaguar.

That alone would have possibly produced over 300 titles for the Jaguar right away. Also, I would have released the MPEG decoder cartridge, fully completed, for the CD unit so it could play VCDs and other movie discs with MPEG-encoded software. Actually, I would have released the CD unit with a built-in decoder for MPEG compression. Atari had made many blunders, and these actions would have corrected them, IMHO. Well, most of them anyway.

But, I could be 180º off on that as well. But, it would have been a better system if these actions were implemented. Also, I would shoot for more developers to be in the know on how to program this beast, which would make a lot of sense since it needed more developers to make games for it. This is a RISC-based system with five RISC processors in it. That is why the Jaguar can be hard to program for. But, hopefully, for home-brewers anyway, languages like Raptor BASIC+ will make it easier than ever before to make games. I would not mind learning it myself and working on my own games for it. But, I need to learn the language anyway, so it is wishful thinking. 

Edited by DegasElite
Link to comment
Share on other sites

4 MB of RAM?  Yes.  Developing solely on Atari computers?  Maybe but makes sense when some ST models had the Blitter processor.  Easier to port ST titles to Jaguar?  Maybe.  The library of games might have helped.  But I remember ready Jaguar game reviews in magazines and every one of them praised the system but did not understand why it was getting ports of tired computer games.  So, unless those games were missed by the public, porting ST games may or may not have boosted Jaguar.

Here is what I would have done.  Developed a more user friendly development package.  One that is not so difficult to learn.  Sign up more third-party developers. The likes of EA, Midway, and Activision would have been great.  

But, there are a few factors to weigh about Jaguar's downfall.  Lack of third-party support, poor marketing strategies, and hard to understand development tools.  But I believe the biggest factor was timing.  Consider all the consoles at the time Jaguar came out.  Sega had Genesis with a new CD add-on, Nintendo was busy with their new Super NES, NEC was toying around with their TG-16, SNK with NEO*GEO.  A lot of consoles to go up against.  Most of these consoles dealt only with 2D gaming.

On the computer side, very little hardware was needed to play games like Doom.  You really did not need fancy graphic cards as the graphics were generated by software for the most part.  Jaguar was equipped with hardware 3D support, the first of its kind, placing it as the first console to do so.  However, 3D gaming on the scale that Jaguar was capable of was a new concept.  That jump had not been made prior on any console.  Or modern computers for that matter.  Jaguar was simply way ahead for its time but should be considered the console that started 3D gaming on a console.

Link to comment
Share on other sites

On 12/3/2018 at 1:10 AM, kamakazi20012 said:

4 MB of RAM?  Yes.  Developing solely on Atari computers?  Maybe but makes sense when some ST models had the Blitter processor.  Easier to port ST titles to Jaguar?  Maybe.  The library of games might have helped.  But I remember ready Jaguar game reviews in magazines and every one of them praised the system but did not understand why it was getting ports of tired computer games.  So, unless those games were missed by the public, porting ST games may or may not have boosted Jaguar.

Here is what I would have done.  Developed a more user friendly development package.  One that is not so difficult to learn.  Sign up more third-party developers. The likes of EA, Midway, and Activision would have been great.  

But, there are a few factors to weigh about Jaguar's downfall.  Lack of third-party support, poor marketing strategies, and hard to understand development tools.  But I believe the biggest factor was timing.  Consider all the consoles at the time Jaguar came out.  Sega had Genesis with a new CD add-on, Nintendo was busy with their new Super NES, NEC was toying around with their TG-16, SNK with NEO*GEO.  A lot of consoles to go up against.  Most of these consoles dealt only with 2D gaming.

On the computer side, very little hardware was needed to play games like Doom.  You really did not need fancy graphic cards as the graphics were generated by software for the most part.  Jaguar was equipped with hardware 3D support, the first of its kind, placing it as the first console to do so.  However, 3D gaming on the scale that Jaguar was capable of was a new concept.  That jump had not been made prior on any console.  Or modern computers for that matter.  Jaguar was simply way ahead for its time but should be considered the console that started 3D gaming on a console.

Sure. Make it more user-friendly. That would make more sense. The third-party developers you mentioned to sign on would have made it a great force to be reckoned with. It needed top billing. Thanks.

Edited by DegasElite
Link to comment
Share on other sites

Imagine if Jaguar picked up ports of Konami's Castlevania and Gradius series?  Or Capcom's Megaman series?  Sunsoft could have jumped on and brought a Blaster Master sequel.  Compile, creators of some of the best shooters on the NES and other consoles, could have brought some of those over to the Jaguar.  There were so many aspects that could have been but never thought about or executed.  Even if those developers used the Motorola as the main CPU to get their feet wet would have done some good to boost Jaguar's library.  

Always happy to see Jag ROMs turn up.  Its cool to see what could have been.

Link to comment
Share on other sites

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: 
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: http://www.jaguar64.eu/viewtopic.php?f=5&t=205&start=30#p1768

GEMS.ZIP

GEMSII.ZIP

GEMSIII.ZIP

GEMSIV.ZIP

Link to comment
Share on other sites

LIB directory. This is Eric Smiths experimentation and working directories. Most of this stuff is available in the SDKs but some of it isn't. 

LIB.zip

 

BND2MDL. 

 

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. To use a link file,
give bnd2mdl a "-link filename" option, e.g.:

    bnd2mdl    -link city.lnk sf1.bnd sf1.mdl

The link file has the following format:

#name: <band name>
#props
< various special surface properties >
#links
<band name>
<band name>

#name: <band name>

 

BND2MDL.zip

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...