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