Hopefully it's not all that high frequency/temperature testing Pik33 did has somehow ruined part of the memory/board. But that would surely affect the 68k accesses too.
You get it now? Any obvious idea would also mess up program and sound (esp. sound, its code is very similar to the graphics. Maybe take a look at it. )
First question: Why are you driving the PSRAM_SELECT pin in reverse...? Probably unrelated, but just strange.
Wait: are these PSRAM access snippets running from the same COG or different COGs?
Okay same COG by the look of it. The reversed Chip select confused me there, I thought there was some pin bitwise OR going on.
I wonder if the P2 clock frequency is setup correctly for pik33? If the P2 was running slow and somehow not keeping up with sprites per scan line and got out of sync with the line counter due to taking too long to do the memory transfer, could the system still work but just show corrupted sprite data?
EDIT:
No, I guess VGA timing should be off then too.
I've got a revB, err: revA sorry, EC32MB but I stupidly didn't buy a carrier to go with it.
For some odd reason I thought I'd be using it on my own designs in short order. But in reality, it's still good to have a known fall-back for testing on when doing even custom carrier boards.
@rogloh said:
I wonder if the P2 clock frequency is setup correctly for pik33? If the P2 was running slow and somehow not keeping up with sprites per scan line and got out of sync with the line counter due to taking too long to do the memory transfer, could the system still work but just show corrupted sprite data?
EDIT:
No, I guess VGA timing should be off then too.
If it couldn't keep up it'd just show the struped blocks, theyre written with the attribute data by LSPC
So if it works fine for you and not for pik33 there are really only two possibilities here.
1) HW differences:
- maybe Pik33's board's RAM at the addresses used differ somehow. From my recollection this was also a new test board rev, correct? The board that VonSzarvas sent him. Different PSRAM chip batches used perhaps.
2) SW build differences:
Ideally we can have a test build distributed that people can test out by unzipping to an SD without needing to build it themselves or source external files etc. If you PM me something I can potentially also try it once I get home.
Just checked my Edge chips too. I have the same numbers on my PSRAM chips as well, AP33RN and 0240K. So it looks like the PSRAM HW should be consistent at least. I sort of now imagine it will be a build difference somehow or different data files being loaded at different PSRAM addresses at startup. I don't imagine the chips will behave differently in the two setups unless timing is marginal - but that should also affect the 68k accesses as Wuerfel_21 mentioned unless there is an address dependency that happens to hit locations specifically where the sprite data gets loaded into memory. We really need to get both of you to run the same binary to rule out build problems. And make sure the code is started in the same way, ie. booting up from SD card not from loadp2 or flash etc in case that was different. Also make sure those DIP switches are set the same and you use the same IO pins for VGA etc.
Another possibility to help pinpoint the issue would be to introduce a special diagnostic check at application startup to read back whatever gets written into PSRAM to confirm it really wrote the correct data at the correct address. It should behave the same in both your systems if things are working correctly. This could show whether this is indeed a write address problem happening at game init time, rather than an actual corrupted read issue.
@pik33 Another thing you could do is to write a test program that fills your PSRAM memory with some test patterns and reads it back to make sure of no corruption in your PSRAM over its full address space. You should be able to use my driver wrapper to do the raw write and read operations, you just need to create a loop and fill with some random number generated sequence, and a read back to compare the data against the expected value. Run it at the same P2 frequency as the game uses. I know you've already run this PSRAM with your own video code, but perhaps the chip's data bytes are only being partially corrupted in some as yet untested portion of the 32MB.
Huh, just gave psram_delay_test.spin2 a whirl with my EC32MB and it has returned unexpected auto-delays. Note how auto-delay 12 is decided on too early, as is 13.
Yeah the timing default was not optimized for the P2EDGE-32MB when it was released, as I was testing with my own board back then and all setups will differ. Interestingly this looks like it transitions right around 338MHz too, where NeoYUME is running. LOL. It's worth patching it back to either 11 or 12 to see if it helps.
Oh, so those are hard-coded ranges then. Suited to Eval Board with add-on. I was imagining it more sophisticated where it did a timing test on driver init or similar.
@evanh said:
Oh, so those are hard-coded ranges then. Suited to Eval Board with add-on. I was imagining it more sophisticated where it did a timing test on driver init or similar.
That would be a good long term approach, as would be adaptively adjusting for temp variation etc, neither of which is in the driver. Right now the easiest fix would be to collect a group of P2-EDGE boards delay runs and average them somehow as the default delay to use. Most people with PSRAM early on will be people running EDGEs now I suspect.
BTW Ada is not actually using my defaults. She uses her own delay, defined differently. Looks like it was being set to (4+1)<<2 + 1 (or 11 in my own number format). So this setting is probably okay.
So I decreased the clock frequency in the video driver from 14x to 13x - no change. Also I messed with several PSRAM timings settings here and there. The result is either no change or nothing (when PSRAM timing are too off). All of this is very strange.
The only possible code difference in the lower code is the audio pins. Can you try leaving them on 30/31? Not that I think it makes a difference, but as said, stir-crazy.
Comments
Hopefully it's not all that high frequency/temperature testing Pik33 did has somehow ruined part of the memory/board. But that would surely affect the 68k accesses too.
You get it now? Any obvious idea would also mess up program and sound (esp. sound, its code is very similar to the graphics. Maybe take a look at it. )
I'm going stir-crazy ~
First question: Why are you driving the PSRAM_SELECT pin in reverse...? Probably unrelated, but just strange.
Wait: are these PSRAM access snippets running from the same COG or different COGs?
Okay same COG by the look of it. The reversed Chip select confused me there, I thought there was some pin bitwise OR going on.
Ye, CS is set to inverted, carryover from megayume, where it does indeed need to wire-or it. Not really needed here, but whatever.
I wonder if the P2 clock frequency is setup correctly for pik33? If the P2 was running slow and somehow not keeping up with sprites per scan line and got out of sync with the line counter due to taking too long to do the memory transfer, could the system still work but just show corrupted sprite data?
EDIT:
No, I guess VGA timing should be off then too.
I've got a revB, err: revA sorry, EC32MB but I stupidly didn't buy a carrier to go with it.
For some odd reason I thought I'd be using it on my own designs in short order. But in reality, it's still good to have a known fall-back for testing on when doing even custom carrier boards.
If it couldn't keep up it'd just show the struped blocks, theyre written with the attribute data by LSPC
So if it works fine for you and not for pik33 there are really only two possibilities here.
1) HW differences:
- maybe Pik33's board's RAM at the addresses used differ somehow. From my recollection this was also a new test board rev, correct? The board that VonSzarvas sent him. Different PSRAM chip batches used perhaps.
2) SW build differences:
Ideally we can have a test build distributed that people can test out by unzipping to an SD without needing to build it themselves or source external files etc. If you PM me something I can potentially also try it once I get home.
Hmm, the carrier boards really need an additional regulator just for supplying 5 Volts to the accessory add-on boards.
It seems PSRAMs are the same.
Just checked my Edge chips too. I have the same numbers on my PSRAM chips as well, AP33RN and 0240K. So it looks like the PSRAM HW should be consistent at least. I sort of now imagine it will be a build difference somehow or different data files being loaded at different PSRAM addresses at startup. I don't imagine the chips will behave differently in the two setups unless timing is marginal - but that should also affect the 68k accesses as Wuerfel_21 mentioned unless there is an address dependency that happens to hit locations specifically where the sprite data gets loaded into memory. We really need to get both of you to run the same binary to rule out build problems. And make sure the code is started in the same way, ie. booting up from SD card not from loadp2 or flash etc in case that was different. Also make sure those DIP switches are set the same and you use the same IO pins for VGA etc.
Another possibility to help pinpoint the issue would be to introduce a special diagnostic check at application startup to read back whatever gets written into PSRAM to confirm it really wrote the correct data at the correct address. It should behave the same in both your systems if things are working correctly. This could show whether this is indeed a write address problem happening at game init time, rather than an actual corrupted read issue.
@pik33 Another thing you could do is to write a test program that fills your PSRAM memory with some test patterns and reads it back to make sure of no corruption in your PSRAM over its full address space. You should be able to use my driver wrapper to do the raw write and read operations, you just need to create a loop and fill with some random number generated sequence, and a read back to compare the data against the expected value. Run it at the same P2 frequency as the game uses. I know you've already run this PSRAM with your own video code, but perhaps the chip's data bytes are only being partially corrupted in some as yet untested portion of the 32MB.
Your
psram_delay_test.spin2does that, Roger.I don't think it exercises all of memory. It's not exhaustive IIRC.
What is the clock speed in neoyume? I am now testing PSRAM at 336 MHz (random writes in 256 bytes block, read, compare)
337.4MHz I think in the code EDIT: oops, the comment says otherwise. Maybe defined elsewhere.
337- ish, yeah. The precise clock calculation is in NeoVGA.spin2
Huh, just gave
psram_delay_test.spin2a whirl with my EC32MB and it has returned unexpected auto-delays. Note how auto-delay 12 is decided on too early, as is 13.And guess what? 337 MHz is right in the bad auto-delay of 13.
Yeah the timing default was not optimized for the P2EDGE-32MB when it was released, as I was testing with my own board back then and all setups will differ. Interestingly this looks like it transitions right around 338MHz too, where NeoYUME is running. LOL. It's worth patching it back to either 11 or 12 to see if it helps.
Oh, so those are hard-coded ranges then. Suited to Eval Board with add-on. I was imagining it more sophisticated where it did a timing test on driver init or similar.
That would be a good long term approach, as would be adaptively adjusting for temp variation etc, neither of which is in the driver. Right now the easiest fix would be to collect a group of P2-EDGE boards delay runs and average them somehow as the default delay to use. Most people with PSRAM early on will be people running EDGEs now I suspect.
It is still testing with no errors detected yet. The clock is 336956522, the delay is set to 12 via startx. 11 and 12 works here, 13 is not good.
BTW Ada is not actually using my defaults. She uses her own delay, defined differently. Looks like it was being set to (4+1)<<2 + 1 (or 11 in my own number format). So this setting is probably okay.
Testing again, delay=11, clock=338_666_667
... tested, OK (except the last MB, but I have a framebuffer there so it is always testing)
)
Actually, the precise value it comes out to is 24_167_829 * 14 = 338_349_606
So I decreased the clock frequency in the video driver from 14x to 13x - no change. Also I messed with several PSRAM timings settings here and there. The result is either no change or nothing (when PSRAM timing are too off). All of this is very strange.
Yes, I know, it's so strange.
The only possible code difference in the lower code is the audio pins. Can you try leaving them on 30/31? Not that I think it makes a difference, but as said, stir-crazy.
@Wuerfel_21 This is looking great.
Was about to test again but I see hyperram support was dropped.
Out of curiosity, why was that?
Just to keep it simple?
Is there an important difference in size or speed?