LinkoVitch

Take the address you get from end and make sure it is phrase aligned move.l #end,d0 add.l #8, d0 and.l #$fffffff8, d0 Will leave you with a phrase aligned address in d0

Can you not define a label at the end of your program BSS and then use that as the heap location? For safety i'd make sure it's at least phrase aligned in RAM though. From what GGN showed earlier I suspect that if the heap is long aligned the malloc will not adjust it for alignment.

Perhaps the compiler isn't setting the variable with NULL correctly? perhaps try manually setting it to NULL in code before calling init_sprites? see if that resolves it, will tell you if compiler is doing it correctly... Or something somewhere is overwriting that variable/populating it?

Yeah, but... *sulks*

Dynamic memory management isn't too difficult to code from scratch, you might benefit from a custom Jaguar specific written one also. If you are say allocating RAM for a bitmap or OP list you are going to want it correctly aligned in memory, using stock generic managers might make more work for you ensuring you request excess RAM and determine correct alignment within. If you wrote your own you could specify any alignment requirements in the request and have the system nicely return memory appropriate to your needs.

I'm wondering given the weird slow down of the letters if perhaps there is a clock issue to one of the CPUs.. Not all games use all CPUs which may also explain why some work and others don't (and maybe why Raiden looks to run). Perhaps either a bad joint, or damaged track? 1st I have ever seen of a jag doing that before, hope you get it fixed.

The start of the DSP code in u235SE sets the DSP up how it likes it, and enables things only once it is ready. I imagine if you are starting the DSP with all the things already set it may be firing interrupts before they are configured, or running in the wrong bank etc. I'd not try and pre-empt it's own setup routine.

Have you checked for corrosion on any of the joints? or activity on the 68K? If the BIOS is socketted (IIRC some may be) perhaps try resocketing it in case there is dry joint. If you have any logic probes or scope, could be worth checking the address lines of the 68K, see if it is at least trying to access ROM/RAM. I am stabbing the dark here, sorry, hopefully it's not something too horrific to get fixed.

If you have a complete spare Jaguar PCB, you essentially have 2 Jaguars, just one is nakey I'd go with CJ's suggestion as a 1st port, plug it in unpowered, then it's essentially as much risk as plugging in a regular cart. You will get a "Power not connected" image on the screen, if you plug a regular cart into the top it should play the cart fine. That's pretty much testing the basics, if that works give it a whirl with power. IIRC from my poking around the PSU of the CD unit isn't connected to the cart pins anyway, there is a feed from the cart that turns on the CD unit's power when the jag is turned on (enables the 2 regulators in the system). I think it's only used for driving the CD electrickery (motors and stuff).

That's a valid option, add a pattern with nothing in that just loops to itself will work. Good thinking BatCJ I'll add the requested features all the same, but that's not happening until I start work on the next release.

I will add that to the feature request pile As there is no definitive "end of module" marker other than hitting the end of the song data, it's effectiveness *may* be a bit iffy with some modules. EG some modules will have multiple songs within a single file. To stop one of these at the end of a song I imagine either testing for the song to jump back to the same position as when it started, or jumping to a previous song position (Song may have an intro and then a body with an endless loop). So it might be worth there being a few "modes" for this, I'll have a think on it and hopefully get it in the next release. If you need it urgently let me know and I'll try and get an early release to you swapD @CJ: A module may not have a jump to the start if it is just a single song. The number of entries in the "song" is set, once you get to the end of that that is the end, at the moment the player does reset back to the start position.

Yep it is DSP. I guess I cannot assume the GPU and DSP cores will behave the same for all things, they do have their other differences, I was simply assuming that the way they would handly things such as stack would be identical. Not had any need to poke the GPU yet, but I will be with current projects soon, so I am glad to be forewarned about the "fun" on my horizon

