@evanh said:
It would be a flaw if it wasn't the whole 16 bits latched. And it does state Y15:0] is "captured".
From Silicon Document:
On completion of each sample period, Y[15:0] is captured for the next output value and IN is raised.
On each sample period. It says nothing about what happens when the sample periods and PWM periods are unaligned.
@evanh said:
PWM does have a noise problem of its own. It has much higher noise at 50% than 1% or 99%. PDM is superior. Something to look into if Chip ever does a respin.
PDM being better, yea. I think all the smart mode bit patterns are exhausted, so it'd have to replace one of the other modes.
@evanh said:
It would be a flaw if it wasn't the whole 16 bits latched. And it does state Y15:0] is "captured".
From Silicon Document:
On completion of each sample period, Y[15:0] is captured for the next output value and IN is raised.
On each sample period. It says nothing about what happens when the sample periods and PWM periods are unaligned.
Well, the hardware "capture" is a copy of Y. Which simply means that the content of Y is ignored until that point. It can be changed as many times as you like but none of changes are acted on. Only what Y holds at the frame period tick gets used.
@evanh said:
PWM does have a noise problem of its own. It has much higher noise at 50% than 1% or 99%. PDM is superior. Something to look into if Chip ever does a respin.
PDM being better, yea. I think all the smart mode bit patterns are exhausted, so it'd have to replace one of the other modes.
I'd happily vote to replace the DAC+PWM mode. That one is the most complex so would incur the least extra gates by changing it to PDM. It may reduce the gate count.
Okay, MisoYume is now up to beta 01. There are no changes to the emulation core, I just worked on everything else. I imported a lot of code from MegaYume...
There's now a file selection menu by default
Can return from the menu by hitting Ctrl+Esc or holding Start+Down on the controller (in-game reset should also work, but doesn't)
Game saves are now persistently saved to disk
I drew a soup bowl to drive the dumb joke home
RAM is now cleared when starting a game
Change audio DAC to PWM mode for better quality
Updated and quite long compatibility report:
Game
Status
ActRaiser
OK
ActRaiser 2
Intermittent boot? Minor crust, pause hangs game
Bust-A-Move
OK, timing crust (WHY IS THIS FASTROM ARE YOU MADE OF MONEY TAITO?)
Castlevania Dracula X
OK, timing crust
Clock Tower
ok?, minor crust
Contra 3
Hangs
Chrono Trigger
Broken audio, crust
Demon's Crest
OK but major time crust
Earthbound
OK?
Final Fantasy III (really 6, etc, etc)
Broken in very odd ways
Final Fight
OK?, minor screen crust
Final Fantasy Mystic Quest
Black screen
F-Zero
Unsurprisingly still OK
GT Racing
Super timing crust (used to be fine???)
Harvest Moon
OK? (also used to have crust?)
Illusion of Gaia
OK-ish? (This used to have severe timing problems last I checked and I changed nothing since then??)
Jaki Crush
OK
Jurassic Park
Screen flicker, otherwise ok?
Zelda: Link to the Past
OK
Cotton 100%
Black Screen
Super Mario All-Stars
Broken inputs
Mega Man 7
OK, very minor crust
Mega Man X
OK, very minor crust
Phalanx
Black Screen
Plok
OK
Pocky&Rocky
OK, transient audio oddity when starting after quitting something else
Pocky&Rocky 2
Thud and black screen
RPM Racing
OK?
Rock'n'Roll Racing
OK
Samurai Shodown
Ok, but screen crust
Sim City 2000
OK
Super Castlevania IV
OK
Super Ghouls'n Ghosts
OK
Super Metroid
Crashes some way into the game
Super Mario World
OK
Secret of Evermore
Inputs don't work
Secret of Mana
Broken audio and title screen, ingame OK-ish
Super Tetris 2 + Bombliss
OK, needs overscan mode
Tetris Attack
Black Screen (SPC700 comm issue)
Trials of Mana
OK but minor crust and hangs when pressing start
Tales of Phantasia
Mostly broken
Wild Guns
Black Screen when level is supposed to start
Wolfenstein 3D
Screen flicker but otherwise OK
Ys 3
OK?
Interesting oddity: You can play a version of Samurai Shodown on MegaYume, NeoYume and MisoYume now. The Megadrive and SNES versions are extremely gormless though.
Also, it appears that at some point time crust in some games got magically fixed and others that didn't have it before started having it, which makes no sense and I am very confused.
Also, I think I need to reset the DSP registers on boot, that would probably help
@Rayman said:
I’ll have to try super Mario world soon
Nice work!
Make sure to grab a controller, the keyboard controls are a bit awkward because they're just using usbnew defaults and I need to decide on an actual non-ludicrous layout (as far as that is even possible)
@evanh said:
PWM does have a noise problem of its own. It has much higher noise at 50% than 1% or 99%. PDM is superior. Something to look into if Chip ever does a respin.
For P2 audio this is not a problem as the noise is in MHz range at over -48 dB - the PWM is used for a lower byte only. Try listen to 1-bit (LSB, -96 dB) square wave or a 3 bit "sine" with an Eval (not Edge) and a good amplifier
Since I'm apparently have caught myself in a war of two fronts, I worked on the tempest thing some more. I managed to hook up the VBlank interrupt and some GPU functionality and ported over the text drawing microcode, so it can now draw some of the copyright text (and after adding a missing RTS, also the hiscore table). The interesting thing is that there is exactly one text drawing microcode. So all the normal static menu text goes through the same scale-y explode-y codepath that the crazy ingame text uses.
Hey @rogloh where's the documentation on how to make command lists happen again? I'm finding myself in the curious situation of having to read two framebuffers and composite them together.
Memory driver PDF documentation for command list formats should be in the driver zipfile under Advanced Requests. The actual method using it execList is in the full blown memory driver (memory.spin2), not the simpler wrappers, but the functionality is still in the low level PASM2 driver code to do it. You just need to chain a sequence of requests together in a linked list format and then pass the head pointer to the driver.
I think I lost the original distribution at some point, I've been using the raw stuff or so long. I guess that's what I should've gone looking for in the first place.
I'm posting this only because it was mentioned by Sebastiano Vigna (co-creator of xoroshiro algorithm) in one of his papers as an example of combining two algorithms, not because SMW has a really good PRNG!
@TonyB_ said:
Super Mario World - Random Number Generation
I've seen that one already - that channel is really good and also has a good overview of all the crazy nonsense that goes on inside the SNES
So I'm back from GPU microcode hell and this is happening now:
(ignore the fact that the 3D graphics are on top of the HUD for now)
So basically, the main code already works perfectly in the background (after fixing some memory areas overlapping), it really just needs all the graphics stuff ported.
I was stuck for quite a while because of MUL/MULS confusion (MULT/IMULT in Jaguar terms, I guess) breaking the goroud depth shading. Also a brain fart when I was trying to be clever with the Z-clipping.
Okay, I've mostly worked on the tempest thing the past few days (MisoYume problems are all nasty right now).
It's almost complete... I think I can quantify what's missing:
Fix warp stage crosshair (basically, screen3 overlay is more complex than I initially thought - should also end up improving performance since I can fetch less framebuffer data)
Fix warp tokens not showing (game wants to render them directly to screen3 - miss me with that, I'll pre-render them somewhere)
Investigate a line clipping issue (mostly happens when getting the AI droid and it flies in from behind)
Add superzapper effect
Add screen feedback effects (will need some external framebuffer gymnastics and will probably be slow)
Add whatever the highscore entry stretchy letters need
Add audio (slightly tricky since the original DSP microcode is supplied as a blob - need to dig up that P2 MOD player code I guess)
Investigate other nonsense (ending screen, duel mode, etc)
Polish (change button messages, etc)
Possibly fix some original bugs (the polygon fill code is horrible and leaves gaps everywhere)
Ok, here's something "cool" I just noticed: Using sysclk/2 PSRAM mode (i.e. USE_PSRAM_SLOW not defined) in MisoYume causes... interesting issues. I hope it's actually just some code bug and not more timing bullshit (it really shouldn't be, the timing is locked to H-syncs - also HyperRAM didn't cause such issues I think). 16 bit mode seems to work fine though, so that's nice.
It works with an EVAL 96MB setup and that's what the default config is for.
I'm currently testing it on the EC32MB - annoyingly, there doesn't appear to be a properly stable timing at sysclk/3 (????????????). So I guess I have to investigate the oddities now.
EDIT: Actually, I'm not sure there's a stable sysclk/2 timing either? 15/sync/sync has been running for a while now, if that makes it through the night I guess that's a relief.
EDIT2: Maybe I'm just stupid? I think those were P2 hard crashes rather than memory crashes. I switched the EC32MB to a different PSU and now things are looking better.
Some more bugs/instability may (?) have just been explained by the PSRAM row boundary handling having been busted. There's a line like TODO correct value for page size where the correct value should be 9 for all types of PSRAM. HyperRAM doesn't really need this, but setting it to 14 (32kbyte pages) is probably good.
EDIT: Hmm, i had Zelda running it's attract cycle for quite a while, but it still doesn't work reliably with pocky&rocky. Maybe predictions are true and sysclk/2 is just not happening with these chips at this CPU speed.
EDIT2: Yea, sys/3 seems to not be so crash-happy. Though by virtue of actually paying attention to them, it seems some of the P&R demos desync? (characters standing in corners and shooting at walls) - may just be game bug where they recorded the demos before some last-minute changes and no-one noticed the issue. Need to verify that. EDIT: Yep game broken
EDIT3: Okay now we're back to nothing working at all? I think I'm actually loosing my mind. I think I'll just go back to my EVAL and forget about this all for now.
EDIT4: Yep, EVAL with HyperRAM is solid as ever. I guess this is where my EC32MB craps out. It's a pre-release Rev A board, allegedly Rev B has improved thermals and better regulators. Might have to e-beg for a Rev B. (Normally I don't even do that and the hardware inexplicably ends up in my mailbox anyways, so it's surely bound to work). Or just try putting a heatsink on my board first. The EVAL runs very cool.
@Wuerfel_21 said:
Some more bugs/instability may (?) have just been explained by the PSRAM row boundary handling having been busted. There's a line like TODO correct value for page size where the correct value should be 9 for all types of PSRAM. HyperRAM doesn't really need this, but setting it to 14 (32kbyte pages) is probably good.
Aren't all the page boundary limits wonderful! LOL.
EDIT4: Yep, EVAL with HyperRAM is solid as ever. I guess this is where my EC32MB craps out. It's a pre-release Rev A board, allegedly Rev B has improved thermals and better regulators. Might have to e-beg for a Rev B. (Normally I don't even do that and the hardware inexplicably ends up in my mailbox anyways, so it's surely bound to work). Or just try putting a heatsink on my board first. The EVAL runs very cool.
I have REV-A P2-EC32MB boards. Don't think I saw performance limits until about 350MHz or so but will have to dig up the test results from old posts to see exactly what I got, maybe I'm thinking of another setup.
EDIT: yeah good results were collected here up to 350MHz: https://forums.parallax.com/discussion/174159/p2-edge-psram-is-working/p1
@rogloh said:
I have REV-A P2-EC32MB boards. Don't think I saw performance limits until about 350MHz or so but will have to dig up the test results from old posts to see exactly what I got, maybe I'm thinking of another setup.
EDIT: yeah good results were collected here up to 350MHz: https://forums.parallax.com/discussion/174159/p2-edge-psram-is-working/p1
Maybe your's works better. Can you try MisoYume? here's the current WIP lower file with the row boundary fix, combine it with the beta01 files from earlier. As previousuly mentioned, I had it running Zelda rather well, but Pocky and Rocky keeps crashing, so be sure to play that one (MD5 of the US version is e74e067787723bc54093a9c03f290e5d)
Nothing builds until I fix your bugs...
./build.sh
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_upper.spin2
|-MegaVGA_ohmyshit.spin2 config.spin2:58: error: syntax error, unexpected '.', expecting '['
|-MegaVGA_ohmyshit.spin2
|-usbnew.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_lower.spin2
|-MegaVGA_ohmyshit.spin2 config.spin2:58: error: syntax error, unexpected '.', expecting '['
Thankfully it just needs the first line changed in config.spin2 from = to :
OBJ vconst : "MegaVGA_ohmyshit.spin2"
Yeah that Pocky game just blank screens after the initial title is shown. No sound was heard apart from a click at the start. I set it up with this, which hopefully should work on the P2-EC32MB.
' Enable one of these to select the exmem type to use
#define USE_PSRAM16
'#define USE_PSRAM8
'#define USE_PSRAM4
'#define USE_HYPER
PSRAM_CLK = 56
PSRAM_SELECT = 57
PSRAM_BASE = 40
PSRAM_BANKS = 1 ' Only used to stop further banks from interfering
PSRAM_WAIT = 5
PSRAM_DELAY = 17
PSRAM_SYNC_CLOCK = true
PSRAM_SYNC_DATA = true
I also had USB on pins 6,7 and that let me navigate the SD card with my USB joystick so at least that was working. VGA was on pin 16, audio on 22,23
Actually this is interesting. Second time I loaded it, it ran. I couldn't start the game though, must have different button mappings on my home made controller. Up down/left right nav worked though. Let the game do its thing without any button input and it initially ran through a bit of a demo with text etc and played music for a bit then it locked up when it looked like it was about to do some gameplay.
UPDATE: played another Robocop game and the inputs worked on that one so I think it was an issue with that Pocky game.
@rogloh said:
Nothing builds until I fix your bugs...
./build.sh
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_upper.spin2
|-MegaVGA_ohmyshit.spin2 config.spin2:58: error: syntax error, unexpected '.', expecting '['
|-MegaVGA_ohmyshit.spin2
|-usbnew.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_lower.spin2
|-MegaVGA_ohmyshit.spin2 config.spin2:58: error: syntax error, unexpected '.', expecting '['
Thankfully it just needs the first line changed in config.spin2 from = to :
OBJ vconst : "MegaVGA_ohmyshit.spin2"
????? WHAT???? Why would that ever happen? And why would changing the = to : fix it rather than make it worse? Anyways it appears to do that so let's not pay it that much mind.
Yeah that Pocky game just blank screens after the initial title is shown. No sound was heard apart from a click at the start. I set it up with this, which hopefully should work on the P2-EC32MB.
' Enable one of these to select the exmem type to use
#define USE_PSRAM16
'#define USE_PSRAM8
'#define USE_PSRAM4
'#define USE_HYPER
PSRAM_CLK = 56
PSRAM_SELECT = 57
PSRAM_BASE = 40
PSRAM_BANKS = 1 ' Only used to stop further banks from interfering
PSRAM_WAIT = 5
PSRAM_DELAY = 17
PSRAM_SYNC_CLOCK = true
PSRAM_SYNC_DATA = true
I also had USB on pins 6,7 and that let me navigate the SD card with my USB joystick so at least that was working. VGA was on pin 16, audio on 22,23
Will try other stuff later if I have time...
@rogloh said:
Actually this is interesting. Second time I loaded it, it ran. I couldn't start the game though, must have different button mappings on my home made controller. Up down/left right nav worked though. Let the game do its thing without any button input and it initially ran through a bit of a demo with text etc and played music for a bit then it locked up when it looked like it was about to do some gameplay.
UPDATE: played another Robocop game and the inputs worked on that one so I think it was an issue with that Pocky game.
That just sounds like bad RAM setting. Is that slow or fast mode? (= sys/3 or sys/2 ). Though the same setting on slow actually works for me, so IDEK
SYNC_CLOCK causes some oddities for me. Maybe the phase of the clock is weird then. EC32MB should have very wide bands where it works though. Are you using Rev A or Rev B?
Also, P&R only starts when you press the appropriately named START button (both on the title screen and the character selection!). So that one should be mapped right. Though when testing this sort of thing I just let the attract sequence cycle through.
Also, a common type of hard P2 core crash with this is that the screen corrupts with two alternating scanlines (basically like striped bars down the screen) - that can never be caused by bad RAM data, that is one of the render cogs kicking the bucket. Monitor turning off is of course also this.
EDIT: Maybe the timing above isn't quite right either? I got so tilted yesterday that I don't remember which the least bad timing is
EDIT 2: No, the Edge just doesn't wanna today. Just had a monitor turning off crash. Yay.
The previous result was with the USE_PSRAM_SLOW # defined. I have a rev A board.
Ok, just tried again with a different controller that has the START button and enabled higher speed clock by commenting out the USR_PSRAM_SLOW line and existing timing from before.
Result: full lockup after ROM loading stage with grey screen.
Also tried with PSRAM_DELAY=16, same.
Also tried with PSRAM_DELAY=18, 19, same.
Tried your exact settings in last post back with USE_PSRAM_SLOW defined again, game started this time. First and second time I ran it it locked up blank after Natsume title screen with quick audio blurp and death, like I had before.
Went back to PSRAM_SYNC_CLOCK=true which I had before and it still doesn't work, same deal.
You may need a utility that can find the best RAM delays with your timing for a given HW system setup, a bit like I did with that delaytest.spin2 thing. Ideally it would spit out the correct lines to paste into config.spin2 file.
Third time's a charm and the game finally ran with my same original settings after prior two lockups and could respond to the controller but immediately locked up 3 seconds after game began with proper gameplay graphics etc.
Yea, I really should make a memory auto-configurator one of those days. Though as previously explored, overall power draw seems to shift the timings, so some effort needs to be put in to simulate that.
Also, do try digging out some kind of heat sink or fan and see if that changes it.
Ok, will try out both of these with fast mode and report back in this post shortly...this game certainly behaves worse than the others I ran.
Update results:
Comments
On each sample period. It says nothing about what happens when the sample periods and PWM periods are unaligned.
PDM being better, yea. I think all the smart mode bit patterns are exhausted, so it'd have to replace one of the other modes.
Well, the hardware "capture" is a copy of Y. Which simply means that the content of Y is ignored until that point. It can be changed as many times as you like but none of changes are acted on. Only what Y holds at the frame period tick gets used.
I'd happily vote to replace the DAC+PWM mode. That one is the most complex so would incur the least extra gates by changing it to PDM. It may reduce the gate count.
Okay, MisoYume is now up to beta 01. There are no changes to the emulation core, I just worked on everything else. I imported a lot of code from MegaYume...
Updated and quite long compatibility report:
Interesting oddity: You can play a version of Samurai Shodown on MegaYume, NeoYume and MisoYume now. The Megadrive and SNES versions are extremely gormless though.
Also, it appears that at some point time crust in some games got magically fixed and others that didn't have it before started having it, which makes no sense and I am very confused.
Also, I think I need to reset the DSP registers on boot, that would probably help
I’ll have to try super Mario world soon
Nice work!
Make sure to grab a controller, the keyboard controls are a bit awkward because they're just using usbnew defaults and I need to decide on an actual non-ludicrous layout (as far as that is even possible)
OMG if the youth of today think gamers in 2001 were Neanderthals, then what would they think of those playing on consoles from the 80's/90s?
https://www.youtube.com/shorts/2-67twDuY-Q?feature=share
For P2 audio this is not a problem as the noise is in MHz range at over -48 dB - the PWM is used for a lower byte only. Try listen to 1-bit (LSB, -96 dB) square wave or a 3 bit "sine" with an Eval (not Edge) and a good amplifier
Since I'm apparently have caught myself in a war of two fronts, I worked on the tempest thing some more. I managed to hook up the VBlank interrupt and some GPU functionality and ported over the text drawing microcode, so it can now draw some of the copyright text (and after adding a missing RTS, also the hiscore table). The interesting thing is that there is exactly one text drawing microcode. So all the normal static menu text goes through the same scale-y explode-y codepath that the crazy ingame text uses.
Hey @rogloh where's the documentation on how to make command lists happen again? I'm finding myself in the curious situation of having to read two framebuffers and composite them together.
Memory driver PDF documentation for command list formats should be in the driver zipfile under Advanced Requests. The actual method using it execList is in the full blown memory driver (memory.spin2), not the simpler wrappers, but the functionality is still in the low level PASM2 driver code to do it. You just need to chain a sequence of requests together in a linked list format and then pass the head pointer to the driver.
I think I lost the original distribution at some point, I've been using the raw stuff or so long. I guess that's what I should've gone looking for in the first place.
Super Mario World - Random Number Generation
I'm posting this only because it was mentioned by Sebastiano Vigna (co-creator of xoroshiro algorithm) in one of his papers as an example of combining two algorithms, not because SMW has a really good PRNG!
I've seen that one already - that channel is really good and also has a good overview of all the crazy nonsense that goes on inside the SNES
So I'm back from GPU microcode hell and this is happening now:
(ignore the fact that the 3D graphics are on top of the HUD for now)
So basically, the main code already works perfectly in the background (after fixing some memory areas overlapping), it really just needs all the graphics stuff ported.
Speaking of, the 3D vector line drawing microcode. Giant piece of work that needs its own overlay to itself, check it out: https://github.com/mwenge/tempest2k/blob/master/src/llama.gas
I was stuck for quite a while because of MUL/MULS confusion (MULT/IMULT in Jaguar terms, I guess) breaking the goroud depth shading. Also a brain fart when I was trying to be clever with the Z-clipping.
Okay, I've mostly worked on the tempest thing the past few days (MisoYume problems are all nasty right now).
It's almost complete... I think I can quantify what's missing:
Ok, here's something "cool" I just noticed: Using sysclk/2 PSRAM mode (i.e.
USE_PSRAM_SLOWnot defined) in MisoYume causes... interesting issues. I hope it's actually just some code bug and not more timing bullshit (it really shouldn't be, the timing is locked to H-syncs - also HyperRAM didn't cause such issues I think). 16 bit mode seems to work fine though, so that's nice.This is with PSRAM4 then?
Can it work in slow mode?
I still need to try super Mario ,
Hopefully this weekend
It works with an EVAL 96MB setup and that's what the default config is for.
I'm currently testing it on the EC32MB - annoyingly, there doesn't appear to be a properly stable timing at sysclk/3 (????????????). So I guess I have to investigate the oddities now.
EDIT: Actually, I'm not sure there's a stable sysclk/2 timing either? 15/sync/sync has been running for a while now, if that makes it through the night I guess that's a relief.
EDIT2: Maybe I'm just stupid? I think those were P2 hard crashes rather than memory crashes. I switched the EC32MB to a different PSU and now things are looking better.
Yea, that seems to be it, spooked myself into thinking MisoYume doesn't run properly on my EDGE by using the wrong power supply. Amazing.
Some more bugs/instability may (?) have just been explained by the PSRAM row boundary handling having been busted. There's a line like
TODO correct value for page sizewhere the correct value should be 9 for all types of PSRAM. HyperRAM doesn't really need this, but setting it to 14 (32kbyte pages) is probably good.EDIT: Hmm, i had Zelda running it's attract cycle for quite a while, but it still doesn't work reliably with pocky&rocky. Maybe predictions are true and sysclk/2 is just not happening with these chips at this CPU speed.
EDIT2: Yea, sys/3 seems to not be so crash-happy. Though by virtue of actually paying attention to them, it seems some of the P&R demos desync? (characters standing in corners and shooting at walls) - may just be game bug where they recorded the demos before some last-minute changes and no-one noticed the issue. Need to verify that. EDIT: Yep game broken
EDIT3: Okay now we're back to nothing working at all? I think I'm actually loosing my mind. I think I'll just go back to my EVAL and forget about this all for now.
EDIT4: Yep, EVAL with HyperRAM is solid as ever. I guess this is where my EC32MB craps out. It's a pre-release Rev A board, allegedly Rev B has improved thermals and better regulators. Might have to e-beg for a Rev B. (Normally I don't even do that and the hardware inexplicably ends up in my mailbox anyways, so it's surely bound to work). Or just try putting a heatsink on my board first. The EVAL runs very cool.
Aren't all the page boundary limits wonderful! LOL.
I have REV-A P2-EC32MB boards. Don't think I saw performance limits until about 350MHz or so but will have to dig up the test results from old posts to see exactly what I got, maybe I'm thinking of another setup.
EDIT: yeah good results were collected here up to 350MHz:
https://forums.parallax.com/discussion/174159/p2-edge-psram-is-working/p1
Maybe your's works better. Can you try MisoYume? here's the current WIP lower file with the row boundary fix, combine it with the beta01 files from earlier. As previousuly mentioned, I had it running Zelda rather well, but Pocky and Rocky keeps crashing, so be sure to play that one (MD5 of the US version is e74e067787723bc54093a9c03f290e5d)
Nothing builds until I fix your bugs...
./build.sh
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_upper.spin2
|-MegaVGA_ohmyshit.spin2
config.spin2:58: error: syntax error, unexpected '.', expecting '['
|-MegaVGA_ohmyshit.spin2
|-usbnew.spin2
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2024 Total Spectrum Software Inc. and contributors
Version 6.9.8-beta-v6.9.7-29-g79179f5c Compiled on: May 17 2024
misoyume_lower.spin2
|-MegaVGA_ohmyshit.spin2
config.spin2:58: error: syntax error, unexpected '.', expecting '['
Thankfully it just needs the first line changed in config.spin2 from = to :
OBJ vconst : "MegaVGA_ohmyshit.spin2"
Yeah that Pocky game just blank screens after the initial title is shown. No sound was heard apart from a click at the start. I set it up with this, which hopefully should work on the P2-EC32MB.
I also had USB on pins 6,7 and that let me navigate the SD card with my USB joystick so at least that was working. VGA was on pin 16, audio on 22,23
Will try other stuff later if I have time...
Actually this is interesting. Second time I loaded it, it ran. I couldn't start the game though, must have different button mappings on my home made controller. Up down/left right nav worked though. Let the game do its thing without any button input and it initially ran through a bit of a demo with text etc and played music for a bit then it locked up when it looked like it was about to do some gameplay.
UPDATE: played another Robocop game and the inputs worked on that one so I think it was an issue with that Pocky game.
????? WHAT???? Why would that ever happen? And why would changing the = to : fix it rather than make it worse? Anyways it appears to do that so let's not pay it that much mind.
That just sounds like bad RAM setting. Is that slow or fast mode? (= sys/3 or sys/2 ). Though the same setting on slow actually works for me, so IDEK
I think this one oughtta though:
SYNC_CLOCK causes some oddities for me. Maybe the phase of the clock is weird then. EC32MB should have very wide bands where it works though. Are you using Rev A or Rev B?
Also, P&R only starts when you press the appropriately named START button (both on the title screen and the character selection!). So that one should be mapped right. Though when testing this sort of thing I just let the attract sequence cycle through.
Also, a common type of hard P2 core crash with this is that the screen corrupts with two alternating scanlines (basically like striped bars down the screen) - that can never be caused by bad RAM data, that is one of the render cogs kicking the bucket. Monitor turning off is of course also this.
EDIT: Maybe the timing above isn't quite right either? I got so tilted yesterday that I don't remember which the least bad timing is
EDIT 2: No, the Edge just doesn't wanna today. Just had a monitor turning off crash. Yay.
Okay here's the new meta: Add a fan. Seems to make it a lot better. Will try heatsinks when I get them in the mail
The previous result was with the USE_PSRAM_SLOW # defined. I have a rev A board.
Ok, just tried again with a different controller that has the START button and enabled higher speed clock by commenting out the USR_PSRAM_SLOW line and existing timing from before.
Result: full lockup after ROM loading stage with grey screen.
Also tried with PSRAM_DELAY=16, same.
Also tried with PSRAM_DELAY=18, 19, same.
Tried your exact settings in last post back with USE_PSRAM_SLOW defined again, game started this time. First and second time I ran it it locked up blank after Natsume title screen with quick audio blurp and death, like I had before.
Went back to PSRAM_SYNC_CLOCK=true which I had before and it still doesn't work, same deal.
You may need a utility that can find the best RAM delays with your timing for a given HW system setup, a bit like I did with that delaytest.spin2 thing. Ideally it would spit out the correct lines to paste into config.spin2 file.
Third time's a charm and the game finally ran with my same original settings after prior two lockups and could respond to the controller but immediately locked up 3 seconds after game began with proper gameplay graphics etc.
@rogloh For fast mode the timing is kinda different (why?) and the correct-er timing is more like
or I think this also worked
Yea, I really should make a memory auto-configurator one of those days. Though as previously explored, overall power draw seems to shift the timings, so some effort needs to be put in to simulate that.
Also, do try digging out some kind of heat sink or fan and see if that changes it.
Ok, will try out both of these with fast mode and report back in this post shortly...this game certainly behaves worse than the others I ran.
Update results:
Ran twice: lockups each time after title screens and wouldn't start
Same outcome.
Note: this memory setting does work on other games.
Well that's an oddity. Do you have an EVAL (with HyperRAM or 96MB board) on hand to sanity check against?
If it crashes this often you may also have insufficient 5V power, as I noticed earlier.
EDIT: Also, yes, P&R seems to trigger something that makes it have more issues. It's not even using fast ROM mode, how odd.
Also, I have been running for over 1 hour with the cooling fan now, so I think that really does something.