JAGUAR 64 DEVELOPMENT OVERVIEW ------------------------------ This overview is intended to address some of the questions which the enthusiastic Jaguar market "surface-dwellers" have about the Jaguar 64 and software development by the "Underground". There are a number of people who claim to be writing software, but show no indication of having any idea of what is actually involved, so I fear much of this is imagination only, "imagine-ware" as I call it. Maybe having a bit better idea of what is involved in Jaguar software development will also help more people "take the plunge" in joining other developers. > When will new "Underground" software be released in the US? > Both Telegames and ICD have expressed interest in projects, and so if we can produce some code to impress them in a few months then we may be on for release. At this stage though it is speculative, and whether the same "quality control" issues will apply by Atari in the future over releases is a matter which affects possible releases of our work. Basically, if Atari need to encrypt the cartridge (and don't like it,) then the cartridge can't be released. If that was not the case then it might be possible to release it on a very small EPROM distribution run like "Aircars", and that would be OK. "Aircars" had to be Atari encoded, and the danger is that Atari will say "not a valid developer- no way", and refuse to encode the game because it is an "underground" project. N.B. I'm not talking "OFFICIALLY" on behalf of "The Underground" as an organisation, if it exists, just as an "underground" developer. Maybe they have some publishing method lined up, maybe we'll see cartridges which by-pass the Atari encryption (it is possible, Atari FLASH ROMs do it via an 8-bit cartridge with a special hardware "trick") as well. > I am going to make a Jag game in the near future. > Good luck- you'll need the devkit (near impossible) or Jaguar Server. (There is more information on the Atari devkit and the 3rd party one, from Cross Products, on the "Just Claws Developers Site" pages.) The Cross Products people discontinued their kit when Sega bought them, and Atari will not even help people get NDA status for development these days; it is unlikely that they would sell you a $5000 devkit. The Jaguar Server is what most of us using for development, and so I do not think that I need to say anything about it. However, I do know that some people are official developers on this list, or were, and they do not know so much. The Jaguar Server is a modification to the standard Jag, and is a combination of hardware (new Jaguar boot ROM, patch cable etc., an Atari ST cartridge,) and software for the Atari ST/TT or a Falcon. Software development is done on the ST, or PC pretending to be an ST, and then the software is squirted down the cable to the Jaguar which is, with the new ROM, sat waiting for such data flow to come. The Jaguar Server ROM gives the Jaguar a new O/S with operations like Load/Run for code testing. It can also switch back to normal. If you're using a Jaguar Server you're at somewhat of an advantage over someone using the official devkit- it's give and take really. You can read/write normal cartridge E2PROMs etc., even disassemble other cartridges (heaven forbid). Devkit users can store their code in a 2Mb (or 4Mb) RAM cartridge, so they can develop bigger code, and they get official debuggers etc., but they're pretty hit/miss. You will need a couple of months after getting it before you get any worthwhile results I'd say, presuming you can't dedicate your time. If you just want to code 68000 programs on the Jaguar, then you may find that you are away coding the machine with results in just days. > I know about the Jaguar Server,I was just wondering is there > somthing I could read that would explain the Jaguar's code? > There are a number of things you need to understand to code for the Jaguar, and you need to understand the Jaguar coding is hard work. Jaguar 64 Overview ------------------ - The Jaguar is a 64-bit system, no doubt. It has a 64-bit bus, but not all components are 64-bit. There is no need for that! The 68000 is always said NOT to be the CPU, but in effect it is for most people. Installed in the Jaguar to give the new developer "a nice warm welcome", it usually coordinates the operation of the machine like any good manager, but not doing all the work itself- delegating. (A 68000 is a 32-bit chip with a 16-bit databus.) The GPU is the real intended CPU and is 32-bit with a 64-bit databus. The DSP is 32-bit, with a 16-bit databus. The blitter is 64-bit, with a 64-bit databus for data manipulation, and a 16-bit databus for programming. The object processor is 64-bit througout with local paths to the blitter and object processor. The RAM is 64-bit as well. The Jaguar implements parallel processing. The GPU and DSP can run independently with zero bus loading, and the object processor and blitter can operate together without loading the system bus, along with the GPU. The 68000 is a bus hog given the chance; Atari should have fitted a 68010 or 68020. The 68010 has a tiny reverse pipeline (effectively a cache) and the 68020 has a useful cache, either would have helped. (Note the Co-Jag Jaguar arcade machine which hosted the hit game "Area 51", and others, has a 68020 and more main RAM.) 68000 assembly language ----------------------- - All your early code will be written for the 68000, there's no real alternative, and your program MUST start off using 68000 if you are developing using the Jaguar Server- at this time. (Note, however, you cannot do any sound generation on the 68K, and you need to have a DSP program to do that at some point.) People who have GPU main code generally turn off the interrupts on the 68000, and stop it. Doing that though can be problematic. Object Processor ---------------- - You MUST understand this processor unless you are going to code the Jaguar like an Atari ST or something like that and write all your graphics into a certain "screen" area in RAM. (You can just ignore it, and use supplied code for the screen update. Note that the object processor reads a list, and each frame update the list needs to be rebuilt- this can be done using an interrupt service routine, or a GPU object instead. Note that the OP can scale, but cannot rotate- blitter does.) The Jaguar can "screen" can be practically any size/resolution as although different resolutions can be set, the "screen" is actually just an object, or objects, so you can determine that. GPU assembly language --------------------- - This is the 32-bit RISC CPU, and is similar (but simpler) than a 68000. The problem is that it is VERY hard to debug (nearly impossible except by putting flags in to write to the screen for example) and it can only run tiny chunks of code- you need to write very small code, and page it in/out- which is why so many people use the 68000 for everything. The GPU is hard! The Atari 'C' compiler used for DOOM did paging automatically. (Note, the GPU can do 2 instructions per clock cycle, so fast if you optimise the code to ensure that no register is used in consecutive statements to avoid register contention. If you do this, your GPU can execute 2 instructions- called dual issue.) DSP assembly language --------------------- - The DSP is VERY similar to the GPU, but has a few special new instructions for sound handling (and a few GPU instructions missing) and is very difficult to code, and buggy in some odd ways. It also has a 16-bit interface to RAM (although it can be "loaded" as 32-bit) and so cannot be used generally as a second graphics processor. It also handles the serial ports, and has more RAM than the GPU. This is the networking chip. Again the blitter is VERY hard to debug- and there isn't any real sound code available. Atari supplied sophisticated code to load into the blitter to do wavetable midi sequencing etc.. The DSP is also dual issue capable, providing you optimise it. Blitter Commands ---------------- - The blitter sits on the bus as a 16-bit chip from the point of view of talking, but can read/write 64-bits at a time. It is VERY sophisticated, making it a long-winded pig to program when you're starting. It can do scaling, rotation, and is so fast you'll not believe it. It also does texture mapping and gouraud shading in hardware, and has a share of buglets too. (Note that if you want to use the blitter to scale/rotate, you're pretty much abandoning the OP unless you think hard.) The blitter is a nice chip, and it was designed to do fast polygon drawing, and h/w texture mapping, but the emphasis was on gouraud shaded polygons- not the texture mapped ones. It would have needed some local texture RAM to be faster, and that is apparently what the Jaguar2 chipset was designed for, although in phrase-mode (64-bit, 8 bytes at a time) mode, the blitter is superb, but texture-mapping is very bus intensive. All the above chips work on a priority system. The object processor can suck graphics from RAM and fire them to the screen, but sometimes it can be so keen that it saturates the bus, distorting your sound as the DSP does not get a look-in. This is the sort of subtle problem... The OP does have special flags you can put on object to compensate, but the problem can be that you get distortion on the screen instead. The Jaguar is a multi-processor unit, and is a challenge to code- it is very like a Sega Saturn in that respect- you need to hit the metal. It is also interesting to note that many things which were touted as being Jaguar hardware functions do not exist- at least as described. Claims like "morphing" in hardware were related more to early games- the Cybermorph title screen, and not to the functions of the blitter. On the other hand features like fogging and transparencies are said to be beyond the Jaguar hardware- but it DOES do these in hardware. The Jaguar can do transparencies using either the OP or the blitter. Atari "libraries" were pretty basic- but things like sound and music libraries are not available to underground developers, so they need to re-invent the wheel without the insight from the h/w designers. I also think most people avoid Atari code to avoid any legal hassle. I expect to see ground-breaking code from developers- but not quickly. I'm sorry if I've made any small typos in the document, I've not got all my Jaguar documents in front of me at present. However, if you're interested in programming for the Jaguar then you really should find out more FACTS- read the "underground" documentation on the machine which is available from several sites around the net- go find them!! That information is as good as it gets, no thanks to Atari though. PUBLICATION: ----------- You can publish my observations above, PROVIDING THEY ARE ANONYMOUS! I do not want to be associated in any way with the above information at this time due to the sensitive nature of my project development. Anonymously, I give full publication rights, but not copyright, to the "APS Atari Preservation Society" and "The Atari Times" and the many other not-for-profit publications which support orphan Jaguars. Any revisions to this document will be released to APS, "Just Claws", and probably other web masters who are supporting Jaguar developers.