LinkoVitch

Looking at the pictures Jeff posted earlier in the thread, the original image is a 32 colour indexed image, assuming this is as it is when extracted from the CoJag ROM, I'd suspect they are stored as 32 colour 8bit images. If they have any other low colour sprites (high score font, HUD etc), then those images would likely have their palettes combined into the shared 256 colour CLUT. Low colour doesn't reduce the dynamic range of the colours (well less than 16bit), just stores the colours via an index, which is more efficient (in terms of memory) than storing the full 16bit value. So if you only need 16 colours, 4bit is perfectly fine, you will still be displaying 16bit colours on the screen, but the pixel data will be a quarter of the size in RAM. Cool thing with the OP is that if you are using 1, 2, or 4 bit images, you can merge the palettes together and then provide an offset index into the CLUT for where that objects palette starts. So you can build a screen with a bunch of low bit depth objects all using different palettes. The less RAM the bitmaps occupy the less bus bandwidth the OP has to consume to build the scan-line, the happier the overall system is. There are trade-offs obviously, but this is the Jaguar a system of trade-offs

Yes, 5bit.. as in the largest number that can be represented by 5bits is 31, hence a possible range of 32. 32 colours = 5bit. You do understand how binary works yeah?

What is a "Spliced" image? 32 colour mode is 5 bit, 4bit x2 would be 8 bit (or 256 colour). What is this splicing?

I don't know if one is available, but probably able to get one made from the PCB design that was published, but an SMD stencil will be a godsend for getting the right amount of solder paste onto the pads for use with your heat gun. I did a few by hand using i thing bit of plastic to apply paste by hand, it was tedious and messy, worked OK for stuff like resistors and caps, but when the pin density got higher I just couldn't get the right amount on pads and got loads of bridges that then took hours to sort out with wick and faff. Using a stencil I was able to solder QFP32 parts in minutes, even QFN32 too! used a lot less solder paste and so much nicer to work with. They have their own challenges, but for me at least it gave a better result than trying to hand/drag solder those parts, or manually applying paste. Good luck with your building whatever approach you go for

Is the ; semicolon in there as part of the path, as a separator or is it supposed to be to comment out the 2nd path?

