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

Console Emulation

15253555758

Comments

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

  • evanhevanh Posts: 15,386
    edited 2024-05-03 05:26

    @Wuerfel_21 said:

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

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-04 01:55

    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

  • RaymanRayman Posts: 14,145

    I’ll have to try super Mario world soon
    Nice work!

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-03 23:41

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

  • roglohrogloh Posts: 5,280
    edited 2024-05-04 00:09

    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? :D
    https://www.youtube.com/shorts/2-67twDuY-Q?feature=share

  • pik33pik33 Posts: 2,358
    edited 2024-05-04 22:07

    @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

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-05 03:21

    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.

  • roglohrogloh Posts: 5,280

    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.

  • TonyB_TonyB_ Posts: 2,144

    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!

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-07 01:43

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

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-11 21:36

    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)
  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-14 17:25

    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 bulls‌hit (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.

  • RaymanRayman Posts: 14,145
    edited 2024-05-14 22:42

    This is with PSRAM4 then?
    Can it work in slow mode?
    I still need to try super Mario ,
    Hopefully this weekend

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-15 11:48

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-16 20:52

    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.

  • roglohrogloh Posts: 5,280
    edited 2024-05-17 02:04

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

  • roglohrogloh Posts: 5,280

    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

    Will try other stuff later if I have time...

  • roglohrogloh Posts: 5,280
    edited 2024-05-17 07:37

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-17 08:57

    @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

    I think this one oughtta though:

    PSRAM_WAIT  = 5
    PSRAM_DELAY = 16
    PSRAM_SYNC_CLOCK = false
    PSRAM_SYNC_DATA = true
    
    ' Uncomment for slower memory clock
    #define USE_PSRAM_SLOW
    

    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

  • roglohrogloh Posts: 5,280
    edited 2024-05-17 10:29

    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.

  • roglohrogloh Posts: 5,280

    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.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-17 10:35

    @rogloh For fast mode the timing is kinda different (why?) and the correct-er timing is more like

    PSRAM_WAIT  = 5
    PSRAM_DELAY = 14
    PSRAM_SYNC_CLOCK = false
    PSRAM_SYNC_DATA = false
    

    or I think this also worked

    PSRAM_WAIT  = 5
    PSRAM_DELAY = 15
    PSRAM_SYNC_CLOCK = true
    PSRAM_SYNC_DATA = true
    

    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.

  • roglohrogloh Posts: 5,280
    edited 2024-05-17 10:43

    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:

    PSRAM_WAIT = 5
    PSRAM_DELAY = 14
    PSRAM_SYNC_CLOCK = false
    PSRAM_SYNC_DATA = false

    Ran twice: lockups each time after title screens and wouldn't start

    PSRAM_WAIT = 5
    PSRAM_DELAY = 15
    PSRAM_SYNC_CLOCK = true
    PSRAM_SYNC_DATA = true

    Same outcome. :(
    Note: this memory setting does work on other games.

  • Wuerfel_21Wuerfel_21 Posts: 4,665
    edited 2024-05-17 10:47

    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.

Sign In or Register to comment.