Zerosquare Posted April 24, 2018 Share Posted April 24, 2018 Don't be fooled. This is just CJ trying to get a sneak peek at the hardware before anyone else 12 Quote Link to comment Share on other sites More sharing options...
DoTheMath Posted April 24, 2018 Share Posted April 24, 2018 Would you say Cyrano is a bit NOSEy ? Don't judge me, it's late... 6 Quote Link to comment Share on other sites More sharing options...
+thanatos Posted April 25, 2018 Share Posted April 25, 2018 Would you say Cyrano is a bit NOSEy ? Don't judge me, it's late... Well done. I feel smart today. Quote Link to comment Share on other sites More sharing options...
leech Posted April 25, 2018 Share Posted April 25, 2018 Don't be fooled. This is just CJ trying to get a sneak peek at the hardware before anyone else 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* Quote Link to comment Share on other sites More sharing options...
SainT Posted April 25, 2018 Author Share Posted April 25, 2018 (edited) 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. Edited April 25, 2018 by SainT 4 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted April 25, 2018 Share Posted April 25, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
SainT Posted April 25, 2018 Author Share Posted April 25, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted April 25, 2018 Share Posted April 25, 2018 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. Quote Link to comment Share on other sites More sharing options...
SainT Posted April 26, 2018 Author Share Posted April 26, 2018 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! 1 Quote Link to comment Share on other sites More sharing options...
SCPCD Posted April 26, 2018 Share Posted April 26, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
SainT Posted April 26, 2018 Author Share Posted April 26, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
phoenixdownita Posted April 30, 2018 Share Posted April 30, 2018 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). 2 Quote Link to comment Share on other sites More sharing options...
blipsqueak Posted April 30, 2018 Share Posted April 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
Gummy Bear Posted April 30, 2018 Share Posted April 30, 2018 Super excited for this. Already got my Jag dusted off and ready. Quote Link to comment Share on other sites More sharing options...
Hastor Posted April 30, 2018 Share Posted April 30, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
djones1960 Posted April 30, 2018 Share Posted April 30, 2018 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. Quote Link to comment Share on other sites More sharing options...
+xucaen Posted May 1, 2018 Share Posted May 1, 2018 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. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted May 1, 2018 Share Posted May 1, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Zerosquare Posted May 1, 2018 Share Posted May 1, 2018 Think about it. I'm sure you could charge twice as much! 4 Quote Link to comment Share on other sites More sharing options...
doctorclu Posted May 1, 2018 Share Posted May 1, 2018 Like everyone, looking forward to this. Love the Skunkboard but this would make development even easier! Quote Link to comment Share on other sites More sharing options...
swapd0 Posted May 2, 2018 Share Posted May 2, 2018 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. Quote Link to comment Share on other sites More sharing options...
SainT Posted May 2, 2018 Author Share Posted May 2, 2018 How? I think that you can't connect it to the PC. Yes you can. USB (and potentially WiFi). 10 Quote Link to comment Share on other sites More sharing options...
Gummy Bear Posted May 2, 2018 Share Posted May 2, 2018 Hahaha. Told. Quote Link to comment Share on other sites More sharing options...
LianneJaguar64 Posted May 3, 2018 Share Posted May 3, 2018 The same way the invocation of "The Fumes" makes me want to throw my laptop out of the window Now that's funny 2 Quote Link to comment Share on other sites More sharing options...
matmook Posted May 5, 2018 Share Posted May 5, 2018 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 ? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.