Zerosquare

Sorry, I completely forgot that you were using a Genesis controller. No wonder the PCB didn't look like the Jaguar one 🤦‍♂️ Thanks for the picture. Can you make a photo of the other side as well?

Which controller is it? The PCB doesn't look familiar. From your description, the wiring isn't correct, but I'd need pictures showing the whole PCB (both sides) to help you.

You should ask @42bs about that. I think he knows the guy.

That's correct. Both red and blue JagVR protos exist (I can't recall the difference right now -- I think it was either a matter of resolution or functionality).

Have you read this? https://www.jagware.org/index.php?/topic/930-how-to-add-a-rotary-knob-to-your-jaguar-controller/ You need a mechanical encoder. Optical encoders won't work as-is (they need a more complex circuit).

Nope. His posts are what you'd expect from a text generator AI: something that may look credible to someone not familiar with the subject, but which makes no sense when you look more closely. Don't waste your time trying to explain anything to him.

Have you checked who you're replying to?

We're talking about a fighting game, not an RPG. If you need more than 5 minutes to start playing against a friend, it's badly designed.

Height maps are mostly smooth, so maybe you could reduce the resolution and do on-the-fly 2D interpolation? Or even delta-packing compression (might be tricky in 2D).

That could make a PSA warning about the dangers of alcohol.

Very few people own the hardware.

And if my aunt had wheels, she'd be a bike.

"On-the-fly" is relative anyways. The decompression is pretty slow -- something like hundreds of milliseconds.

Unless it's a CD game, there's no point in copying the compressed picture into RAM first. It's an extra step and you don't gain anything.

Because there's so much bullshit in that thread (and the other dozens of similar ones) that the people who actually know about the hardware have given up refuting it.

Never checked, but I don't think it claims to compress any better than ordinary JPEG. From my understanding, it's just a variation that's better suited for implementation on the Jaguar hardware.

From your code, I assume you mean main RAM, not GPU/DSP RAM. It's accessible normally with the 68000 ; there's nothing special to do, and no need to write GPU/DSP code for this. Since you didn't post the complete source, it's hard to tell why the 68000 hangs, but here are a few guesses: - you have a typo in your code - you're overwriting areas that shouldn't be overwritten (exception vectors, display list) - if your code is running from RAM, it's overwriting itself

JagPEG is the predecessor of BPEG. There's some info on it, but no source code (that I know of):

Oh dear. Here we go again.

Perfect. Ship it!

You've got it backwards. The first question to ask is: is there anyone who's both able and willing to spend time creating such patches?

People living in glass houses, etc. ?

With software only, it's not possible to tell the difference between dirty contacts and a bad/missing EEPROM chip.

But the Jaguar is a big cat. How is he supposed to play the game, then? Seriously though, if you haven't done so already, clean the cart contacts and the cart slot on the Jaguar. Dirt on the pins can cause the issue you're encountering.

65.000 (65.536 actually) is the color bit depth, not the amount of unique colors per screen.