Tyrant

Just a not so subtle reminder that This is ending today: eBay Auction -- Item Number: 230500438116 (and so far it's going quite cheap)

What I meant is, surely you don't need a whole new assembler to process the macros for keeping track of the alignments, you should be able to use the macro support in madmac to do the same thing, right? No. With madmac you have to do it manually I believe. With Smac the macros are built in to automate the process. That ws part of the reason smac was created, beyond the ability to be used on new systems. Do what manually? Do you mean manually include the macros; or that for some reason madmac's macro capabilities aren't advanced enough to cope with the alignment issues?

Shameless self bump. Just over 2 days to go on this now.

A question I would expect to see archived here, but oddly was missing when I searched (apologies if I missed it): Where can one find an archive of ST Format disk images? I've got almost all of them on disk, along with the magazines, but they're 40 miles away in storage, and I did have a complete collection downloaded once, but they're sadly gone, along with every site I've ever known that has hosted them. Does anyone know where they can be found currently? Thanks in advance.

No i just said that because i wasnt sure if it was you or not who makes and sells the rotary controllers lol i know now though, i think thats awsome. Yep thats me I'm not the only one who has made and sold them, although I was the first to build them into the controller in that style. Unfortunately I've run out of controllers to modify, so I won't be making any more unless I can find more controllers cheap. Others continue to make them though, so this isn't the last to go, and rotaries are not as rare as some games (or catboxes). Now light guns on the other hand... they're rare (and also pretty much pointless right now).

Thanks i should buy the rotary controller on ebay when i buy tempest2000, i wonder if it helps with the game. I wasn't trying to push my auction, and my recommendation for T2k was genuinely because it's one of the Jaguars best selling points (hell, the Project Tempest emulator was built initially *just* to target that one game and bring it to the pc). But from my experiences it does make a pretty huge difference to the game, although a few people I've spoken to do prefer the d-pad.

If I can chime in here I can almost see where he's coming from. Syndicate is one of those games that I think requires a certain investment in learning before it starts to be really rewarding, and thus is probably not a very good first pick-up-and-play game. Also while I've only played the CD version, I personally don't think that much of hover strike either. It's technically quite good, but the excessive amount of texture mapping doesn't do it any favours since the resolution (of any Jag game) is so low. Iron Soldier on the other hand I do love. However, it's still not really a pick-up-and-play game in the way that doom or tempest is. With IS you have to either read the manual *gasp* or experiment to find out what the controls are. Even moving forward is on the unconventional hold-a-and-press-up. Now while I'm not saying it's not a brilliant game (because it really is), it's not the most easy thing to launch into. Especially since it's mission-based and you have to remember your objectives, navigate a complex map, fight enemies on all sides with a really sluggish turning rate (even the fast turn by holding C isn't very fast), all while trying to work out a control scheme that really needs it's own dedicated controller (e.g. the mech warrior/commander series). However, I would recommend you give it another try, possibly after reading the manual (which is available here on AA if you don't have a paper copy). Also, I would strongly recommend Tempest 2000 as a prime example of what the Jaguar can do. It's a shooter, starts out easy enough, gets quite manic quite quickly, has really impressive visuals and sound, pounding music, and some of the best gameplay on the system if you ask me. All that and it's pretty cheap to pick up (although I have seen people charge silly money for what is quite a common game).

I'm all for that, but I say forget BASIC, it should run FORTH, and be aimed at kids aged 10-35.

What I meant is, surely you don't need a whole new assembler to process the macros for keeping track of the alignments, you should be able to use the macro support in madmac to do the same thing, right?

Just to let you all know I've got what I think is the last rotary controller I'm ever likely to make up on eBay right now. Unless I find some more boxed new-old-stock controllers, I'm unlikely to ever make any more, as I've always liked keeping things minty fresh throughout the production. All of my controllers have always shipped with the original box and plastic bag, and even the twist around the controller flex still attached, untouched since leaving Atari's factory. This is your last chance to get a Tyrant made rotary new. Auctions can be found on eBay.co.uk and eBay.com

Hmm... surely the required macros could be used for madmac too? I've not tried, but the rules concerning the alignment don't seem particularly tricky to follow. That's not going to be an issue for me until/unless someone writes an improved wdb.

Sorry, I perhaps should have been clearer, I meant madmac the Atari macro assembler, vs the more newly written "smac" assembler.

I'm just wondering what the differences are, and what reason there might be to upgrade my toolchain?

The CD BIOS and the Memory Track BIOS code gets copied down below $4000 if they are connected. Ah, fascinating.

Nope, I started playing with the Jag back before they were written. It took me a while to set up my dev tools, and I'm happy with what I've got. I code on an alpine so I have to use wdb (well I could use rdbjag but wdb is so very useful), and that means I have to use win98 in order to get the parallel port to work. Plus I sort of dropped out of the Jag scene a few years back due to real life taking over for a bit, and when I came back, there are all these shiney new tools. I kinda missed most of the announcements, and thus didn't even know about the skunkboard until after it was too late to get one. As for the new assembler and linker... well, the old ones do the job perfectly well, and I don't really know what's different about the new ones or why I should switch. Indeed. Each unto their own. Just so long as that doesn't go so far as gnu automake But yeah, lets not derail this thread, makefiles are awesome powerful tools, and really need not be complicated or hard to understand. I think people get scared off by them when they don't need to be. Make does one thing and does it well: it compares the modification date of the compiled program with the modification dates of all the files that created it, and all the files that created them, and it rebuilds anything that has been changed since last time you ran it. That's all, but it's very helpful.

# # 68k jaguar specific asm files # startup.o : startup.s $(GAS2OBJ) # # 68k jaguar specific C files # jag.o : jag.c $(C2OBJ) These can be replaced with the somewhat more generic version below # # 68k jaguar specific asm files # %.o : %.s $(GAS2OBJ) # # 68k jaguar specific C files # %.o : %.c $(C2OBJ) The difference is that the former rule told make how to make startup.o from startup.s, and jag.o out of jag.c, respectively. The new rules tell make how to make any .o file out of a correspondingly named .s or .c file. For comparison, the makefile format I normally use looks like this: #==================================================================== # Macro & Assembler flags #==================================================================== STADDR = 4000 MACFLAGS = -fb -g ALNFLAGS = -v -v -e -g -l -rd -a $(STADDR) x x #==================================================================== # Default Rules #==================================================================== %.o : %.s mac $(MACFLAGS) $* %.s : %.tga tga2cry -header -f rgb -o $*.s $*.tga #==================================================================== # EXECUTABLES #==================================================================== OBJ = startup.o main.o objlist.o logo.o background.o demo.cof: $(OBJ) aln $(ALNFLAGS) -o demo.cof $(OBJ) #==================================================================== # EXTRA DEPENDANCY INFO #==================================================================== main.o: objlist.inc objlist.o: objlist.inc #==================================================================== # CLEANUP #==================================================================== .PHONY: clean clean: del *.o del *.cof del *.bak The first section sets up macros for the flags past to mac and aln, as well as the address where the code should be linked to, in this case 4000 hex, which is the start of "user ram" I've never worked out what's below that address on retail consoles, or if it's usable, but it's used by the official dev kit for storing code and data related to the link with the debugging pc and other stuff, so the Atari docs suggest linking to there. Of course they suggest code and data should be at 802000 hex, which is the start of cart space (after the encryption header, which goes from 800000 to 801FFFF). The second section contains rules for building .o files out of .s files, and for converting images into .s files out of .tga files by running tga2cry. I have taken to using the -header option, as well as outputting to source code, which provides a global label as well as a header with the image dimensions, and a set of blitter flags. One cute thing about make is that it can do these intermediate transformations. If it finds it needs to make background.o, and has a rule for making *.o out of *.s, but doesn't have a background.s, it will look and see if it can make it, find the rule for making a *.s out of *.tga, execute it, making background.s, then compile that into background.o, and then finally delete the intermediate file background.s. It is then smart enough to still do this even when checking for modifications, so if I change background.tga, background.o will automagically be updated too. Next comes the section where we define the files to be included in the final output. OBJ defines a list of files equivalent to OFILES in the original example, and the next line is the main rule that tells make how to call aln to link all the objects together into a coff format executable. The 4th section tells make about any extra dependancies that it needs to know about. For example, if I were ever to change objlist.inc (a file containing definitions of constants and static variables for my object list building code), then the files which included it would need to be updated. Make can't determine that on it's own, so these lines teach it about those dependancies. Finally the last section declares a phony target called clean, which (when invoked with "make clean") will delete the executable (*.cof), any object files (*.o) and also backup files made my text editor (*.bak).

Hmm... where in this is the Jag being set up? it seems to me that this code takes over after the point that the video registers and basic object list have already been set up, and doesn't cover them in any detail. Which is a shame, because otherwise I would recommend changing them so as to use a 240 line high screen, which is a better fit for both pal and ntsc screens. Still, once you've got basic video set up, something like this would be helpful as a basic starting point for people I suppose.

My only experience playing the icd release of aircars was at the very first JagFest UK, where myself and Stone sat down to have a networked game, and could not stop laughing at how awful the game was the whole way through. From the massive grey boulders that loom over your car when it's damaged (smoke?) to the absurdity of the two giant towers (dubbed the two dildos) that you fly through when you exit the level, to the way that in order to draw a border round the radar mini-map, the developers drew this massive red line on the ground in the game world, everything about that game just seemed poorly done. However, having said that, the 3D was fairly good (except for the aforementioned giant boulders of smoke), the networking seemed solid, and, by playing it networked, we didn't really get much idea of the single player gameplay. I don't think it should be dismissed so quickly. If you can look past it's problems, it looked like it had the potential to be a pretty good game, and this release certainly doesn't seem unreasonable. Producing cartridges is hard work, especially producing BOXED cartridges, and I think £50 is a very reasonable price.

Interesting: That's not a lot of alpines.

Mine is more or less the same as it was some seven! years ago, some additions, no subtractions, and laid out differently (it's been moved three times since then), but still made of awesome. I'm rather proud of that photo actually, it makes for a rather nice way to present my setup (note the old AA skin on the centre monitor, and my old forum avatar being shown on the Jag's TV )

Wow, I remember when you first started buying everything you could see. It was crazy. Now your collection rivals JSmiths. Hell, your collection contains quite a lot of what made his so epic. It was a shock when he started selling stuff, and it's a shock that you are, but I guess all things change with time. Still, at least you're not getting out of the scene all together, and now does seem to be the time to sell, Jag stuff is reaching silly prices on ePay.

I've got a dreamcast wireless gun with a d-pad on the side, does that count?

No, I meant learnt. I'm English, therefore we spell things differently. Deal with it. Sorry, I wasn't actually thinking of your project when I wrote that. Are you using fulsyn or did you write your own music system from scratch? My point was not to tar everyone with the same brush, but point out that the brush in fact has paint on it, not tar. There should be more libs out there, and using them should not be anything to be embarrassed or ashamed of. Imagine if a C++ coder on any other platform decided they were deliberately not going to use stdio, or were going to throw out the whole STL and re-implement basic functions themselves just for the hell of it. They'd be laughed at, whereas here things seem the other way round. Atari didn't supply much useful code, not even a malloc(), and the communities attitude towards libs confuses the hell out of me.

I've been trying to stay out of things for a while now, but there's a few things I just have to say Gorf. What exactly makes a game "Jag worthy", and who is the judge of that? Also we're ALL using pre-made libs. Everyone has to use the Atari supplied startup code if they have any hope of getting things to display right on more than their own TV, and the only people I know of who aren't using the sinister mod player for music are Reboot (who afaik ported one of their own mod players from the ST to the Jag). Given how many basic functions of the Jag are left as exercises for the developers (OP list maintenance for example), I think a nice generic set of library routines can only be a Good Thingtm. I agree, anyone could code simple games (and simple games can be great fun), but not many people are doing so. Why not? How do you know nobody has made use of them. What counts as "use" in your opinion? Maybe nobody has released a clone of them, but that doesn't mean they haven't been useful. Years ago I learnt how BSP trees work by reading the Doom source. I'd read maybe a dozen tutorials before and none of them made any sense, until I saw the code and walked through it in my head. Different things are useful to different people.

I've been in the Jag scene for a long time now, sometimes more active, sometimes less. I've seen trends and patterns emerge and develop, and watched as the same topics are repeated over and over. One thing I have come to realise about this community is that there are a lot of very creative people in it, who have great ideas for what would make interesting games on the Jag, but who, for one reason or another, seem to feel they are incapable of bringing them to life. This thread is designed to address that. Coding on the Jaguar really isn't all that difficult. It requires a bit of time and effort to learn how to do it, and it is perhaps not the easiest platform to work with, but these are quite frankly a very bad reason not to want to even try. So my challenge to each and every one of you is this: You've almost certainly got ideas in your head, what exactly is stopping you making them a reality? And, on the flip-side, what help would you like from the existing developers to make things easier for you?