SCPCD

Hi ! Today, I tried to beat my hi-score (that I haven't beat since July 2006) of this great game, and I make it ! My new Hi-score : 1 454 360 (Expert Mode from level 1 to boss of level 10)

Hi ! You can found next pdf version of schematics of the board converted from Curt's files Lynx_Vid_pdf.zip

Hi ! Great job SubQMod I have corrected a bug to sln that doesn't give the possibility to link with object contained into a subdirectory. With ray_tscc, we have work onto another problem that doesn't give the possibility to use _TEXT_E/_DATA_E/_BSS_E internal symbols but without success, that works fine with aln. Is it a known issue ? or is it in development for a next release ? sln.zip

kskunk > Ok, thanks

There's nothing to read, the board didn't used to boot when plugged into the JagCD. KSkunk has solved this problem for the new run (and we will probably be able to backport the fix to the old boards). It does not do anything specific with the JagCD. Just by curiosity, What was the problem with the skunkboard and the jagCD ? Is it a line conflict or something other ?

Yes, sorry about that it's my fault, I don't say that before because it was a so evident things that I don't thought that I should say it clearly. That explain why you insist so seriously about that. And if you were a jagware member (with access to the jagcf section but if you asked it you would have this access) you would have the first jagcf documentation of mars 2006 that have the mapping explain next. If I don't say wrong things, Jaguar cartridge game start at $802000, so you should remap more than $2000 (=8ko) to disallow original cartridge game, else a simple jump to $802000 and most of original jaguar games can run (after allow the 68k to execute code in the cartridge space) or maybe I haven't understand correctly your idea. That's why when I started the version of the jagcf with SDRAM, the sdram was mapped at 1Mo upper. It's the liberty to people to make what they want at home. If it's his philosophy, why not ? We have never said that. You invent false arguments.

I'm bored about this debat of ROM or not ROM. I don't participate to this debate because I'm the developper of the jagcf and I shall be impartial. But at this time, I can say that arguments about ROMs support (on CF or not on CF) are more powerfull than arguments against this one. This feature is NOT my priority. Because I personaly don't care about it, I have the most part of the jaguar games library, and games that I haven't, I can play those at RGC or AC in france because there are jaguar collector that have ALL (in original obviously) jaguar games. I prefer also to take time on more difficult task than this one which is simple. i.e. it can be added easily in the JagCF architecture. Gorf, I don't know where you have read that I have changed my mind when friend jagware members ask me this feature or maybe it's a misunderstood, because it's not true. I have changed my mind because other developpers than friend jagware members give me good arguments to add it. (and one of those are a well known jaguar developper) About friend's jagware member, part of those are collector so they don't care about pirate roms, the other part of those do simply not care of games, they are only developpers and prefer to code insteed of playing. If they would like to test a game, there are RGC and AC to do it. About your remap idea, maybe you think that I have waiting you to have this idea, but it was my first solution since the beginning (what's the easiest way of blocking ROMs ?). So, please, stop to fill all forums with this idea, we read it so many time that it's boring. It's not to say 1Gtimes the same thing that it will be made more quickly. Edit : Grammar

Why ? Haven't we already a lot of support ? Some developers have already the instruction set of the DSP, but to make simpler the communications, modifications, choise, optimisations of the instruction set, this is limited to a few people because it is not 100% complete and I make a lot of improvement each time I work on it, so too much versions of documentations are existing. see below (about the 32X) 8megs are not for the DSP only but it's mapped to the Jaguar Cartridge. 96MHz it's because it's a perfect solution to have the highest efficiency for the shared of the SDRAM between jaguar access, all JagCF DMAs and the JagCF DSP. All of this without slow down the Jaguar access to the SDRAM. To simplify me the development, everything into the JagCF work at this speed that's all. What's about the falcon CT60 ? For me and for many others, it's always a falcon because it use the falcon architecture. But for me the falcon with a video card onto a CTPCI is not a falcon. It's just a point of view, a limit between when it considered to an other system. The JagCF is exactly the same thing : more RAM, another CPU but require Jaguar chips to complete the sound processing, the video processing, the PAD control, etc.... The JagCF DSP can not be a master onto the Jaguar Bus because of the jaguar cartridge limitation. His main purpose is to give the possibility to have access to MP3, MPEG or/and other things to permit to developers to have access to the full power of the jaguar with a compensation of original design faults. Why is the interest to make that ? It's not because a processor run at 1GHz that you can not run 16MHz application on it. We have already our logo. Wich name ? Wich logo ? If you speak about Jag-Ware vs Jagware : 1) It's a mere chance that it's the "same" name, we search after a name "xxxware" from the idea of "software" and "hardware" and we choose "jagware" to have a reference to the Jaguar of Atari 2) It's not the same name : Jag-Ware vs Jagware 3) We have a logo that breathe-in from the Jaguar original logo : OK, and it's not the same that the Jag-Ware logo. All of this is to keep in mind the "Jaguar" and have a direct reference to the game system, like everyone make the same thing with it's favorite mark or favorite game like we can find : T2KFreeker (I presume from Tempest 2000), Atariman, GT turbo, and many many others. Why could we not make that also for our development team ?

Sorry about that, this will take a bit of time, I have a great amount of work for many weeks.

It's a first try, i'll make other test in the futur. I have made some changes to see more easily this onto the LA. move.l #ints,VBL_VECTOR move.w #%1111100000010,INT1;clear all pending int, & enable GPU interrupt gorf_test: move.l #gpu_code_start,G_PC move.l #1,G_CTRL stop #$2100;wait a gpu stop bra gorf_test ints: move.w #%1111100000010,INT1 move.w #0,INT2;68k to normal level rte .qphrase gpu_code_start: .gpu BLITBASE .equr r14; base of blitter registers A1FLAGS EQU 1; register index defines A1CLIP EQU 2 A1PIXEL EQU 3 A1STEP EQU 4 A1FSTEP EQU 5 A1FPIXEL EQU 6 A1INC EQU 7 A1FINC EQU 8 A2BASE EQU 9 A2FLAGS EQU 10 A2MASK EQU 11 A2PIXEL EQU 12 A2STEP EQU 13 BCMD EQU 14 BCOUNT EQU 15 BSRCDH EQU 16 BSRCDL EQU 17 BDSTDH EQU 18 BDSTDL EQU 19 BDSTZH EQU 20 BDSTZL EQU 21 BSRCZ1H EQU 22 BSRCZ1L EQU 23 BSRCZ2H EQU 24 BSRCZ2L EQU 25 BPATDH EQU 26 BPATDL EQU 27 BIINC EQU 28 BZINC EQU 29 BSTOP EQU 30 BLITI0 EQU 31 BLITI1 EQU 32 BLITBASEHI .equr r15; pick up were last index register leaves off....not using most of these here but ; good to have for future endevors....this is the same loaction as BLIT_I2 BLITI3 EQU 1 BLITZ0 EQU 2 BLITZ1 EQU 3 BLITZ2 EQU 4 BLITZ3 EQU 5 moveq #0,r0 moveq #2,r1;for G_CTRL register : interrupt the 68k movei #A1_BASE,BLITBASE movei #PITCH1|PIXEL32|WID128|XADDPHR,r2 movei #source,r3;=somewhere in DRAM phrase aligned movei #destination,r4;=G_RAM+$8000 movei #$00010010,r5 movei #SRCEN|LFU_REPLACE,r6 movei #G_CTRL,r7 store r2,(BLITBASE+A2FLAGS) store r3,(BLITBASE+A2BASE) store r0,(BLITBASE+A2PIXEL) store r0,(BLITBASE+A2STEP) store r2,(BLITBASE+A1FLAGS) store r4,(BLITBASE) store r0,(BLITBASE+A1PIXEL) store r0,(BLITBASE+A1FPIXEL) store r0,(BLITBASE+A1STEP) store r0,(BLITBASE+A1FSTEP) store r0,(BLITBASE+A1CLIP) store r0,(BLITBASE+A1INC) store r0,(BLITBASE+A1FINC) store r5,(BLITBASE+BCOUNT) store r6,(BLITBASE+BCMD) nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop store r1,(r7) ;done...stop GPU and launch a CPU interrupt nop nop .68000 .gpu_code_end: .dc.l 0 Actually I don't know how I can easily trig for your test so I add a repeat of it. But as the 68K is stopped the only possibility to restart when the blitt is finisched is to restart the 68k by an interrupt but there is no Blitt interrupt for the 68K. And I can not launch the CPU interrupt before the blitter is idled, else the 68k take the priority... so I add nop and reduce the length of the blitt for a first try. this is the result : in A : the first 2 instruction of the GPU. We have 13 cycles for 2 consecutive moveq. 12 cycles per each "32-bit GPU instruction" read until "store" instructions. then each 2x"store rn,(rn+x)" takes 14 cycles. When the blitter start, we can see that there are interleaved of gpu instructions and blitter access, and more interesting : time between each GPU instruction takes less time to read into the dram ! time between 2 "32-bit GPU instruction" are not constant but seems to be about 8 cycles. time between 2 blitt are 8 cycles. I'll make updates in the futur, now I have others things to do

I'm preparing for it. You should have it soon.

Nop. This was sampling @ 200MHz and @1.4V logic thresold level (sorry, I have forgotten to change the logic level...I make it too quickly), so errors with a 26.59MHz is totaly normal. My LA have a 10Hz resolution for the frequency mesurement and can samplig up to 500MHz. But it's not the clock frequency that is important here, it's the number of cycle that give us information

BZZZZT! It's false. Show me where it's written into the jag documentation because it's wrong. - the GPU/DSP prefetch is 32-bit not 64-bit and the prefetch in external DRAM work like in internal RAM so ask new data when the previous prefetch is empty, not before. - DRAM latency are 2cycles (CAS valid) if we stop the analysis here, you are right, it's possible to have the same throuput but it's not all : FACT : - bus controller latency : 1) the GPU prefetch is empty -> ask of the next 32-bit 2) the GPU can not take the bus immediately : it have not the highest priority (even if it was alone to work !). 3) between the bus request and the moment where the DRAM controller launch the command, there is a lot of latency : RAS is needed?, refresh is needed? etc.... 4) between the DRAM controller ready and the DRAM data read ready there are 2cycles (CAS dead time) (already said before) 5) after data latched, there is the data dispach to go through the GPU gateway to go to the prefetch unit. This takes some time. each of this step is synchronous (it could be seen by reading TOM netlist). (I haven't describe all steps) And make this totally asynchronous @ 26.59MHz, with a so complex design, would be totally crazy. Let me see with a logic analyzer with the next code : [...useless init cutted...] move.l #gpu_main_init,G_PC move.l #1,G_CTRL stop #$2700 .phrase .gpu gpu_main_init: movei #G_FLAGS,r28 load (r28),r29 bclr #3,r29 bclr #14,r29 store r29,(r28) nop nop nop nop nop gpu_main_jump:;align data to phrase to see easily the addq on the analyzer addq #1,r0 addq #2,r2 jr T,gpu_main_jump nop .68000 now the result : we could see in A the read of the two addq, then in B the jr+nop, then a dummy read before return to the A step. The dummy read is the prefetch error describ into the documentation that could cause wrong jump. The time between A and B, which is the time to execute 2 GPU instructions, is 12 GPU cycles (about 450ns). (that's why I say that it's operating like a CISC) this made a throuput of : 4.44MIPS MAX. this is 16.7% of the real power of the GPU. Sorry, but I don't think that it is very insignificant and I don't think that it's the GPU full speed (or maybe with a real complete wrong written RISC code). PS : tested with ONLY the GPU running and DRAM refresh (obviously). (68K stopped, no OP, no DSP, no blitter) And about DRAM access : Only the OP, when it reads OBJ headers, run at the full DRAM speed wich is 106MBytes/s with one phrase per 2 cycles. Pixel phrase (at the higher speed : no RMW, no scale) are read at 3cycles not 2cycles (except for the first phrase) . It's the same thing for the blitter that access to the DRAM at 3cycles not at 2cycles. (2 for /CAS = 0 and 1 "dead" cycle for internal bus latency) I totally agree whith you about that. I have never said the opposite. The GPU will be always powerfull than the 68k even if the GPU code is totally horrible. The 68k on the jag have also restriction like the GPU. Atomic time for 68k's intructions on the jag are 5cycles not 4cycles like on other computer. (result from logic analyzer) There are also other dead time to add to 68K instructions when the 68k read the DRAM after a write DRAM cycle. The 68k is "The Ugly Duckling" of the jag. Everyone agree about that.

