T2k Atari Jaguar Emulator

[Firefox]

It's closed source I'm afraid. I had to give a fair amount of assurances to get permission to do the Linux port.

However, I'm working on the RISC core emulation at the moment (and getting some nice speedups already). They're really cool devices, despite a few bugs! You can find out lots of gritty in-depth detail about them (and the rest of the Jaguar) here:

http://www.mulle-kybernetik.com/jagdox/dox.html

It would've been very cool if they'd fitted a third RISC core instead of the 68000, though I suppose the 68000's large fund of tools and know-how would have been a big advantage to developers at the time. Though I seem to remember that they did do a version of the Jaguar as an arcade board with a MIPS R3000 instead. That would have been a cool platform to code for back in the day! B)

 

[Exophase]

It's closed source I'm afraid. I had to give a fair amount of assurances to get permission to do the Linux port.

However, I'm working on the RISC core emulation at the moment (and getting some nice speedups already). They're really cool devices, despite a few bugs! You can find out lots of gritty in-depth detail about them (and the rest of the Jaguar) here:

http://www.mulle-kybernetik.com/jagdox/dox.html

It would've been very cool if they'd fitted a third RISC core instead of the 68000, though I suppose the 68000's large fund of tools and know-how would have been a big advantage to developers at the time. Though I seem to remember that they did do a version of the Jaguar as an arcade board with a MIPS R3000 instead. That would have been a cool platform to code for back in the day! B)



Way ahead of you, I read through that site earlier today. Jaguar kinda sounds like an embryonic Saturn. I mean, just look at it, like Saturn it has:

- 2 RISC cores running at around 27MHz, with 16bit wide instructions.
- A 68k (but on Saturn it's delegated as a secondary CPU, on Jaguar it's the main thing.. not like it should matter that much but in the end I guess it steered how people used it)
- A programmable video processor with flow control (although Saturn has two of them)
- Additional hardware for some 3D stuff (I think Saturn has a lot more), FM synth, wavetable synth.

It's not as powerful as Wikipedia makes it look, but it's pretty powerful just the same (despite some crippling flaws and bugs).

I think having THREE RISC cores wouldn't have done any good for it, having two alone makes it hard enough for devs to adequetly use the thing. I would guess that the machine is already heavily under-utilized most of the time. From what you've been saying it looks like games are relying on the 68k. If standard libraries were indeed used for GPU and DSP code then maybe HLE is the best approach (like with N64's coprocessor).

By the way, since all of the Jaguar's address space is "valid" you might be able to get away with using lookup tables instead of function calls. That's a little faster since on ARMv4 you have to pay for the indirect branch (pipeline stall) and it takes some extra instructions to do it since you don't have blx. The memory table lookups, on the other hand, can be as short as only 3 instructions (although two consecutive ldr's will grant you a stall). It'll also be a little lighter on icache.

 

[Firefox]

Fsck me, I hadn't realised that the Saturn was such a complicated beast!

Anyway, what I meant about having a third RISC core instead of a 68000 was having it running from the cartridge ROM and DRAM instead of a tiny smidge of SRAM like the Tom and Jerry RISC cores are (and at the same clock speed as the other two RISC cores as well).

Then you'd have a much faster system overall. BUT, that probably wouldn't have been popular with many developers because they'd have had to have coded all of the game logic in RISC assembler instead of being able to using the wide range of C compilers, debuggers and other tools that were available for the 68000 at the time.

 

[Exophase]

Fsck me, I hadn't realised that the Saturn was such a complicated beast!

Anyway, what I meant about having a third RISC core instead of a 68000 was having it running from the cartridge ROM and DRAM instead of a tiny smidge of SRAM like the Tom and Jerry RISC cores are (and at the same clock speed as the other two RISC cores as well).

Then you'd have a much faster system overall. BUT, that probably wouldn't have been popular with many developers because they'd have had to have coded all of the game logic in RISC assembler instead of being able to using the wide range of C compilers, debuggers and other tools that were available for the 68000 at the time.

I thought the GPU, blitter, and OP were all connected to main RAM and cartridge (all under the same address space)..

 

[Firefox]

I thought the GPU, blitter, and OP were all connected to main RAM and cartridge (all under the same address space)..

They are, but Tom's and Jerry's RISC cores can only execute code from their respective SRAM. Which means that if you're a Jag programmer you have to slice your RISC code up into 4kB chunks and keep loading the right one into SRAM depending on what job you want that RISC core to do.

