Jump to content
SainT

Upcoming Jaguar Game Drive Cartridge

Recommended Posts

 

 

One thing is: GPU/DSP shall stop itself.

 

Here some code from Atari:

;
; now kill the GPU
;
    movei    #G_CTRL,r0
    moveq    #2,r1
.die:
    store    r1,(r0)
    nop
    nop
    jr    .die
    nop


Trust me. An interrupt at the wrong time can restart that.

  • Like 1

Share this post


Link to post
Share on other sites

Trust me. An interrupt at the wrong time can restart that.

 

Therefore the loop. Anyway, it is always better to leave the room clean and proper, means disable all interrupts. Else it bites you the next time you start the GPU.

Still, I do not see a reason why one would stop it once started. I use it at least for OP-list update, so I let it running.

Share this post


Link to post
Share on other sites

 

Therefore the loop. Anyway, it is always better to leave the room clean and proper, means disable all interrupts. Else it bites you the next time you start the GPU.

Still, I do not see a reason why one would stop it once started. I use it at least for OP-list update, so I let it running.

 

Multiple code modules (game, menu, highscores, etc) that can be stand-alone binaries with shared ram for variables. Or a menu, loading multiple titles.

  • Like 2

Share this post


Link to post
Share on other sites

 

 

One thing is: GPU/DSP shall stop itself.

 

Here some code from Atari:

;
; now kill the GPU
;
    movei    #G_CTRL,r0
    moveq    #2,r1
.die:
    store    r1,(r0)
    nop
    nop
    jr    .die
    nop


 

How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code?

 

;)

  • Like 10

Share this post


Link to post
Share on other sites

 

How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code?

 

;)

 

Write each line as a caption of a screen capture from a popular Sci-Fi TV series.

 

It's what all the truly "leet" coders do :D

  • Like 4

Share this post


Link to post
Share on other sites

Those would've been fighting words with Sam Tramiel back in 1995. You should've seen his eyes pop out in anger at me at the Shareholder's Meeting when I questioned him about how much of a true Highlander fan he was for having licensed the rights to the relatively unknown-and-unloved animated series instead of the mega popular live-action tv series at the time...

 

Good times! :)

I weirdly enjoyed Highlander on the JagCD. I think it, Myst and Vidgrid were the only games I completed on the CD. My brother beat Battlemorph and Blue Lightning though.
  • Like 2

Share this post


Link to post
Share on other sites

Being able to play Highlander without buying a Jag CD is literally the thing I'm most excited about for this SD cart (not that I'll wait to buy one if CD support is delayed). It looks like exactly the kind of bad (or "bad") game I enjoy.

 

I'm also looking forward to playing the upgraded version of Hover Strike, since I quite enjoyed the original.

  • Like 3

Share this post


Link to post
Share on other sites

Yeah, I bought a Jag CD from Electronics Boutique (anyone remember them) back when the Jag was out and the sales guy was laughing at me for buying it and tried to talk me out of it.

 

Now I'm the one crying since I sold it 10 years ago lol. So Jag CD support would be a really nice feature if it can be done.

Edited by TheNameOfTheGame
  • Like 3

Share this post


Link to post
Share on other sites

Yeah, I bought a Jag CD from Electronics Boutique (anyone remember them) back when the Jag was out and the sales guy was laughing at me for buying it and tried to talk me out of it.

 

Now I'm the one crying since I sold it 10 years ago lol. So Jag CD support would be a really nice feature if it can be done.

 

I bought one of the launch Jaguars from EB on Oxford St. in London -- made a day trip down on the train to get it, lol.

  • Like 8

Share this post


Link to post
Share on other sites

 

How do I print this on 3 pages to make sure I'm getting the full effect of this GPU stopping code?

 

;)

 

You need to use the advanced mathematical field of numberwang - coupled with a fresh box of crayons.

  • Like 3

Share this post


Link to post
Share on other sites

 

Write each line as a caption of a screen capture from a popular Sci-Fi TV series.

 

Can someone enlighten me which Sci-Fi series it is?

Share this post


Link to post
Share on other sites

 

Can someone enlighten me which Sci-Fi series it is?

Battle star gallactica

 

Sent from my TA-1012 using Tapatalk

  • Like 3

Share this post


Link to post
Share on other sites

The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now.

 

Awesome show, not as cheesy as the original

  • Like 2

Share this post


Link to post
Share on other sites

The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now.

 

Awesome show, not as cheesy as the original

 

I liked the original and it was something for it's day. But I like this reboot much better. Which is usual since too often they screw up the re-boots.

  • Like 1

Share this post


Link to post
Share on other sites

