Shop OBEX P1 Docs P2 Docs Learn Events
Console Emulation - Page 26 — Parallax Forums

Console Emulation

1232426282958

Comments

  • Power supply is always a contender... hopefully multiple have been tried.

  • Wuerfel_21Wuerfel_21 Posts: 4,671
    edited 2022-06-06 13:35

    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)

    game_mslug byte "mslug",0,"Metal Slug",0,"201-",0,GAME_OK
    byte SET_CHAR
    byte LOAD_CROM,"C1",0,"C2",0,word $80_0
    byte LOAD_CROM,"C3",0,"C4",0,word $80_0
    byte SET_PROG+WITH_OFFSET,word $10_0
    byte SET_PORT
    byte LOAD_BSWAP,"P1",0,word $20_0
    byte SET_ADPCM_A,SET_ADPCM_B
    byte LOAD_RAW,"V1",0,word $40_0
    byte LOAD_RAW,"V2",0,word $40_0
    byte SET_FIX
    byte LOAD_SROM,"S1",0,word $02_0
    byte SET_Z80
    byte LOAD_RAW,"M1",0,word $02_0
    byte SET_BIOS,LOAD_BIOS
    byte 0
    

    @VonSzarvas said:
    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!

    The crazyness spreads!

    Have a jar of pickled corn.

  • @rogloh said:
    Power supply is always a contender... hopefully multiple have been tried.

    Agreed. A stable source, and with enough "oomph" to source a couple amps without significant voltage sag (and certainly not below ~4.5V)

  • @Wuerfel_21 said:

    The crazyness spreads!

    Have a jar of pickled corn.

    Yum Yum :smiley:

  • Essen Sie das mit honig? Warum?

  • Neee, der Honig ist da schon drin, steht ja auf dem Etikett.

  • @rogloh said:
    Essen Sie das mit honig? Warum?

    Nein, aber es enthält Bienenhonig und Brantweinnessig, und etwas Speisesalz

  • pik33pik33 Posts: 2,358
    edited 2022-06-06 14:35

    @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

  • I wonder... is it possible to change the code pin assignments for the psram; perhaps invert the order of the physical ram chips ?

  • pik33pik33 Posts: 2,358

    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?

  • Wuerfel_21Wuerfel_21 Posts: 4,671
    edited 2022-06-06 15:39

    @VonSzarvas said:
    I wonder... is it possible to change the code pin assignments for the psram; perhaps invert the order of the physical ram chips ?

    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 strcasecmp to not building at all. cool.

  • pik33pik33 Posts: 2,358

    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.

  • @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.

  • RaymanRayman Posts: 14,147
    edited 2022-06-06 22:09

    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.

  • roglohrogloh Posts: 5,281
    edited 2022-06-06 23:56

    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.)

  • 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.

  • roglohrogloh Posts: 5,281
    edited 2022-06-07 00:51

    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.

  • pik33pik33 Posts: 2,358

    @rogloh said:

    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.

  • 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.

  • @pik33 said:

    @rogloh said:

    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 :)

Sign In or Register to comment.