Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About JagMod

  • Rank
    Chopper Commander

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

9,437 profile views
  1. One more small suggestion for rln. Change from malloc() to calloc() in rln.c to expose several bugs.
  2. If you're looking at the parser... This does not work: x REGEQU r1 y REGEQU r2 z REGEQU r3 Error: syntax error; expected symbol however, this does work: xx REGEQU r1 yy REGEQU r2 zz REGEQU r3
  3. I've been following this thread. I checked my code and I am doing what you were, not what DOOM is. I have two interrupts turned on in the GPU, one from the OP, the other from the Blitter. The OP interrupts once per vblank, the blitter interrupts ~10,000 times in a vblank. So maybe it isn't a frequency problem as much as it is which interrupts are being used. I've never used the timer interrupt with the GPU. You said you were doing 1ms timer interrupts. (1000 times a second) The Blitter is interrupting in the 60k to 80k times a second, and I've never seen this bug.
  4. Is there such a thing as a good baseball, golf or tennis game?
  5. There are three rom variations. The 1mb has one version of the rom. The 2mb has two versions of the rom, 9000E version has some differences in the startup code.. There is also a demo version of Cybermorph on the the Test cart, and there are many versions of the test cart.
  6. Developers and programmers don't need this tool, they can just write one themselves.
  7. Someone beat you to it. lol, that sneaky bastard! Wasn't me.
  8. All three of those labels have different roms. Two are 2mb, the third is 1mb. The two 2mb carts are different.
  9. You're missing one of the labels. All three labels
  10. No, I was just copying memory in a tight loop, one load, one store, and the gpu was slower running from main than the 68k. As soon as I put multiple load/stores into the loop, it got faster. But if you are writing something like a strcpy in C for the gpu, that's the kind of assembly the compiler will generate. I'm still a proponent for gpu in main ram, but you have to be careful what you are doing, not everything running on the gpu is faster.
  11. Um...it was assembler using SMAC...it has nothing to do with gcc. GCC would not help at all, nor would any C compiler. Thre are going to be several places, no C compiler will avoid such a tight loop. You can tell the C compiler to unroll loops, but then as Owl has suggested many times, everything is a trade off. If you always unroll loops, now your code grows significantly.
  12. The problem was with smac and mac. The point is, there is no magical solution to fixing and optimizing all the quirks of the jaguar system. smac helps a lot by allowing code to be executed from main, but it doesn't keep the programmer from writing bad code.
  13. There is one case where the tight loop senario indeed chokes the GPU. But we are talking very few instructions in between the loop points. Once unrolled it actually ran as fast as it did in local. your saying in that situation the 68k could of done it faster? It sounds like a very extreme example though - and the kind of thing that could be optimised even in C code for gpu. ( ie - if there's a tight loop, unroll it a few times in C code ) Not extreme at all, in fact, a C compiler would just make this worse as it would usually try to minimize instructions and create this case.
  14. The main memory bug and running C on the riscs has nothing to do with each other. Running gpu out of main is not always faster than the 68k. It would have to be "wonderfully optimized assembly" in order to be useful in main.
  • Create New...