For anyone interested CyranoJ of Reboot has released the binaries (in *.rom format) for another ST Port, which you can play on the GameDrive. I'm unaware of any current plans to make a physical version of it like some of the other ST ports but you can find it here.

Back when most users were going to need RF anyway it made sense to build it into the system and include an RF switch. By the time the Atari Jaguar launched several game consoles had largely stopped doing that even if they still included RF standard (looking at you, Genesis 2).

The point was obviously to avoid spending money on the modulator if people didn’t need to use it and to MAKE money on an external one if they insist (sell an accessory). Heck, in Japan it was standard to leave out all TV cables and the power adapter so you had to either reuse accessories from other consoles or make additional selections during your purchase. No bundled cables you might not use.

So why did Atari include an RF modulator without an RF switch/lead? Seems like a waste of money when you could sell an external modulator RF switch combo (Genesis 2-style) that uses the AV connections it already has. If you were going to build the modulator in anyway but only include one cable then you should include an RF switch and drop the AV cables, like SNES did when they introduced the Control Set. It just seems backwards the way they did it… especially when the RF users didn’t even have to buy Atari’s RF switch.

At least they weren’t pointlessly tethering a long RF lead like they did with the VCS/2600, 400/800, and 5200.

Hello. I just acquired my own Jaguar cd the other day. And I’m having issues getting my burned games to work. Does it need to be a specific format? I tried bin, cue, iso and nothing is working. Hope this isn’t dumb question. Thank you

I've tried looking for answers but couldn't find any. The game overall isn't bad, but one of the biggest complaints about the game that often gets brought up is the fact that the ship is too big in 2000 and Plus modes. This is a problem because not only do you lose a life in a single hit in this game, but the ship is completely vulnerable to any small projectile that moves very fast and this makes the game more frustrating than it needs to be.

I mention this because I recall reading some comments from people in a few forums explaining that the reason Minter (aka Yak) doesn’t consider Defender 2000 to be one of his best efforts is simply that he didn’t like how big the ship ended up being in the main mode and the Plus mode because apparently, at some point in development, the producer of the game demanded to make the ship bigger than it was before for some reason. The Plus mode was the closest thing to what Minter wanted the main mode to be, but because of the problems with the game’s balance and the size of the ship, he was left feeling dissatisfied once the game was ready for release. Shortly after the release of the game, Minter decided to leave Atari.

So why exactly, was Minter forced to make the ship bigger than it was originally? Why was this decision made out of all of the changes he could have made to the gameplay? Was it due to time constraints? Was the game too easy with the originally intended size? Was the ship hard to see with all of the effects occurring on screen or something like that? These are just a couple of theories I can think of.

Interestingly, Classic Defender doesn’t have this problem.

Captured this awhile back on a 2005 Polaroid, featuring a cool graphic done on a white board in the background, I feel it’s aged like fine wine, how about you all?

https://preview.redd.it/h7od4i738btd1.jpg?width=2027&format=pjpg&auto=webp&s=2e7a61cf310d709ba92cc9bbd05086eaca0467a5

How to start off owning one, any reccomended games or hardware knicks I should be aware of?

Since there’s next to no information about this online, I figured I’d list all of the examples of differences between NTSC and PAL versions and post them here.

For example, the Jaguar didn’t come out in Europe until June 27, 1994, 7 months after its initial release in the United States. Both versions of the console look the same externally, though the NTSC unit has a red LED, whereas the PAL unit has a green LED.

Now here are the differences between the NTSC and PAL versions of certain games:

Music tracks in the PAL release of Evolution: Dino Dudes play at a slower speed than the music in the NTSC release.

The next example is Trevor McFur in the Crescent Galaxy. The PAL version has a cockpit below the level select screen that is nowhere to be found in the NTSC version. The PAL version of the game also seems to show more of the screen, so you can see a bit more of the backgrounds. Although the PAL version is slower-paced compared to the NTSC version, possibly because most NTSC players complained about the game being too challenging, so Atari slowed it down for PAL users to make it less challenging but more tedious.

Another example is White Men Can’t Jump. The PAL version has additional decorated horizontal borders that appear in the intro and menus. These are not found on NTSC.

Same goes for Pitfall The Mayan Adventure where its unique horizontal borders can be seen from top to bottom of the screen on PAL but not on NTSC.