Now I come to think about it, I seem to remember John Carmack lamenting this in an interview he did about porting Doom to the Jag...

 

[jimid2]

You know, it's funny... I don't understand 10% of what's being said, but I still find reading through it utterly fascinating! :lol:

Firefox, if I can one day play Alien vs. Predator on my GP2X, I will buy you beers! Many beers!

Rock on, guys! I wish you success!!

 

[InsertFaveGameNameHere]

Is the Aliens vs Predator for the Jaguar the same as the arcade version? Where its a scrolling beat em up ala Final Fight?

So funny jimid2 - I'm exactly the same. Don't have a clue what they're saying but keep reading the thread nonetheless!

 

[Exophase]

I thought the GPU, blitter, and OP were all connected to main RAM and cartridge (all under the same address space)..

They are, but Tom's and Jerry's RISC cores can only execute code from their respective SRAM. Which means that if you're a Jag programmer you have to slice your RISC code up into 4kB chunks and keep loading the right one into SRAM depending on what job you want that RISC core to do.

Now I come to think about it, I seem to remember John Carmack lamenting this in an interview he did about porting Doom to the Jag...


That must be a weird quirk/flaw of the instruction cache (it only being ported to that SRAM and not the rest of it).. funny, I think this is the size of the cache itself, makes you wonder why they even bothered having cache in the first place.

Maybe this is a good thing for emu authors, means that the tasks on the RISC cores were straightforward and that they were overall underutilized. Would explain a lot, like why some of the games looked worse than average Genesis games. I guess also explains how you can generally get away with not emulating Jerry at all, if you don't care about sound.

EDIT: Could it be that it doesn't have instruction cache at all and that this area of SRAM is what is (incorrectly) being referred to? RISC CPUs must have instructions coming from fast RAM somewhere, but making it normal tiny SRAM instead of a real cache is a huge mistake.

EDIT2: The aforementioned quote by John Carmack confirms exactly that. Pretty stupid design. Earlier RISC CPUs in consoles (like on PS1) would often lack data cache and provide scratchpad, but instruction cache is essential.

 

[foleyjo]

Is the Aliens vs Predator for the Jaguar the same as the arcade version? Where its a scrolling beat em up ala Final Fight?

No its a FPS where you can be an Alien Predator or Colonial Marine. One of the better games for the Jag

 

[Firefox]

@Exophase: That's correct, there is no cache.

Remember that the Jag was designed in the early 90s, when cache memory was still a rarity except in very expensive workstations. Also, the RISC cores were developed in-house (well, developed by ex-Flare engineers) so just connecting them to an SRAM chip would've saved a huge amount of work compared to developing a cache controller for them.

I'm the sort of programmer that finds the idea of constantly swapping blocks of code into a small amount of high-speed SRAM an interesting challenge, but possibly if I were a game developer with a looming deadline I'd feel a bit differently.

(edit) Oh, I think Jerry's RISC core has an 8kB SRAM, not 4kB like I said before. I've been focussing on Tom lately and haven't really even looked at Jerry much, so I'm a bit fuzzy on its specs.

 

[jimid2]

Is the Aliens vs Predator for the Jaguar the same as the arcade version? Where its a scrolling beat em up ala Final Fight?

No its a FPS where you can be an Alien Predator or Colonial Marine. One of the better games for the Jag

I think it's the best game on the Jag excepting Tempest 2K... I also think that it is arguably (one of) the first games that could qualify as a FPS/"survival horror" hybrid, mostly because it scared the piss outta me when I was playing it back in the day... Playing as a Marine was freaky - those face huggers consistently creeped me out!

 

[Exophase]

@Exophase: That's correct, there is no cache.

Remember that the Jag was designed in the early 90s, when cache memory was still a rarity except in very expensive workstations. Also, the RISC cores were developed in-house (well, developed by ex-Flare engineers) so just connecting them to an SRAM chip would've saved a huge amount of work compared to developing a cache controller for them.

I don't know, x86 has had cache since 486 (1989) and that wasn't even a RISC design, although it did employ pipelining. Instruction cache was of key importance in the original RISC designs of the early 80's, in order to keep the pipeline as full as possible.