But what is the performance ? You lose most advantage of the RISC architecture. The GPU/DSP with this solution is like a CISC... For me, GPU/DSP use in DRAM is totaly useless : GPU and DSP code are 98% of the time for intensive calculation, so internal execution is the only one solution. And you could not convict me that it's powerfull than copy data from DRAM to internal ram with the blitter. Let me give you another point of view with your results : 4k -> ~1500cycles per frame. but 1 video line takes : 64us so @ 26.59MHz, this is about 1700cycles. so a complete copy of 4K is made in 1 line time drawing (HBL) so if you have 6 GPU code to flip per frame, this takes per frame : 6 HBL. In conclusion, even though this number per frame could be reduced (blitt new code when the old is always running, optimisation of the code, or other solution), this can not give you a so big improvement to have a lot of textures and a lot of extra frames for a game. You are right for the "second" point of view, but a game doesn't work at the "second time", it works at a "frame time".

I use Zero5 as benchmark because on all my jaguar cartridge games, it's the only one game where there is a real improvement. For 1 VBL games there is no improvement and it's normal, it's not possible to have higher frame rate than 1 VBL (but there is always the accelerate sounds) For near 1 VBL games (like zero5) the improvement are important. For exemple : to have a frame rate refresh from 2 to 1 VBL give the game 2x faster. For slower games the overclock gives the game smoother but it's not so important. It's like go from 12fps to 15fps. So an overclock can help the jaggy where the game frame rate slow down during the game for a normal jaguar, and it's more interesting for near 1 VBL games. For other games it's almost useless. To be more interesting, the overclock should be reach the 2x original jaguar clock but it's not commonplace.