Power Drive Rally is an interesting case because it seems to be the only game in the entire Jaguar library to have two different box arts for both PAL and NTSC, interestingly enough. As for the differences in game, there aren’t any that I can tell.

HUD in the PAL version of Cybermorph was slightly altered in terms of the size and placement of certain icons.

A couple of Jaguar CD games, those being Space Ace and Dragon’s Lair do not work properly on a PAL unit due to compatibility issues. This can be resolved by modifying the console to have a 50hz/60hz switch, or if you’re not using the Jaguar CD, you could also load them off the GameDrive and it’ll work on PAL with no problem without modification.

Are there any more examples I’m not aware of? Other than those differences, I noticed that most, if not all Jaguar games run faster and smoother on NTSC than on PAL.

Hey all, so I'm just now checking out the relatively new BigPEmu emulator, and i'm a little mystified on how to map the controls.

Now initially I wanted to use my Saturn controller (via USB adapter), but it automatically picked up and automapped my Xbox Series X controller.

Which is fine; figured I'd just go with that for now since it already has default mapping for that.

But i'm confused on a couple of things, and also just a little out of the know as to how controls were generally used for Jaguar games.

Now I got into a few Jaguar games a while back on my Android, but played simple games like Zool 2, where there's not much need for more than the 2 or 3 standard buttons.

But now with this awesome emulator, i'm ready to try out all of the other games that just couldn't work before (especially some of the CD games, like Battle Sphere Gold), which I can only assume definitely gets into using the number pad.

The default setup seems to be coherent enough (though a little questionable on the order of the number pad mappings; might make a few changes there to make it more linear), considering there's just no great way to map all of this stuff.. or is there?

And why are there no mappings for the Z, Y, X, L & R buttons?

Were those extra buttons on the later controller basically just used as hot-keys for what would otherwise be one of the number pad buttons?

And along with that: generally speaking, how many of those numbers are actually used? Or in other words: which numbers are more commonly used, and worth having their own buttons (instead of holding L & pressing R3, for example)?

I figured my Saturn controller will be great for some Jaguar, with the 6 face buttons and L & R; basically a replica of the layout (but without the number pad).

So i'm assuming Z, Y, X, L & R would've been mapped to the five most commonly used numbers in games; but what are those numbers?

I would expect them to be 1, 2, 3, 4 & 5, but for all I know, those could be "2, 7, #, 4 & 9".. lol

So if anyone can point me in the right direction, or even just share some recommendations on how / what to map the buttons to, and what controllers they think are best for this situation, I would love to know.

-_-_-_-

Also, bonus question: do they make a Jaguar to USB adapter?
(like my Saturn USB adapter that allows me to use my original, official Saturn controller on my PC)

I would love to use an actual Jaguar controller if possible.

Thanks

New trailer released for an upcoming homebrew:

https://youtu.be/SfxRc8f1lJQ?si=acGAacAN3EtqaDDJ

It looks quite promising in my view, I may buy it if there is a way to get it here in Europe.

I was wondering if this one is as good as the Jaguar GameDrive fro Stone Age Gamer? Says it runs CD images too.

Thank you

https://preview.redd.it/rlwpitwcfmod1.png?width=764&format=png&auto=webp&s=76692a5034c3f62210a003b6725ebc95cd95cf3b

The game cartridges came with the console when I got it a while ago, but I don’t really use them anymore since I play everything on the GameDrive.

I think I now understood how a missing revisions lead to the effect that only some instructions have access to results from the previous cycle. JRISC was meant to be a minimalistic processor implementation. Also they say that they use RAM for the register file. Still it has two ports and is not of the standard variety. But then again this building block (macro) does not specify what happens when read a value in the same cycle that it is written. Maybe they optimized for something else. So the Jaguar designer wanted to stick with a single input register for the second operand. Complications arrive when we have three instructions. The first instruction writes it result into the register file, while the second instruction is executed. In the second cycle the result could be read back and used by the fourth instruction. So one of the operands skips two instructions. The shortcut and flags skips one instruction to better match this?

Another explanation would be that the bus to transfer values from 5 pipeline registers ( ALU, shifter, multiplier, LOAD, short cut and register file ) to the two input registers of the next processing unit is slow. Or at least we would save current and heat, if address and values are all set before we broadcast anything on the bus. It just feels weird to save power at the heart of the chip.

