DSTB1 exxos first tests & experimental firmware.

[exxos]

Try removing the altram_ext term from the .ACCESS() line again, and I bet the problem goes away.

Tried multiple things , not having much luck. It's "stabbing in the dark" type diagnostics :roll:

I just tried EMUTOS but did not make any difference with the experimental firmware.

[ijor]

There are, however, a LOT of terms in the equations governing the SDRAM. I honestly just think this is one too many. The line probably isn't stable in time and the state machine gets out of whack. For you, it's FB that shits out, for me it's MiNT.

Sorry to insist with this, but have you performed timing analysis?

[exxos]

@Badwolf EMUTOS makes no odds it seems

Oddly..

Code: Select all

wire SLOW = (~altram_access_int ) ;

Removing the other terms causes problems to get worse. So IMO there is some odd timing issues going on somewhere between clock switching and accessing SDRAM.

[Badwolf]

Sorry to insist with this, but have you performed timing analysis?

No.

BW

[Badwolf]

Try removing the altram_ext term from the .ACCESS() line again, and I bet the problem goes away.

Tried multiple things , not having much luck. It's "stabbing in the dark" type diagnostics :roll:

I just tried EMUTOS but did not make any difference with the experimental firmware.

EmuTOS might help your stock firmware test (because of my FRB driver mistake), but I doubt it will make any difference to your homebrew firmware if the timing has been taken out of whack.

BW

[exxos]

EmuTOS might help your stock firmware test (because of my FRB driver mistake), but I doubt it will make any difference to your homebrew firmware if the timing has been taken out of whack.

I've tried just about every combination of everything already. Nothing really makes any odds. I just use my hacked firmware as it didn't have floppy issues.

Bottom line is basically when anything uses alt-ram it goes nuts. With the exception that sometimes I can run YAARTTT and it passes RAM fine. Oh and I can run GB6 fine. But I guess there isn't much "load" on alt-ram in GB6 anyway as its mostly going to hammer ST-RAM and ROM. I guess if I left GB6 running for long enough it would ultimately crash as well.

[ijor]

Removing the other terms causes problems to get worse. So IMO there is some odd timing issues going on somewhere between clock switching and accessing SDRAM.

If there are timing issues, as you both suspect, then results might always be unpredictable and very difficult to diagnose. You have to constrain the design properly and perform a full timing analysis. Otherwise you are IMHO shooting in the dark.

[Badwolf]

Removing the other terms causes problems to get worse. So IMO there is some odd timing issues going on somewhere between clock switching and accessing SDRAM.

If there are timing issues, as you both suspect, then results might always be unpredictable and very difficult to diagnose. You have to constrain the design properly and perform a full timing analysis. Otherwise you are IMHO shooting in the dark.

Just to go back to this as I didn't have time yesterday.

You're quite correct Ijor and I have (not for this project, but for DFB1) tried to set up timing requirements and a timing report is always available.

However there are a number of problems.


1) I don't know how to correctly set up timing requirements.

This is a bit of a biggie. Any requirement I can figure out how to set up never passes anyway


2) I don't know how to correctly interpret the timing report.

OK, I can read the delay from AS to AS_INT (say), but what are the key signals on the third state of nine of the DRAM controller? No idea.



3) Even if I could do both 1 and 2, I wouldn't know what to do about it afterwards.


So my approach has been to reduce complexity as much as possible, set everything to speed mode and measure the results. If it appears to work, test it extensively. If it doesn't, attempt mitigation and go again.

My theory is this is open source. It only needs to be good enough to work and then somebody who *does* know what they're doing can improve it later. Hence why this shipped with blitter not permitted to access altram. I don't think it could meet the timing requirement, but it wasn't a show-stopper and someone else may be able to.

What I hadn't quite understood from Exxos' posts (he works on it during the day, I try to follow it and act on it in a couple of hours at night -- we sometimes get out of sync) was that the stock firmware was not working reliably for him. I thought all these problems were caused by trying to get blitter to work so my answers have all revolved around the timing issue I picked up with that.

It's possible (more than likely now I see issues with stock too) that there are differences between the H5 and STE that need to be accommodated too.

BW

[exxos]

Just sent similar info to @Badwolf Just.

I want to clarify there has been a bit of a "oops" with all this. As BW sent me the booster I tried GB6 and YAART and seemed fine. The RAM corruption I was seeing right at the beginning was down to the CPU I was using. I changed to a different one and those problems went away. So basically ignore that issue.

I later added in 206 decoding, then fast decoding, then got the blitter working. GB6 and YAARTT all passed fine. So as a final test I ran FrontBench to post the frame count score.. And it crashed...

I then spent a lot of time going around in circles digressing all the changes I did trying to figure out what I broke. But going back to BW's original firmware just, frontbench does not run with that firmware either. So the changes I did do not related to frontbench crashing.

The bottom line is that there is something amiss with the original firmware which seems to have problems with the alt-RAM, which needs investigating. It is not something I can do because I'm not very familiar with SDRAM or Verilog. Obviously it was a bit of a red herring that YAARTTT passed all the RAM so I assumed that RAM access was all working fine :? .

[ijor]

My theory is this is open source. It only needs to be good enough to work and then somebody who *does* know what they're doing can improve it later.

That sounds a very reasonable approach indeed. I'm not an expert on this Xilinx’s CPLD family, but I'll try a timing analysis later.

So my approach has been to reduce complexity as much as possible, set everything to speed mode and measure the results. If it appears to work, test it extensively. If it doesn't, attempt mitigation and go again.

What I hadn't quite understood from Exxos' posts (he works on it during the day, I try to follow it and act on it in a couple of hours at night -- we sometimes get out of sync) was that the stock firmware was not working reliably for him.

No idea if this the case here, but it might be very well a timing problem. When you test it and it works, it just mean it works on your own setup on specific conditions. But conditions might be different for others. This includes of course differences in voltage and temperature. But also each chip has a different performance. Let alone if somebody decides to use a compatible SDRAM chip from a different manufacturer.

That's the purpose of timing analysis. It considers the worst (and the best) conditions. That could be the difference between "guaranteed to work" and 'it works for me".

It's possible (more than likely now I see issues with stock too) that there are differences between the H5 and STE that need to be accommodated too.

Off the top of my head between ST and STE, not sure if it affects your case, but are you aware about the different DTACK behavior when accessing the PSG? I remember this affected an Exxos accelerator, but I think it was a much faster one?