Jump to content

LinkoVitch

Members
  • Posts

    2,812
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by LinkoVitch

  1. Have you tried other discs? it should read/play standard music CDs. Make sure the disc is clean. Do you see / hear the disc spin through the window? Does it make a noise like slipping plastic or spin up nice and quietly?
  2. Teh FOOMZ! Only answer, remember, operate your Atari Jaguar equipment in a well ventilated space! This isn't the most nuts developer shenanigans I have witnessed in jaguland either ! RE IP addresses, they're not secret, your computer gives them away any time you talk to another on the internet, and they don't link back to you specifically, unless you have your own allocation from IANA, and in that case your registration address is going to be stamped to the look-up on them anyway.
  3. If my memory serves the CLUT is only 16bit RGB, but yeah you can have a predefined palette of 256 colours.
  4. Yeah a quick PoC is a great idea, but the concept here is "Mortal Kombat" not "Character Selection screen". We all know the Jaguar can play samples, do sprites and animation, this proves nothing with regards to the Jaguar's capabilities to do the target game. I am not knocking him for getting what he has going and having fun doing it, but claiming it's a "start" or PoC is a significant stretch. To my mind a PoC would show that the parallax was viable with 2 animated characters, not fighting or even controllable, just 2 characters cycling through animations whilst the screen moved around the full extents of the playarea. That would be a better PoC, as it would be doing all the key graphical needs of the game without spending the time needed to add in the controls, AI, game states, score, UI etc etc etc. There are waaaay too many "I'm making a game, look I have this cool intro/screen/animation" projects, (often followed with box and cart mockups), which then go no where as it turns out "Making games is actually hard". Not knocking the desire here at all, have at it, make an MK clone for the Jag, do it.
  5. Don't really think a fairly static character select screen fits the bill of "Proves the jaguar could do it". I don't doubt that it would be do able on the jag, but that example is a long way off proving the parallax, sprite counts etc. Good that he gave it a shot and hopefully had fun. Seeing a level or two rendered would be a much better demo however (IMHO).
  6. Blue was the one Gaz had which is now in Italy, which is the high res fully functional unit. IIRC the red were low res protos or just mock up units.
  7. That's not a Jag VR, not even close. I'd bet that's a newer VR unit (Scuba ? or derivative)
  8. IIRC This is the time that the BIOS is checking the contents of the cart against it's digital signature. The larger the game, the longer it takes as it reads every address on the cart.
  9. I’d check you aren’t accidentally calling init multiple times. That would cause random seeming lock ups
  10. Yeah might be a conflict, if you are not using the pad code in the SE, I'd recommend disabling it (you can switch parts you are not using off with the SR)
  11. So are you saying it works if you don't init the SE but crashes the moment you init the SE or some time later? The SE will quite happily sit there running on DSP without playing mods or sounds, it will continue to run RNG and poll pads. Are you attempting to make any calls to talk to the pad addresses? If it is crashing as soon as you init, I'd say there is something wrong with the init process or the binary blob being loaded onto the DSP.
  12. Fairly aware of its function (check my sig ). Have you checked for shorts on the pins also, an increased current draw caused by short somewhere could cause excessive heat. What kind of temp diff is there? It runs at the same clock as the GPU core, and is a smaller package so it's heat dissipation may differ. Honestly never dug into the physical side of the audio subsystem, is the actual DAC output direct from Jerry? or located elsewhere? The data is sent to the DAC via a serial bus from the RISC core, I don't know if this is decoded within the die or externally.
  13. I'm curious, how do you know it is half working? Have you checked for dry or cracked joints?
  14. Yes. This is queried every time the sample is sent to the DAC.
  15. Might be that the DSP has stopped before writing the final update to the status register (3 would indicate I2C has stopped). Doesn't matter if the voices are running, once it stops, it will stop everything. Might possibly be that there is some issue reading the value from DSP RAM.. but you shouldn't be seeing a lot of 3s.
  16. The All stop stops the entire sound engine so that the DSP can safely have the code replaced, not just stopping all sounds (just to be clear). That doesn't look right for the value of the status register. Whatever is doing the conversion to hex looks wrong. If the Pad read and RNG are enabled and everything is running I would expect that register to look like: C0000000 possibly C0000010 3 would only appear if stop had been issued and the I2C had stopped but Timers 1 and 2 were still running. Fully stopped *SHOULD* look like C000000F (Assuming pad and RNG enabled, and a render request not active at that time)
  17. I'm confused. So you say you now have it working? Regarding the output, is each line a hex representation of what is in D0? as that doesn't look right at all?
  18. Does the value in the status reg change at all?
  19. It might still be that dodgy crap sound code you are using! Please don't assume my code is free from bugs, hopefully you haven't found a new one, but it's still possible it's become upset for some reason. If it happens again, maybe just reset the system and see if a really simple test code works correctly too (perhaps the playback demo in the sound engine zip). If that screws up then it's probably not the SE, if that works fine, then could be the SE is getting upset for some reason.
  20. TBH, with the right tools it's not too difficult to de-solder and resolder a DSP. Flux, hot air, patience. Still more of a pain than replacing some dead through hole cap or something Good luck with your quest.
  21. Might be worth checking power and clock signals to the DSP.. silicon devices always go a bit wacky when under voltage. Might just be a cap going bad near the DSP and causing a short, essentially browning out the DSP. Possibly dry joint on the package, or bad/damaged trace. If you can scope the clock pins might be worth a look to make sure it's getting it's full dose of 25MHz, but I'd check the others 1st.
  22. I've just checked the 3 versions I have of the Jag Tech Ref. ONLY the printed copy I have that came with my Alpine has that line in! The PDF scan and the V8 ref don't have it!! (My printed copy is dated June 7, 1995). Is there a PDF (preferably OCR'd version of this out there, or should I look to fire up the scanner? I'd rather not as I have had it spiral bound and that might be a right pain to reset)
  23. I don't think that should matter? It is adding a 16bit to a 32bit value, but the point of the addition CLUT is a value (I am assuming it is a #define for the CLUT memory address?) the result of the addition of a 32bit and 16bit values is then cast to a uint16_t pointer, so the addition is made prior to it becoming a pointer. Well, that's how I read it
  24. I have no idea what is happening under your code (the assembly the compiler generates).. I wonder if there is some issue with making word (16bit) length writes to the CLUT? Or perhaps the compiler is using long writes and sometimes either the source or destination is not fully long aligned? I have had weird corruption with misaligned longs on the DSP RISC. In your picture examples I see no differences in the palette codes, are these values being read from the CLUT? or your source palettes? I assume they are the source palettes.. can you read the values from the CLUT and see how it has been corrupted? Might help identify what is going on. The index value you are passing in I assume is a multiple of 2? Otherwise you are going to end up with a target address that is odd.. if not then I would suggest you add on (index << 1) rather than just index when setting the CLUT pointer.
  25. IIRC with pointer maths (it's been a while ) but whilst a pointer is itself 32bit, an increment with ++ will increment the pointer by it's type size (assuming it's a typed pointer). So a Uint16_t* will increase by 2 bytes irrespective of if the pointer itself is 32 or 64bit. I *think* that's correct
×
×
  • Create New...