T2k Atari Jaguar Emulator


Yeah, VLM is awesome and it would also be cool to play the handful of good Jag CD games.

I have an thought about emulation. Bear with me though, I have only a little programming experience :)

About Jerry, it's the same basic RISC chip design as Tom, right? Just with different functions and some differing instructions. So, could someone combine them both into one super chip, that input/outputs different instructions depending on whether Tom or Jerry is required? I suppose a dynarec would help reduce whatever extra strain is created on the 920, but hopefully the idea is to reduce some overhead that emulating two chips compared to one would cause. Hope that makes sense :)

I also heard the Jaguar can play MP3s natively, but considering the source (Gorf), I'm not too sure if that's accurate.
 
Jaguarandine said:
I also heard the Jaguar can play MP3s natively, but considering the source (Gorf), I'm not too sure if that's accurate.
XD

That guy is full of all kinds of things.

There's no way Jaguar has any kind of MP3 chip or anything like that.
 
Last edited by a moderator:
Yeah, that guy is too much sometimes. The sad part is many Jaguar owners are desperate for validity, anything that justifies the Jaguar's existence, that they eat up what he says. That's why I don't go around there much anymore, it's just too depressing. Though I might fish out his mp3 comment just for the heck of it..
 
hey guys.
big 'happy' shouts to Firefox :)

i'm deeply grateful for this.
donations. how, when and where?

cool beans!
 
Yes firefox you are the best you got jag emulator running at good speed it's totally incredible, i know you will get this emu running full speed one day but is there any chance of sound in the next update, do any games work for jaguar cd.
 
Sorry there hasn't been any progress lately chaps; for the last couple of months I've had my hands full with my day-job work, and haven't had much mental energy left over for anything else.

Rest assured that the GP2X version of T2K hasn't been abandoned! As soon as I get a bit more free time it'll be the first thing to get worked on. I've very nearly got my new Jaguar RISC processor emulator finished - it runs for quite a bit before going bang - so there's the tantalising possibility that with just a little bit more debugging it might suddenly run reliably at full chat!

I won't be abandoning the GP2X version when the Pandora comes out, either. The Pandora will be so stupidly powerful that it won't be any challenge at all to get the emulator running at full speed on it. The GP2X is a much more resource-constrained platform and therefore more interesting, in a funny sort of a way.

@sukhigp: The next release will probably not have sound, just the speed increase. *But*, I've reorganised the code since the last release so I now have the GP2X's second ARM spare. Fingers crossed, that means that I'll be able to get sound going without too much extra work (famous last words ;) )
 
Firefox said:
I won't be abandoning the GP2X version when the Pandora comes out, either. The Pandora will be so stupidly powerful that it won't be any challenge at all to get the emulator running at full speed on it. The GP2X is a much more resource-constrained platform and therefore more interesting, in a funny sort of a way.
Very interesting comment. I fully understand and agree with your opinion. Good luck for your project, Firefox!

Regards,
Stephan
 
Last edited by a moderator:
Firefox said:
Rest assured that the GP2X version of T2K hasn't been abandoned! As soon as I get a bit more free time it'll be the first thing to get worked on. I've very nearly got my new Jaguar RISC processor emulator finished - it runs for quite a bit before going bang - so there's the tantalising possibility that with just a little bit more debugging it might suddenly run reliably at full chat!
I always wanted to talk to you about how you're actually handling the Tom emulation, it's pretty interesting work. If you're doing an interpreter then I think the bare minimum you will be able to achieve is something like this for a simple flags setting ALU operation... fortunately you can use dest copy to emulate N/Z flags, even though some operations are non-standard in how they treat them (clears N flag) it should still be a valid state.

1 cycle - instruction fetch 1 (ldr)
1 cycle - emulate cycle counter + accumulate carry
1 cycle - instruction fetch 2 (shift right)
5 cycles - instruction decode 1 (ldr pc)
3 cycles - decode 2 (operand a = shift + and, operand b = and)
1-2 cycles - operand fetch (load register operands from emulated register file, schedule to avoid stalls)
1 cycle - emulate operation + N/Z flags (dest copy)
1 cycle - store result to register file
1 cycle - prepare C flag

So at least 15 ARM9 cycles for a binary ALU instruction in the interpreter (unary is a little better) - memory accessing instructions will be worse. You can actually avoid a cycle at the cost of an extra instruction by splitting the decode 1 phase into two steps if you fetch into a register then bx to it with something inbetween. This would require scheduling in advance but your instruction set is pretty small and could be hand-coded without much headache.

