@Rayman said:
No, it might be old.
Looks like it's from April 15.
That seems about right. I haven't worked on it since. Kinda haven't been doing well the past few months.
I just built MegaYume for EC32MB + LCD6 with flexspin's git master and it works, so uhhh.
My MisoYume also won't compile, comes out around 20 bytes too big...
??????
Also make sure you're using the correct build settings (i.e. build.sh). They change sometimes and I remember having to change something to un-frick one of the emulators semi-recently. Though there might be a blind spot, I actually use the far spicier settings from build_comptest.sh most of the time (dogfooding compiler ImprovementsTM)
Certainly try all of the softwares I added LCD support to and tell me if they still work (I think that's now the 3 emulators and the tempest port? For the latter you want the video branch IIRC? Check which ones more recent)
@Rayman said:
Was about to say that Misoyume has a problem compiling.
With latest code and compiler.
But, forgot that need to adjust my Build_N_Run.bat file to match your build.sh file.
Seems some of the settings there changed...
Yeah I think I checked the preconfigured ones you have on your website and the misoyume was ancient. Beta 02 I think. There've been big strides in compatibility after that. Then I forgot to bother you about it.
@Rayman said:
Hmm. Misoyume gives me a black screen after selection ROM and the message after that...
Guess should see if VGA mode works...
Is that a ROM that previously worked?
Some of them do legitimately just get stuck on black screen due to SPC700-related race conditions that I haven't been able to fix yet. (Due to DMA speed issue that needs to be fixed first)
@Rayman said:
Oh wow, this looks kind of complicated to try... I have to build something with WSL? Hopefully, I've done this already and have it somewhere....
You don't have to, I am just unconfident that it works with MinGW/MSYS et al. It's easier to just say "use Linux of some sort" because that will figure itself out.
@Wuerfel_21 Found the actual source of my troubles yesterday... Seems the SWaP carrier board that was first being tested on had a 9DOF mems chip connected via QWIIC cable with pins that happen to overlap with HyperRam.
Normally, this wouldn't be an issue, but this particular sensor happens to be rigged for serial output, meaning pin contention...
@Rayman said:
@Wuerfel_21 How does 2 player work? Supposing have USB hub with two USB controllers plugged in, how does it know who is player 1 and who is player 2?
Based on the port number. Most hubs don't have any markings for port order, so you just need to try it out.
@Rayman said:
@Wuerfel_21 was just thinking back to the great debate over 16 regular cogs for P2 vs 8 super cogs. 8 won of course.
But, was just wondering which would have been better in this space…
Assuming smartpins the same and hubexec and hub access the same or perhaps with hub bandwidth halved.
Maybe 16 would have been easier?
16 would've certainly be a lot, but if they'd have been weaker there'd have to be a lot more splitting of tasks into multiple cogs. E.g. if the MUL instruction wasn't there, that would've been sour.
The current P2 design can be parametrized for 16 cogs, but then you get double the hub latency. No way around that with the deterministic time-slices. I think most P2 programs that are slow are slow because of overreliance on high-latency RDLONG etc for memory access.
What could have been done is to take 2 cogs and pair them together. Since each instruction takes two cycles, I think there end up being a lot of circuits that are idle 50% of the time, so they could be shared. Or alternatively, pair 4 P1 style 4-cycle CPUs. In that case the cog RAMs are single-ported still, but need some kind of fat crossbar for entering into the 4-way shared ALU. Not that I know much about that sort of thing.
IMO the main missing things:
- TMDS pixel repetition
- Nibble reverse instruction
- lower-latency 32 bit multiply (i.e. better to be a macro instruction like MULPIX than to stall 50+ cycles on a CORDIC op. Especially relevant to compilers)
- SCAS without shifting right (or possibly some version of ARM's SMUAD dot-product-ish instruction)
- WRLONG and such should probably be buffered to hide latency? (can approximate this with WRFAST + WFLONG, but resets FIFO in the process)
I think I finally started work in earnest on trying to fix the issues in MisoYume where the CPU can fall behind the video signal, so I can start posting about it. This issue usually manifests in flashing lines at the top of the screen and glitchy raster effects (also called "time crust" by me)
Super Metroid w/ 4-bit PSRAM is very affected by time crust
The main problem currently is DMA transfers, which really have 2 compounding problems that make them run far too slow:
The DMA transfer loop takes too long per byte, partially because it calls the random access rk_read8 function each time, so memory region decoding has to happen individually for each byte.
As a consequence of calling rk_read8 ROM->VRAM transfers end up using the small (6..8 byte) random access cache, which results in more PSRAM traffic than is really needed.
So I'm rewriting that whole DMA mess to work in larger blocks, which reduces the inner loop timing and also allows smart pre-fetching of the necessary ROM data.
One thing that seems apparent is that bumping up the data cache size (PSRAM_CACHESIZE) by one notch for 8 and 16 bit memory is a good idea.
Bytes prev.
Bytes now
Alignment
PSRAM4
6
6
1
PSRAM8/Hyper
6
8
2
PSRAM16
8
12
4
(I'm going mad with the tables recently)
The alignment is important here. If the address is worst case aligned (LSBs all ones) you might only get 5 contiguous bytes out of 8 bytes fetched from PSRAM16 (4-aligned). (that was infact the original intent - a HDMA channel might consume up to 5 contiguous bytes from its list data)
Fetching 8 bytes on 8bit is of course always faster than 6 on 4bit.
There's a point where the extra overhead for purely random access overwhelms the benefit of optimizing sequential access (especially when the DMA rewrite is done and moves a lot of sequential access off that path). But 4/6 extra cycles (fast/slow modes) seem worth it (in the sense of making code run faster).
And in the end I am fairly confident even PSRAM4 is going to make a decent showing.
@Rayman said:
@Wuerfel_21 Is there still a list of supported/running ROMs from MegaYume somewhere?
Thought there might be something in the code, but don't see it...
MegaYume has actually OK compatibility, so just assume it runs unless it doesn't.
Totally borked ROMs I am aware of:
NBA Jam (??? weird bug)
Double Dragon 2 (??? also strange bug)
Super Street Fighter 2 (as opposed to regular Street Fighter 2: Special Champion Edition! That one works) (unemulated ROM mapper)
Sonic&Knuckles (unemulated ROM mapper / Lock-OnTM -> use Sonic 3 Complete ROM hack)
Virtua Racing (unemulated coprocessor)
There's a few more that have minor bugs.
Of course the README has a few nice freebies linked that (obviously) work. Certainly grab Cave Story MD! (you probably(?) want doukutsu-en.gen) Though that got an update recently, so I haven't tested the new version.
@Wuerfel_21 said:
Super Metroid w/ 4-bit PSRAM is very affected by time crust
Behold! The crust has been vanquished! This is still sysclk/3 4-bit PSRAM. Yet, no glitches.
All thanks to just locking in and spending ~2 days staring at the DMA nonsense.
Currently only on dev branch, still need to test for regressions tomorrow. Big code diff
Games that seem to have a lot less glitches of that sort (some of it is just natural/"intended"):
Comments
That seems about right. I haven't worked on it since. Kinda haven't been doing well the past few months.
I just built MegaYume for EC32MB + LCD6 with flexspin's git master and it works, so uhhh.
??????
Also make sure you're using the correct build settings (i.e. build.sh). They change sometimes and I remember having to change something to un-frick one of the emulators semi-recently. Though there might be a blind spot, I actually use the far spicier settings from build_comptest.sh most of the time (dogfooding compiler ImprovementsTM)
Ok, downloaded the latest Megayume from github and it works with the latest Flexprop.
Nevermind. Sorry about that.
Yeah but that's captital-W Weird since the last version was April 5th.
April 17 is file date, but maybe that's when it was unzipped or something...
Is there an actual version in there? Maybe right? Can't find it.
Zip file says April 17 too, guess that is strange...
Wow, did windiff on the directories and they are identical.
And now, the old one works with the new FlexProp too.
Guess I need some sleep or something...
Maybe reverted to some old FlexProp while investigating something and didn't switch back.
Certainly try all of the softwares I added LCD support to and tell me if they still work (I think that's now the 3 emulators and the tempest port? For the latter you want the video branch IIRC? Check which ones more recent)
Was about to say that Misoyume has a problem compiling.
With latest code and compiler.
But, forgot that need to adjust my Build_N_Run.bat file to match your build.sh file.
Seems some of the settings there changed...
Yeah I think I checked the preconfigured ones you have on your website and the misoyume was ancient. Beta 02 I think. There've been big strides in compatibility after that. Then I forgot to bother you about it.
Hmm. Misoyume gives me a black screen after selection ROM and the message after that...
Guess should see if VGA mode works...
Is that a ROM that previously worked?
Some of them do legitimately just get stuck on black screen due to SPC700-related race conditions that I haven't been able to fix yet. (Due to DMA speed issue that needs to be fixed first)
Think so. I have a few other versions of this to try.
This one also gives black screen with VGA.
But, I do recall that uSD files get corrupted with all the testing I do, so may need to refresh them...
Just noticed that USE_PSRAM_SLOW was defined.
Works after turning that off...
Works with LCD6 too (of course)
NeoYume was easier.
It just worked...
Where is Tempest? Don't see it in GitHub....
https://github.com/Wuerfel21/tempest2k/tree/video-nextgen
Is not in the irqsoft repo because it's technically kinda bootleggy
Oh wow, this looks kind of complicated to try... I have to build something with WSL? Hopefully, I've done this already and have it somewhere....
Ok, found some executables, but they are unlikely work with LCD6...
You don't have to, I am just unconfident that it works with MinGW/MSYS et al. It's easier to just say "use Linux of some sort" because that will figure itself out.
@Wuerfel_21 Found the actual source of my troubles yesterday... Seems the SWaP carrier board that was first being tested on had a 9DOF mems chip connected via QWIIC cable with pins that happen to overlap with HyperRam.
Normally, this wouldn't be an issue, but this particular sensor happens to be rigged for serial output, meaning pin contention...
All sorted out now...
@Wuerfel_21 How does 2 player work? Supposing have USB hub with two USB controllers plugged in, how does it know who is player 1 and who is player 2?
Based on the port number. Most hubs don't have any markings for port order, so you just need to try it out.
Operational notice
Seeing as GitHub has kind of deteriorated over time (notice how slow it is and how they keep trying to advertise Copilot?) and appears to be in imminent danger of further enshittification, I'm trying to find secondary hosts for my Git repos, starting with all of our favorite P2 emulators.
It seems GitLab is also deteriorating, so I'm trying SourceHut now.
The project page is at: https://sr.ht/~wuerfel_21/p2-dreamy-emulators/ and the individual repos are at https://git.sr.ht/~wuerfel_21/MegaYume , https://git.sr.ht/~wuerfel_21/NeoYume and https://git.sr.ht/~wuerfel_21/MisoYume
The GitHub pages remain available for now with identical contents between both. Currently SourceHut doesn't render my READMEs because it doesn't detect uppercase .MD extensions, so keep that in mind.
@Wuerfel_21 was just thinking back to the great debate over 16 regular cogs for P2 vs 8 super cogs. 8 won of course.
But, was just wondering which would have been better in this space…
Assuming smartpins the same and hubexec and hub access the same or perhaps with hub bandwidth halved.
Maybe 16 would have been easier?
16 would've certainly be a lot, but if they'd have been weaker there'd have to be a lot more splitting of tasks into multiple cogs. E.g. if the MUL instruction wasn't there, that would've been sour.
The current P2 design can be parametrized for 16 cogs, but then you get double the hub latency. No way around that with the deterministic time-slices. I think most P2 programs that are slow are slow because of overreliance on high-latency RDLONG etc for memory access.
What could have been done is to take 2 cogs and pair them together. Since each instruction takes two cycles, I think there end up being a lot of circuits that are idle 50% of the time, so they could be shared. Or alternatively, pair 4 P1 style 4-cycle CPUs. In that case the cog RAMs are single-ported still, but need some kind of fat crossbar for entering into the 4-way shared ALU. Not that I know much about that sort of thing.
IMO the main missing things:
- TMDS pixel repetition
- Nibble reverse instruction
- lower-latency 32 bit multiply (i.e. better to be a macro instruction like MULPIX than to stall 50+ cycles on a CORDIC op. Especially relevant to compilers)
- SCAS without shifting right (or possibly some version of ARM's SMUAD dot-product-ish instruction)
- WRLONG and such should probably be buffered to hide latency? (can approximate this with WRFAST + WFLONG, but resets FIFO in the process)
MUL is key to a lot of things, remember pushing hard for that...
I think I finally started work in earnest on trying to fix the issues in MisoYume where the CPU can fall behind the video signal, so I can start posting about it. This issue usually manifests in flashing lines at the top of the screen and glitchy raster effects (also called "time crust" by me)
Super Metroid w/ 4-bit PSRAM is very affected by time crust
The main problem currently is DMA transfers, which really have 2 compounding problems that make them run far too slow:
rk_read8function each time, so memory region decoding has to happen individually for each byte.rk_read8ROM->VRAM transfers end up using the small (6..8 byte) random access cache, which results in more PSRAM traffic than is really needed.So I'm rewriting that whole DMA mess to work in larger blocks, which reduces the inner loop timing and also allows smart pre-fetching of the necessary ROM data.
One thing that seems apparent is that bumping up the data cache size (
PSRAM_CACHESIZE) by one notch for 8 and 16 bit memory is a good idea.(I'm going mad with the tables recently)
The alignment is important here. If the address is worst case aligned (LSBs all ones) you might only get 5 contiguous bytes out of 8 bytes fetched from PSRAM16 (4-aligned). (that was infact the original intent - a HDMA channel might consume up to 5 contiguous bytes from its list data)
Fetching 8 bytes on 8bit is of course always faster than 6 on 4bit.
There's a point where the extra overhead for purely random access overwhelms the benefit of optimizing sequential access (especially when the DMA rewrite is done and moves a lot of sequential access off that path). But 4/6 extra cycles (fast/slow modes) seem worth it (in the sense of making code run faster).
And in the end I am fairly confident even PSRAM4 is going to make a decent showing.
@Wuerfel_21 Is there still a list of supported/running ROMs from MegaYume somewhere?
Thought there might be something in the code, but don't see it...
MegaYume has actually OK compatibility, so just assume it runs unless it doesn't.
Totally borked ROMs I am aware of:
There's a few more that have minor bugs.
Of course the README has a few nice freebies linked that (obviously) work. Certainly grab Cave Story MD! (you probably(?) want
doukutsu-en.gen) Though that got an update recently, so I haven't tested the new version.Behold! The crust has been vanquished! This is still sysclk/3 4-bit PSRAM. Yet, no glitches.
All thanks to just locking in and spending ~2 days staring at the DMA nonsense.
Currently only on dev branch, still need to test for regressions tomorrow.
Big code diff
Games that seem to have a lot less glitches of that sort (some of it is just natural/"intended"):