That would require the game to make no calls to cart space (which given it's a CD game is likely during game play), however it would also require a rewrite of the audio code to switch from CD source to streamed from cart, which may not be too complex if the full source is available, but is also going to add additional load to the systems bus. CD Audio data comes from the CD via the I2C bus and therefore doesn't impact the main system bus at all, reading from cart space would do, and at a slower rate than reading from RAM, and only 16bits at a time for the DSP (thanks Atari! ). Certainly an interesting idea, but like most things on the Jag compromise is going to be needed quite likely (will depend how hard the system bus is being pushed)

If you are doing a cart only version, with/without Audio CD, perhaps worth considering a GD locked ROM version perhaps with MP3 of the audio tracks too? Save you on manufacture and shipping costs too.

Quick update for you and anyone else hitting this bug. There is a patched version available now: https://www.u-235.co.uk/se/files/u235se-2020-07-20.zip This resolves the need to have a mod to use the pads/RNG

If anyone is interested I have just pushed a container to docker hub that contains the latest build of RMAC and RLN. I am using it for testing commits and package building for my Sound Engine in a CI/CD environment. Other than RMAC/RLN it also features Make and a 68000 version of nm for extracting labels from the relocatable build of the sound engine. Built on Ubuntu 18.04 base and is only about 100MB. It's probably pretty niche but it's available if anyone else wants to use it. I plan to stick the Dockerfile that built it on github when I get around to it. Anyone interested in it can snag it with: docker pull hisol/jagbuild (no versions at this time as this is just the 1st push that I needed for my automation shenanigans in GitLab ) Will try and keep it updated as new releases of RMAC/RLN are made.

OUCH! I'd hate to work on something like that, much prefer chopping my source into smaller more manageable chunks and using include to combine them. I find it makes it easier to find the bits I am looking for. Would also make VCS like git store more data as it will save the whole file for a single character change.

Wow, that must be a huge file to need more than 65535 lines

Glad it's working for you thanks for saying.

There is no way to setup any delay on pad reading in my Sound Engine.. it reads both pads as fast as it can and presents the states of the pads. I just checked the code and it actually reads BOTH pads data at the same time as their data is mixed together. No it's not, they are size identical, one is using 8bit signed integers, the other is using 8 bit unsigned integers. The sample resolution is 8 bits in both formats per sample, hence they are identically sized and easy to convert between (literally add 127 to each byte if memory serves - for signed to unsigned).

For the record you ARE using SE as SE = Sound Engine It's not Second Edition or anything. As for changes in the latest version there is only one breaking change, it is quite major in terms of audio in that it won't work if you don't do it, but that's it. Other changes are actually reduction in bus usage and improved playback accuracy, and the ability to disable some features. I don't understand what you mean about requiring a delay to read the pads, all U235 SE does is process the pads internally and present the values there whenever you need them, you only need to read them when you want to, the whole engine is a passive system that you cannot really directly interact with. Not sure of any controller functions that would require a delay, can you give an example? In terms of signed/unsigned samples, it only supports signed samples because that is what is needed for MOD standards, there is no difference in quality between signed/unsigned samples, just the format the data is written in, it's pretty trivial to convert between the two formats, one day I will add unsigned support, but I have a long list of features to add and no time to add any of them. Internally the engine and the mod player are separate, the golden plan has always been to make it modular so you could swap out the mod player for another (OctaMed etc), again no time or that would be in. I'd seriously look to using 0.24 in terms of audio and performance it's a much nicer engine. If there were some nice API to adding commands to RB+ I'd probably look to implementing the necessary wrapper myself, I simply don't have time to hack away at RB+ Thanks for the feedback, if you find bugs/issues or have features let me know and they can end up "on the list"

I'd not suspect it's the RAM, the OP makes 64 bit reads from the RAM, so all 4 chips are being used whenever you see something on screen. Of course there could possibly be a single pin/track gone/going bad somewhere, I'd just suspect bad ram as having a more instant effect. Bad power isn't going to help, so deffo look at that, perhaps dried out cap in the power chain ?

Morbid curiosity, but what is wrong with U-235 SE ? If no one tells me of an issue I cannot fix it. So given U-235 SE does have a mod player, pad reading & random number generator, what is it missing that makes it not of interest to you?

Err 4 (assuming that is 68K) is Illegal instruction. Either it's hit an "illegal" or hit some garbage in ram when executing. The rest of the values are Program counters and 68000 Register dumps. When you try with official BIOS do you get a red screen on boot? or does the game also start and then crash out? IIRC BJL doesn't verify the whole cart like the official BIOS if you boot a cart from it, so it's possible to have a bad cart contact and the game crash when it needs to use that pin. Do the games included with BJL work OK?

If you want to check functionality of 68K and be able to step through it to make sure it's doing what you expect I highly recommend Easy68K.. it's a full featured 68000 simulator, and you can step through instructions, monitor memory etc. Really handy. I assume you are building up a SE command, would it not be faster to combine the values with or and only write to memory once (well 2x 16bit words) rather than a bunch of individual 8 bit writes.

Had a look in my backlog and there is an active bug in 0.24 that if there isn't a mod playing, the pad read/RNG doesn't run! This may be related to the "hang" you are experiencing. If you don't want to have music, a hacky work around would be to have a mod with a single blank pattern, no instruments and set this playing. Also if you start and immediately stop playing a module, this works too. (thanks for update CJ) I clearly need to update my testing to include situations where there is no music. I've not looked into this bug further, but it will be fixed in the next release (whenever that happens )

OOPS! Looks like I had a brain fart whilst I was writing that part :D Cheers for the heads up (fixed). Sorry not responding too quickly, very busy with work of late. RE Crashes, the mod player does have bugs, but these are mostly around effect playback and not lockups. Make sure the mod/samples are correctly aligned in your game, if the alignment is word and not long it can cause issues.

Why am I only just learning about these now! did a quick google and they look AWESOME fun! we never did them on my Comp Sci course ? (or if we did I was too busy not attending or asleep). Cheers for the info shamoo

Yep EQURUNDEF is your friend.

D'awww *blushes* thanks for the kind words. Glad that guide is still coming in useful on occasion, and glad you got your issue sorted most importantly! Word of warning, don't get it wet, or leave it alone in a dark loft for years.. they multiply! (alas mostly dead units but still ). Welcome to the crazy world of Jaguar (well, sounds like you are already well and truly in anyway, but meh, welcome )

Could be that the wire for one of the channels isn't fully connecting at either end. Off top of my head I can't remember if the Roar is a diff channel to the tune, sorry.

How are you connecting it to TV? might be one channel isn't connected properly, or the TV isn't mixing Stereo to Mono well