Upcoming Jaguar Game Drive Cartridge

[JagChris]

Go take a walk and think about it.

[RARusk]

Have you considered getting a rubber duck? From what I read programmers, when they get stuck on something, talk to the duck explaining the situation and somehow they come up with the solution while doing so. Won't hurt to try.

[JagChris]

Only works in the bathtub where duckies work their magic ?

Edited April 20, 2018 by JagChris

[swapd0]

I hope that all this headaches don't affect the final price XD

[LinkoVitch]

Have you considered getting a rubber duck? From what I read programmers, when they get stuck on something, talk to the duck explaining the situation and somehow they come up with the solution while doing so. Won't hurt to try.

 

 

Rubber ducks for programming are a mith.. honest... Nothing to see here...

 

(no idea why that is rotated)

[Krip316]

Unfortunately, every single time I start explaining my technical findings in jaguar subforums (in 8-bit section, it's possible to have such discussions), a shitstorm ensues, as certain characters start spinning sh*t in 10 directions, disregarding the technical reality, mocking me like we're in kindergarten (and we're all roughly in the 40-50 age bracket here), thus killing every possible ounce of my motivation to waste energy on such explanation.

Why don’t you pm SainT your findings then? Like he said, he could use all the help he can get.

[SainT]

Have you considered getting a rubber duck? From what I read programmers, when they get stuck on something, talk to the duck explaining the situation and somehow they come up with the solution while doing so. Won't hurt to try.

 

Lol, that's why I post here in a way! I find actually writing down what a problem is actually gives you a better insight into the problem as you actually have to fully explain it. Plus there are actually people here with good insight into the Jag's weirdness too, ofc... not saying you lot are rubber ducks. You give far more useful feedquack. er. back.

 

Sorry, been a fun day banging my head against the Jaguar.

[SainT]

GPU code from the Baldies loader. Thought some might find it interesting. The CD BIOS code resides at the pointer Stack, which is also the stack top. No prizes for figuring out how the code could fail with it ending up executing the CD BIOS interrupt code out of interrupt!!

 

So now I know how... just not sure why!

.gpu
.org $F03050
EntryPoint:
movei #Stack,r31 ; stack
movei #ShutDown,r00 ; shutdown semaphore
L5C:
load (r00),r01 ; F0305C A401
or r01,r01 ; F0305E 2821
jr z,L5C ; F03060 D7A2
nop ; F03062 E400
nop ; F03064 E400
movei #$0,r00 ; F03066 9800 0000 0000
movei #$f02114,r01 ; F0306C 9801 2114 00F0
store r00,(r01) ; F03072 BC20
nop ; F03074 E400
nop ; F03076 E400
nop ; F03078 E400
nop ; F0307A E400
ShutDown:
dc.l 0
ds.l 16 ; 16 long stack
Stack:
ds.b 334

Edited April 20, 2018 by SainT

[SainT]

Despite much poking, it still makes little sense. My money was on a stack overflow corrupting the semaphore / shutdown code, but that isn't the case. I've also run the same GPU code in my test harness with no problem. So there's something strange going on.

 

I've replaced the existing "wait" code with something to flash the BG color in a tight loop, so I can see the GPU is running. The odd things is, it never hangs, the background is constantly strobing. It would appear that the GPU executes for a short period and processes interrupts correctly, then executes the interrupt code out of interrupt. The return address in this case, as there isn't actually one pushed on the stack, is $8000, which would mean is just starts executing random crap from main memory.

 

The same happens if all interrupts are disabled, the IRQ code gets executed. Oddly though, if I put an endless loop on a bittest of the imask bit (which is 0), then the GPU still runs and the screen still strobes.

 

So while the GPU goes off the rails, it seems to reset itself.

 

Unfortunately all this bizarreness means I'm probably going to abandon CD support for the time being, as there is no logical explanation as to what is going on and no currently solution to make the GPU run correctly.

[coleshores]

I wonder if it's possible to track down the original author of the CD bios to help explain the logic. Jeff Minter probably knows who wrote that routine since he wrote the VLM.

[SainT]

I wonder if it's possible to track down the original author of the CD bios to help explain the logic. Jeff Minter probably knows who wrote that routine since he wrote the VLM.

 

Absolutely nothing to do with the CD BIOS at all, this is my code. The issue is the GPU / RISC chip is doing things it really shouldn't be doing...

[Agent 47]

Will this flashcart be firmware upgradable by the customer? If the initial batch of carts ship without CD support and you discover a solution later on, do you think it will be possible to upgrade the original carts with a firmware or will a new cart need to be purchased? CD support is a feature I would really want, so I would probably hold off on preordering if you think this feature will come later and require a new purchase. Hopefully, that’s not the case.

 

Thanks for working so hard on this. I’m sure the final product will be great with or without CD support.

[LinkoVitch]

Despite much poking, it still makes little sense. My money was on a stack overflow corrupting the semaphore / shutdown code, but that isn't the case. I've also run the same GPU code in my test harness with no problem. So there's something strange going on.

 

I've replaced the existing "wait" code with something to flash the BG color in a tight loop, so I can see the GPU is running. The odd things is, it never hangs, the background is constantly strobing. It would appear that the GPU executes for a short period and processes interrupts correctly, then executes the interrupt code out of interrupt. The return address in this case, as there isn't actually one pushed on the stack, is $8000, which would mean is just starts executing random crap from main memory.

 

Are you running the GPU with split registers or unified? If you have split the registers (I cannot remember the term and about to head out), then you'd need a second stack pointer IIRC for the interrupt calls.

 

Could it possibly be a second interrupt is attempting to fire before the current one has finished executing? and consuming 2 addresses from the stack? or perhaps getting a return address inside the ISR and hence running the rout outside of an interrupt ?

[LinkoVitch]

Quick copy pasta from one of my Timer routes (Timer 1) on the DSP if it's any help.

t1handler:
	bclr	#3,r29			; Clear IMASK
	; ----------------------------------------------------- timer code here
; blah blah, codey code blah blah
	; ----------------------------------------------------- end of timer code	
	bset	#11,r29			; Clear the T1 latch   D_TIM1CLR		$00000800
	load	(STACKPTR),r28		; Get the address of the last instruction executed from stack
	addq	#4,STACKPTR			; realign the stack
	addq	#2,r28			; point to the next instruction
	jump	T,(r28)			; jump back into main code
	store	r29,(r30)		; write the control flags back
	nop
	nop	

I am sure you have working code, but may be of some help. STACKPTR is r31 and I run with the registers split in 2, so ISR gets the 2nd bank

[SainT]

Does the same with interrupts disabled, I'm afraid. My test code originally used both register banks with non interrupt in bank 1 and interrupt in bank 0 (as it has to be for interrupts). The Baldies loader code just uses bank 0, but equally does nothing in the non-interrupt code other than wait for exit. The stack is set correctly.

 

And to answer the other question, it will be firmware upgradable, so additinal features can be added after launch, yes. Assuming no hardware modifications are required of course. However my enthusiasm for debugging broken hardware is waning... I spend most of my time figuring out why the Jaguar hardware doesn't work rather than actually doing anything productive.

Edited April 23, 2018 by SainT

[coleshores]

While it would be be unfortunate to not be able to play Battlemorph, it ultimately isn't that big of a loss. There isn't much software on the Jag CD that couldn't be found elsewhere.
As a work around, would it be possible to integrate something like the MSU-1 on the SD2SNES? Many(most?) Jaguar games lack music so it would be nice to patch it in.

Edited April 23, 2018 by coleshores

[SainT]

On 4/23/2018 at 8:58 PM, coleshores said:

While it would be be unfortunate to not be able to play Battlemorph, it ultimately isn't that big of a loss. There isn't much software on the Jag CD that couldn't be found elsewhere.

As a work around, would it be possible to integrate something like the MSU-1 on the SD2SNES? Many(most?) Jaguar games lack music so it would be nice to patch it in.

 

But no games support anything like that? Not sure what use it would be.

 

I can add additional audio hardware (I already have a YM2149 in mind), but without software to support it, it's not going to do anything. Just being able to stream (more or less) limitless amounts of PCM wave data from a memory card solves the music issue in itself for new software. But things like the YM2149 open up the ST ports for full audio, or a YM2612 would help on Megadrive audio ports, etc...

 

I have a fair bit of space left on the CPLD, so extra features are definitely a possibility.

 

Its a shame I cant use it to fix the broken hardware of the Jaguar.

Edited October 25, 2019 by SainT

[DoTheMath]

While it would be be unfortunate to not be able to play Battlemorph, it ultimately isn't that big of a loss. There isn't much software on the Jag CD that couldn't be found elsewhere.

As a work around, would it be possible to integrate something like the MSU-1 on the SD2SNES? Many(most?) Jaguar games lack music so it would be nice to patch it in.

Well there's also Highlander and Iron soldier 2's superior cd version.

 

Edit: It would't be that big of a problem especially if it can be patched...

Edited April 23, 2018 by DoTheMath

[leech]

Well there's also Highlander and Iron soldier 2's superior cd version.

 

Edit: It would't be that big of a problem especially if it can be patched...

Robinson's Requiem was finally released as well. Plus a bunch of free games which are much easier to run off a CD. Then again I guess with the SD Cart we wouldn't need to burn them

[+CyranoJ]

I'd be happy to run a fresh set of eyes over it if you like?

[DoTheMath]

Robinson's Requiem was finally released as well. Plus a bunch of free games which are much easier to run off a CD. Then again I guess with the SD Cart we wouldn't need to burn them

I kinda want to replay Myst on the Jag even if i finished it on PC back then

[SainT]

I'd be happy to run a fresh set of eyes over it if you like?

 

The problem is that its not the code in itself... I can run the same code in a test harness and it works. There's something more going on. Plus my code should never even be hit when interrupts are disabled, and the other GPU code is just a tight loop flashing the BG col! It should never exit that loop....

 

What might be a good idea is I get a few niceties fixed up, like running code from USB and updating the CPLD and Micro in-system, and build up another cart and send you one. At least you could then see the issue yourself and might be able to make some sense of things.

 

I have one more idea to trace the issue. Put the GPU in single step mode and just keep stepping it via the 68k and keep track of the PC. Although, what normally happens, is if you try and trace an issue in this way, it magically goes away...

[aminor00]

 

The problem is that its not the code in itself... I can run the same code in a test harness and it works. There's something more going on. Plus my code should never even be hit when interrupts are disabled, and the other GPU code is just a tight loop flashing the BG col! It should never exit that loop....

 

What might be a good idea is I get a few niceties fixed up, like running code from USB and updating the CPLD and Micro in-system, and build up another cart and send you one. At least you could then see the issue yourself and might be able to make some sense of things.

 

I have one more idea to trace the issue. Put the GPU in single step mode and just keep stepping it via the 68k and keep track of the PC. Although, what normally happens, is if you try and trace an issue in this way, it magically goes away...

Is it possible that it's a Jaguar hardware issue? Do you have any other Jags to try it on?

 

I've got a couple and could drop them off with you if you thought it was worth while. I think I'm pretty close to you, in Haslemere, Surrey.

 

Sent from my SM-G930F using Tapatalk

[+CyranoJ]

 

The problem is that its not the code in itself... I can run the same code in a test harness and it works. There's something more going on. Plus my code should never even be hit when interrupts are disabled, and the other GPU code is just a tight loop flashing the BG col! It should never exit that loop....

 

What might be a good idea is I get a few niceties fixed up, like running code from USB and updating the CPLD and Micro in-system, and build up another cart and send you one. At least you could then see the issue yourself and might be able to make some sense of things.

 

I have one more idea to trace the issue. Put the GPU in single step mode and just keep stepping it via the 68k and keep track of the PC. Although, what normally happens, is if you try and trace an issue in this way, it magically goes away...

 

It would be an honour, sir!

[leech]

Loving the cooperation here!