Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by LinkoVitch

  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)
  16. 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
  17. 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.
  18. 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
  19. unless you decide you want to insert something part way through or at the start of one of your switch statements.. at the moment you will have to update the values for all the subsequent case statements with new values. As that Switch statement grows, the amount of effort to make a small change near the start becomes more complex and time consuming, making it more faff to tinker and change things later.
  20. Google is your friend. Simple google of "writing scalable code" gives a bunch of results. We are not making these terms up! 1st link: https://blog.sarasarya.com/what-the-hell-is-scalable-code-anyway-f6626ad78227 Scalability applies to more than just sprites. RE Switch.. Think about it, how does the computer know what part of the case statement to run? It doesn't magically know that a value of 15 = run this code.. it has to check each possible solution to figure out what bit of code to run. So a Switch statement with 100 possible cases will compare the input value with each in turn until it finds the one that matches and then run that.. So if you have 100 cases and the value you pass in doesn't match any of them, it will check against all 100 and then move on to the next instruction after the switch, so you just made 100 comparisons for nothing! From a cursory glance at your code I assume you are using a counter to indicate when something should happen? when it reaches a certain value, do a thing and you are using the switch statement to decide what thing to do, but you are doing this every iteration, so even at times when nothing should happen. I am sure there will be more efficient ways to trigger "events" and the like at set times, some things may happen on a timer, but I doubt everything should do. This is the designing part of the code, figure out how to do as little as possible each frame/tick/iteration, only trigger events when it makes sense, if something can only happen after a specific other event has happened, don't test for it every iteration, only after that event, or trigger it directly from that event. Programming isn't a simple subject there are many many many ways to do a thing (especially in games!) which is why it's so much fun, there is so much to learn and expand on, I've been coding for probably 30 years, I am still learning new things.
  21. Your answer to 3 proves Welshworriers point 1. When code is said to not scale it means that the code is very rigid to a specific use case, if a small aspect of that case changes then the code has to be changed to accommodate that use case. Writing such rigid code and trying to make it fit, results in a tangled and complicated mess which ends up generally being the cause for bugs and is notoriously difficult to maintain and debug. Writing modular scalable code, you could re-use common logic for different purposes (say Menu input and gameplay input with a joypad), without having to modify loads of code or produce tangled spaghetti code. IE you could have something that reads pad input and presents it in a standard format. Then have an interchangeable handler function for each use case, which knows how to interpret the users key presses into actions. The game then references the appropriate handler for the appropriate part of the game. If you then decide to change how the gameplay inputs work, you only need to handle the GamePlayControllerHandler and don't make any changes to the InputCore or the UIControllerHandler. Using a modular and scalable solution also allows you to handle multiple input types, using adaptors and different handlers as required.
  22. Might be worth adding a "If you bought this you have been ripped off, the disc is free here:" kind of thing to the start. Just noticed it's split into a bunch of parts and Nero.. if there are ways this could be made simpler for people to burn then may help too. Some people I imagine will want the box and label and simply won't be interested in burning themselves. Unless you are going to produce them on demand it's always going to happen.
  23. JagCD units WILL fit into one another, I've had 3 or more plugged in like that on a shelf. Never tried it on a system as I didn't want to put excessive strain on the connector, and I didn't power up because I CBA finding enough PSUs to try I'd imagine it will work to a point, and then the bus will be extended sufficiently far enough with enough connectors that it will probably just become a huge noise generator / antenna and the Jag will just crash.
  24. Don't see any reason why not assuming it is available as a Linux application? Do you have URL for it? Sorry for the slow response, I don't always get around to keeping up to date with the retro goodness these days
  25. Sounds like you have sorted it? One thing to be aware of is if you stop a mod that has looping samples, these will continue to play after the mod processing stops, which is where sending stop commands or volume commands to voices 0-3 is needed too.
  • Create New...