@Rayman said:
@Wuerfel_21 This is looking great.
Was about to test again but I see hyperram support was dropped.
Out of curiosity, why was that?
Just to keep it simple?
Is there an important difference in size or speed?
I think(tm) the HyperRAM has higher latency, which idk if that'd be an issue. (Also, getting 1 byte/cycle out of it is a bit tricker.) The actual issue is that 8MB is just waaay too small. The 32MB PSRAM isn't even enough for bigger games like Metal Slug 2.
Will the code run from the button addon instead of needing usb keyboard ? Not got the usb addon with me ... poop! (Have found 3 versions of the p2ec32mb board though!)
Today's morning (~5:00am @UTC-3) I was composing the following text when the eventuality of a delay-related issue was being discussed; I saved it for reference, and went to bed (sleep-urgeing demanded by brain/eyes). Perhaps it's still useful to post it...
There's also chance for at least a micro solder crack to affect one of the pads located at the perimeter (though it's soldered to one of the power planes, the center-line exposed pad isn't connected to the silicon die) , introduced during the thermal-cycling torture tests conducted by @VonSzarvas.
Since pik33's card appears to respond to the majority of the commands (that are issued at the beggining of each access cycle), I'll innitially would not blame none of the fast-signal-carrying lanes, but the long-steady-standing ones (/CE, VDD and VSS, that happens to be located just at three of the four corners) could have suffered from any thermal-cycling-induced mechanical distortion, aggravated by the extraction/insertion of the edge card into the test fixture, and the underlying cool-down.
The positioning of those tiny chips at the top of the pcb, put them exactly under the most-likely finger-contact line of pressure, during any push/pull movements.
Yep, just patched in direct pin input, can be enabled in config. The default configuration maps player 1 controls (missing D and select) to two button boards on basepins 0 and 8 in a slightly gank way.
@Yanomani said:
Today's morning (~5:00am @UTC-3) I was composing the following text when the eventuality of a delay-related issue was being discussed; I saved it for reference, and went to bed (sleep-urgeing demanded by brain/eyes). Perhaps it's still useful to post it...
There's also chance for at least a micro solder crack to affect one of the pads located at the perimeter (though it's soldered to one of the power planes, the center-line exposed pad isn't connected to the silicon die) , introduced during the thermal-cycling torture tests conducted by @VonSzarvas.
Since pik33's card appears to respond to the majority of the commands (that are issued at the beggining of each access cycle), I'll innitially would not blame none of the fast-signal-carrying lanes, but the long-steady-standing ones (/CE, VDD and VSS, that happens to be located just at three of the four corners) could have suffered from any thermal-cycling-induced mechanical distortion, aggravated by the extraction/insertion of the edge card into the test fixture, and the underlying cool-down.
The positioning of those tiny chips at the top of the pcb, put them exactly under the most-likely finger-contact line of pressure, during any push/pull movements.
Hope it helps...
I tested the PSRAM. This P2-EC also works with the P2Play, which keeps the framebuffer and audiobuffer in the PSRAM and also did all the blitting stuff to scroll the info window. The video test which uses 2 PSRAM video buffers and does a lot of things there also works. It crashes at 354 MHz and this is the P2 which crashes. One (random) of working cogs stops working after several seconds. The symptoms are: the small window and sprites stop moving, or the graphics in the window stops changing (this is another cog, or the graphics in the main window stops changing (yet another cog) while the rest of cogs, including the PSRAM driver, still work.
At 336 MHz however the test is full stable.
My PSRAM works fine with NeoYume I tested two REV A 32MB Edge boards and both were okay.
For reference I used VGA+audio @ P24-31 and USB @ P16-P23. I also modified config.spin2 to choose to output VGA ,not NTSC by default, and I used loadp2 to download NeoYume, not some SD boot. DIP switches 1-4 were set as On, On, Off, Off on both boards.
Was hoping my generic controller would work with NeoYume but it doesn't seem to respond. It was working before in the earlier test code macca was doing...maybe it needs a special PID and VID added, not sure.
The text is in Polish but a lot of pictures explain all, and you can still use a translator. This is a 3D printed box and 2 controllers for retro gaming using a RPi Zero, but I think it can be also modified to fit the Edge with necessary connectors. What is the most fun there, are these controllers.
I forked the project to my github
One thing I think I found with NeoYume is that the volume output level seems to potentially differ on each boot...not sure why. I took it from top of the GitHub tree this morning.
@rogloh said:
My PSRAM works fine with NeoYume I tested two REV A 32MB Edge boards and both were okay.
For reference I used VGA+audio @ P24-31 and USB @ P16-P23. I also modified config.spin2 to choose to output VGA ,not NTSC by default, and I used loadp2 to download NeoYume, not some SD boot. DIP switches 1-4 were set as On, On, Off, Off on both boards.
Yay! I guess I didn't merely dream of graphics afterall.
@rogloh said:
Was hoping my generic controller would work with NeoYume but it doesn't seem to respond. It was working before in the earlier test code macca was doing...maybe it needs a special PID and VID added, not sure.
EDIT: just hacked the USB code and got it to work...
Yeah, supporting any 'ol HID controller is a bit of a pickle. Even if you figure out the report format, you don't really know which button is which. As per the readme, there's two specific HID controllers that it does support with hardcoded PID/VID, as well as any XInput type controller. I guess if you send the details for yours I can add it upstream. Should probably use a script system instead of hardcoding every single one, idk.
@rogloh said:
One thing I think I found with NeoYume is that the volume output level seems to potentially differ on each boot...not sure why. I took it from top of the GitHub tree this morning.
Shouldn't be that way. If you've got it plugged into anything vaguely smart it might get confused by the DC offset click and AGC it down by varying amounts. Also, each game of course has a different overall loudness. There's an OVERDRIVE constant somewhere that lets you play with the total volume (1.0 ensures no clipping even if all channels are going full ham).
The text is in Polish but a lot of pictures explain all, and you can still use a translator. This is a 3D printed box and 2 controllers for retro gaming using a RPi Zero, but I think it can be also modified to fit the Edge with necessary connectors. What is the most fun there, are these controllers.
I forked the project to my github
Neat. Controller looks a bit painful though with the individual direction buttons (they show SF2 - how do you do a halfcircle on that without breaking your finger?). I guess 3D printing a proper pivoting pad is possible, but would need big brain to design properly. Interestingly, they use the 15pin port, one could wire that to be compatible with the NeoGeo pinout (which is also used by some other stuff), but they didn't do that.
@Wuerfel_21 said:
Yay! I guess I didn't merely dream of graphics afterall.
No it works okay. Pik must have a bad setup - you+him may need to check his build process is following yours, or share a common build.
Yeah, supporting any 'ol HID controller is a bit of a pickle. Even if you figure out the report format, you don't really know which button is which. As per the readme, there's two specific HID controllers that it does support with hardcoded PID/VID, as well as any XInput type controller. I guess if you send the details for yours I can add it upstream. Should probably use a script system instead of hardcoding every single one, idk.
My generic USB gamepad (PID=E401,VID=081F) seems to send using this 10 byte report data format:
XX YY dd dd dd Wd UV dd dd dd
where
XX and YY are the digital representations of an analog left/right or up/down stick value for the X and Y axes.
L=0x00 U=0x00
R=0xFF D=0xFF
Center = 0x7F
dd (are ignored byte/nibble values)
WUV nibbles are these in MSB:LSB order
W = Y:B:A:X button bits according to the picture I posted of the gamepad in the link above
V = 0:0:RightTrigger:LeftTrigger
U = 0:0:Start:Select
I actually hacked into the following code and overrode your neogeo joystick handler with my own stuff just to test it and this mapping worked nicely, keeping the same colours for the buttons:
@rogloh said:
One thing I think I found with NeoYume is that the volume output level seems to potentially differ on each boot...not sure why. I took it from top of the GitHub tree this morning.
Shouldn't be that way. If you've got it plugged into anything vaguely smart it might get confused by the DC offset click and AGC it down by varying amounts. Also, each game of course has a different overall loudness. There's an OVERDRIVE constant somewhere that lets you play with the total volume (1.0 ensures no clipping even if all channels are going full ham).
Yeah I'm now not 100% sure myself. I thought it dropped very low once between running NeoYume, might have been a poor analog connection or the noisy pot in my speaker amp. Seemed to come good again after this. I'll keep an ear out.
@Wuerfel_21 said:
Yay! I guess I didn't merely dream of graphics afterall.
No it works okay. Pik must have a bad setup - you+him may need to check his build process is following yours, or share a common build.
As said, I've already verified that his listings match mine, so unless the binary gets corrupted on the way into RAM, it should work.
Could it be that pik's P2 has a faulty RAM location or something like that? Though memory arbiter ends up in cog 0, which seems like it'd cause more obvious failures if it had a busted RAM.
You say all your edges are Rev A, maybe it really is a Rev B thing somehow. I guess we gotta wait on @VonSzarvas and his trove of edges for an answer.
I actually hacked into the following code and overrode your neogeo joystick handler with my own stuff just to test it and this mapping worked nicely, keeping the same colours for the buttons:
Kept the same colors? Kinda makes sense, though might be slightly confusing with something like samsho because it breaks the symmetry between AB and CD. Will think about it a little more.
I couldn't compile the sources without Flexprop .12, which I couldn't compile on my laptop without installing all the build tools. Will try again tomorrow when I have more time.
@VonSzarvas said:
I couldn't compile the sources without Flexprop .12, which I couldn't compile on my laptop without installing all the build tools. Will try again tomorrow when I have more time.
If you're in a pickle, you can just copy the libc.a from the current git commit into your .11 install.
(And no, I have no idea why I'm talking about pickles so much lately. I don't even like pickles.)
Unrelatedly, if anyone ever needs timely help with anything I've ever written, I am online on discord literally all day everyday (well, mostly, anywys)
@Wuerfel_21 said:
If you're in a pickle, you can just copy the libc.a from the current git commit into your .11 install.
That led to other errors, (error: different __fromfile strings for function getcwd, etc..)..
Anyway- Now I set up a debian box and could compile flexprop .12, plus the Neoyume. Great so far...
At the TV, the NEO.YUME screen appears, then "NO GAMES!"
I've copied in a couple of games following the directory instructions at your IRQsome git. Tried FAT32 and FAT for fun. (Yeah, seems like FAT32 is needed). Then tried renaming all to uppercase. Bore. And yeah, no change.
SD card has structure: NEOYUME\MSLUG\201-C1.bin (and a bunch more .bin files, total 9)
oh wait... does the .bin suffix also need to be uppercase ? Nah !
@Wuerfel_21 said:
If you're in a pickle, you can just copy the libc.a from the current git commit into your .11 install.
That led to other errors, (error: different __fromfile strings for function getcwd, etc..)..
Anyway- Now I set up a debian box and could compile flexprop .12, plus the Neoyume. Great so far...
At the TV, the NEO.YUME screen appears, then "NO GAMES!"
I've copied in a couple of games following the directory instructions at your IRQsome git. Tried FAT32 and FAT for fun. (Yeah, seems like FAT32 is needed). Then tried renaming all to uppercase. Bore. And yeah, no change.
SD card has structure: NEOYUME\MSLUG\201-C1.bin (and a bunch more .bin files, total 9)
oh wait... does the .bin suffix also need to be uppercase ? Nah !
Hmm, that's funny. Can you try listing the directory with flexprop's shell example (or MegaYume's file chooser would also work if that's easier for you). NO GAMES means it can't find the game directory (it only checks for the presence of a correctly named entry, it does not care if it actually contains any files (or if it even is a directory), so I guess you can try creating SAMSHO or CRSWORDS or TWINSPRI or whatever and see if it picks those up)
Maybe it's an issue with how linux handles 8.3 file names in its VFAT driver.
All filesystem operations should be case-insensitive, btw.
I had tried those other folder names, and moving them up a level/etc..
Maybe it's a linux thing. I've compiled the binary on debian with fresh git clones. There were a good bunch of warnings, but the lower binary got spat out, so copied that to Windows for flexprop to write-to-flash,
Hmm.. That's a timeout for today. Feels like I'm chasing rabbits, and I should probably wait for the windows binary of .12 to be released then try again if the issue might be file system or beta-version related.
ps. Megayume dir listing was fine last time I tried it. No idea how to use flexprop shell for listing things, so can't do that quickly now. BTW.. I tried using _BOOT_P2.BIX with the same issue, "NO GAMES", then flashed all the modules thinking the SD card couldn't both boot the firmware and run the game, but still "NO GAMES".. If I remove the SD card then boot, the "Directory error" msg pops up, as expected. Progress slow today, but we'll get there another day
Comments
I think(tm) the HyperRAM has higher latency, which idk if that'd be an issue. (Also, getting 1 byte/cycle out of it is a bit tricker.) The actual issue is that 8MB is just waaay too small. The 32MB PSRAM isn't even enough for bigger games like Metal Slug 2.
Audio pin did nothing. To move a video pin to 24 I have to find another breakout board. I should have another one here.
Edit: AV accessory on 24, nothing new
Will the code run from the button addon instead of needing usb keyboard ? Not got the usb addon with me ... poop! (Have found 3 versions of the p2ec32mb board though!)
Today's morning (~5:00am @UTC-3) I was composing the following text when the eventuality of a delay-related issue was being discussed; I saved it for reference, and went to bed (sleep-urgeing demanded by brain/eyes). Perhaps it's still useful to post it...
There's also chance for at least a micro solder crack to affect one of the pads located at the perimeter (though it's soldered to one of the power planes, the center-line exposed pad isn't connected to the silicon die) , introduced during the thermal-cycling torture tests conducted by @VonSzarvas.
Since pik33's card appears to respond to the majority of the commands (that are issued at the beggining of each access cycle), I'll innitially would not blame none of the fast-signal-carrying lanes, but the long-steady-standing ones (/CE, VDD and VSS, that happens to be located just at three of the four corners) could have suffered from any thermal-cycling-induced mechanical distortion, aggravated by the extraction/insertion of the edge card into the test fixture, and the underlying cool-down.
The positioning of those tiny chips at the top of the pcb, put them exactly under the most-likely finger-contact line of pressure, during any push/pull movements.
Hope it helps...
Nope, but I could rig that up real quick.
In the meantime, just uncomment the DIRECT_BOOT line in the config file. That'll cause it to skip the selection menu and boot directly into a game.
Yep, just patched in direct pin input, can be enabled in config. The default configuration maps player 1 controls (missing D and select) to two button boards on basepins 0 and 8 in a slightly gank way.
Gank is Good! Will go test the thing!
I tested the PSRAM. This P2-EC also works with the P2Play, which keeps the framebuffer and audiobuffer in the PSRAM and also did all the blitting stuff to scroll the info window. The video test which uses 2 PSRAM video buffers and does a lot of things there also works. It crashes at 354 MHz and this is the P2 which crashes. One (random) of working cogs stops working after several seconds. The symptoms are: the small window and sprites stop moving, or the graphics in the window stops changing (this is another cog, or the graphics in the main window stops changing (yet another cog) while the rest of cogs, including the PSRAM driver, still work.
At 336 MHz however the test is full stable.
The 354 MHz crash will be hubRAM corruption due to high workload raising the die temperature too far.
My PSRAM works fine with NeoYume
I tested two REV A 32MB Edge boards and both were okay.
For reference I used VGA+audio @ P24-31 and USB @ P16-P23. I also modified config.spin2 to choose to output VGA ,not NTSC by default, and I used loadp2 to download NeoYume, not some SD boot. DIP switches 1-4 were set as On, On, Off, Off on both boards.
Was hoping my generic controller would work with NeoYume but it doesn't seem to respond.
It was working before in the earlier test code macca was doing...maybe it needs a special PID and VID added, not sure.
https://forums.parallax.com/discussion/comment/1537819/#Comment_1537819
EDIT: just hacked the USB code and got it to work...
I found this a while ago: https://zw-robotics.pl/projekty/konsola-do-gier-retro-z-raspberry-pi
The text is in Polish but a lot of pictures explain all, and you can still use a translator. This is a 3D printed box and 2 controllers for retro gaming using a RPi Zero, but I think it can be also modified to fit the Edge with necessary connectors. What is the most fun there, are these controllers.
I forked the project to my github
One thing I think I found with NeoYume is that the volume output level seems to potentially differ on each boot...not sure why. I took it from top of the GitHub tree this morning.
Yay! I guess I didn't merely dream of graphics afterall.
Yeah, supporting any 'ol HID controller is a bit of a pickle. Even if you figure out the report format, you don't really know which button is which. As per the readme, there's two specific HID controllers that it does support with hardcoded PID/VID, as well as any XInput type controller. I guess if you send the details for yours I can add it upstream. Should probably use a script system instead of hardcoding every single one, idk.
Shouldn't be that way. If you've got it plugged into anything vaguely smart it might get confused by the DC offset click and AGC it down by varying amounts. Also, each game of course has a different overall loudness. There's an OVERDRIVE constant somewhere that lets you play with the total volume (1.0 ensures no clipping even if all channels are going full ham).
Neat. Controller looks a bit painful though with the individual direction buttons (they show SF2 - how do you do a halfcircle on that without breaking your finger?). I guess 3D printing a proper pivoting pad is possible, but would need big brain to design properly. Interestingly, they use the 15pin port, one could wire that to be compatible with the NeoGeo pinout (which is also used by some other stuff), but they didn't do that.
No it works okay. Pik must have a bad setup - you+him may need to check his build process is following yours, or share a common build.
My generic USB gamepad (PID=E401,VID=081F) seems to send using this 10 byte report data format:
XX YY dd dd dd Wd UV dd dd ddwhere
XX and YY are the digital representations of an analog left/right or up/down stick value for the X and Y axes.
L=0x00 U=0x00
R=0xFF D=0xFF
Center = 0x7F
dd (are ignored byte/nibble values)
WUV nibbles are these in MSB:LSB order
W = Y:B:A:X button bits according to the picture I posted of the gamepad in the link above
V = 0:0:RightTrigger:LeftTrigger
U = 0:0:Start:Select
I actually hacked into the following code and overrode your neogeo joystick handler with my own stuff just to test it and this mapping worked nicely, keeping the same colours for the buttons:
cmp htmp,##$E401_081F wz if_z jmp #.neogeo ' No good jmp #.data_out .neogeo 'rdword retval,ptrb[0] call #hat_to_rldu 'setnib pad_tmp,retval,#0 rdlong retval,ptrb[1] testb retval,#12 wc ' X bitc pad_tmp,#7 testb retval,#13 wc ' A bitc pad_tmp,#4 testb retval,#14 wc ' B bitc pad_tmp,#5 testb retval,#15 wc ' Y bitc pad_tmp,#6 testb retval,#20 wc ' Select bitc pad_tmp,#9 testb retval,#21 wc ' Start bitc pad_tmp,#8 ... hat_to_rldu rdbyte htmp, ptrb[0] cmp htmp,#$ff wz bitz pad_tmp, #3 cmp htmp,#0 wz bitz pad_tmp, #2 rdbyte htmp, ptrb[1] cmp htmp,#$ff wz bitz pad_tmp, #1 cmp htmp,#0 wz _ret_ bitz pad_tmp, #0Yeah I'm now not 100% sure myself. I thought it dropped very low once between running NeoYume, might have been a poor analog connection or the noisy pot in my speaker amp. Seemed to come good again after this. I'll keep an ear out.
As said, I've already verified that his listings match mine, so unless the binary gets corrupted on the way into RAM, it should work.
Could it be that pik's P2 has a faulty RAM location or something like that? Though memory arbiter ends up in cog 0, which seems like it'd cause more obvious failures if it had a busted RAM.
You say all your edges are Rev A, maybe it really is a Rev B thing somehow. I guess we gotta wait on @VonSzarvas and his trove of edges for an answer.
Kept the same colors? Kinda makes sense, though might be slightly confusing with something like samsho because it breaks the symmetry between AB and CD. Will think about it a little more.
I couldn't compile the sources without Flexprop .12, which I couldn't compile on my laptop without installing all the build tools. Will try again tomorrow when I have more time.
If you're in a pickle, you can just copy the
libc.afrom the current git commit into your .11 install.(And no, I have no idea why I'm talking about pickles so much lately. I don't even like pickles.)
Unrelatedly, if anyone ever needs timely help with anything I've ever written, I am online on discord literally all day everyday (well, mostly, anywys)
@Wuerfel_21 Any idea how critical the PSRAM speed is? Could it be half as fast and still work?
The PSRAM is for the game ROM, right? Are the reads usually just a few bytes at a time, or long strings?
That led to other errors, (error: different __fromfile strings for function getcwd, etc..)..
Anyway- Now I set up a debian box and could compile flexprop .12, plus the Neoyume. Great so far...
At the TV, the NEO.YUME screen appears, then "NO GAMES!"
I've copied in a couple of games following the directory instructions at your IRQsome git. Tried FAT32 and FAT for fun. (Yeah, seems like FAT32 is needed). Then tried renaming all to uppercase. Bore. And yeah, no change.
SD card has structure: NEOYUME\MSLUG\201-C1.bin (and a bunch more .bin files, total 9)
oh wait... does the .bin suffix also need to be uppercase ? Nah !
Hmm, that's funny. Can you try listing the directory with flexprop's shell example (or MegaYume's file chooser would also work if that's easier for you). NO GAMES means it can't find the game directory (it only checks for the presence of a correctly named entry, it does not care if it actually contains any files (or if it even is a directory), so I guess you can try creating SAMSHO or CRSWORDS or TWINSPRI or whatever and see if it picks those up)
Maybe it's an issue with how linux handles 8.3 file names in its VFAT driver.
All filesystem operations should be case-insensitive, btw.
I had tried those other folder names, and moving them up a level/etc..
Maybe it's a linux thing. I've compiled the binary on debian with fresh git clones. There were a good bunch of warnings, but the lower binary got spat out, so copied that to Windows for flexprop to write-to-flash,
Hmm.. That's a timeout for today. Feels like I'm chasing rabbits, and I should probably wait for the windows binary of .12 to be released then try again if the issue might be file system or beta-version related.
ps. Megayume dir listing was fine last time I tried it. No idea how to use flexprop shell for listing things, so can't do that quickly now. BTW.. I tried using _BOOT_P2.BIX with the same issue, "NO GAMES", then flashed all the modules thinking the SD card couldn't both boot the firmware and run the game, but still "NO GAMES".. If I remove the SD card then boot, the "Directory error" msg pops up, as expected. Progress slow today, but we'll get there another day
No, I meant (ab)using it to see what the directories on the card are actually called.
EDIT: Wait, there was a change to the SD code in flexspin just now, maybe that's just busted.
Yep, flexsplorp alert
Jeepers!
Welp, bothered eric about it.
I guess the solution for the meantime is to build from commit 1571a11b9f997067700be544c307aa1ca42276a0
Ok, issue debugged, Eric splorped the codegen and that causes
strcasecmpto never return a match. (The files actually enumerate just fine)“Splorped the codegen”?
Actually… nevermind. That word suddenly makes a disturbing amount of sense. 🤣
to splorp
verb
1. to mess up smth. in an unexpected way
flexsplorp
noun
1. an issue with the FlexSpin compiler suite by Total Spectrum Software
THIS is why I hang around this place! 🤣