LinkoVitch

You have no idea if his reasons are good or not, he doesn't owe you anything. He is even leaving the repo up for a couple of days to allow people to make copies if they so wish, so he's not stopping you from doing anything. You are being very self centred. Hardly "taking his ball and going home", he has developed and provided support for this language for the last 6 years for FREE, and from what I have seen very little thanks! He is under no obligation to keep developing or supporting anything. If anyone could be accused of "taking their ball" etc, it would be you for this poor attitude.

Assuming I am understanding what you are doing (I think you might have pasted the wrong bug link BTW) I think the current version or RMAC does work correctly for calculating the difference between two labels. I have the following code in the SE .pc: move PC, JUMPTO addq #(mainloop - .pc), JUMPTO to calc a branch to the main loop, and that is working fine for me.

I'd have thought the CPLD would have been programmed via the JTAG and the voltage supplied by the programmer itself via the JTAG header? RE amps, it will draw what it needs, you just have to supply enough potential. IIRC the analogy is imagine the wire as a water pipe, Amps is the diameter of the pipe, voltage is the pressure, so as long as the "pressure" (volts) isn't too high the amps won't matter.

I would suggest one of the tips that is flat and angled (looks a bit like a knife point). The theory I read was that the tip is cooler at the point than the larger portion, so as you drag along the pins keeping the whole flat edge on the pins with the point end being the last to touch the pin as you pass over, the solder is slightly cooled and it distributes evenly. Obviously dab a LOAD of flux over the unsoldered pins with the part in place, makes a cool popping noise as you solder but helps with the bridges. My drag soldering is a bit naff tho

Yes the CLUT can only have 256 colours in it. Don't use an indexed bitmap object, use a 16bit or 32 bit object. The CLUT isn't used if the colour data is stored directly in the pixel data. Might be worth asking this question in the RB programming section, I have never used Raptor Basic

Your assumption is wrong, the Jag can display 24bit true colour images, 16/15bit RGB, 16 bit CRY, as well as 256x 16bit colours on screen at the same time.

I don't know why you are fixating on 16 colour TBH, that is just one of the options. Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc. I am speculating I've not tried pulling the ROM apart yet

From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..

Think we are at cross purposes here and perhaps I haven't understood your meaning. 1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it. If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels. There maybe fewer colours, but they are still 16bit. 2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites. Having a more subdued palette in the background works nicely for me (in games where I have seen it). If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less. Won't always be possible. It's going to matter precisely on the project and the resources, there is no single right answer.

Nope, I think you should re-read what I put about the reasons for using indexed objects. You are absolutely correct you should use indexed object for those types of images, and I never said otherwise. Save on storage, bandwidth etc, much more efficient. I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not. I don't recommend you do mind, but if done properly the Jag COULD do that.

I guess you refer to this Chris: And that "technique" was known way back in the days of them designing the silicon and publishing the developer manual. Technically EVERYONE has used that technique, because without it the OP crashes/acts weird, and probably pretty much everyone else with more than a handful of objects on the screen will have done it. This isn't some secret dark art that only the elite few know. I've actually mentioned it in passing a bunch of times in my posts on this thread in fact.

I'm going to chip in as there seems to be some confusion with what I said and stuff, so just to add in my 2p Fishing frenzy most certainly shouldn't tax the jag at all, punting sprites it can do. Of course a badly created object list will overly tax the system for what it is drawing on the screen, but even with a simple list with no branches I'd imagine the jag could happily handle fishing Frenzy. There seems to be some confusion about the "bit" of colours... Now, this is the confusion.. a 1bit, 2bit, 4bit and 8bit image on the jag are all using 16bit colour :).. the 1,2,4, & 8 refer to the size of the colour index into the CLUT (Colour Look-Up Table). Each entry in the CLUT is 16bit RGB or CRY depending on mode. The index value of a pixel simply points to which colour in that LUT to use. So a 1bit image can be 0 or 1, 2bit = 0-3, 4bit = 0-15, and 8bit = 0 - 255. The assets are high quality colour, just the pixel data is stored efficiently. Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate. Not for the graphics, but depending on the complexity you can spam the bus by making too many calls or tie the OP up with too long a list (the whole list is processed every single scan-line, every frame.) If you have a large image using indexed pixels saves a load of RAM and also memory bandwidth. The OP will like to read it's data in 64bit wide chunks. 1 64bit read is 4x 16bit pixels, 8x 8 bit pixels, 16x 4 bit pixels, 32x 2 bit pixels, and 64 1bit pixels.. so for Jeffs 352 pixel @ 4bit that's 22 reads to read a whole scan-line, vs 176 reads if it were 16bit. (assuming my dodgy mental maths worked there ). Of course if the object is smaller than a single read, you are going to waist a chunk of that potential pixel slurping. Whilst this may all sound super ossum, it does have it's own cost, in that an indexed Object has to also do a lookup in the CLUT to find the actual colour to paint, so there is additional overhead there, only slight, but still something to bear in mind. oh and you are limited to 256 colours in total shared between all those Indexed objects. Sorry Jeff, it won't.. not if it's done correctly. When you move something on the screen with the OP, it doesn't actually "move" anything. If you badly build your list, don't make use of branches and a well structured list, or have overly large objects that hang off the sides of the screen, then yeah it's going to struggle and fail. But it is entirely possible to have a full screen image with many layers of parallax. Sorry if that's a bit all over the place HTH anyway

I quite liked planar but then we established years ago I'm not normal

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.