Jump to content

LinkoVitch

Members
  • Content Count

    2,799
  • Joined

  • Last visited

  • Days Won

    14

LinkoVitch last won the day on October 21 2013

LinkoVitch had the most liked content!

Community Reputation

2,122 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

15,879 profile views
  1. Yes. This is queried every time the sample is sent to the DAC.
  2. 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.
  3. 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)
  4. 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?
  5. Does the value in the status reg change at all?
  6. 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.
  7. 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.
  8. 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.
  9. 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)
  10. 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
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...