@Wuerfel_21 said:
Ok, issue debugged, Eric splorped the codegen and that causes strcasecmp to never return a match. (The files actually enumerate just fine)
You can work around this by just overriding the file chooser step by enabling DIRECT_BOOT instead in config.spin2.
E.g. you can probably setup this #define DIRECT_BOOT game_mslug
3 versions including current board appear ok for the start screen.
Button board not working yet, to Start the game, but I'll go back to look at the config again.
.
Now, what can I have done wrong with the compilation? Can you attach a working binary and neo-epo to test?
The board seems to work with all I run on it, except this.
Is the current github Flexprop good or is it still splorped? (splorpen? splurp?)
So the question is, where was it failing for pik33? Maybe there was a config issue - perhaps a couple of video modes enabled on the same pins?
How? And why the "Metal slug" orange logo and "push start" is not garbled?
Attached binary works with this setup. Ignore the click breakout and red cable (well, unless your hdmi device needs the 5V !)
The binary has #define DIRECT_BOOT game_mslug
@pik33 said:
Now, what can I have done wrong with the compilation? Can you attach a binary to test?
The board seems to work with all I run on it, except this.
Yeah, here's one for USB on pin 16, VGA+audio on pin 8. If that's not right, just tell me what you want.
Is the current github Flexprop good or is it still splorped? (splorpen? splurp?)
Yep, the small logo during the demo and all the text is drawn on the FIX layer, whose tileset lives in Hub (though it gets loaded into PSRAM first and is then copied back)
I run this .bix and a fresh downloaded metal slug and neo-epo. The picture is as splorped as it was. Either the board is damaged in a very strange way or the bios/game files are bad. neo-epo.bin is the same as it was, as I found only one source of this.
@pik33 said:
I run this .bix and a fresh downloaded metal slug and neo-epo. The picture is as splorped as it was. Either the board is damaged in a very strange way or the bios/game files are bad. neo-epo.bin is the same as it was, as I found only one source of this.
@Rayman said:
Do you have to boot from uSD with neoyume ?
Think I had megayume booting from flash…
I did boot from uSD from the .BIX file just to save me time when testing multiple modules.
It works when programmed to flash too, and I've also been running it that way until today.
@pik33 said:
I run this .bix and a fresh downloaded metal slug and neo-epo. The picture is as splorped as it was. Either the board is damaged in a very strange way or the bios/game files are bad. neo-epo.bin is the same as it was, as I found only one source of this.
Just sent you a PM
Not good. Symptoms are the same. Several texts are ok, the rest is garbled. But.. if the board is really damaged, how can I run the video driver and player on it? They are also PSRAM heavy. Too tight timings somewhere in the code, or something like this? It seems it displays these sprites, but at wrong place at the screen. As if the offset between lines was bad.
@Rayman said:
Do you have to boot from uSD with neoyume ?
Think I had megayume booting from flash…
Of course it can be loaded from anywhere. How do you think I debug this stuff?
You could even make it use the 9p filesystem, but it'd be extremely slow. (megayume could technically also, but the file browser is only designed to handle 8.3 names)
@VonSzarvas said:
Loosely related... just tried Twinklestar.... almost scary fun times, "fun" tune !!
Twinkle Star, scary? Are we playing the same game? I guess it is scary and very fun if you only have 4 buttons to control it.
Could the regulator on pik33's board be somehow affecting things? Or board noise, xtal oscillator? @VonSzarvas What's the difference on that board pik33 has compared to the REV A myself and presumably also Wuerfel_21 both use?
@pik33 said:
Not good. Symptoms are the same. Several texts are ok, the rest is garbled. But.. if the board is really damaged, how can I run the video driver and player on it? They are also PSRAM heavy. Too tight timings somewhere in the code, or something like this? It seems it displays these sprites, but at wrong place at the screen. As if the offset between lines was bad.
To me it really looks more like its just putting bad data into the sprite pixels. They do appear at the right point on the screen.
@rogloh said:
Could the regulator on pik33's board be somehow affecting things? Or board noise, xtal oscillator? @VonSzarvas What's the difference on that board pik33 has compared to the REV A myself and presumably also Wuerfel_21 both use?
Ah yes, get out the crack pot!
Your edge is a really early one, too, isn't it?
But Von the Edgelord says his RevB works, too, soo uhhhh....
I have to look at the code. Maybe this particular P2 chip is somewhat slower than other and starts to fail at 338 MHz and a heavy load and some bits of computed addresses are bad. A good check can be to allocate the cogs to tasks in a different way.
@pik33 said:
I have to look at the code. Maybe this particular P2 chip is somewhat slower than other and starts to fail at 338 MHz and a heavy load and some bits of computed addresses are bad. A good check can be to allocate the cogs to tasks in a different way.
Quick pointers: the cogs are all started by the upper code, using pointers in zeropage (exception: USB cog is started by the input cog, which then kills itself). Memory arbiter is started last and overtakes cog 0. Yes, I should probably have commented the cog startup better.
@pik33 said:
I have to look at the code. Maybe this particular P2 chip is somewhat slower than other and starts to fail at 338 MHz and a heavy load and some bits of computed addresses are bad. A good check can be to allocate the cogs to tasks in a different way.
Or possibly layout the external memory differently to see if the problem morphs somehow. i.e. swap around the locations of where 68k code and sprite data go.
@pik33 said:
I have to look at the code. Maybe this particular P2 chip is somewhat slower than other and starts to fail at 338 MHz and a heavy load and some bits of computed addresses are bad. A good check can be to allocate the cogs to tasks in a different way.
Or possibly layout the external memory differently to see if the problem morphs somehow. i.e. swap around the locations of where 68k code and sprite data go.
I think relocating the sprite data may not actually work. You could try a different game though. Crossed Swords or Sengoku are relatively small, so I guess try those.
A different game behaves in exactly the same way. I have older Flexprop here and the new one is still not good: maybe I can do some experiments later at home where I have the proper compiler installed.
@rogloh said:
Could the regulator on pik33's board be somehow affecting things? Or board noise, xtal oscillator? @VonSzarvas What's the difference on that board pik33 has compared to the REV A myself and presumably also Wuerfel_21 both use?
pik33 has a full-production brand-new revB.
I've tested another full-production revB (built on the same panel as pik's), and also a revA and one other test version.
@pik33 What is the power source for your P2-Edge breakout board ? Also, are you using the 64019 mini breakout as I used ?
Another thought that maybe I'm late to the party with, but I think Rogloh had some sector-by-sector test code to ensure the PSRAM consistency across various frequencies. So wouldn't that demonstrate the PSRAM on pik's board is healthy ? (I think that's already been tried, right?)
@VonSzarvas said:
Another thought that maybe I'm late to the party with, but I think Rogloh had some sector-by-sector test code to ensure the PSRAM consistency across various frequencies. So wouldn't that demonstrate the PSRAM on pik's board is healthy ? (I think that's already been tried, right?)
Yeah that is the delay test and it has been run by pik33. It doesn't test all of memory however. I believe pik33 has written a separate test that exhaustively tests his memory though and run it at the frequency of the emulator. Although it might not be exercising all other COGs at the same time, so the power load will be different.
Comments
Come for the chips, stay for Ada-chan's questionable humor.
Yeah checks out i guess.
You can work around this by just overriding the file chooser step by enabling DIRECT_BOOT instead in config.spin2.
E.g. you can probably setup this
#define DIRECT_BOOT game_mslugDIRECT_BOOT got it running (thanks!)
3 versions including current board appear ok for the start screen.
Button board not working yet, to Start the game, but I'll go back to look at the config again.
.
Yay!!
So the question is, where was it failing for pik33? Maybe there was a config issue - perhaps a couple of video modes enabled on the same pins?
The Edgelord has spoken!
And now I'm just more confused. Surely it is down to the tropical polish climate.
Now, what can I have done wrong with the compilation? Can you attach a working binary and neo-epo to test?
The board seems to work with all I run on it, except this.
Is the current github Flexprop good or is it still splorped? (splorpen? splurp?)
How? And why the "Metal slug" orange logo and "push start" is not garbled?
still splorped
when I tried this morning.
Attached binary works with this setup. Ignore the click breakout and red cable (well, unless your hdmi device needs the 5V !)
The binary has #define DIRECT_BOOT game_mslug
Yeah, here's one for USB on pin 16, VGA+audio on pin 8. If that's not right, just tell me what you want.
Yep, still ensplorpified.
I think they might come from HUB RAM.
Yep, the small logo during the demo and all the text is drawn on the FIX layer, whose tileset lives in Hub (though it gets loaded into PSRAM first and is then copied back)
Could pik33's ROM files just be somehow corrupted? Were any CRCs/SHA results confirmed on them?
Loosely related... just tried Twinklestar.... almost scary
fun times, "fun" tune !! 
Do you have to boot from uSD with neoyume ?
Think I had megayume booting from flash…
I run this .bix and a fresh downloaded metal slug and neo-epo. The picture is as splorped as it was. Either the board is damaged in a very strange way or the bios/game files are bad. neo-epo.bin is the same as it was, as I found only one source of this.
You don't have to use SD for the code, I was able to use loadp2 to download it serially. The ROMs need to be on the SD card though.
Just sent you a PM
I did boot from uSD from the .BIX file just to save me time when testing multiple modules.
It works when programmed to flash too, and I've also been running it that way until today.
Not good. Symptoms are the same. Several texts are ok, the rest is garbled. But.. if the board is really damaged, how can I run the video driver and player on it? They are also PSRAM heavy. Too tight timings somewhere in the code, or something like this? It seems it displays these sprites, but at wrong place at the screen. As if the offset between lines was bad.
Of course it can be loaded from anywhere. How do you think I debug this stuff?
You could even make it use the 9p filesystem, but it'd be extremely slow. (megayume could technically also, but the file browser is only designed to handle 8.3 names)
Twinkle Star, scary? Are we playing the same game? I guess it is scary and very fun if you only have 4 buttons to control it.
Could the regulator on pik33's board be somehow affecting things? Or board noise, xtal oscillator? @VonSzarvas What's the difference on that board pik33 has compared to the REV A myself and presumably also Wuerfel_21 both use?
To me it really looks more like its just putting bad data into the sprite pixels. They do appear at the right point on the screen.
Ah yes, get out the crack pot!
Your edge is a really early one, too, isn't it?
But Von the Edgelord says his RevB works, too, soo uhhhh....
I have to look at the code. Maybe this particular P2 chip is somewhat slower than other and starts to fail at 338 MHz and a heavy load and some bits of computed addresses are bad. A good check can be to allocate the cogs to tasks in a different way.
Quick pointers: the cogs are all started by the upper code, using pointers in zeropage (exception: USB cog is started by the input cog, which then kills itself). Memory arbiter is started last and overtakes cog 0. Yes, I should probably have commented the cog startup better.
Or possibly layout the external memory differently to see if the problem morphs somehow. i.e. swap around the locations of where 68k code and sprite data go.
I think relocating the sprite data may not actually work. You could try a different game though. Crossed Swords or Sengoku are relatively small, so I guess try those.
A different game behaves in exactly the same way. I have older Flexprop here and the new one is still not good: maybe I can do some experiments later at home where I have the proper compiler installed.
pik33 has a full-production brand-new revB.
I've tested another full-production revB (built on the same panel as pik's), and also a revA and one other test version.
@pik33 What is the power source for your P2-Edge breakout board ? Also, are you using the 64019 mini breakout as I used ?
Another thought that maybe I'm late to the party with, but I think Rogloh had some sector-by-sector test code to ensure the PSRAM consistency across various frequencies. So wouldn't that demonstrate the PSRAM on pik's board is healthy ? (I think that's already been tried, right?)
Yeah that is the delay test and it has been run by pik33. It doesn't test all of memory however. I believe pik33 has written a separate test that exhaustively tests his memory though and run it at the frequency of the emulator. Although it might not be exercising all other COGs at the same time, so the power load will be different.
Hmm. Then I guess I'm even more confused than pickles !
Time for crazy things, like trying a different monitor or hdmi cable ! Or thinking about other sources of interference in the neighbourhood!