Thanks to the rather stupid design of this CPU a lot of games, that is, the ones that actually bother to really utilize the thing at all, will take more than one cycle on average for ALU instructions. But if they do utilize it well then there's no way you'll have enough CPU power to emulate it on GP2X. I find that when testing things on the GP2X platform they actually perform much worse than these numbers would have you believe they would, probably thanks to the heavy price of cache misses and bus contention, and maybe because of OS things going on in the background.

A dynarec would do much better than this. If you haven't already decided to do one you should think about it.
 
Last edited by a moderator:
My Jaguar RISC core is a simple interpreter. I haven't looked at it for a couple of months (brain sadly crammed full of complicated day-job stuff at the moment...) so I can't remember the nitty-gritty details of how it worked.

In general, though, when I was working on optimising the original C version of the core I noticed that many of the Jag instructions could be emulated very efficiently by the ARM - it is after all a 32-bit RISC processor, and a more sophisticated one at that. In particular the ARM's ALU flags do the same as the Jag RISC's ALU flags, so the calculations to determine the flag states done by the original C code can be elided and the real ARM flags saved after arithmetic ops are emulated (often by just a single ARM instruction).

Decoding the Jag instruction stream does indeed take quite a few ARM instructions... I'm thinking I might patch the Tom and Jerry memory handlers to do the decode when a write is made to a location in SRAM, then read the pre-decoded fields directly in the RISC emulation core. But I'll get the thing to run properly as-is before I start tinkering with stuff like that.

Currently all the Jaguar instructions have ARM asm handlers and they all work - but they're hooked into the core of the original C Jaguar RISC emulator and have little conditionally-assembled blocks of ARM code that read the state of the Jaguar's flags and set up the ARM's flags, then at the end of the handler there's another conditionally-assembled block that stores the state of the ARM flags back into the emulator.

It runs fine like that, and even a bit quicker than the pure C version. That last piece of the puzzle that I'm working on is getting a 100% asm framework together for the instruction handlers to sit in, so as much of the emulation state as possible can be stored in ARM registers while it rips through a batch of several thousand Jaguar instructions. There should be a big speed up when I get that to finally work... Just have to keep adding debug code and applying good old fashioned detective work to the problem, I suppose. :)

Eventually I'd like to do a proper dynarec for my own interest, but I think the interpreter version might be just about fast enough for a 240MHz GP2X - and I doubt there'll be a future platform that's less powerful.
 
I know the pandora isn't out yet i know you are going to release the jaguar emulator on pandora console would it be full speed with sound and have jaguar cd support.
 
Firefox said:
Eventually I'd like to do a proper dynarec for my own interest, but I think the interpreter version might be just about fast enough for a 240MHz GP2X - and I doubt there'll be a future platform that's less powerful.
If you do end up interested let me know some time. Jaguar games are probably not optimized for the most part and end up with a ton of stalls so I doubt they even push over 10MIPS per processor.. but if you really can get good speed at 240MHz then a dynarec could probably get you both Tom and Jerry's CPUs for around the same, especially since the amount of code they can run is pretty limited. You don't even need a lot of translation cache.
 
Last edited by a moderator:
sukhigp said:
I know the pandora isn't out yet i know you are going to release the jaguar emulator on pandora console would it be full speed with sound and have jaguar cd support.
I'm pretty optimistic that a straight port of the PC Linux version will run at full speed with sound enabled on the Pandora. That means that I could get a Pandora version out of the door pretty quickly and it'd be the latest version of the emulator codebase and so would run more cartridges. Fingers crossed! I suppose we'll find out in a few months. :)

As for Jaguar CD support, if you mean running the VLM sound-to-light program then it is supported in the PC version of the emulator. It just needs a stream of audio data to replace what would be coming from the CD drive on a real Jaguar. That comes from some Windows API on the Windows version, but I don't quite know where you'd get that from on the Pandora... It might be possible to write a plugin for a media player program, I suppose.

If you mean Jaguar CD games then I'm afraid I don't think they're supported.
 
Last edited by a moderator:
Little off topic here, but i have a question directed at Firefox and Exophase; How did you learn all this information about programming and processors etc?
I'm thinking of doing computer science at university, and was wondering whether any of you had went through a similar course.

Thanks
 
Darth Gazak said:
Little off topic here, but i have a question directed at Firefox and Exophase; How did you learn all this information about programming and processors etc?
I'm thinking of doing computer science at university, and was wondering whether any of you had went through a similar course.

Thanks
I got an MS in computer science but you can learn most of what you need to do things like this without it. Honestly, I recommend just wandering around Wikipedia to get basic overviews of some topics then google up further information (or use the related links).
 
Last edited by a moderator:
Back
Top