Chilly Willy

Sounds good! I still hold out hope to being able to use my 65XE with the AtariMax Flash cart.

That's pretty much the way Psygnosis handled music on the Amiga. If you look at MODs made from their games, the instruments are usually identical across all MODs. Clearly, the game just loaded the instruments to chip ram and swapped just the scores.

Back in the 90's there was an article posted called "Real Programmers Don't Eat Quiche." One of the lines from it has always remained with me as it's mostly as true now as back then... Real programmers don't comment. If it was hard to write, it should be hard to read, and even harder to maintain.

That's exactly how the Justifier for the Sega Genesis worked with two guns. The game enables one gun on one frame and reads the value, then enables the other gun on the next frame and reads the value.

Yep. If the team had been successful WITHOUT Ross pumping in cash, it wouldn't have tanked. That they needed Time Warner cash to survive says they failed on their own without any need to blame anyone else.

It would be helpful for people not in the know to provide a link for D. http://dlang.org/index.html Anywho, nice little assembler.

Most studies show piracy stimulates sales... if the game is good. Piracy only hurts BAD games - the kind that they try to push as hard as possible without sending copies to magazines for review because they KNOW it sucks and people will only buy it until word of mouth gets around. Lucas Film games did NOT suck. They were among the very best ever made.

That's why I added an auto-map to my 32X port of Wolf3D, which I then ported back to the PSP version. I find an auto-map indispensable on games like Wolf3D, Doom, AvP...

You could try what the Amiga does - all the messages don't go in one queue, every task makes one or more ports that serve as the queue for messages for the task. You allocate one or more signals for each port, so the system knows when signals occurs which ports to process.

How about a plastic case that took the guts of a Saturn controller and a keypad, along with a PIC chip to convert both to the ProPad interface. If you REALLY wanted a crazy idea, there were 6-button Dreamcast pads made (I have eight of them made by MadCatz) - so put a keypad in the area you would put the VMU, and add a PIC to make it all ProPad compatible.

So, the closer to the sun you are, the hotter it is? I don't think it works that way. Ask any mountain climber.

That would certainly be the easiest way to deal with it as well... except for transcendental functions. Trying to add mixed type support wouldn't be as easy, but would be more "fun". Also having the source allows improvements to be made. For example, the issue with FOR/NEXT mentioned - you could extend the code to save the result of the lookup the NEXT op does so that the next time through it's much faster. Things like that.

I love that the Atari had well-documented OS and BASIC, and a great hardware manual. It's part of the reason I went with the A8 instead of the CoCo. Mixed types shouldn't be too hard to handle. The operator can automatically call type converters as it pops arguments off the stack, depending on what it expects. For example, if ADD pops an FP and an INT, it would be easy enough to call INT2FP on the INT arg and then do a FPADD. If it popped two INTs, it just does an integer add. I'd make it where it handles all ints the fastest since that's where people expect the speed. FP is already slow, so making recognition of FP args or having to do type conversion slower isn't a big deal.

The source code for the original Atari BASIC and floating point package was released - in fact, a whole book was devoted to explaining how Atari BASIC worked, where the bugs were, and how to fix them properly. Using that, integers could easily be added to Atari BASIC. Integer vars in BASIC normally make it MUCH faster as was seen in several other versions that used integer vars as opposed to floating point. http://users.telenet.be/kim1-6502/6502/absb.html Grab all the pages and read this from cover to cover. Anyone who hasn't read this shouldn't be considered qualified to comment on Atari BASIC.

You might try this: http://burn-osx.sourceforge.net/Pages/English/home.html

Documentation is important, but even MORE important is mature, bug-free tools. The 68000 compilers were fairly decent by then, but the lack of a decent JRISC compiler hurt. Even the very last compiler version in June 95 (well after the Jag was dead) had bugs. It's why nearly everything for the Jaguar is >95% assembly. Asking devs to do mostly assembly in the early to mid 90's was a significant hold-back.

That first screen says it can't find the title pic in the rom wad file. Sounds like the cart is bad... could be bad card edge, bad lines to the rom, or a bad rom. No telling where the problem lies. Most likely bad card edge. That's what usually goes bad first. Other carts work fine, right?

Nice! Can't wait to get one... finally. Just waiting on details for sending payment.

One thing to remember about burners today is that they tend to operate in zonal mode - they increase the speed as they pass from one zone on the CD to the next. It may start at 20X at the inside, jump to 26X, then to 32X, and so on until it reaches its max speed on the outside part of the CD. Old 1X and 2X CDs in particular can't handle that. You don't need to burn a CD at the slowest speed, but you need to burn at a speed where your writer doesn't use zonal mode. Most burning apps show the write speed while burning a disc. Watch it and look for those jumps in speed. It should either stay the same speed, or slowly increase the speed steadily to work best on old drives. If you see a big jump, forget it! You also need to use high quality media. crappy cheap discs usually fail to read on old consoles. Try a few different brands and use the one that works best for your console. I use Verbatim DataLifePlus discs, myself. Those work on my Sega CDs... don't have a JagCD yet. Remember that the JagCD does NOT use the standard ISO data correction on CDs, so high quality media with no errors is essential! One final thing - I have one old console that HATES CDs written in DAO mode - it prefers discs written in SAO mode, even though there's only one session. Very weird, but that's the way it is. Try different burn methods to see if your JagCD likes one mode better than another.

Contrary to what many people think, CDs do NOT give you extra/better looking data for games in general. Just because you can put 600 MBytes of textures on a CD doesn't mean they can be used in the game. You've only got 2MBytes of ram in the Jaguar, and once it's full, it's FULL. To use more data, you would need to flush any unused data and load the new data from disc. That is exactly the reason PSX Doom has simplified levels and textures despite being more than powerful enough to play the "full" game. To fit in 2MB of ram, many levels of Doom would need to be split into several sublevels and still maintain the same detail as the PC. As it is, the Jaguar cart version of Doom loads textures on the fly from rom since there's not enough room to even load the entire simplified levels and data into 2MB of ram. At least loading from rom is fast. Loading from the Jaguar CD would be VERY slow. In case you were wondering, some levels of (full) Doom at high difficulty setting can push ram usage over 10MBytes. The original Doom code was designed to setup a zone for ram usage of 2 to 6 MBytes in size (for 4 to 8 MByte systems), and loaded the data on the fly from hard drive. You can always tell in a level when the data loads - the hard drive light goes on and the game stutters almost to full halt. It's far worse when trying to play directly from CD, even on higher speed CDs since even 52X CDs usually have 1 to 2 seconds of seek time.

What I'd like is an adapter that takes a Saturn 6-button pad as well as a USB numeric keypad to make a fake ProPad. The Saturn pad is widely accepted as the best pad ever made, and USB numeric keypads are dirt cheap on ebay.

I'll take a shot at it... it would be difficult at best. I2S is meant for simply streaming audio samples, and that's all the Jaguar uses it for. I2C is not only physically different, but imposes a protocol over the data sent/received, allowing for commands to be sent as well as data. I2S has none of that, merely a left/right indicator for the samples.

No sweat. We know what you meant, and most of us agree. It's why games like Doom get called 2.5D instead of 3D - because most people don't consider them real 3D since the data is closer to 2D. True polygon games that reside in a full 3D map are what most people consider real 3D, but those were mostly beyond consoles and computers of the times unless restricted to a bare handful of polys.

Yeah, it's bizarre how something like that happens. I bought mine a few years ago, and now you can't even find an article on it. It's got all kinds of Jaguar awesomeness on it. The high-lights include AvP, Tempest 2K, and VLM.

It's on the Jaguar Source Code Collection CD from JSII.