"Practical" Jaguar Hardware Upgrades

[Atariman]

So it has been a long time since I've actually posted, but there was something I have been mulling over ever since I read through the TOM manual... I have an embedded hardware and software background and I don't think I ever realized just how configurable the Jaguar chipset is until now.  Looking at the schematics and trying to get my head wrapped around the documentation, I started thinking about "practical" upgrades, meaning hardware improvements that could be made that wouldn't require software to be rewritten.

 

While admiring the architecture laid out in the manual, I did see that the chipset can support a relatively wide variety of RAM options.  This left me with some thoughts and questions...

 

1. How much is RAM speed contributing to the bottlenecks in the Jaguar?  If it had RAM available to it that was...say 50ns or faster (versus the 80ns in it now), would there be ANY performance changes, noticeable or not?

2. How widely available is documentation pertaining to the boot ROM?  Based on the TOM manual, there would be some changes that would have to happen to MEMCON when the system starts up.  I think I have my head wrapped around how these should be configured for the most part, but I'm not sure where to start for looking at changing the ROM.

3. Whether due to age of the parts or rarity, I'm not seeing a lot of drop-in replacements that are available.  There are some that are close... but where the current DRAM has signals for Upper/Lower write enable and a single CAS input, the ones I've been finding have had a single write enable with upper and lower CAS inputs.  This would presumably add a need to modify the board to accommodate it.

4. I also see that the manual mentions SRAM, but with the multiplexed addressing used by DRAM, I'm not 100% certain how this would be implemented.  I'm guessing that it would have to be demuxed and I've read more about hardware solutions for that, but I wasn't sure if I'm right.  I'm thinking that SRAM is the use case for the option to turn off refresh entirely.

 

So... thoughts?  I have some spare Jaguar hardware and the ability to make modifications (and lay out PCBs if necessary).  I'm also trying to steer clear of overclocking and other "easy" modifications that have been proven to reduce software compatibility (in addition to adding stress to the hardware).  Hopefully this is a change of pace from the usual 'what if' topics that get kicked around regarding Jaguar hardware.  I'm not thinking that this would be leading to some marketable upgrade or anything like that, merely thinking about what someone could do to get better performance out of the hardware with as few modifications as possible.

 

I was also thinking about the modifications that would be necessary to add a 68020... but that's a mess that I'm not quite ready to wade into (although the TOM manual did get those gears turning in my head as well).  Try and cut me some slack, Jaguar HW gurus... I'm doing my best to get up to speed and not be totally ignorant. ?

[Zerosquare]

The best person to answer your question is @SCPCD. He wrote a complete Jaguar implementation in a (high-end) running with several performance improvements over the original design. So he'll be able to tell you what the actual performance gains would be.

 

That being said, here are my two cents:

 

- Faster RAM will make no difference. The chipset only supports four different timings for DRAM, and the console is already using the fastest one (DRAMSPEED=3 in register MEMCON1).

 

 - As far as I know, the boot ROM is not documented, either officially or unofficially. You'd have to reverse-engineer it yourself. Fortunately, the instructions that set MEMCON1 are at the very beginning of the ROM:

lea     MEMCON1,a0              ;E00008: 41F900F00000
move    #$1861,(a0)             ;E0000E: 30BC1861

Unfortunately, as explained above, there's nothing to be done to make things faster.

 

- I doubt that the performance enhancement from disabling DRAM refresh would be worth the extra complexity and cost of using SRAM and translation logic.

 

Sorry.

[Atariman]

Thanks for the response, Zerosquare - I'm amazed that it is already at its most aggressive timing considering the complaints I have read about Atari's decision to use "slow" RAM.  Knowing this, I'm definitely not as keen on trying to replace it, not even with something that didn't require the DRAM refresh since I didn't figure that alone would be much of a benefit.  I had been looking at the Cojag schematics and wondered why they seemed to use the same RAM and configuration (just more of it), so your answers explain that as well.

 