I have heard that the GPU Object is buggy. IIRC it doesn't fire just when the OP gets to YPOS but every time or something. I have never played with it myself. RE Stack handling from interrupts, I have never had an issue with stack pointer corruption. I use: load (r31),r28 addq #4,r31 addq #2,r28 jump T,(r28) At the end of my ISR routines in U235SE. I have split the reg banks, so my ISRs have their own bank of registers to play with no worries of corrupting the secondary set.

I just found the page, and looking at the diagram I still think the GPU only has 32bit external access. The diagram beneath that text doesn't label things clearly. At the bottom is the 64bit system bus, below the GPU bus gateway. The blitter connects directly to the 64bit side of the gateway. Above the gateway is the 32bit local GPU bus, which connects to the GPU core and GPU local RAM (as well as blitter, I imagine for speed and convenience). I believe that to say make a phrase read/write the GPU would fetch or write twice to the main RAM, I doubt the gateway does a 64bit r/w operation, I don't think it forms part of the RISC core. SCPCD probably knows 100% given his tinkering

I was more referring to the physical aspects of the bus(es). IIRC the GPU is only a 32bit bus, it is within the Tom silicone which obviously has the 64bit bus attached and used by blitter and OP, but the GPU bus is still only 32 bit is it not?

Would phrase read make sense? Given both the Cart bus and the GPU memory bus are both 32bit not 64? Not sure if a split phrase read is more efficient or not than a regular long read? (I don't know the answer, hence asking the question)

Oh I fully understand who and why he did what he did/does. As I mentioned in my initial post, his pure fabrication of facts got to me back on that day and I snapped. I try to not snap often and TRY to leave this characters idiotic toxic behaviour out of my sight (one thing I really cannot stand is a liar, it's my kryptonite so it can be difficult to ignore at times). The silver lining is that hopefully my released binary will have given others ideas, and if not, it has caused the very wicked GGN to point me at some very useful and interesting source which should hopefully help get a more useful product released (hopefully not in a billion years either). Thanks for the kind words all the same

H8TE J00!!!!! :D Having actual player source will be sooper handy, my current barely working code has some horrible hacks that modify ST binary player code to work with the API for JYM, having actual source will be MUCH nicer! Cheers for the link.. you horrible nasty man :D

Bad GGN! Dangling exciting fun projects in front of my poor over projected mind! (I'm not just thinking 2149 either )

The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now. Awesome show, not as cheesy as the original

When I get time to finish it off I plan to release something, possibly as a version of my Sound Engine, or something along those lines.

Write each line as a caption of a screen capture from a popular Sci-Fi TV series. It's what all the truly "leet" coders do

The capacitors (decoupling capacitors) are there to reduce noise from the power lines caused by the circuitry within the ICs from switching on and off. Not using them may work, but also may introduce random noise into the system (whole Jaguar system), which in turn may lead to strange behaviour and crashes in the extreme. They will also help ensure the EPROMs get a nice smooth power feed, and noise from the system doesn't cause errors reading from the ROMs too. Personally, I'd say if they are there, they have been put there for a reason, so I'd be inclined to also include them.

How ironic you choose a picture of the man who oversells his own worth and abilities constantly, talking to his imaginary 'friend' to represent yourself Vladr. Many a true word said in jest as they say.. combined with a picture says a 1000 words... But then, you are also a psychology professor now too IIRC? you did read that book after all.

Would this the project he said he'd show in September that he never did and still hasn't. He's far too busy making poor attempts to bait people who actually produce things for the system and misusing terms like "Multi-Threading". It's OK he's actually pretty new to coding, I remember back when he first appeared and it took a few of us quite a few attempts to explain the concept and purpose of double buffering to him. As much fun and as easy as it is to poke fun at Vladr, his poor attempts to get a rise, his attempts to sound like he knows what he's doing, numberwang and his blatant non-starting projects, and failure to produce anything. It's probably better we all just ignore him like you would that irritating child eating its own snot whilst impersonating Pikachu and keep this much more important thread on it's rails. Vladr's had his pat on the head of attention now, lets wipe our hands and perhaps keep this thread about all the wonderful things SD Cart.