Jump to content
shaggyneo

Red Screen of Death Help

Recommended Posts

I have a Jaguar I am trying to figure out what is causing the red screen of death. The cart slot seems to be fine. I inserted a blank cart PCB and tested the connection to the bottom of the motherboard and everything has continuity. All of the caps seem fine and I tried a new bios chip. Every game I try goes to a red screen except my skunkboard. The skunk works perfectly with any game I flash to it. I'm out of ideas. Does anyone have any experience with anything else causing the red screen? Thanks in advance for your time.

Share this post


Link to post
Share on other sites
10 minutes ago, shaggyneo said:

I have a Jaguar I am trying to figure out what is causing the red screen of death. The cart slot seems to be fine. I inserted a blank cart PCB and tested the connection to the bottom of the motherboard and everything has continuity. All of the caps seem fine and I tried a new bios chip. Every game I try goes to a red screen except my skunkboard. The skunk works perfectly with any game I flash to it. I'm out of ideas. Does anyone have any experience with anything else causing the red screen? Thanks in advance for your time.

When testing continuity did you just test the pin on the bottom or the board to your card. Or did you follow the trace to their next path? If not I would advice doing that. Also what Skunkboard are you using, A few runs by a  3rd party manufactured ones had a thicker pcb with out beveled edges which over time would bend the cart connectors outwards. 

  • Like 1

Share this post


Link to post
Share on other sites

Every time I've had a red screen of death on either of my Jags, it went away after giving the cartridge pins a through cleaning.

Sorry, if that is not working but your Skunkboard is, I don't know what it would be.

Share this post


Link to post
Share on other sites

Check the motherboard carefully for damaged traces.

 

If all continuity checks pass, one possibility is that one (or several) of the bus buffer chips (U12, U14, U17, U19, U22, U26, U30, U31) is defective.

Share this post


Link to post
Share on other sites

I really appreciate all of the help. Upon closer inspection I did find some corrosion on a couple of the pins on u17 and u30. After using some ipa and a soft toothbrush to clean it up a bit I am now getting just a black screen. It seems like it is being held in reset. My friend got this unit traded into his shop and he asked me to look at it for him. It is getting beyond what I am want to dive into as a favor so I am just going to give it back. It was known as red screen when he took it in so it was a gamble to start with. Again I really appreciate all of the help.

Share this post


Link to post
Share on other sites
On 2/27/2021 at 5:23 AM, shaggyneo said:

Every game I try goes to a red screen except my skunkboard. The skunk works perfectly with any game I flash to it. I'm out of ideas.

The fact that games flashed to the Skunkboard play correctly suggests that all the Jags processors and circuits are essentially working correctly.

There are others here who may have a better understanding of such things than me but I believe the Skunkboard somehow bypasses the Jaguar BIOS, which is why it goes straight to a green screen instead of displaying the Jaguar boot screen. 

Whether that is correct or not the fact that the Skunkboard works when game cartridges do not suggests the reason for the RSOD is probably connected to difference between the way the Jaguar boots with a Skunkboard inserted compared to how it boots when a game cartridge is inserted. For example if the Skunkboard bypasses the cartridge checksum and any cartridge checksum value stored in the BIOS chip and has become corrupted that would result in a checksum fail that could be causing the RSOD.

 

Is it just ROM images that are flashed to RAM that run on the Skunkboard or do those stored on the Skunkboard (run by pressing up/down to select the appropriate memory bank) also run?    

18 hours ago, shaggyneo said:

It seems like it is being held in reset.

I cannot be certain but would think that unlikely, if it was being held in reset then none of the processors should be operating and so I would expect it to do nothing at all, no RSOD or Skunkboard operation.

On 2/27/2021 at 10:17 AM, Zerosquare said:

If all continuity checks pass, one possibility is that one (or several) of the bus buffer chips (U12, U14, U17, U19, U22, U26, U30, U31) is defective.

If that were the case would it not also affect ROM images running on the Skunkboard?

  • Like 1

Share this post


Link to post
Share on other sites

The Skunkboard is 16-bit wide, normal carts are 32-bit wide. A fault in the buffering for the upper data bits could explain the symptoms.