Any thoughts on the lengthy and arduous task of hacking in a 68020?  I've looked less into this aside from understanding that it should be generally backwards compatible with the 68k.  The thing I'm less certain of is why the bitness of processor is seemingly selected via an input pin on TOM in addition to Bit 14 in MEMCON1.  Is one to indicate the width of the interface to the micro and the other is indicative of the bitness of the micro core?  (and for some reason I can't seem to find the 68020 in the Cojag schematics.  I must be missing something.)

 

Thanks for the responses to my n00b questions.  I know I'm not the first to ask about adding a 68020, but I didn't find these specific questions being asked.

 

Also, I'm most definitely interested in the FPGA implementations of the Jaguar.  It has been quite some time since I've written anything in a hardware description language, but it's something I'd like to get back into at some point.  I'll plan on reaching out to SCPCD at some point to see if there is anything that could be shared...

[Atariman]

49 minutes ago, Atariman said:

 The thing I'm less certain of is why the bitness of processor is seemingly selected via an input pin on TOM in addition to Bit 14 in MEMCON1.  Is one to indicate the width of the interface to the micro and the other is indicative of the bitness of the micro core?

To elaborate the reason I ask is because I noticed that XMA[5] is tied to ground in the schematic and the MEMCON1 register seems to have the 32-bit Micro bit set to 0.  That to me would indicate that it would require a change to the boot rom, but not to how XMA[5] is pulled.

[Clint Thompson]

It's been a few years since I've been down the CoJag rabbit hole and could be confusing the R3000 with the 68020 but from what I remember, they were able to operate the processors entirely independently from the Jaguar chipset so that it could continue working instead of waiting. As far as hacking in a 68020, I assume you mean to be accessed and used externally from boot? Things like that interest me, even if they will most likely result in next to zero people actually using them. The idea of someone trying it and getting it to work would be cool to see.

 

Regarding realistic or arguably 'practical' hardware upgrades, the best of its kind (in my opinion) would be a modernized bank switching cartridge that houses and accesses far beyond 16MB. Sure you could get a GD and eventually be able to access a file system but there are pros and even the interest side to a cheaper dedicated solution to more ROM space. Zerosquare is right in that your RAM speed is going to do next to nothing for you but having 512MB (for example) of bank switchable ROM space at your disposal would be next level. I'm not sure if that falls under your category of hardware improvement without software needing to be re-written as much as it would require new software to take advantage of it but then again, so would adding a 68020.

 

My time has been increasingly limited lately and my goal after the 6MB cart was to tackle 16MB then to try and find a solution to go beyond that but at this rate, it could be years. Either way, would be cool to see what you attempt to do in any case because stuff like that is fun.

[agradeneu]

I think the mindset for old consoles developing is a bit different: do crazy programming tricks on limited hardware and find workarounds in software. This could lead to great results.

Upgrading hardware is not really a good solution: Its expensive, it is a lot of work and it makes software development of games even more limited, as it fragmentates the community.

The Jaguar is quite powerful for what it is, e.g. compared to a Genesis, Super Nintendo or Game Boy (Advance) 

 

 

[+cubanismo]

I didn't think I would, but I've had a lot of fun messing around with peripheral HW bits for the Jaguar. However, I agree with @agradeneu No one is going to actually use the updated stuff or write software to take advantage of it for you. If you're doing it just because tinkering is fun, that's great, I agree. If that's the case, maybe trying to convert a Jaguar board to something that could run CoJag games or very lightly modified CoJag games would be an interesting goal. I assume you'd have to just break it down to components first, but if you found a way to do it with a daughterboard or something, that'd be really cool.

 

For those that have already poked around at CoJags, I'm curious how they wired up the hard drive.

[neo_rg]

A jaguar cartridge with combined ROM and ram would be nice. 

[phoboz]

A proposal from my side is just to add more RAM, 2 Mb is far to little for fighting games (which has large sprites with many animation frames). The NeoGeo CD has 4 Mb of graphics RAM, and even that console could not handle conversion of all NeoGeo MVS/AES games. The reason for this request is that the Jaguar has problems to render graphics stored in ROM, unlike the NeoGeo MVS/AES. Cartridge ROM size is not that big of an issue, as the grahpics can be stored compressed in ROM. It would need to moved to RAM when used, so the in can be decompressed at that time anyway.

 

This memory upgrade was forseen for the Jauguar 2 prototype as well.

Edited October 23, 2021 by phoboz

[Atariman]

21 hours ago, Clint Thompson said:

My time has been increasingly limited lately and my goal after the 6MB cart was to tackle 16MB then to try and find a solution to go beyond that but at this rate, it could be years. Either way, would be cool to see what you attempt to do in any case because stuff like that is fun.

I hear you there.  Most of what I've done so far is just think about some of this stuff.  Once temperatures start to drop here and I can't justify getting work done outside anymore, I'll be spending more time working on this stuff.  I'm going to try something... and I'll share the results once I've either had success or given up!

 

(but I'll tell you that I don't know enough about developing new bankswitching schemes (yet?), so it won't be that (again, yet?) )

[Atariman]

7 hours ago, cubanismo said:

I didn't think I would, but I've had a lot of fun messing around with peripheral HW bits for the Jaguar. However, I agree with @agradeneu No one is going to actually use the updated stuff or write software to take advantage of it for you. If you're doing it just because tinkering is fun, that's great, I agree. If that's the case, maybe trying to convert a Jaguar board to something that could run CoJag games or very lightly modified CoJag games would be an interesting goal. I assume you'd have to just break it down to components first, but if you found a way to do it with a daughterboard or something, that'd be really cool.

 

For those that have already poked around at CoJags, I'm curious how they wired up the hard drive.

Out of curiosity, what have you found with the peripheral HW bits?  I have scrolled past some of that in the manual, but haven't totally tried to get my head wrapped around that yet.  Always curious about what others have discovered (and I will tell you - I have read a LOT of Jaguar hardware posts over the last week or so).

 

I've been digging around in the CoJag schematics a bit and haven't gotten the hard drive interface figured out quite yet.  I've mostly been looking at the hardware configuration differences on TOM, but the hard drive interface has been at least in the back of my mind.

[+cubanismo]

Oh I didn't discover anything new. Just went on a learning adventure rediscovering what others have already done because I was late to the party. I just meant to build myself a BJL adapter and a Skunkboard since they were scarce and I wanted to write some code. Then I ended up going down a rabbit hole and built a lot more Skunkboards, a vga adapter, and a Sega master system lightgun adapter thus far, all just carefully following in the footsteps of others because I enjoyed it. It's all based on info found on these forums or in the manuals.

[Zerosquare]

On 10/23/2021 at 1:00 AM, Atariman said:

Any thoughts on the lengthy and arduous task of hacking in a 68020?  I've looked less into this aside from understanding that it should be generally backwards compatible with the 68k.

I can't say I have ever looked into it. The 68020 is not 100% compatible with the 68000, but the differences are in features Jaguar games probably don't use (exceptions stack frames, and the MOVE from SR instruction in user mode).

A more annoying problem may be that the different timings expose dormant race conditions in the games' code. I think @Shamus (the author of Virtual Jaguar) once mentioned that many games were affected, and @SCPCD had to patch bugs in some of the original games to get them to run correctly in his FPGA implementation.

 

On 10/23/2021 at 1:00 AM, Atariman said:

for some reason I can't seem to find the 68020 in the Cojag schematics.  I must be missing something.

This is going to sound stupid, but are you sure you got the right schematics? There are at least two different versions of the CoJag design, and one of them uses a MIPS processor instead of the Motorola one.

[Zerosquare]

On 10/23/2021 at 2:10 AM, Clint Thompson said:

having 512MB (for example) of bank switchable ROM space at your disposal would be next level.

Sure. It would also be quite expensive (you'd need NOR Flash memory, which isn't anywhere near as cheap as the NAND Flash kind that's used for SD cards and the like).

And the ongoing shortage of silicon chips isn't going to help things, either.

Anyways, I was under the impression that someone here was working on such a design, at least the last time I talked to him

 

9 hours ago, neo_rg said:

A jaguar cartridge with combined ROM and ram would be nice. 

 

7 hours ago, phoboz said:

A proposal from my side is just to add more RAM, 2 Mb is far to little for fighting games (which has large sprites with many animation frames). The NeoGeo CD has 4 Mb of graphics RAM, and even that console could not handle conversion of all NeoGeo MVS/AES games. The reason for this request is that the Jaguar has problems to render graphics stored in ROM, unlike the NeoGeo MVS/AES.

Unfortunately, even if you had on-cart RAM, you'd still get the same access times you already get on the Skunkboard and Jagtopus boards: both use the 5 clock cycles setting, and that's the fastest one that's supported by Tom (to be precise, there's also a 2 clock cycle test mode, but it is buggy). The only way up is to use 32-bit wide memory (instead of 16-bit wide), and I believe that's what the JagGD is already doing.

[agradeneu]

14 hours ago, phoboz said:

A proposal from my side is just to add more RAM, 2 Mb is far to little for fighting games (which has large sprites with many animation frames). The NeoGeo CD has 4 Mb of graphics RAM, and even that console could not handle conversion of all NeoGeo MVS/AES games. The reason for this request is that the Jaguar has problems to render graphics stored in ROM, unlike the NeoGeo MVS/AES. Cartridge ROM size is not that big of an issue, as the grahpics can be stored compressed in ROM. It would need to moved to RAM when used, so the in can be decompressed at that time anyway.

 

This memory upgrade was forseen for the Jauguar 2 prototype as well.

The NEO GEO CD is only single speed, so it needs a much bigger RAM size. The cart system has even less RAM than the Jaguar, considerably. But I agree that 3MB or 4MB would be much better, especially for 8 bit and 16 bit graphics. (BTW the NEOGEO tiles are 4 bit)  But I would say its not impossible to pull graphic/sounds from ROM to save RAM? If I rember correctly, music of Gravitic M. is streaming from ROM. Otherwise the gfx would not fit into RAM.

For a figthing game, e.g. Mortal Kombat Lynx, they are pulling the animation frames from ROM, to make the game run on a system with 64K RAM (!). I think RAM was the main reason many thought MK would be "impossible" on the Lynx. But here we are.

 

[agradeneu]

6 hours ago, Zerosquare said:

 

 

Unfortunately, even if you had on-cart RAM, you'd still get the same access times you already get on the Skunkboard and Jagtopus boards: both use the 5 clock cycles setting, and that's the fastest one that's supported by Tom (to be precise, there's also a 2 clock cycle test mode, but it is buggy). The only way up is to use 32-bit wide memory (instead of 16-bit wide), and I believe that's what the JagGD is already doing.

Question is if the GD is fast enough to stream animation frames for a 1vs 1 fighting game?

[Clint Thompson]

There’s no point of a lot of RAM without a lot of ROM or data to feed it. A CD based system is the only scenario in which it would make sense, outside of the Jaguar having been built with more RAM to begin with.

 

The Jaguars architecture was built as such that it treats the cart as RAM and that’s exactly how I’ve managed over 120 animations and audio voice lines with Zilch on a 6MB cart. I’m not sure what problems @phoboz is having with accessing graphics stored from ROM are (feel free to send me a PM, it is an interest of mine) as I don’t have an issue with it but both face similar limitations. As such, you have to work within said limitations. I’ll have to look but I want to say the Street Fighter Alpha (test I made) sprite and music are both being accessed from ROM with the background and SFX in RAM.

 

The only difference of accessing add-on RAM is that you can write to it, but that is moot if you can just pull the data directly from ROM to begin with.

 

...so then...

 

I would go as far to say that adding RAM would end up crippling the Jaguar even more because the bus constraints would be even greater. Whatever advantage you had previously of pulling assets would be halved, at least. Unless (possibly) you’re no longer pulling assets from ROM only to then shift over to RAM, but why would you? It circles back to where that would only make sense in a purely CD based system. 

 

45 minutes ago, agradeneu said:

Question is if the GD is fast enough to stream animation frames for a 1vs 1 fighting game?

Yes.

[agradeneu]

22 minutes ago, Clint Thompson said:

There’s no point of a lot of RAM without a lot of ROM or data to feed it. A CD based system is the only scenario in which it would make sense, outside of the Jaguar having been built with more RAM to begin with.

 

The Jaguars architecture was built as such that it treats the cart as RAM and that’s exactly how I’ve managed over 120 animations and audio voice lines with Zilch on a 6MB cart. I’m not sure what problems @phoboz is having with accessing graphics stored from ROM are (feel free to send me a PM, it is an interest of mine) as I don’t have an issue with it but both face similar limitations. As such, you have to work within said limitations. I’ll have to look but I want to say the Street Fighter Alpha (test I made) sprite and music are both being accessed from ROM with the background and SFX in RAM.

 

The only difference of accessing add-on RAM is that you can write to it, but that is moot if you can just pull the data directly from ROM to begin with.

 

...so then...

 

I would go as far to say that adding RAM would end up crippling the Jaguar even more because the bus constraints would be even greater. Whatever advantage you had previously of pulling assets would be halved, at least. Unless (possibly) you’re no longer pulling assets from ROM only to then shift over to RAM, but why would you? It circles back to where that would only make sense in a purely CD based system. 

 

Yes.

 

IMO 1 vs 1 fighting is a hard choice for a genre, but not because of technical limitations. I just thinks its incredibly difficult and time consuming to create a game that does not suck.

Edited October 24, 2021 by agradeneu

[+CyranoJ]

A fighting game is entirely impractical.

 

Not because of the Jaguar, but because of the dpad.

[+CyranoJ]

15 hours ago, phoboz said:

A proposal from my side is just to add more RAM, 2 Mb is far to little for fighting games. 

The SNES would like to discuss this with you further at great lengths. 

[agradeneu]

1 hour ago, CyranoJ said:

The SNES would like to discuss this with you further at great lengths. 

Or the NEO GEO AES system

[phoboz]

2 hours ago, agradeneu said:

Or the NEO GEO AES system

The thing with NeoGeo MVS/AES is that it has two separate computers, with two independent busses to different ROMs. This means that it has no problem to show graphics from directly from ROM, while playing sound. If you have that possibility, you don't need much RAM, becuase the graphics never has to be stored in RAM at all. Neo Geo CD on the other hand, needed graphics RAM, and sound RAM. Becuase the 1x speed CD drive had no chance to provide the needed data fast enough.

 

The Jaguar can theoretically show graphics directly from ROM, but in practise the screen will start flickering when you have very many sprites on the screen at the same time. Sound can indeed be played directly from ROM, if the sound player buffers the data (e.g. read sound packages by blocks, and store them on the DSP) I don't know if the same could be done for graphics by the GPU, but I guess you cannot buffer much graphics given the 4k memory buffer of the GPU?

 

Mortal Kombat 2 on the PC kept on loading moves from the harddrive if you han anything less than 8 Mb of RAM.

Edited October 24, 2021 by phoboz

[phoboz]

3 hours ago, agradeneu said:

I’m not sure what problems @phoboz is having with accessing graphics stored from ROM

When I use the object processor to render ~250-300 sprites on the screen at the same time + full screen backgrounds. It will start flickering, if I move all graphics from ROM to RAM, it works fine.

[agradeneu]

1 hour ago, phoboz said:

The thing with NeoGeo MVS/AES is that it has two separate computers, with two independent busses to different ROMs. This means that it has no problem to show graphics from directly from ROM, while playing sound. If you have that possibility, you don't need much RAM, becuase the graphics never has to be stored in RAM at all. Neo Geo CD on the other hand, needed graphics RAM, and sound RAM. Becuase the 1x speed CD drive had no chance to provide the needed data fast enough.

 

The Jaguar can theoretically show graphics directly from ROM, but in practise the screen will start flickering when you have very many sprites on the screen at the same time. Sound can indeed be played directly from ROM, if the sound player buffers the data (e.g. read sound packages by blocks, and store them on the DSP) I don't know if the same could be done for graphics by the GPU, but I guess you cannot buffer much graphics given the 4k memory buffer of the GPU?

 

Mortal Kombat 2 on the PC kept on loading moves from the harddrive if you han anything less than 8 Mb of RAM.

 

The Jaguar works different than the NEOGEO, yes. But I don't see how this backens your verdict that 2MB RAM were not suffice enough for a 1vs 1 fighting game.

There are quite some nice examples that show huge sprites and fluid animations could be done, even in 8 bit and 16 bit color.

Tricks, like e.g. unpacking graphics data on the fly are not possible on the NEOGEO. 

 

Sprites are rendered totally different than on the Jaguar, it's a little bit like apples and oranges really:

 

  https://wiki.neogeodev.org/index.php?title=Sprites

 

The point is, you might be totally flabbergasted how many tight hardware limits imposed on coders of the 8 bit and 16 bit era had to be overcome and worked around to create 

the great classic games, e.g. when I watched how NES games were made its both fascinating and intimitating:

 

 

 

So, enough complaining.

 

 

Edited October 24, 2021 by agradeneu

[phoboz]

49 minutes ago, agradeneu said:

The Jaguar works different than the NEOGEO, yes.

Yes I fully agree, and my verdict was probably a bit harsh.

 

However, it will require some work to port arcade games like the later NeoGeo fighters, and Mortal Kombat. Also I do note that the existing fighters (for example Ultra Vortek) for the Jaguar has a little bit slugish animations (e.g. perhaps not to many animation frames for the characters). On the other hand, I have heard that the sprites for Primal Rage was reduced in size.

 

I can definately see a solution like for the PC port of Mortal Kombat 2. It would be even faster to load moves on the run from the Jaguar ROM, than from the PC harddrive.

 

5 hours ago, Clint Thompson said:

I’ve managed over 120 animations and audio voice lines with Zilch on a 6MB cart

This also sound very interesting, but the graphics cannot be compressed that way. It might be hard to fit a large fighting game uncompressed on a 6 Mb cart? So I do prefer the solution to load, and unpack on the fly.

120 frames of animation is not that much, the predator inspired mini-boss (Rapax) in Asteroite has that ammount of frames alone.

Edited October 24, 2021 by phoboz