Jaguar II tech ref.

[downix]

Just another indication of how rushed things were - the extra RISC processor was in Puck - so the first games developed on Cobwebs would have been very similar to Jag 1 games ( in the use of the 68k ) - just with better texturing.

Yes and no, as the final design was to use a 68020, so would be closer to a CoJag in capability.

[Crazyace]

I'm not sure that was true - the 68k was in the cobweb board - and in the docs it doesnt talk about a 68020 - ( or in any interviews ), the idea seemed to be that the 68k was only there for Jag compat and boot - and Jag II games would ditch it once the RISC had started ( something to warm Gorf's heart )

 

( To me - putting a 68020 in JagII wouldn't make any sense at all - at worst it would screw up the timing of old games - ruining backwards comp... )

[Gorf]

I'm not sure that was true - the 68k was in the cobweb board - and in the docs it doesnt talk about a 68020 - ( or in any interviews ), the idea seemed to be that the 68k was only there for Jag compat and boot - and Jag II games would ditch it once the RISC had started ( something to warm Gorf's heart )

 

( To me - putting a 68020 in JagII wouldn't make any sense at all - at worst it would screw up the timing of old games - ruining backwards comp... )

 

 

 

The best thing would have been to leave it out and use the RGPU for emulation fo the 68k.

[downix]

I'm not sure that was true - the 68k was in the cobweb board - and in the docs it doesnt talk about a 68020 - ( or in any interviews ), the idea seemed to be that the 68k was only there for Jag compat and boot - and Jag II games would ditch it once the RISC had started ( something to warm Gorf's heart )

 

( To me - putting a 68020 in JagII wouldn't make any sense at all - at worst it would screw up the timing of old games - ruining backwards comp... )

 

 

 

The best thing would have been to leave it out and use the RGPU for emulation fo the 68k.

I've found several references to an 020 in the design, but I agree with Gorf, the RCPU can emulate the 68k with better accuracy for legacy games.

[Shamus]

I don't mean to be pushy, but have you sent those netlists yet? Totally understand if you're too busy.

[Crazyace]

Interesting idea - it would be quite difficult to run at the same speed though..

[downix]

Interesting idea - it would be quite difficult to run at the same speed though..

Yes and no, depends on how they did it. I worked for a company which worked on m68k run time emulators, I've seen what can be done,and I think it would have been quite close.

[Gorf]

Interesting idea - it would be quite difficult to run at the same speed though..

 

 

It only has to run at half the clock of the RISC's and I bet at the 66 MHZ

internal clock, cached(the new RISC's have REAL caches and not just local

ram now), it would be fine.

 

Most of what you do on the 68k is tons of cycles anyway and I bet the RGPU

would still manage to out cycle the real thing on average. Also remember,

the stalls have been eliminated on the RISC's in this next gen version. That

and a number of corrected issues would be plenty of horse power to emulate

a broken leg 68k.

[Crazyace]

66MHz is a bit faster than the cobweb though - I guess this is your target speed for the new chip?

I've found that a big problem with emulation sometimes isn't emulating too fast, but actually emulating at the exact same speed...

 

I thought the only RISC chip with cache was on puck - The Oberon one seemed very similar to Tom. I suppose if you look at how the cache was implemented on Nuon that would probally be indicative of what they intended for puck

[Gorf]

66MHz is a bit faster than the cobweb though - I guess this is your target speed for the new chip?

I've found that a big problem with emulation sometimes isn't emulating too fast, but actually emulating at the exact same speed...

 

I thought the only RISC chip with cache was on puck - The Oberon one seemed very similar to Tom. I suppose if you look at how the cache was implemented on Nuon that would probally be indicative of what they intended for puck

 

Well Puck would be the chip that holds the RGPU as designed. GPU Core + Jerry(with bug fixes and enhancements.) = Puck.

 

The cache on the RGPU, if I read correctly is indeed a cache and not just fast local RAM as was the old school

silicon but a true cache into external memory. Even if not the case, it can be made so Im sure. All the new

J-RISC's are main code proper now. They obviously found the issue. There are a lot of advantages with the

nwer J-RISC and of course at the same time more complications.....but I'll take them..all of them.

[downix]

66MHz is a bit faster than the cobweb though - I guess this is your target speed for the new chip?

I've found that a big problem with emulation sometimes isn't emulating too fast, but actually emulating at the exact same speed...

 

I thought the only RISC chip with cache was on puck - The Oberon one seemed very similar to Tom. I suppose if you look at how the cache was implemented on Nuon that would probally be indicative of what they intended for puck

 

Well Puck would be the chip that holds the RGPU as designed. GPU Core + Jerry(with bug fixes and enhancements.) = Puck.

 

The cache on the RGPU, if I read correctly is indeed a cache and not just fast local RAM as was the old school

silicon but a true cache into external memory. Even if not the case, it can be made so Im sure. All the new

J-RISC's are main code proper now. They obviously found the issue. There are a lot of advantages with the

nwer J-RISC and of course at the same time more complications.....but I'll take them..all of them.

Such a simple issue too...

 

And the difference between a cache and local RAM is only in how you view it from a programming model. (save the model was broken in Jaguar)

[Shamus]

Thanks for the info--all I can say is WOW! :)

 

No more guesswork!

 

BTW, what is the language used? I can't seem to find any reference to it anywhere, and I'm no hardware guru.

Edited February 10, 2008 by Shamus

[downix]

Thanks for the info--all I can say is WOW! :)

 

No more guesswork!

 

BTW, what is the language used? I can't seem to find any reference to it anywhere, and I'm no hardware guru.

 

Those are OrCAD netlists, tango format, a modified form of PALASM. I've had limited luck in converting them to verilog, but gave up after awhile and just began recreating them in schematical form, to then make new verilog from that.