The very excellent reboot, which from your question suggests you haven't seen it. If so, I HIGHLY recommend you go and watch it post haste! I got the entire blu-ray boxset from Amazon for a very low price as it's a few years old now.

 

Awesome show, not as cheesy as the original

 

Battle star gallactica

 

Sent from my TA-1012 using Tapatalk

 

Ah. Remember Lorne Green. First time I saw the original films, I thought, "wow" Bonanza goes Star Wars ;-)

Thanks for the hint. (Now we are very very off topic *ROTFL*)

  • Like 2

Share this post


Link to post
Share on other sites

Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds.

 

Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter.

 

In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed.

 

So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected.

 

There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit.

  • Like 14

Share this post


Link to post
Share on other sites

Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds.

 

Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter.

 

In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed.

 

So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected.

 

There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit.

Just one STOP object? Could you possibly expand that to three pages of code and two pages of forum text with cycle counts? Sorry - couldn't resist. So looking forward to this cart!

  • Like 6

Share this post


Link to post
Share on other sites

Ok, I just found a really interesting bug. Took me a while to figure out what was going on. I'd just patched the GCC linker to correctly handle the GPU / DSP word swapped relocations and got that working, then it all seemed to just hang. But oddly, reverting the changes to the compiler made no odds.

 

Then it took a little while to realise it wasn't actually hung, but only the first graphics object allocated was rendering. This coincided with recompiling the boot portion of the ROM, not the menu, but it was affecting the menu and not the booter.

 

In the end it turned out that just shutting down the video processor with suitable display begin and end values doesn't stop the object processor. So it looks like the object processor had a pointer in RAM which it was running through, which was actually pointing to data being decompressed from the ROM onto RAM. So I believe the OP actually managed to corrupt the data in RAM by its writeback mechanism for keeping track of objects as they are processed.

 

So now I've added a STOP object in ROM which I set it the OLP to, then wait a couple of frames for everything to settle, and now it runs as expected.

 

There was a weird intermittent issue with startup for ages which went away. It may just have been luck, I have a feeling this is the main culprit.

 

I do this at the beginning of my code and at the end before jumping back to menu:

 

lea $F00000,a0

move.l d0,0.w

moveq #4,d0

move.l d0,4.w

moveq #0,d0

move.l d0,$20(a0) ;; set OP to STOP-OBJECT

 

But pretty sure I saw this in some Atari example code back in time :-)

  • Like 1

Share this post


Link to post
Share on other sites

Crazy thought I just had - would it make a difference if the SD cart, once powered on, loaded the first rom it found on the SD card? My thought was that, with 1 and 2 GB SD cards being so cheep, that we could use an SD card like a cart - one rom or CD image on a card. Would the SD Cart then have better luck loading the cartridge and CD image? Anyways, yes, crazy thought. Ignore more if not worth a response. So, how 'bout them Pats? :D

 

Cheers

Share this post


Link to post
Share on other sites

Crazy thought I just had - would it make a difference if the SD cart, once powered on, loaded the first rom it found on the SD card?

 

If one can write to the SD card, one could load the last used ROM if e.g. A is pressed on boot, else load the menu. I'd prefer an SD card with _all_ the games and home brews ;-)

  • Like 3

Share this post


Link to post
Share on other sites

Good progress being made here. The interrupt stuff seems pretty stable now. I only enable, handle and disable interrupts from RISC code, and I've not had any odd hang-up issues on the RISC now. I also found a hardware bug in my ASIC which was causing weird behavior. The Jaguar hardware doesn't correctly de-assert the chip-selects when accessing external memory space from the RISC chips. it seems to behave OK from the 68k. I'm not sure if its because it's do contiguous reads so the external bus is saturated and the chip select doesn't get de-asserted, or if the external get is lazy and doesn't de-assert until a different address space is accessed. Either way, it meant I was getting stale data from reading a single address in a loop, so I've sorted that and it's been pretty stable.

 

The only odd thing I am seeing now is that sometimes the RISC doesn't start. I basically have this code --

		move.l	#RISCGO,G_CTRL

.waitStart:	move.l	G_CTRL,d0
		and.l	#RISCGO,d0
		beq.s	.waitStart

.waitStop:	move.l	G_CTRL,d0
		and.l	#RISCGO,d0
		bne.s	.waitStop

I've made sure the RISC is stopped before loading code and starting it up. I've added some border colour changes to see where its hanging, and its in the .waitStart loop waiting for the RISC to be running.

 

Has anyone seen this before?

  • Like 3

Share this post


Link to post
Share on other sites

Oh, interesting. If I add instructions between the GPU start (move.l #RISCGO,G_CTRL) and the wait start loop, it appears not to start more frequently. Odd.

 

The code can't be completing before it even detects it has started as its copying 256 bytes around.

  • Like 2

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...