Jump to content

LinkoVitch

Members
  • Content Count

    2,805
  • Joined

  • Last visited

  • Days Won

    14

LinkoVitch last won the day on October 21 2013

LinkoVitch had the most liked content!

Community Reputation

2,132 Excellent

2 Followers

About LinkoVitch

  • Rank
    River Patroller
  • Birthday 03/06/1976

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Mossley, UK
  • Interests
    Coding, Computers, gaming, whisky, beer

Recent Profile Visitors

16,542 profile views
  1. 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.
  2. I’d check you aren’t accidentally calling init multiple times. That would cause random seeming lock ups
  3. 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)
  4. 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.
  5. 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.
  6. I'm curious, how do you know it is half working? Have you checked for dry or cracked joints?
  7. Yes. This is queried every time the sample is sent to the DAC.
  8. 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.
  9. 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)
  10. 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?
  11. Does the value in the status reg change at all?
  12. 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.
  13. 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.
  14. 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.
  15. 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)
×
×
  • Create New...