LinkoVitch

Did you have any interrupts running? and/or have any problems subsequently copying new code into the processors RAM once you stopped it in this fashion? Problem I saw was when you then tried to load code back into the supposedly stopped processor it would sometimes lock up.

I had fun with stopping the DSP, Shamus thankfully pointed out the error of my ways. Originally I was just stuffing 0 into D_CTRL which in my mind should stop the DSP dead. It more often than not caused it to lock up. The solution I now have in place (thanks Shamus ) is a semaphore that signals to all interrupts that a stop is requested. When each interrupt fires and sees this semaphore set it disables itself from the D_FLAGS register and exits, also setting a flag to say it has stopped. Once ALL interrupts have confirmed they have stopped, THEN the main loop stuffs 0 into D_CTRL and does a bunch of nops just to be sure it doesn't get carried away and run some extra code for lols I suspect that what was happening in my case was an interrupt was firing after I had set D_CTRL to 0, and essentially running the core in a zombie state, so it ate it's own brain and just sat there jammed up. Hopefully that is of some use to you squire? Obviously for GPU you're going to want to replace those D_ for G_ :D

The fumes might smell better from a Microwave tho

Another thing worth checking.. have you checked the system with another cart that has sound? I am thinking the fault MAY be the actual Audio hookup to the TV (or the TV ). I have had SCART plugs partially come out which has left the picture working perfectly but one audio channel vanishing. Depending on what you are using cable wise might be worth checking too. Perhaps check the AV connector on the back of the Jag, make sure it is nice and happy and that the cable is well seated there too. Or if you have an RF enabled (never thought I'd refer to RF as "enabled" ) perhaps try tuning that in and see if the audio is present there?

Good spot that man I was of course assuming stock Jaguar BIOS.

NOT if it's using a fully signed header like official Atari released carts, as the console reads the whole cart to generate the signature, 1 bit wrong and it's red screen time. Unless of course the full scan was made without error and THEN the contacts went bad. Universal header, then yeah it'll boot regardless as no verification performed.

Is this an official Atari Karts made by Atari, Skunk running ROM or a Repo? If there is a bad contact or incorrect ROM (corruption) then the initial signature of the cart should fail and red screen. However if the header has been changed to the universal header then there will be no cart check and it would try and run even with corruption. Same is true of Skunk as it replaces the header with it's own, so if the flash isn't quite right or your skunk isn't perfectly seated you may get errors in the flash. (I have also seen my Skunk behaving oddly if the USB cable is connected to the skunk but not to a PC, I assume it's acting like an antenna/capacitor and upsetting things).

The "To the Article" link on the page just takes you to the same page? I assume that's not correct (can't see anywhere where you state which wire goes to which pin on that page). I'd recommend soldering on a socket also rather than direct to an EEPROM, that way you can always change it up later or have diff EEPROM for diff projects. (Side note, some of the revisions of EEPROM will need the data width selection pin setting appropriately, older revisions didn't)

They are not difficult to write, just code one up for your purposes, should take only 10-15 minutes to write from scratch in pretty much any native PC based language (C, C++, C#, PHP, Python, JAVA etc), choose your preferred language and just write it.

And setup some bits and pieces in booth 16, but then denied it existed?

I wonder if they tried for booth 64

Wow! an original Jaguar voice modem on top of your TV! AWESOME

Thanks. The details of the GPU/DSP instructions are already in the Tech manual, I've found it has enough detail on them.. If there are any that you have questions on, this is the forum (perhaps not this exact thread ) to ask in . Fair few people have wrestled with the RISC cores of the jag on here and happy to help I imagine.

I created a spreadsheet years ago to help me visualise the structure of OP objects. Just needed it again and it took me FAAAR to long to find. As I find it useful, others might as well, so I am posting on my website. Hopefully this will be of use to someone (and I'll be able to find it easier in future ) https://www.u-235.co.uk/developer/object-lists/

present for you or your mste?

This is the 1st release with ELF (which I don't use myself) so I imagine there are going to be a few snagging points OOPS on the duplicates! I'll make a note of that and get the inc file cleaned up, they are just external definitions so no harm in them being there, you can always delete the extra ones. Just had a look at the elf.o with nm and you are correct it seems that there are a bunch of labels undefined, but they do all exist. The output is from RMAC, again, maybe an option I have missed somewhere. I'll add these to the bug list and try to resolve for next release when I get time to work on it again.

I have just posted version 0.23 of the U-235 SoundEngine to the site. Squashed a bunch of bugs, code optimisations, a new feature or two (minior), but generally better sound quality (more in tune), and DSP performance improvements. Grab it here I should probably go to bed

Well as of version 0.23 (not released just yet ) there will be an ELF binary object included in the release. For questions about Jiffi, probably worth starting another thread and IIRC ask Cyrano Jones ?

I'm using RLN with RMAC, not LD. I can include an ELF object file, but for my main Makefile and example code I'll stick to RLN / ALN I think. Other than people who are writing stuff with tools like GCC, I suspect there aren't many using LD?

That's a pretty common rule, not forgetting whilst optimizing the code go though tutting at how badly written parts are that you are rewriting (that you wrote months/years ago)

I was thinking we should draw up a list of features that people want, and then split the list 50/50 between our two engines,

This could be due to SCART being a bit of a behemoth of a connector at the TV end. I thought I had a bug/fault when I lost an entire audio channel, turned out that the official Atari SCART cable I used had managed to partly disconnect, so one of the audio channels wasn't connected. Especially if unplug and replug solves the issue, I'd say that's a bad connection between the SCART plug and socket of your TV. Also, always make sure to plug it into the RGB SCART socket if the TV has multiple, as a cost saving some TVs with multiple SCART holes don't always support RGB on all of their scart holes. They normally have some small icon to indicate this, or deets in the manuals

I just checked and RMAC seems happy to create ELF objects, however they don't seem to work too well with RLN, I guess you are using some other tool for linking? I should be able to include both BSD and ELF format object files however, not like they are huge.

Sample compression is already on the backlog of things to do Focusing on a bit of a code tidy, bug fixes and optimisations for the next release, although not likely to squash all bugs alas. This is beta afterall

It's all part of my plan, I have started a new life like Michael Jackson, but I couldn't afford an oxygen tent, so I got a Helium one instead, I am now trying to make everything else sound normal to me