I'm the sort of programmer that finds the idea of constantly swapping blocks of code into a small amount of high-speed SRAM an interesting challenge, but possibly if I were a game developer with a looming deadline I'd feel a bit differently.

It might be interesting, but it's undeniable that it'll come at a performance hit no matter what, and it's going to limit the complexity of what you can do.

(edit) Oh, I think Jerry's RISC core has an 8kB SRAM, not 4kB like I said before. I've been focussing on Tom lately and haven't really even looked at Jerry much, so I'm a bit fuzzy on its specs.

I wonder why they didn't give Tom as much as Jerry, maybe they found they needed more for wavetable synthesis...

 

[Firefox]

I don't know, x86 has had cache since 486 (1989) and that wasn't even a RISC design

I think a 486 would have been a very rare and expensive item in 1989, but now I think again they were becoming reasonably common in 1994. Fair point.

I think the Jag's RISC chips are like that because it was a lower-cost and lower-risk (no pun intended) approach that would still be "good enough".

 

[Exophase]

I don't know, x86 has had cache since 486 (1989) and that wasn't even a RISC design

I think a 486 would have been a very rare and expensive item in 1989, but now I think again they were becoming reasonably common in 1994. Fair point.

I think the Jag's RISC chips are like that because it was a lower-cost and lower-risk (no pun intended) approach that would still be "good enough".

Someone on the atariage Jaguar forum (goes by "Gorf") claims that you can access code on the RISCs from main RAM just fine (of course this has to come at a huge speed penalty). Unfortunately he's wrong about so many other things while coming off as extremely confident that he's right that I don't know if he actually is.

 

[DaveC]

I've got a first edition! Let's see how fast she'll go... B)

(edit) Woo-hoo! Mine does 280 as well!

I'll keep developing for 240, since everyone's can do that. Nice to have a bit in reserve, though.

You are lucky. My MK2 only does 240

Do you think that that sound "simulator" would be possible? Maybe even just using samples like MAME often does would be ok. Since it is T2K maybe just the sounds for that could be done? I have a hard time getting into a game if there is no sound at all. Is sound possible or is that too much to ask for this hardware?

 

[Gruntfuggly]

 

[Firefox]

Someone on the atariage Jaguar forum (goes by "Gorf") claims that you can access code on the RISCs from main RAM just fine (of course this has to come at a huge speed penalty). Unfortunately he's wrong about so many other things while coming off as extremely confident that he's right that I don't know if he actually is.

I've been thinking about that... The emulator is definitely coded so that it halts with an error if code tries to run outside the SRAMs, but I think that that could well be like that so that it's easy to see if any games need that feature. I'll have a look in the latest emulator source code (the GP2X version is currently based on an old version of the emulator) and ask Dio about it.

Grrrr, now I've got an urge to build a ROM emulator cart so I can try things out on my real Jag... Don't really have the time, though. :unsure:

 

[Firefox]

Do you think that that sound "simulator" would be possible? Maybe even just using samples like MAME often does would be ok. Since it is T2K maybe just the sounds for that could be done? I have a hard time getting into a game if there is no sound at all. Is sound possible or is that too much to ask for this hardware?

I've been thinking about that a lot lately, too...

Dio's latest PC version has this special mode for PCs without much horsepower in which it does a checksum of the cartridge ROM and if it matches Tempest 2000 it runs some native x86 code that does the same job as the RISC code running in Jerry. That wouldn't be a simple recompile, but I might manage something similar...

I don't know to be honest. I should have the asm RISC core for Tom finished this week, then I'm going to look at the blitter to see if anything can be done to speed that up, then I'll have a good look at Jerry.

 

[rob27]

This is very interesting. Will have to order my GP2x now! Played AVP last night on Project Tempest and seemed pretty good.

 

[Firefox]

It might be a while before it runs AvP, so think carefully if you're mainly splashing out on a GP2X because of this...

I'm still debugging the new ARM assembler Jaguar RISC processor core emulation code (try saying that quickly!) It's a bit painful, because now it runs for a bit and then blows up because of something that happened many (emulated) instructions before... But I do some more to it every weekend and I'm gradually squashing the bugs.

I'm wondering if it might be an idea to release a version with a hybrid RISC emulation core - one that is the bulk of my assembler core grafted onto part of Dio's original C core. I think that's a bit faster than what was in the last release, but not nearly as fast as it should go with the 100% assembler core.

Dunno, I'll see how things go this weekend.