Zerosquare

Check that you have not forgotten to put a .org statement before your GPU code.

For red, the parts to check are resistor R29 and ferrite L15. If you can, also check that your TV/monitor/converter works correctly with another RGB source.

It may be an issue in the game itself. Virtual Jaguar's emulation is not cycle-accurate, so it can "hide" some issues that exist on real hardware (or the opposite). Which is why even if your use VJ for development, it's important to also run the game on real hardware to check everything works right.

What kind of video cable are you using?

It only works on mice which natively support both modes. Most early USB mice did, but current ones may not.

Either you encountered a rare bug, or it was a poor contact problem (the EEPROM has dedicated pins on the cartridge).

Oh boy. The only thing Hasbro ever released is a pretty vague press release claiming the Jaguar was an "open system". They didn't release any technical info, much less "documentation on cloning the console". All the info that's publicly known came from other sources. And even with the current prices, cloning it would require massive efforts and cost a lot more than what the original sells for. This is not an Atari 2600 we're talking about.

I don't mean the stack pointer in the game, I mean the stack pointer in your menu code.

move.l 4(sp),a0 move.l 8(sp),a1 If the stack pointer is located at the end of RAM, at that point the values on the stack may have been overwritten by the code you've copied there. Load the values from the stack before copying. Also, check the operator priority there: move.w #(_end_copy_run-_copy_run)/2-1,d7 Is it evaluated as ((_end_copy_run-_copy_run)/2)-1, or (_end_copy_run-_copy_run)/(2-1)?

If you have a way of recording it (preferably directly), it would be helpful to diagnose the problem.

Just ask CyranoJ. He loves answering that question. *ducks*

Which makes absolutely no sense. In other words, par of the course for Atari's marketing.

Why settle for Super Mario 64, when DooM 3's source code is open-source? It should be even easier to port, since Doom already exists for the Jaguar.

As a compromise, you could make it possible to hide/show the console by pressing a button, and/or using a transparent or translucent background instead of the solid black one.

Maybe JagCD games could be sold as audio CDs, then. Technically, it's even almost true

The Skunkboard is 16-bit wide, normal carts are 32-bit wide. A fault in the buffering for the upper data bits could explain the symptoms.

Also, if you're using C, make sure every variable that's accessed by both the 68k and another processor has the volatile keyword in the declaration: https://barrgroup.com/embedded-systems/how-to/c-volatile-keyword Otherwise you'll have endless weird and hard-to-find bugs.

Isn't it basically how you wrote Jagtopia?

Some people like claiming that programming the Jaguar is extremely complicated because there are too many hardware bugs. Maybe that MiSTer core is a solution for them, when they find out the real thing is not that bad after all

Check the motherboard carefully for damaged traces. If all continuity checks pass, one possibility is that one (or several) of the bus buffer chips (U12, U14, U17, U19, U22, U26, U30, U31) is defective.

Sir, this is the Jaguar forum...

I've been informed that someone else in the Jaguar community has been working on a very similar project that's almost complete -- it's just not been announced publicly yet. Since there would be no point in having two different carts that do the same thing, I'll let this person unveil their project when they're ready. But I have another idea for a related project that's not quite the same thing. So, stay tuned

Not that I remember.

Desolder those ICs and check the rails again.

Before replacing them, have you checked whether the output voltages are correct, and if not, if there is a short between output and ground?