Neat to be able to run more with PSRAM4. On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target. https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
@rogloh said:
Neat to be able to run more with PSRAM4.
It's not a PSRAM4-exclusive fix, that one's just the absolute worst for ROM->VRAM DMA. Wolf3D does tons of WRAM->VRAM, that one was busted regardless of RAM speed. The new DMA code properly grabs the ROM data for the upcoming transfer block in one go, so a lot less overhead on that.
On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target. https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
800x480 should be fine, I can do that on HDMI, so parallel LCD shouldn't be a problem on that front. You just get big bars on the games.
Hmm, so I can find 2 games that definitely don't work anymore with the new DMA code: Donkey Kong Country and Jurassic Park. Former is a big pain, I just fixed that one in beta07!
Also, there's timing problems in Demon's Crest that are still not fixed with this. Though I'd assume that's regular "where does the IRQ go" type problems.
EDIT: Fixed it, just went into an infinite loop based on difference of opinion on when exactly events should happen between DMA setup and everything else.
Appears that actual 480p resolution games can gain a lot. Not clear about these games that are more like QVGA though.
Does mention sega genesis though, so maybe...
Nothing worthwhile. The HDMI output from the P2 is already as good as it gets.
These kinds of things tend to just attempt to apply an FXAA-type algorithm to smooth edges.
As previously mentioned, this release is an optimizations-only one, This means games that previously had graphical glitches due to the CPU cog falling behind (especially on slow 4-bit PSRAM boards) are now FIXED.
This notably includes:
The Legend of Zelda: A Link to the Past
Super Metroid
Super Mario All-Stars
Wolfenstein 3D
I did not find any regressions, though there's potential for those, as the entire DMA code got re-written and certain A-Bus areas can no longer be DMA source/destination (notably, DMA from/to cartridge RAM is currently not implemented due to lack of test cases).
I also added some extra info to the file browser.
@Rayman said:
Those sound like good titles to have working. Thanks!
Technically they were already working, just with some amount of flickering.
Reminds me that still want to make full sized console for TV…
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
The P2 game box thing from @MXX is basically like that, though it has 96MB PSRAM and a built-in USB hub. (I actually have his schematics for that, but don't know if it's ok to share them)
(added on afterwards)
The next big thing missing from MisoYume is CPU/SPC synchronization. This is the leading cause of broken games. Basically, most games use explicit handshakes when communicating with the sound board. Those work. But some games rely on implicit timing to reduce overhead (or just because they're busted) and that doesn't work. Basically the CPU emulation works on ~64µs time slices (one video scanline) and the SPC emulation works on ~31µs slices (one audio sample). Within each slice the actual work is done at the beginning and the rest is spent waiting.
So the difficulty now is to figure out a scheme that allows synchronizing the mailbox accesses to simulate the processors running in tight lock-step (tigh-ish anyways - the real SNES sound board is clocked by it's own ceramic resonator circuit, so it's not in a very stable relationship with the main clock)
The DMA optimization was a blocker for this, because having the CPU be 100s of µs late to its own time is not conducive to that sort of time-sync effort.
@Wuerfel_21 said:
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
@Wuerfel_21 That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
@Rayman said:
That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Remember that the HDMI audio currently relies on having analog outputs somewhere to provide the timing reference. If you don't have 2 unused pins to send DAC output to, I'd need to engage in major refactoring.
Also not everything, Spin Hexagon still doesn't have it.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
PC-Engine type situation where the "multitap" is required for more than 1 player
Unrelatedly, I would consider putting the Rayslogic StoreTM link more prominently somewhere, I think people don't know it exists. Need to seed more 96MB PSRAM and P2Plat among the populace for our nefarious schemes. Maybe more aggressive forum signature ad like "Rayslogic Store: [link] - P2 SwAP, P2 Platform, PSRAM expanders and more" added as a 2nd line.
(Also, is a 640x480 RGB816 LCD board still happening?)
Yet unrelatedly to any of those things, but to pad out this post with some non-nonsense of general interest, a "sneak preview" of that alleged WIP software I'd mentioned elsewhere :
(I actually had this on discord days ago, I guess it's go there to get the real (low-effort) scoops?)
(You can tell it's old because for P1CC it doesn't build @zx81vga games yet, which were finished last)
The idea is that you just have to write 1 config and then run this script on it and it will grab all the softwares from their git remotes, configure them, build them (including any tools required) and stuff them into a ready-made directory structure (assuming we had a working SD IPL... of course one can also just load the BIX files from there manually).
Grabbing, configuring and building are mostly working, but I need to find a good way to ingest a machine configuration in a hassle-free manner (i.e. where you can say "A/V accessory on basepin 8" and it automatically figures out the analog audio and video pins) and convert that into project-specific config values. Also PSRAM latency settings are ??? (will definitely need a way both to guess the correct setting and to override that when it goes badly). Also need a way to reject building stuff that can't possibly be configured (e.g. can't configure NeoYume on a PSRAM-less machine no matter how hard you try).
Also need to figure out how to best get the prerequisites and turn that into a guide for Linux/Win/Mac/etc (currently: ruby, git, bison and gcc/build-essentials).
@Wuerfel_21 said:
(Also, is a 640x480 RGB816 LCD board still happening?)
Hmm. Seems dropped the ball on that one. Found some 24-bit ones that were made, but seems we decided at some point that 16-bit would be better.
Also, had to redo connection for pin-35 as that was actually a demo mode switch. Also, wanted to redo header so could work with edge...
Found a new layout, but have to see if it was ever made...
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
@Wuerfel_21 said:
Unrelatedly, I would consider putting the Rayslogic StoreTM
But one can't have their inventory and sell it too
Sure, but I just feel the sales are entirely synchronized with me making mention of it. (I think another one just went?)
@Rayman said:
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
Fair, but they don't offer these with pin header connections, just bothersome HDMI connectors.
@Rayman said:
Not really sure what is going on there, but guess this is wireless I2C?
No, the controller just sends out whatever signals it does, likely one-way, then the receivers put up a USB HID / I2C front end (respectively) for the system to poll. I wouldn't be surprised if both types of receiver would happen to work simultaneously from the same pad.
You can get one that does the same trick with a variety of Bluetooth controllers: https://www.8bitdo.com/retro-receiver-snes-sfc-classic/ (or the plain old SNES version of this that simulates a shift register... I have that one).
Though wired is always better to me. Less hassle, less latency.
(EDIT) Currently I'd be in a bit of a pickle recommending one, as both of my favorite retro-ish USB controllers have died on me. Those would've been the "Retro-Bit SEGA 8-Button Arcade Pad with USB" (cable went bad) and the "8bitdo SN30 Pro USB" (firmware bricked itself under mysterious circumstances - while connected to my PC, no experimental HW/SW involved). The newer "8bitdo Ultimate 2C Wired" has been good to me so far, but it's a more modern-style layout (and also has trouble with usbnew on P2 sometimes).
Comments
Neat to be able to run more with PSRAM4. On one of my old projects in this thread here I have a 4 bit PSRAM (and parallel LCD or VGA) plus USB so it might be a candidate for some retro gaming one day too. The LCD is 800x480 however so is probably not that nice a resolution to target.
https://forums.parallax.com/discussion/169431/p2-voyager-project-was-new-toy/p3
It's not a PSRAM4-exclusive fix, that one's just the absolute worst for ROM->VRAM DMA. Wolf3D does tons of WRAM->VRAM, that one was busted regardless of RAM speed. The new DMA code properly grabs the ROM data for the upcoming transfer block in one go, so a lot less overhead on that.
800x480 should be fine, I can do that on HDMI, so parallel LCD shouldn't be a problem on that front. You just get big bars on the games.
Hmm, so I can find 2 games that definitely don't work anymore with the new DMA code: Donkey Kong Country and Jurassic Park. Former is a big pain, I just fixed that one in beta07!
Also, there's timing problems in Demon's Crest that are still not fixed with this. Though I'd assume that's regular "where does the IRQ go" type problems.
EDIT: Fixed it, just went into an infinite loop based on difference of opinion on when exactly events should happen between DMA setup and everything else.
Curious about what this gizmo would do for Sega Genesis emulator:
https://marseilleinc.com/products/buy-mclassic
Appears that actual 480p resolution games can gain a lot. Not clear about these games that are more like QVGA though.
Does mention sega genesis though, so maybe...
Nothing worthwhile. The HDMI output from the P2 is already as good as it gets.
These kinds of things tend to just attempt to apply an FXAA-type algorithm to smooth edges.
Yeah, think my monitors and tv already do up scaling. Works well on actual 480p or better input. But this is just too blocky to work…
Do wonder though if output were to just one corner of screen, maybe upscaler would work and then maybe could zoom into that area on screen…
You can not squeeze blood from a stone
With no further ado,
MisoYume beta11
As previously mentioned, this release is an optimizations-only one, This means games that previously had graphical glitches due to the CPU cog falling behind (especially on slow 4-bit PSRAM boards) are now FIXED.
This notably includes:
I did not find any regressions, though there's potential for those, as the entire DMA code got re-written and certain A-Bus areas can no longer be DMA source/destination (notably, DMA from/to cartridge RAM is currently not implemented due to lack of test cases).
I also added some extra info to the file browser.
Get it at SourceHut, GitHub or grab the attached ZIP file!
Those sound like good titles to have working. Thanks!
Reminds me that still want to make full sized console for TV…
Technically they were already working, just with some amount of flickering.
Could really just drop a P2Platform into a nice box for that one. It's got the goods.
The P2 game box thing from @MXX is basically like that, though it has 96MB PSRAM and a built-in USB hub. (I actually have his schematics for that, but don't know if it's ok to share them)
(added on afterwards)
The next big thing missing from MisoYume is CPU/SPC synchronization. This is the leading cause of broken games. Basically, most games use explicit handshakes when communicating with the sound board. Those work. But some games rely on implicit timing to reduce overhead (or just because they're busted) and that doesn't work. Basically the CPU emulation works on ~64µs time slices (one video scanline) and the SPC emulation works on ~31µs slices (one audio sample). Within each slice the actual work is done at the beginning and the rest is spent waiting.
So the difficulty now is to figure out a scheme that allows synchronizing the mailbox accesses to simulate the processors running in tight lock-step (tigh-ish anyways - the real SNES sound board is clocked by it's own ceramic resonator circuit, so it's not in a very stable relationship with the main clock)
The DMA optimization was a blocker for this, because having the CPU be 100s of µs late to its own time is not conducive to that sort of time-sync effort.
@Wuerfel_21 That is exactly the plan. But, need to make some more of these breakouts with HDMI and USB. Had a few, but lost them somewhere...
Have some with VGA+Audio+USB, but thinking HDMI is better, now that you have sound for everything over HDMI.
Also debating whether to include a 4-port USB hub in the box, or just let it be external, if needed...
Remember that the HDMI audio currently relies on having analog outputs somewhere to provide the timing reference. If you don't have 2 unused pins to send DAC output to, I'd need to engage in major refactoring.
Also not everything, Spin Hexagon still doesn't have it.
PC-Engine type situation where the "multitap" is required for more than 1 player
Unrelatedly, I would consider putting the Rayslogic StoreTM link more prominently somewhere, I think people don't know it exists. Need to seed more 96MB PSRAM and P2Plat among the populace for our nefarious schemes. Maybe more aggressive forum signature ad like "Rayslogic Store: [link] - P2 SwAP, P2 Platform, PSRAM expanders and more" added as a 2nd line.
(Also, is a 640x480 RGB816 LCD board still happening?)
Yet unrelatedly to any of those things, but to pad out this post with some non-nonsense of general interest, a "sneak preview" of that alleged WIP software I'd mentioned elsewhere :
(I actually had this on discord days ago, I guess it's go there to get the real (low-effort) scoops?)
(You can tell it's old because for P1CC it doesn't build @zx81vga games yet, which were finished last)
The idea is that you just have to write 1 config and then run this script on it and it will grab all the softwares from their git remotes, configure them, build them (including any tools required) and stuff them into a ready-made directory structure (assuming we had a working SD IPL... of course one can also just load the BIX files from there manually).
Grabbing, configuring and building are mostly working, but I need to find a good way to ingest a machine configuration in a hassle-free manner (i.e. where you can say "A/V accessory on basepin 8" and it automatically figures out the analog audio and video pins) and convert that into project-specific config values. Also PSRAM latency settings are ??? (will definitely need a way both to guess the correct setting and to override that when it goes badly). Also need a way to reject building stuff that can't possibly be configured (e.g. can't configure NeoYume on a PSRAM-less machine no matter how hard you try).
Also need to figure out how to best get the prerequisites and turn that into a guide for Linux/Win/Mac/etc (currently: ruby, git, bison and gcc/build-essentials).
But one can't have their inventory and sell it too
Hmm. Seems dropped the ball on that one. Found some 24-bit ones that were made, but seems we decided at some point that 16-bit would be better.
Also, had to redo connection for pin-35 as that was actually a demo mode switch. Also, wanted to redo header so could work with edge...
Found a new layout, but have to see if it was ever made...
Guess sort of lost interest when found hdmi based lcd modules for decent price...
Why would one want this that uses 16 pins when could just use HDMI with just 8 pins and use a standard cable?
BTW: Got some more wireless controllers for the set top version:
https://www.amazon.com/dp/B0BWY5CJFR?
These are interesting because also come with Nunchuk type adapters.
Not really sure what is going on there, but guess this is wireless I2C?
Sure, but I just feel the sales are entirely synchronized with me making mention of it. (I think another one just went?)
Fair, but they don't offer these with pin header connections, just bothersome HDMI connectors.
No, the controller just sends out whatever signals it does, likely one-way, then the receivers put up a USB HID / I2C front end (respectively) for the system to poll. I wouldn't be surprised if both types of receiver would happen to work simultaneously from the same pad.
You can get one that does the same trick with a variety of Bluetooth controllers: https://www.8bitdo.com/retro-receiver-snes-sfc-classic/ (or the plain old SNES version of this that simulates a shift register... I have that one).
Though wired is always better to me. Less hassle, less latency.
(EDIT) Currently I'd be in a bit of a pickle recommending one, as both of my favorite retro-ish USB controllers have died on me. Those would've been the "Retro-Bit SEGA 8-Button Arcade Pad with USB" (cable went bad) and the "8bitdo SN30 Pro USB" (firmware bricked itself under mysterious circumstances - while connected to my PC, no experimental HW/SW involved). The newer "8bitdo Ultimate 2C Wired" has been good to me so far, but it's a more modern-style layout (and also has trouble with usbnew on P2 sometimes).