Well, with Metal Slug, the graphics take up the first 16MB of RAM, then come 2MB of 68000 program, then 8MB of ADPCM, then FIX, Z80 and BIOS. Some issue with accessing the first half of RAM would seem semi-plausible, but pik said he tried another game, so I guess that isn't it. (unless he chose one of the other 16MB CROM games)
@pik33 What is the power source for your P2-Edge breakout board ? Also, are you using the 64019 mini breakout as I used ?
This is a mini breakout board bought with a Edge rev. A. The power supply is "RPi type" PSU, with a "barrel" connector attached to fit the breakout board input, 5.1V, 3.1A. (I use several of them) The voltage measured on the breakout board is now 5.02 V (with a prop2play running and a RPi interface attached to the board - i tried the neoyume without this, only HDMI and AV connected).
Time for crazy things, like trying a different monitor or hdmi cable ! Or thinking about other sources of interference in the neighbourhood!
I have 2 places to play with P2s, home and the university, 20 km distance 4 different monitors and cables, 2 set of PSU, also the picture is garbled the same way with HDMI and VGA
The most strange thing is the player works. Even with a fullHD driver. This is 1920x1080, more than half of the PSRAM bandwidth used, then there is also a scrolling panels and the audio driver that also use PSRAM. The audio is loaded at the low part, from 0 on near 0, then, in the $700000 region there are scrollers, and there is 2 MB framebuffer at the top and all of this works at 336 MHz using up to 7 cogs. Maybe I have to test the 8th one?
So even if the order of the 4 pins per chip stays the same, but just change which group of 4 pins goes to each ram chip- that's still hardwired beyond reason is it ?
I experimented with several things.
Change cog initialization order=no result
Mess with the sprite reading from PSRAM: either nothing changed or several parts of picture disappear
Lowering the clock: if too much, it stops working at all, if not too much (22 instead of 24 MHz)=no change
No ideas.
I can only do the heavy testing of PSRAM running my video demo with the framebuffer here and there. It is 2 MB long at full HD.
@pik33 said:
I experimented with several things.
Change cog initialization order=no result
Mess with the sprite reading from PSRAM: either nothing changed or several parts of picture disappear
Lowering the clock: if too much, it stops working at all, if not too much (22 instead of 24 MHz)=no change
No ideas.
I can only do the heavy testing of PSRAM running my video demo with the framebuffer here and there. It is 2 MB long at full HD.
Among all the tests you've conducted, is there at least one able to verify and confirm Psram's self-refresh proper operation?
If it was a refresh issue it'd just slowly get corrupted.
I feel like I need to say it again: The audio and 68000 program also come from PSRAM and they work just fine. It certainly isn't a general PSRAM issue.
MegaYume clock freq depends on video mode and goes between 322 and 328. NeoYume runs at 338 MHz. But as I just said, the fact that only the sprite graphics go bad means that nothing is failing catastophically.
Can't remember, but have we tried the ROM readback thing yet? That is, when the ROM sprite data gets copied into PSRAM at game init time, we read it back from PSRAM then to compare what was just written and that it matches the expected data. This would be done before the game runs and does all the shared reads by 68k and audio.
@rogloh said:
Can't remember, but have we tried the ROM readback thing yet? That is, when the ROM sprite data gets copied into PSRAM at game init time, we read it back from PSRAM then to compare what was just written and that it matches the expected data. This would be done before the game runs and does all the shared reads by 68k and audio.
No, I don't think we have. Might whip up some code to that extent tomorrow, though I don't think that's it (from previous testing I think we ruled out the "bad data in CROM" explanation. The corrupted graphics aren't static.)
Another thing I thought of regarding this problem is if the sprite ROM data file either stored on or read from the SD card was somehow corrupted it could point sprites to random data (eg. somehow corrupted FAT/directory entry). A test of data loaded and read back from PSRAM would then match okay with a simple compare, yet the actual source data on the SD was read wrong.
It would be worth loading the files onto another uSD or even a fresh SD card to rule that one out. Simple test.
The other way things could be corrupted might be when the files are read if the SPI link is unreliable for pik33's particular uSD card, although you'd think that should hit the other ROMs too, unless there is something related to the ROM file read order in the loader code that always affects the sprite ROM sector reads perhaps...?
The CROM load is indeed quite different from everything else, in that it needs to interleave data from two files. However as said, the artifacts in pik's video just don't look like that.
Still worth looking into IMO.
The shimmering effect in the video pik33 posted is potentially just sprite animation not really noisy data as such. The part right at the start looks a lot more static to me.
It would be worth loading the files onto another uSD or even a fresh SD card to rule that one out. Simple test.
This was already done. I got the image of the card from VonSzarvas - and put it on another SD, The image has also the self-start game other than Metal Slug and I even don't know what it is. The binary was prepared to start from SD and display on HDMI.
The result was exactly the same except colors of the mess.
I want to do the test like this: instead of getting sprite data from PSRAM, feed these longs with some static data like $55AAFF00 or something like this.
It would be worth loading the files onto another uSD or even a fresh SD card to rule that one out. Simple test.
This was already done. I got the image of the card from VonSzarvas - and put it on another SD, The image has also the self-start game other than Metal Slug and I even don't know what it is. The binary was prepared to start from SD and display on HDMI.
The result was exactly the same except colors of the mess.
I want to do the test like this: instead of getting sprite data from PSRAM, feed these longs with some static data like $55AAFF00 or something like this.
Might have been two boot files on that SD image, .BIX and .BIY
If you rename the BIX then then other game would run. Don't ask which was what
Comments
Power supply is always a contender... hopefully multiple have been tried.
Well, with Metal Slug, the graphics take up the first 16MB of RAM, then come 2MB of 68000 program, then 8MB of ADPCM, then FIX, Z80 and BIOS. Some issue with accessing the first half of RAM would seem semi-plausible, but pik said he tried another game, so I guess that isn't it. (unless he chose one of the other 16MB CROM games)
The crazyness spreads!
Have a jar of pickled corn.
Agreed. A stable source, and with enough "oomph" to source a couple amps without significant voltage sag (and certainly not below ~4.5V)
Yum Yum
Essen Sie das mit honig? Warum?
Neee, der Honig ist da schon drin, steht ja auf dem Etikett.
Nein, aber es enthält Bienenhonig und Brantweinnessig, und etwas Speisesalz
This is a mini breakout board bought with a Edge rev. A. The power supply is "RPi type" PSU, with a "barrel" connector attached to fit the breakout board input, 5.1V, 3.1A. (I use several of them) The voltage measured on the breakout board is now 5.02 V (with a prop2play running and a RPi interface attached to the board - i tried the neoyume without this, only HDMI and AV connected).
I have 2 places to play with P2s, home and the university, 20 km distance
4 different monitors and cables, 2 set of PSU, also the picture is garbled the same way with HDMI and VGA
I wonder... is it possible to change the code pin assignments for the psram; perhaps invert the order of the physical ram chips ?
The most strange thing is the player works. Even with a fullHD driver. This is 1920x1080, more than half of the PSRAM bandwidth used, then there is also a scrolling panels and the audio driver that also use PSRAM. The audio is loaded at the low part, from 0 on near 0, then, in the $700000 region there are scrollers, and there is 2 MB framebuffer at the top and all of this works at 336 MHz using up to 7 cogs. Maybe I have to test the 8th one?
No, the pins-to-FIFO connection is kinda hardwired to be in order.
Unrelatedly, I love that this is the funni haha thread now.
So even if the order of the 4 pins per chip stays the same, but just change which group of 4 pins goes to each ram chip- that's still hardwired beyond reason is it ?
Now we have:
1)
SIO0 - p52
SIO1 - p53
SIO2 - p54
SIO3 - p55
2)
SIO0 - p48
SIO1 - p49
SIO2 - p50
SIO3 - p51
3)
SIO0 - p44
SIO1 - p45
SIO2 - p46
SIO3 - p47
4)
SIO0 - p40
SIO1 - p41
SIO2 - p42
SIO3 - p43
Change it to:
4)
SIO0 - p52
SIO1 - p53
SIO2 - p54
SIO3 - p55
3)
SIO0 - p48
SIO1 - p49
SIO2 - p50
SIO3 - p51
2)
SIO0 - p44
SIO1 - p45
SIO2 - p46
SIO3 - p47
1)
SIO0 - p40
SIO1 - p41
SIO2 - p42
SIO3 - p43
No, its always a contiguous grup of 16 pins - shouldn't you know this?
hmm, maybe. But it's just a driver thing really. I never accept never !
Eitherhow, if there was an issue with just one chip, you'd be able to see that (because the graphics are nibbles), this aint it.
Unrelatedly, the flexsplorp evolved from broken
strcasecmpto not building at all. cool.I experimented with several things.
Change cog initialization order=no result
Mess with the sprite reading from PSRAM: either nothing changed or several parts of picture disappear
Lowering the clock: if too much, it stops working at all, if not too much (22 instead of 24 MHz)=no change
No ideas.
I can only do the heavy testing of PSRAM running my video demo with the framebuffer here and there. It is 2 MB long at full HD.
Well, it seems the splorpening is over, but keep your eyes open.
Among all the tests you've conducted, is there at least one able to verify and confirm Psram's self-refresh proper operation?
If it was a refresh issue it'd just slowly get corrupted.
I feel like I need to say it again: The audio and 68000 program also come from PSRAM and they work just fine. It certainly isn't a general PSRAM issue.
Wonder if the P2 freq is too high for @pik33 ... Do Megayume and Neoyume work at same P2 clock? It's over 300 MHz, right?
@pik33 Did you already try Megayume?
MegaYume clock freq depends on video mode and goes between 322 and 328. NeoYume runs at 338 MHz. But as I just said, the fact that only the sprite graphics go bad means that nothing is failing catastophically.
Can't remember, but have we tried the ROM readback thing yet? That is, when the ROM sprite data gets copied into PSRAM at game init time, we read it back from PSRAM then to compare what was just written and that it matches the expected data. This would be done before the game runs and does all the shared reads by 68k and audio.
No, I don't think we have. Might whip up some code to that extent tomorrow, though I don't think that's it (from previous testing I think we ruled out the "bad data in CROM" explanation. The corrupted graphics aren't static.)
We could still be looking in the wrong place...
Another thing I thought of regarding this problem is if the sprite ROM data file either stored on or read from the SD card was somehow corrupted it could point sprites to random data (eg. somehow corrupted FAT/directory entry). A test of data loaded and read back from PSRAM would then match okay with a simple compare, yet the actual source data on the SD was read wrong.
It would be worth loading the files onto another uSD or even a fresh SD card to rule that one out. Simple test.
The other way things could be corrupted might be when the files are read if the SPI link is unreliable for pik33's particular uSD card, although you'd think that should hit the other ROMs too, unless there is something related to the ROM file read order in the loader code that always affects the sprite ROM sector reads perhaps...?
The CROM load is indeed quite different from everything else, in that it needs to interleave data from two files. However as said, the artifacts in pik's video just don't look like that.
Still worth looking into IMO.
The shimmering effect in the video pik33 posted is potentially just sprite animation not really noisy data as such. The part right at the start looks a lot more static to me.
This was already done. I got the image of the card from VonSzarvas - and put it on another SD, The image has also the self-start game other than Metal Slug and I even don't know what it is. The binary was prepared to start from SD and display on HDMI.
The result was exactly the same except colors of the mess.
I want to do the test like this: instead of getting sprite data from PSRAM, feed these longs with some static data like $55AAFF00 or something like this.
Well that image posted by Weurfel_21 last night really sums things up.. this is one sweet pickle we are in. I'm out of ideas now.
Might have been two boot files on that SD image, .BIX and .BIY
If you rename the BIX then then other game would run. Don't ask which was what