Another weird design is to give the flag evaluation for a branch its own cycle. I think the manual lumps registers and flags in the same sentence in a wrong way. Register values are 32 bit values and routed. Flags are 1 bit and there is some logic to combine them with the 5 bits of the conditional flag. So the opcode needs to be available for this. This is the execution step, isn’t it? Or is there a whole pre- processing step to set the zero flag? Most instructions don’t even set flags. An ALU spits out flags as part of their internal operation. Even if some logic was required, it could easily work. Ah scrap that. MUL, barrel shifter and ALU can all set flags. To easy routing , the zero flag is probably evaluated in the second cycle. Thinking of it, an adder does not know if something is zero. It is more interested in sequences of 1 which propagate the carry. The zero calculation flag needs a sequence of 3 NANDs for 32 bit. So there is some delay, but not much. Maybe Atari used the pipeline stages for debugging . So confusing that RISCV does a comparison between two registers in a single cycle, while JRISC needs three CMP, NOP, cons. JMP + delay Slot .

ALU and shift can set the carry flag independently of the value. So actually, 33 bits are needed on the bus.

I guess that MUL and DIV units were designed internally of Motorola and could be optimized in detail and run basically at twice the speed. FPGAs get their programming as the register transfer logic. Like in the Jaguar manual the hardware exposes non-transparent register bits. These are made of a sequence of two data flip flops. The first closes its input. So it need to wait for the final, stable value for this. The second flip flop then opens its input so that its output moves straight to the new value. The CMOS 386 puts some logic between these data flip flops. Preliminary data or voltages between the logic levels may reach the next stage for a short transient. But on the flip side, we don’t waste as much time on safety settling.

The difficult part is to find a place along the circuit where we have a low number of wires. Luckily, MUL consist of a Wallace tree with 64 bit out put and an adder . So we just need 32 more flip flops. The division unit on Jaguar spits out 2 bits per cycle. Obviously, the division circuit is duplicated. Information goes ping pong between data flip flops.

I once thought if this trick can be applied to the 4 bit adder in the Z80. The result would be 2 odd bits and 4 even bits to pass through the ripple carry. But an adder has side effects. We need to feed the inputs. There would be two input shift registers which shift on alternating phases. Likewise there would be two output registers. Overall, cost is as high as carry look ahead.

Motorola internally surely used these tricks for their Macros, which Atari then wired together.

With such a conservative design, I wonder how the blitter got its pipeline bug.

Ah, the blitter is different. It has 64 Bit registers and 4 16 Bit adders, possibly even with ripple carry. It needs two cycles for an add because is does fractions in one cycle and integer part in the other cycle. For this it needs 4 carry flags and 3 port memory. And either reading or writing to registers need to be part of the ALU cycle to achieve the 2 cycle round trip. Maybe the blitter is even old and optimized enough so that the ALU sits on the odd phase. The blitter can alternate between intensity and z values. So it is not a closed cycle. Also the ALU can add a signed shading value to the source pixels (so destination pixels are darker ). So the state machine can make the ALU address these registers. This is clearly more optimized than JRISC. I just wish that there was no saturation. Why did they not think about it?

I should now probably consult the net list. But it feels like the blitter register file is fully custom. For example there would be accumulator registers and increments. So no two random out ports. Like the LOAD register on JRISC the source register can be written from the outside (only from outside). Like the STORE in JRISC the destination register can only be read from the outside. The CPU can write only to these registers, obviously to save a multiplexer for the read ports. There is only a tiny number. F0227C is total wild. It needs additional skewed word lines ? Or read modify write..but CPU cannot write! I can just assume that JRISC really had a hard time to ROR color and intensity when going to the next scanline.

I got my Jag CIB with cybermorph early 2023 for £210 now it's close to £300 for one without the box? And I got chequered flag CIB too for £33 now it's £53!

im looking into the homebrew side of the system, wandering what the best games for it are

Hello, I've been told there is no support for (and no plans to support) the CD addon in JagStudio, which I can understand.

My question is, is there a toolpath that could allow me to utilize the extra space externally? I've seen some CD specific utilities while browsing the web but nothing that looks like it can stuff a binary on a disc to make it run-able.

Before you recommend it, I have no interest in and no intention of buying / supporting the GameDrive.

Is buying a used Catbox still worth it these days? Will it fit beneath the Jag CD?