@Wuerfel_21 said:
Ah, I see, that's what's going on with the USB connector. They designed it to plug into the Pi Zero. Yeah that's just doing OTG, which should work passively if you're just trying to be a host. I think an actual OTG device needs that extra 5th pin to do something to switch into host mode, but we just assume we're a host (and I think the Pi Zero does, too? I don't think it can do device mode?) So trying it with the Serial Device accessory is fine if you can manage that.
You're saying this USB connector doesn't have GND and VBUS connected to anything? That'd be odd.
Yeah they both float, only D-/D+ pass through the flex cable to the card edge fingers. I guess the controller doesn't really need ground and VBUS because it's supplied internally and grounded separately. 5V already directly powers the Pi from the Case 2W Lipo boost converter, so there's really no need to feed 5V back via VBUS into the controller with the Pi acting as a host..even though normally the Pi would want to power the device being plugged into its OTG port.
The fifth ID pin thing I believe is just a way to identify which end of the OTG cable A or B is plugged into the port so it knows what to default to at startup, although there are more advanced protocols nowadays that can control a lot of that. I am hoping this USB controller is kinda dumb and not too smart for it's own good so it will interwork with your driver. https://en.wikipedia.org/wiki/USB_On-The-Go
Don't want to put the cart before the horse but if initial testing works out we might be able to make a 64MB PSRAM P2 board that fits neatly inside the cartridge...and could look a bit like this. Maybe HDMI out is an option as well (micro or mini socket). Or if we can figure out USB-C alternate modes we could dual purpose that instead for carrying HDMI and/or a PropPlug input path via USB.
UPDATE: we could do something like this perhaps...
P0 - uSD card power reset/detect pin?
P1 - PSRAMCS1
P2 - PSRAMCS2
P3 - PSRAMCLK1
P4 - PSRAMCLK2
P5 - LCD VSYNC
P6 - LCD HSYNC
P7 - LCD DE
P8,9 - USB D-/D+
P10-15 - BLUE
P16,17 - PWM1, PWM2
P18-23 - GREEN
P24,25 - POWERON, !POWERDOWN
P26-P31 - RED
P32-P39 - HDMI
P40-P55 - PSRAM DATA
P56 - LCD PIXELCLK
P57 - independent uSD card DO pin or !CS to interfere less with boot Flash?
Looking good for USB. I just hooked up a janky connection to the handheld case via the Parallax serial device breakout on a P2-EVAL and a separate ground wire and loaded USBNEW's hidpad_to_vga.binary application. Am now seeing all front buttons (except the turbo "star" which I think only acts locally inside the controller to turbo press a nominated switch in-game), report binary 1 when pressed, also including the rear trigger switches and extra "home" switch on the front panel which can be used to jump out to a menu. The 4 way direction switch reports as a HAT with values from 00-07 or 0F depending on which direction(s) are actively pressed down on the 8 way switch. The USB PID/VID reports this as an XBOX360 controller.
This is great news so far. I didn't do a lot of experimenting with P2 resets and shutdowns etc, but so far so good and means really it's just the LCD that needs to work now for this to be a success. I do hope it's not flipped or something, then we might be screwed.
Tried feeding a P2 OPN2 cog demo audio output into the GPi Case 2W's GPIO19 pogo pin position (which should be one of the audio PWM channel inputs) with the unit switched on but couldn't hear anything with volume level slid fully up/down. Might be a couple of things. Perhaps the internal amp path is only turned on when active video is present, to avoid clicks/pops at startup, or perhaps P2 DAC line level outputs are no good and PWM logic levels are needed if filtered/processed internally. Harder to reach GPIO18, but that might also be it if it uses a mono amp only internally - I should retry this from the headphone outputs too. EDIT: no output on headphone socket L&R either.
Hmm, digitally buffering the PWM signal would be A Choice, certainly.
I think I can add PWM audio as an option (I think this just requires changing some values), but the quality will be really low, since each sample period is only a few thousand cycles (so 12 to 13 bit quality?). OPN2cog is special in that it actually runs comically high sample rates (so ~1/6th of normal sample period!), but only has 9 bits of effective output precision to begin with, so shrug.
But more likely the amp circuit just isn't enabled and needs to be started somehow.
Says 600 mA at 5V, but guess that's not enough. Or, being pulled under 5V so that USB doesn't work.
Think the solution here is to power the SWaP directly from lipo and use the boosted 5V only for USB.
Also, made a mistake with power switch. Was originally targeting a different module that needed a momentary switch, but this booster board needs an actual on-off switch that can handle the full current...
But, for now can just power using small power bank.
Main issue now is the uSD not working unless accessed first by FSRW.
Have to either mod Megayume and add some FSRW code, or come up with a menu program that can boot a binary file from uSD.
Seems will want a menu at some point anyway, so guess will go that way...
Need to look at either the @Wuerfel_21 teapot code or think there was a suggestion of using Megayume upper.
@Rayman said:
Says 600 mA at 5V, but guess that's not enough. Or, being pulled under 5V so that USB doesn't work.
That should be fine even if it's kinda thinning the soup. It appears the P2 EDGE running MegaYume + the 2" LCD together consume ~360mA at 5V. (no idea if the SWaP board is more or less efficient). Though if that USB controller consumes more than ~100mA you might start getting into problems. Though all the ones I've tried read as zero on the meter (again, cursed USB amp meter, maybe try this yourself - you probably want to not have > 500mA average current if you want the battery to actually last).
Think the solution here is to power the SWaP directly from lipo and use the boosted 5V only for USB.
I don't you're supposed to do that, the battery needs a protection thing on it?
@Rayman said:
But, for now can just power using small power bank.
Main issue now is the uSD not working unless accessed first by FSRW.
That should hopefully be fixable...
Have to either mod Megayume and add some FSRW code, or come up with a menu program that can boot a binary file from uSD.
Seems will want a menu at some point anyway, so guess will go that way...
Need to look at either the @Wuerfel_21 teapot code or think there was a suggestion of using Megayume upper.
Don't look at the teapot, that has nothing useful for this. Re-using the megayume menu code might be a bit trickier than I implied then, because to actually show anything it needs the whole VDP thing set up and running, which is a bit involved.
Maybe I should just make it myself, after all.
@rogloh said:
Don't want to put the cart before the horse but if initial testing works out we might be able to make a 64MB PSRAM P2 board that fits neatly inside the cartridge...and could look a bit like this. Maybe HDMI out is an option as well (micro or mini socket). Or if we can figure out USB-C alternate modes we could dual purpose that instead for carrying HDMI and/or a PropPlug input path via USB.
UPDATE: we could do something like this perhaps...
P0 - uSD card power reset/detect pin?
P1 - PSRAMCS1
P2 - PSRAMCS2
P3 - PSRAMCLK1
P4 - PSRAMCLK2
P5 - LCD VSYNC
P6 - LCD HSYNC
P7 - LCD DE
P8,9 - USB D-/D+
P10-15 - BLUE
P16,17 - PWM1, PWM2
P18-23 - GREEN
P24,25 - POWERON, !POWERDOWN
P26-P31 - RED
P32-P39 - HDMI
P40-P55 - PSRAM DATA
P56 - LCD PIXELCLK
P57 - independent uSD card DO pin or !CS to interfere less with boot Flash?
Oh, I didn't see this one before~
So, uh HDMI+LCD simultaneous isn't happening (hardware limit) and the code I have really is not designed to switch outputs at runtime (especially not from/to HDMI with its massive TERC encoder overlay).
Doing VGA+LCD could work, but that REALLY wants the LCD's HSYNC to be on P0.
For USB video, you really need DisplayPort signalling (the HDMI alt mode AFAIK only exists on paper), which is a whole other can of horrible worms. Apparently there used to be a DP encoder that'd have fit the bill (STDP4028) but of course useful parts get the axe. Maybe a tiny FPGA could that trick, but that'd require a bunch of severely annoying programming.
So in that light, maybe better idea to just do 4bit SD there.
Also, how do those soft power control pins work? I think this can be made to work nicely with very little code (though in for a bad time if you ever get a hang).
Second thought: Though if the 640x480 display used is anything like the ones I can find, the controllers are designed for somewhat higher resolutions, so shouldn't mind being clocked slightly too fast.
In that case you could include some TFP401-shaped device to drive the parallel interface from our HDMI output, which then just needs to be buffered somehow so it can go to two sinks. Didn't you already make a breakout for that chip, @rogloh ?
Comments
Yeah they both float, only D-/D+ pass through the flex cable to the card edge fingers. I guess the controller doesn't really need ground and VBUS because it's supplied internally and grounded separately. 5V already directly powers the Pi from the Case 2W Lipo boost converter, so there's really no need to feed 5V back via VBUS into the controller with the Pi acting as a host..even though normally the Pi would want to power the device being plugged into its OTG port.
The fifth ID pin thing I believe is just a way to identify which end of the OTG cable A or B is plugged into the port so it knows what to default to at startup, although there are more advanced protocols nowadays that can control a lot of that. I am hoping this USB controller is kinda dumb and not too smart for it's own good so it will interwork with your driver. https://en.wikipedia.org/wiki/USB_On-The-Go
Don't want to put the cart before the horse but if initial testing works out we might be able to make a 64MB PSRAM P2 board that fits neatly inside the cartridge...and could look a bit like this. Maybe HDMI out is an option as well (micro or mini socket). Or if we can figure out USB-C alternate modes we could dual purpose that instead for carrying HDMI and/or a PropPlug input path via USB.
UPDATE: we could do something like this perhaps...
P0 - uSD card power reset/detect pin?
P1 - PSRAMCS1
P2 - PSRAMCS2
P3 - PSRAMCLK1
P4 - PSRAMCLK2
P5 - LCD VSYNC
P6 - LCD HSYNC
P7 - LCD DE
P8,9 - USB D-/D+
P10-15 - BLUE
P16,17 - PWM1, PWM2
P18-23 - GREEN
P24,25 - POWERON, !POWERDOWN
P26-P31 - RED
P32-P39 - HDMI
P40-P55 - PSRAM DATA
P56 - LCD PIXELCLK
P57 - independent uSD card DO pin or !CS to interfere less with boot Flash?
Looking good for USB. I just hooked up a janky connection to the handheld case via the Parallax serial device breakout on a P2-EVAL and a separate ground wire and loaded USBNEW's hidpad_to_vga.binary application. Am now seeing all front buttons (except the turbo "star" which I think only acts locally inside the controller to turbo press a nominated switch in-game), report binary 1 when pressed, also including the rear trigger switches and extra "home" switch on the front panel which can be used to jump out to a menu. The 4 way direction switch reports as a HAT with values from 00-07 or 0F depending on which direction(s) are actively pressed down on the 8 way switch. The USB PID/VID reports this as an XBOX360 controller.
This is great news so far. I didn't do a lot of experimenting with P2 resets and shutdowns etc, but so far so good and means really it's just the LCD that needs to work now for this to be a success. I do hope it's not flipped or something, then we might be screwed.
Tried feeding a P2 OPN2 cog demo audio output into the GPi Case 2W's GPIO19 pogo pin position (which should be one of the audio PWM channel inputs) with the unit switched on but couldn't hear anything with volume level slid fully up/down. Might be a couple of things. Perhaps the internal amp path is only turned on when active video is present, to avoid clicks/pops at startup, or perhaps P2 DAC line level outputs are no good and PWM logic levels are needed if filtered/processed internally. Harder to reach GPIO18, but that might also be it if it uses a mono amp only internally - I should retry this from the headphone outputs too. EDIT: no output on headphone socket L&R either.
Hmm, digitally buffering the PWM signal would be A Choice, certainly.
I think I can add PWM audio as an option (I think this just requires changing some values), but the quality will be really low, since each sample period is only a few thousand cycles (so 12 to 13 bit quality?). OPN2cog is special in that it actually runs comically high sample rates (so ~1/6th of normal sample period!), but only has 9 bits of effective output precision to begin with, so shrug.
But more likely the amp circuit just isn't enabled and needs to be started somehow.
Wired up battery power using the Sparkfun booster, but seems it is not strong enough with Megayume and screen at full brightness:
https://www.sparkfun.com/lipower-boost-converter.html
Says 600 mA at 5V, but guess that's not enough. Or, being pulled under 5V so that USB doesn't work.
Think the solution here is to power the SWaP directly from lipo and use the boosted 5V only for USB.
Also, made a mistake with power switch. Was originally targeting a different module that needed a momentary switch, but this booster board needs an actual on-off switch that can handle the full current...
But, for now can just power using small power bank.
Main issue now is the uSD not working unless accessed first by FSRW.
Have to either mod Megayume and add some FSRW code, or come up with a menu program that can boot a binary file from uSD.
Seems will want a menu at some point anyway, so guess will go that way...
Need to look at either the @Wuerfel_21 teapot code or think there was a suggestion of using Megayume upper.
That should be fine even if it's kinda thinning the soup. It appears the P2 EDGE running MegaYume + the 2" LCD together consume ~360mA at 5V. (no idea if the SWaP board is more or less efficient). Though if that USB controller consumes more than ~100mA you might start getting into problems. Though all the ones I've tried read as zero on the meter (again, cursed USB amp meter, maybe try this yourself - you probably want to not have > 500mA average current if you want the battery to actually last).
I don't you're supposed to do that, the battery needs a protection thing on it?
That should hopefully be fixable...
Don't look at the teapot, that has nothing useful for this. Re-using the megayume menu code might be a bit trickier than I implied then, because to actually show anything it needs the whole VDP thing set up and running, which is a bit involved.
Maybe I should just make it myself, after all.
Oh, I didn't see this one before~
So, uh HDMI+LCD simultaneous isn't happening (hardware limit) and the code I have really is not designed to switch outputs at runtime (especially not from/to HDMI with its massive TERC encoder overlay).
Doing VGA+LCD could work, but that REALLY wants the LCD's HSYNC to be on P0.
For USB video, you really need DisplayPort signalling (the HDMI alt mode AFAIK only exists on paper), which is a whole other can of horrible worms. Apparently there used to be a DP encoder that'd have fit the bill (STDP4028) but of course useful parts get the axe. Maybe a tiny FPGA could that trick, but that'd require a bunch of severely annoying programming.
So in that light, maybe better idea to just do 4bit SD there.
Also, how do those soft power control pins work? I think this can be made to work nicely with very little code (though in for a bad time if you ever get a hang).
Second thought: Though if the 640x480 display used is anything like the ones I can find, the controllers are designed for somewhat higher resolutions, so shouldn't mind being clocked slightly too fast.
In that case you could include some TFP401-shaped device to drive the parallel interface from our HDMI output, which then just needs to be buffered somehow so it can go to two sinks. Didn't you already make a breakout for that chip, @rogloh ?