Jump to content
SainT

Upcoming Jaguar Game Drive Cartridge

Recommended Posts

This comment made me think of one of the Atari ST menu disks which had a little mini platformer game as the game selector. Damned if I can remember which disk it was though.... but that would be awesome as a Jag launcher.

 

Games for screen selection were popular in the Atari ST demo scene. I dont think it was really that common on other platforms, interestingly. I'm not sure how it started, but the Cuddly Demos was the first I remember.

 

There was some very cool stuff like the European demos with fullscreen 50Hz scrolling...

 

european_menu.gif

  • Like 1

Share this post


Link to post
Share on other sites

 

Games for screen selection were popular in the Atari ST demo scene. I dont think it was really that common on other platforms, interestingly. I'm not sure how it started, but the Cuddly Demos was the first I remember.

 

Indeed, screen selection "games" were very popular at the ST. I think the first one was "The Union Demo" from 1989.

 

And there were also a few demos with full games like Sokoban and Match-It in the Syntax Terror Demo and of course Crap Man from the Synergy Mega Demo which is one of the best pac-man clones on any (classic) platform.

  • Like 3

Share this post


Link to post
Share on other sites

Another "why is the Jaguar behaving weirdly" question...

 

I'm updating the palette every frame to fade a logo in and out, and the colours are not stable. In particular when I'm writing the SAME palette every frame, colour 11 (light grey) flickers black. This is happening writing the palette quite soon after the vblank interrupt. I'm just doing a direct word copy from the palette in main ram to the palette registers (0xF00400) while applying a fade.

 

There have been so many "what the *£$%$" moments trying to get the Jaguar working how I want, especially without a debugger... :mad:

Edited by SainT

Share this post


Link to post
Share on other sites

Ah, Dark Side of the Spoon... the demo that I spent a week of disconnects and pain with a 1200 bod modem to download... and it ended up notworking on the Mega STe.

Share this post


Link to post
Share on other sites

There have been so many "what the *£$%$" moments trying to get the Jaguar working how I want, especially without a debugger... :mad:

Hi! Welcome to the world of Jaguar development :D

  • Like 3

Share this post


Link to post
Share on other sites

Hi! Welcome to the world of Jaguar development :D

 

Lol, there are some lovely hardware nuances. :-o

 

One thing that helps is setting VDE to 0xffff, which is what most games seen to do. But oddly, this doesn't seem to be enough. The palette is mostly stable now, fading up and holding, but fading down is still a bit ropey. But the code is identical... just decrementing a value not incrementing. Bizarre.

 

It would seem possibly writing to the palette register while its being read by the OP is causing the write to fail? But even so, I'm writing to the registers after the vblank interrupt, with the OP guarded with branches over the blank areas. So.... meh. I dont know.

 

Final fix was to calculate the palette and store it, then write it to the palette registers in the vblank.

 

Very odd. :?

  • Like 3

Share this post


Link to post
Share on other sites

There is no vertical blank interrupt (VBI) on the Jaguar, only a video interrupt (VI) which can occur on any scanline(!). The only way to ensure that you are in the vertical blanking period is to watch VC (video count) and wait until the correct number of lines has gone by, or set the VI register to the correct value. :P

 

It sounds like you're trying to use the Palette RAM as a read source? If so, that might not be so stable. :)

 

Like Zero said, welcome to the world of Jaguar development! ;)

 

BTW, if you have the time to make notes on the differences between what VJ does and real hardware does, I'd love to see those. :D

  • Like 2

Share this post


Link to post
Share on other sites

There is no vertical blank interrupt (VBI) on the Jaguar, only a video interrupt (VI) which can occur on any scanline(!). The only way to ensure that you are in the vertical blanking period is to watch VC (video count) and wait until the correct number of lines has gone by, or set the VI register to the correct value. :P

 

It sounds like you're trying to use the Palette RAM as a read source? If so, that might not be so stable. :)

 

Like Zero said, welcome to the world of Jaguar development! ;)

 

BTW, if you have the time to make notes on the differences between what VJ does and real hardware does, I'd love to see those. :D

Yeah, if VI is set to VDE (which it is, well, what VDE should be) then the video interrupt is at the start of the blanking period. Which is what everyone does from what I can see, so to all intents and purposes it's a vertical blank interrupt.

 

No, I'm not reading the palette, just writing. The only reads will be from the OP while drawing the bitmap object, but this shouldn't be happening outside of the active display area, unless I've got my branches setup wrong. Although the issue is still there when VDE is setup correctly (not FFFF) which should rule out incorrect branches being a cause.

 

I also found that when the palette appeared to be stable while just writing to the first clut, I thought I'd try also writing to the second (even though writing to either writes to both) to see if that cleared up the fade down issue. This then caused the palette to be unstable again all the time. So there's definitely something odd going on relating to timing of writes into the clut... but I'm really not sure what.

 