Share this post


Link to post
Share on other sites

Damaged traces can be repaired most likely.

 

Please make sure this unit doesn't wind up in the trash. Someone on here will give it a new home/repair if the shop owner doesn't want to deal with it. 

Share this post


Link to post
Share on other sites

And for the record, Skunkboards do no exactly bypass the BIOS. It's still the BIOS that kicks off the process. The universal verification header it uses just exploits the cartridge checksum security mechanism as it is being "decrypted" by the BIOS, making the boot process go a lot faster because it doesn't have to load the entire contents of the cartridge.

 

Regardless, money on @Zerosquare
hypothesis.

Share this post


Link to post
Share on other sites

Necro again, sorry about that. :)

 

Quote

The universal verification header it uses just exploits the cartridge checksum security mechanism as it is being "decrypted" by the BIOS, making the boot process go a lot faster because it doesn't have to load the entire contents of the cartridge.

Sort of. There's no exploit going on, but it is taking advantage of the way the system works.

 

The Jaguar boots a cartridge by decrypting 10 blocks of heavily encrypted code into the GPU, and executing it. That GPU code then checksums the cartridge, and writes an unlock code and exits. When the BIOS sees the unlock code, it starts the cartridge.

 

Most people use the "universal AB" header on their ROMs, which still goes through all those motions but ignores the resulting checksum.

 

Skunkboard's encrypted boot is custom. It turns out the number of blocks to be decrypted is part of the header, so Skunkboard has a minimal boot that only needs to decrypt 2 blocks, which actually saves most of the time. It then just immediately writes the unlock code and returns to the BIOS, which then boots the ROM. There's a simple flag in the ROM header for bypassing the Jaguar animation.

 

I revisited all that a few years ago and wrote a new universal boot that does it in 2 blocks, still checksums the cart, and puts the checksum in unencrypted space so it can be modified with a hex editor, giving a fast boot (and that version doesn't set the flag, so you still get the boot animation, without most of the 5 second delay).

Here's my writeup, link to github at the bottom: https://tursilion.blogspot.com/2016/09/atari-jaguar-programming-causes-brain.html

 

  • Like 2

Share this post


Link to post
Share on other sites

That was a good read. Apologies if what I said was inaccurate. I haven't even tried to mess with that part of the code. I was basing my comments off of what I assumed was your older write-up of a fast Jaguar boot process in FULL_RELEASE/z_misc/Notes_width_boot.txt, but looks like it may have actually originally come from someone else and it's not really clear that it's even what the Skunk ultimately ended up doing, re-reading it now. Heavily abridged, this is what led me to refer to it as an exploit:

 

Quote

 

The  second trick involves hacking the encryption...

 

...I  got to this point  and then realized the whole thing is absurdly weak. If I can make the GPU crash, I can probably make it crash in a way that benefits me...

 

...So I outfitted my 68K harness with the ability to check for the needed bit pattern in GPU RAM, and let it run overnight. In the
morning I had a 66-byte chunk that contained the right jump instruction followed by a whole bunch of random garbage. And now I can boot my Jaguar in half a second.

 

 

All the text files in this archive were great reads. I had to read through everything several times before I felt comfortable enough with my understanding to expend actual effort and money trying to build one of these (Thanks for the time, COVID). In particular though, theory of operation.txt has a bunch of notes on cool, unfinished ideas. One that stands out:

 

Quote

The software layer was intended to boot off of USB stick and present a menu of available games, demos, and so on.

 

Who'd be crazy enough to try that, and what's the point? I thought this thing's primary purpose was development, @Tursi ;-)

Share this post


Link to post
Share on other sites

Yeah, that was KSkunk's description, long before we worked on producing it. It was that level of crazy that made me want to make sure everyone could have a Skunkboard. ;)

 

USB stick is still useful for development. It just never made it to the top of the priority stack. That said, the development focus was my call, because I didn't want to spend all my time reverse-engineering commercial games that didn't work for one reason or another. It turned out that very little didn't "just work". ;)

 

 

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.
Note: Your post will require moderator approval before it will be visible.

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   0 members

    No registered users viewing this page.

×
×
  • Create New...