Jump to content
SainT

Upcoming Jaguar Game Drive Cartridge

Recommended Posts

Don't be fooled. This is just CJ trying to get a sneak peek at the hardware before anyone else :D

I am okay with that... as long as we get some included ST ports with our shiny new SD Carts when they are ready... *wink wink, nudge nudge, know what I mean*

Share this post


Link to post
Share on other sites

Got around to doing a trace of the GPU code using single stepping, and I was right about the GPU going mental and resetting itself. That's precisely what happens.

 

Execution starts at the right place $f03050, the first MOVEI instruction seems to get executed ok (the PC ends up at the right place), then after the next MOVEI instruction the PC is completely wrong.... it's skipped ahead from $f03056 to $f0307a.

 

The same happens if I replace the first couple of instructions with nops, it jumps from $f03052 to $f0307a.

 

But also when the PC runs from $f0307a, it doesn't seem to execute code correctly. The PC increments by 2 every time, regardless of the instruction until it eventually jumps off into random main RAM and crashes the GPU, resetting it. I've no idea where the PC ends up then, but most of the time the code in GPU RAM is run.

 

BUT get this.... if the PC is $f0304e with a NOP there... guess what? It runs fine.

 

So it would seem, if you start your GPU code with a PC of $f03050 then it crashes the GPU. Sometimes the GPU doesn't reset itself also, it just hangs. I'll have a go at actually getting things working with this new found knowledge. I can add work-arounds in the CDinit code to detect the particular game and patch the issue if required.

 

I'm trying to find some logical explanation for this, but I really cant. Can the prefetch queue somehow not be getting invalidated if the PC was set as that the last time it was run or something?

 

Hmm, doesn't seem so. I set the PC to $f0304e, single stepped one instruction. Stopped the GPU, reset the PC to $f03050 and single stepped again. Same problem!

 

Amazing. But not in a good way. :-o

Edited by SainT
  • Like 4

Share this post


Link to post
Share on other sites

From what I can remember (And I just woke up so....)

 

There are 5 interrupt vectors, each of $10 bytes from $f03000 to $f03040.

 

All the GPU code I've written (that does not use interrupts) starts at $f03080. I've never bothered to see if it could start lower because 'this just works' but I wouldn't be shocked if something trashes that space out. AFAIR all the Atari examples start at $f03080 as well.

  • Like 2

Share this post


Link to post
Share on other sites

From what I can remember (And I just woke up so....)

 

There are 5 interrupt vectors, each of $10 bytes from $f03000 to $f03040.

 

All the GPU code I've written (that does not use interrupts) starts at $f03080. I've never bothered to see if it could start lower because 'this just works' but I wouldn't be shocked if something trashes that space out. AFAIR all the Atari examples start at $f03080 as well.

Yep, you are spot on, $f03050 should be the first usable non-interrupt vector memory for the GPU. And to be honest, that's most likely where I would put code also if I wanted to have the possibility of using all interrupts. I quite often use $f03000 if interrupts are disabled for quick test code. If there is just one interrupt enabled I'd also just use the vector start address as the code start.

 

So it doesn't seem unreasonable code to me. But nothing is trashing the memory... the GPU is actually hanging!

 

I need to have a look at the verilog code generated from the Jaguar netlist to see if I can see what on earth is going on with this one. It's just too bizarre.

  • Like 2

Share this post


Link to post
Share on other sites

Gridrunner doesn't use the vectors to JUMP to code, as I only use one interrupt (GPU) so I put the code over the vector to save some cycles.

 

It starts at $f03030 and runs to $f035E, followed by 4 longwords of data. So it would seem that the GPU can run code from that address when under an actual interrupt.

Share this post


Link to post
Share on other sites

Gridrunner doesn't use the vectors to JUMP to code, as I only use one interrupt (GPU) so I put the code over the vector to save some cycles.

 

It starts at $f03030 and runs to $f035E, followed by 4 longwords of data. So it would seem that the GPU can run code from that address when under an actual interrupt.

 

Yep, as described above when starting at $f0304e, it can run code at this address. However if you set the PC to $f03050 initially, then start the GPU, it will screw up.

 

It purely just seems to be a startup issue. I could do with investigating if any other addresses cause a problem, or if its just the one! :)

  • Like 1

Share this post


Link to post
Share on other sites

There is no bug on the GPU on that.

 

If it crashs the way you say, I would be probably 100% sure it's one the following way :

- GPU code is wrong (wrong registers used, or not properly initialised, wrong address/instructions from the build process, wrong alignment)

- Another CPU makes it crachs : most probability the 68k, then the Blitter (wrong commands), then DSP, and the less probability for the OP.

 

 

What is running on other CPU when the GPU crash ?

 

Some games make fucking bad stuff with the GPU (like overwriting GPU PC at any time, step by step, PC checking, no semaphore, etc...)

Many use GPU code in main memory to init some basic stuff but it can be possible that the loading/unpacking process was not executed properly or at the good time if not used on real jaguar with real jagcd and original boot rom, GPU will then crash.

  • Like 1