Finding issues like this makes me very nervous. If you can't rely on the fact that writing to a register actually works, then it's massively unsettling! If I understood the root cause I'd feel happier... :)

 

Oh, and another weird thing. Can you not just write to the status register of the 68k on the Jag? On a few occasions I've been using move.w #$2700,sr or 2000 etc and getting weird hangs, whereas if you move the sr to d0, modify and then move back to sr it seems happy. This behaviour seems to happen in VJ also. I cannot ever remember issues like this wile in supervisor mode on the ST. :?

 

I need to get the hardware debugger working. I've got provision for triggering an NMI from the debug header on the Jag if connected to the cart, so I can do hardware breakpoints on read / write / execute at addresses etc... Might be able to get to the bottom of the weirdness then! :)

  • Like 5

Share this post


Link to post
Share on other sites

Oh, and another weird thing. Can you not just write to the status register of the 68k on the Jag? On a few occasions I've been using move.w #$2700,sr or 2000 etc and getting weird hangs, whereas if you move the sr to d0, modify and then move back to sr it seems happy. This behaviour seems to happen in VJ also. I cannot ever remember issues like this wile in supervisor mode on the ST. :?

 

I'm afraid I have no insight into why this happens. Maybe someone with better 68K knowledge can chime in. :)

Share this post


Link to post
Share on other sites

Latest update, things are pretty functional now. Next up is EEPROM emulation (I did say CD emulation in the video, but I forgot about EEPROM... ;)).

 

  • Like 27

Share this post


Link to post
Share on other sites

 

I'm afraid I have no insight into why this happens. Maybe someone with better 68K knowledge can chime in. :)

 

This seems to be something odd to do with pending interrupts or hanging the OP or something like that I think. I dont know if the Jaguar does something weird in terms of interrupt generation for the 68k, but I've found I can get booting stable by disabling the video output, setting up the video regs and interrupt setup, then re-enabling the video display. Before I changed to this method of disabling video output (very briefly) I would get random hangs with interrupts not being generated. Very odd.

Share this post


Link to post
Share on other sites

Glen, how about a feature on your show.

 

Who is SainT? What is his day to day job? What makes him tick? How did he become involved in the retro scene? What is his favourite colour? That sort of thing.

 

I think we'd all be interested.

 

Sent from my SM-G930F using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites

Good job!

 

I see the boot/logo code is run when you launch a game, is there a particular reason for that?

I don't think it's actually needed since the Skunkboard doesn't do it and games still run fine, and it slows down the process of launching a game.

But maybe you're actually rebooting the Jaguar?

 

This seems to be something odd to do with pending interrupts or hanging the OP or something like that I think. I dont know if the Jaguar does something weird in terms of interrupt generation for the 68k, but I've found I can get booting stable by disabling the video output, setting up the video regs and interrupt setup, then re-enabling the video display. Before I changed to this method of disabling video output (very briefly) I would get random hangs with interrupts not being generated. Very odd.

Have you written all the code from scratch, or based it on the existing examples? The Jag hardware is pretty finicky, so if it's the former, you may have missed a small thing somewhere.

Share this post


Link to post
Share on other sites

Glen, how about a feature on your show.

 

Who is SainT? What is his day to day job? What makes him tick? How did he become involved in the retro scene? What is his favourite colour? That sort of thing.

 

I think we'd all be interested.

 

Sent from my SM-G930F using Tapatalk

 

Quite happy to answer questions, although I'm not a video chat kinda person yet... ;)

 

Favorite colour. Lol. :)

  • Like 1

Share this post


Link to post
Share on other sites

Good job!

 

I see the boot/logo code is run when you launch a game, is there a particular reason for that?

I don't think it's actually needed since the Skunkboard doesn't do it and games still run fine, and it slows down the process of launching a game.

But maybe you're actually rebooting the Jaguar?

 

Have you written all the code from scratch, or based it on the existing examples? The Jag hardware is pretty finicky, so if it's the former, you may have missed a small thing somewhere.

 

For the boot, I expect it's quite possible to just jump to the beginning of the cart code, however I know from previous experience that if the hardware isn't in exactly the same state as when booted it can cause problems for some games (I know this from the Lynx!). I'll add the option to fast boot though and see how it goes, but at the moment it's actually toggling the hardware reset line so I know it's going to boot as expected.

 

All code is written from scratch, and largely in C, but is based on examples. I also do weird things like depack and run a second executable from the cart and re-initialise everything for a second time. This seemed to cause issues as well before I shut down the video briefly while in setup. Its now solid. So, yes, the Jaguar is a bit picky, but I *think* I've tracked down all the weirdness now.

  • Like 8

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