Oh, yes I haven't try with the JagCD, I will try sooner or later

Nop. It's not needed to change the boot rom configuration. (and I think that some games change video configuration so it could be a problem) In fact, the jaguar video chip is so well designed that it has different input clock : one for the video generator and another for the core. So, the only thing to make is to separate on the board the video clock to the general clock (that is already made for first generation jaggy with a patch) and give another clock for the system clock Very easy task. Yes, it's totaly normal that the sound plays faster because in contrast to TOM, Jerry has the same clock for all the core. I haven't try to have different clocks for TOM & Jerry & 68K but I think that the system will crash.

It's what it is made with the soon available JagCF : a DSP to help the jag for difficult task. The cartridge port is not "directly" linked to TOM : data and address lines pass throw transceivers to separate the high speed internal jag bus and the low speed external bus. These transceiver are not all bidirectionnal : address and control lines are unidirectionnal. So it's not possible to add an external master on the bus. But a coprocessor is possible So all AI, logic, etc. would be made by the jaguar and the external processor should be used for "impossible" task for the jag like complex 3D, video/audio decompression or other and rapatriate the frame one time per vbl for exemple to add jags possibility onto each frame

Hi ! (from Jaguar Mods topic ) The new mod for the jaguar is the Overclock ! It was the 3rd June that I have success to overclock the Jag, but no time to make videos All my cartridge games (about 33) work perfectly on the overclock jaggy at all tried frequency except that the sound is played more quickly and some music player of games have bugs, but it's perfectly playable (when it's not too accelerate ) ! The JagCF works perfectly as well. Photos of the overclock jaggy : First try : Fixed mod : Videos at different speed : The FastLara demo by Orion_ with VBL consumption in red : (it's a PAL demo and on a NTSC jag some part of the screen are cutted) FastLara @ 32MHz (68K @ 16MHz) FastLara @ 37.5MHz (68K @ 18.75MHz) Then on a game : Zero5 @ original speed (26.59MHz -> 68K @13.295) Zero5 @ 32MHz (68K @ 16MHz) Zero5 @ 37.5MHz (68K @ 18.75MHz) (onYoutube) At 37.5MHz, the jag cube on startup is distort and the jag can crash. (this why I launch the game before it appears) I tried to 40MHz but the Jag crash on startup. It's, for me, normal because the 68K is already over it's limit which is 16.67MHz from the datasheet. Cheers ! Edit : videos reuploaded (less size)

Hi ! There are 3 modes : - bambam mode (ex : level 1) - hit-pack mode (ex : level 2) - trench mode (ex : main part of level 3) After these 3 "training" levels, their 3 modes are shuffled, so for exemple there are levels with hit-pack & bambam mode or trench & bambam mode but the main mode of the game is the bambam mode. Red stars at the mission 1 are boss of this level and there are 2 of them in Novice & Cadet mode (and 1 blue stars then 1 red stars more in Expert mode) To destroy red stars, it's important to have the highest powerfull weapon of bambam (4 red shot instead of 2 "low" red shot) so for that you should destroy all enemies of the level and take all bonus to have the shoot level bitmap in green (top left of the screen) (after that you could change to '2' or '3' to have energy or high-score bonus ) When you have this weapon, and arrive to red stars, you should find & take the right position and shoot very quickly to destroy in same time enemies shoot and enemies and use smart bomb when it's necessary. if you would like to see how is the 10 first level of the game in Expert mode : (it's a video of me playing Zero5 in August 2006 with a standard pro-controller) Zero5 (mission 1 -> start of mission 10 - Expert Mode) Exactly ! It's for me the best game of the Jaguar Regards.

A new released game would know easily if it run on the JagCF : by writing then reading the same address in SDRAM for exemple or by access to registers, other techics are possible.

Hi ! This is only true if the dram controler can use the DRAM at higher speed. On the Jag it is not true. The DRAM on the jag is used at the highest speed that TOM could control it. So replace DRAM at 70ns by 60ns or 50ns don't increase the speed of games if you don't increase the TOM clock. But increase TOM clock could made the system very unstable because all clock registers are not properly initialised (videos registers, and others) at the boot or at game initialisation. The last bad point is that we have no informations about the TOM and Jerry timings so increase frequency could crash TOM and/or Jerry where I think that TOM and Jerry are not very tolerent on higher speed. Regards, SCPCD.

Hi ! I hope that the JagCF cartridge will be available for developers for september. (time to finish to check the prototype and launch the first production) All features added to the JagCF don't drive the cost up because of their low price For example : 8MB of SDRAM : 5$ and it is the componant added that it is the most expansive The memory map in the cartridge space will be : $800000 -> $8FFFFF : Boot ROM (1MB) $900000 -> $CFFFFF : SDRAM first bank and second bank choose by a bit in a register. (so 2*4MB) $D00000 -> $DFEFFF : registers & CF cache memory Regards, SCPCD.

Yes you are right. The CF systeme is not compatible with either JagRoms or CDs. The software must be specially written to take advantage of it.

- Highest Speed - More Features - More Spaces - More possibilities Everything is possible with the JagCFv2 The use is not like a cart but more like the JagCD even though it is also different I don't want to made this possible principaly for copyrights. I know that it should be awesome to have all jag cartridge games on a CF and also copy of CD on a CF but I don't want to be responsible for hacked Jag Games. and to see other photo of the CFv2 V1 vs V2 V1 vs V2 side b v2 JagCFv2 Regards, SCPCD