Share this post


Link to post
Share on other sites

There is no bug on the GPU on that.

 

If it crashs the way you say, I would be probably 100% sure it's one the following way :

- GPU code is wrong (wrong registers used, or not properly initialised, wrong address/instructions from the build process, wrong alignment)

- Another CPU makes it crachs : most probability the 68k, then the Blitter (wrong commands), then DSP, and the less probability for the OP.

 

 

What is running on other CPU when the GPU crash ?

 

Some games make fucking bad stuff with the GPU (like overwriting GPU PC at any time, step by step, PC checking, no semaphore, etc...)

Many use GPU code in main memory to init some basic stuff but it can be possible that the loading/unpacking process was not executed properly or at the good time if not used on real jaguar with real jagcd and original boot rom, GPU will then crash.

 

I've verified it several times, try it yourself -- I'd be curious to see what you get. Most people wouldn't notice as the GPU hangs and resets itself most of the time, so you never actually realise what has happened.

 

Initialise the GPU SRAM with all NOPS, clear the flags so there are no interrupts and set the PC to $f03050, then single step it with the 68k storing the GPU PC each step and see what results you get.

 

As I say, it's nothing to do with code, this happens with just nops.

  • Like 2

Share this post


Link to post
Share on other sites

I've verified it several times, try it yourself -- I'd be curious to see what you get. Most people wouldn't notice as the GPU hangs and resets itself most of the time, so you never actually realise what has happened.

 

Initialise the GPU SRAM with all NOPS, clear the flags so there are no interrupts and set the PC to $f03050, then single step it with the 68k storing the GPU PC each step and see what results you get.

 

As I say, it's nothing to do with code, this happens with just nops.

Does it mean the GPU cannot execute nops or that the GPU plain just doesn't work at all? .... the second case seems to be a little disproved ... not sure you tripped on the only location that causes that behavior or the method you use to track the GPU PC is just not supported and does not do what you think it should do.

It may just be broken, not saying what you did was wrong in principle.

 

Also totally agreed on delay the CDROM thing and ship what you have and get to it later if/when you have time ... too many projects got bogged down by "just one more debugging session and I get the SW right" ... "just one more resistor change and the voltage is perfect" .... keep up the good work, it's about time the Jag gets a "flash cart" (I know it's a misnomer but may as well).

  • Like 2

Share this post


Link to post
Share on other sites

Do whatever you want. I don't have a TON of interest in CD emulation for retail stuff anyway, obviously... It's a shame for CD exclusive homebrew but I would totally be cool with a future update if possible.

Share this post


Link to post
Share on other sites

I'll admit the CD emulation was perhaps the biggest deal for me here - I have most of the carts I'll ever play, but never got a CD drive, and put my plans to buy one on hold when this was announced. That said, I'd much rather have a flash cart that does cart games, as there's a few I've missed, soon, than to wait forever. However I'd also like to hope that it doesn't kill research on the ability... It seems really close (to someone who knows jack about this level of stuff).

 

I'd be more than happy to buy a second, more expensive cartridge in 6 months or a year, that has CD support, if the current one can't be firmware upgraded to support it. I'd just hate to think that the idea is dead forever. If so, let me know so I can start gathering the hardware for the CD games, which are the majority of Jag games I've missed out on.

  • Like 3

Share this post


Link to post
Share on other sites

I've been reading along and have enjoyed the hardware discussion. It's just a shame I don't know enough about the Jaguar's internal hardware to have much of anything to contribute. One thing I'm curious about. It's been mention that it's not an interrupt that is causing a the problem. Does the Jaguar have or use DMA and could that be causing the problem being experienced? Probably a dumb question. But it might give some food for thought.

Share this post


Link to post
Share on other sites

I am okay with that... as long as we get some included ST ports with our shiny new SD Carts when they are ready... *wink wink, nudge nudge, know what I mean*

Hmmm... I wonder if the ST ports could be made to only work with the SD cart, as a sort of exclusive release. I'd pay extra for that. ;-)

Share this post


Link to post
Share on other sites

Hmmm... I wonder if the ST ports could be made to only work with the SD cart, as a sort of exclusive release. I'd pay extra for that. ;-)

 

Extra than the free for the Skunk versions.. Hmm.

  • Like 2

Share this post


Link to post
Share on other sites

Like everyone, looking forward to this. Love the Skunkboard but this would make development even easier!

Share this post


Link to post
Share on other sites

Like everyone, looking forward to this. Love the Skunkboard but this would make development even easier!

 

How? I think that you can't connect it to the PC.

Share this post


Link to post
Share on other sites

 

How? I think that you can't connect it to the PC.

 

Yes you can. USB (and potentially WiFi).

  • Like 10

Share this post


Link to post
Share on other sites

I'm just trying to understand this thing...

 

I use to place my gpu code right after the gpu vector table (filled with nop so my code start at $f03050) and it's working all the times. Have you set a 68k vbl interrupt ? When you start, what is the value of G_FLAGS ?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   1 member

×
×
  • Create New...