I'm currently working on a USB mass storage demo that's getting close to a drop, and after that hub.
It's really good to hear that you also have hub plans in the future garryj, that will be extremely useful for P2 in addition to all your USB work in general. Great stuff.
I'm currently working on a USB mass storage demo that's getting close to a drop, and after that hub.
It's really good to hear that you also have hub plans in the future garryj, that will be extremely useful for P2 in addition to all your USB work in general. Great stuff.
From the paltry amount of reading I've done regarding hubs, from a signalling standpoint, it looks like full-speed devices should be fairly straight-forward. Low-speed may be more of a challenge, as in a full/low speed mixed environment all upstream hub<->host signalling is at full-speed, and packet send/receive to/from a low-speed device is done at low-speed bit timing. I looks like a 12Mbs<->1.5Mbs bitclock transition would be less than 10 P2 clocks, but I haven't done any physical testing on how that transition affects theUSB signaling.
To no one in particular, in my specific use case (admittedly, an odd/rare one), the four USB jacks for the keyboards can be connected separately to the P2 without a hub, but I fear that would make it even more likely that more cogs were needed. So, I guess the keyboards could go through a hub as an intermediary providing that they could be uniquely identified. However, such identification might not be possible. Anyone know if there is anything in the HID packets that would allow differentiating which device/keyboard (not simply which kind of device) was sending the data?
As for possible P2 pin usage for analog VGA for the four screens, I'm considering using P0-P3, P8-P11, P16-P19 and P24-P27 as the DAC groups. In other words, Screen 0 would use P0-P3 for RGB & H, Screen 1 would use P8-P11 for RGB & H, and so on. Does that seem okay with the way that the DAC's can be assigned? If so, I'd probably use P4, P12, P20 and P28 as the Vsync pins for Screens 0-3, respectively. I'm trying to stay away from Port B to keep it as free as possible for other things (and obviously, the high-numbered pins are spoken for already).
I'm also wondering whether to put Hsync first or last for each of the groups of pins above. For example, for the group of pins P0-P3 that would be assigned to one cog's DAC (say for Screen 0), I wonder if it's best to put Hsync on P0 or P3. I assume that it could go either way (or to any of those four pins, for that matter). But I'd like to put it on P3 to get it next to P4 with the Vsync signal. But I'd also like to follow the convention, if any, that others are using (or will likely use), where possible.
Similarly, what's the preference for the color channel order? Is it more likely for people to use the DAC's in the order of RGB or BGR? I'd prefer to go in the order of RGB, assuming that it's not swimming against the current. For example, I'd like to assign the RGBHV signals to P0-P4, respectively, with P4 being a non-DAC pin. How does that sound? Now, if it were the case that Vsync was also being handled by a DAC, then I might go with a VHRGB order for P0-P4 (with the pair of sync signals coming first instead of last), but Vsync will be handled separately.
As for using the P2D2 module, I think it would be best for me to use it inverted as Peter plans to use it and with female headers on the component side. Among other things, this arrangement allows the backside of the P2D2 board to face upwards once plugged into a carrier, leaving more room for a heat sink and letting the heat rise upwards unimpeded.
As for possible P2 pin usage for analog VGA for the four screens, I'm considering using P0-P3, P8-P11, P16-P19 and P24-P27 as the DAC groups. In other words, Screen 0 would use P0-P3 for RGB & H, Screen 1 would use P8-P11 for RGB & H, and so on. Does that seem okay with the way that the DAC's can be assigned?
Looks okay to me from what I understand of the DACs.
I'm also wondering whether to put Hsync first or last for each of the groups of pins above. For example, for the group of pins P0-P3 that would be assigned to one cog's DAC (say for Screen 0), I wonder if it's best to put Hsync on P0 or P3. I assume that it could go either way (or to any of those four pins, for that matter). But I'd like to put it on P3 to get it next to P4 with the Vsync signal. But I'd also like to follow the convention, if any, that others are using (or will likely use), where possible.
Similarly, what's the preference for the color channel order? Is it more likely for people to use the DAC's in the order of RGB or BGR? I'd prefer to go in the order of RGB, assuming that it's not swimming against the current. For example, I'd like to assign the RGBHV signals to P0-P4, respectively, with P4 being a non-DAC pin. How does that sound? Now, if it were the case that Vsync was also being handled by a DAC, then I might go with a VHRGB order for P0-P4 (with the pair of sync signals coming first instead of last), but Vsync will be handled separately.
I think you should go HSYNC, B, G, R (in the low to high pin sequence in a 4 bit group) to match the native streamer order. VSYNC is sort of separate, and you might be able to skip it depending on your monitor's capability to handle a combined sync on HSYNC. If you want to keep things in a nice sequence and together you could have the pins assigned like this...
Thanks, rogloh! Very interesting! And thanks for mentioning the possibility of bumping things up four pins to be able to bring Vsync down and next to Hsync.
Could someone comment further on how HBGR better matches "the native streamer order"? Would byte shifting be required to do it the way I originally proposed? And if the colors are being reassigned using the LUT's in the cogs, would such shifting still come in to play? I'll go take a look at the docs, but thought I'd post first.
Again, rogloh, thanks a bunch! Even if there are no streamer or hardware reasons to change the order, I think I like your way better. Although, if there were no advantages code/time-wise, I don't know if I'd go VHBGR or VHRGB. But it sounds like you're saying that there is a difference with respect to the streamer.
To no one in particular, in my specific use case (admittedly, an odd/rare one), the four USB jacks for the keyboards can be connected separately to the P2 without a hub, but I fear that would make it even more likely that more cogs were needed. So, I guess the keyboards could go through a hub as an intermediary providing that they could be uniquely identified. However, such identification might not be possible. Anyone know if there is anything in the HID packets that would allow differentiating which device/keyboard (not simply which kind of device) was sending the data?
Yes, the USB standard requires each device to enumerate with a unique address with 127 addresses available. All transfers from the keyboards would be controlled by address. The USB driver would need to make this information available to the input processing routine.
Much thanks, rogloh! Thanks for excising that very specific pic from docs. Now, I "just" need to study the docs to see if those particular assignments are [1] arbitrary, [2] conventional or [3] required. Perhaps that particular order matches the way the color channels tend to be stored in memory. But even if so, I need to study up on the streaming path(s).
Thanks, AJL! That's great information. I've read that devices needed to be enumerated before, but wasn't sure if they'd get enumerated the same way each time. Maybe it depends on the order in which they get attached. I guess high-level code could take care of associating the keyboards with players, such as by having a player type something at the very beginning. But even with such addresses, perhaps USB drivers don't usually pass the addresses up to the application, just the keys strokes. So, like you said, the USB driver handling the keyboards for the game console would need to do that. I used to do something similar with PS/2 keyboards when they were handled by a separate slave Propeller on an old version of the console. The slave would send the keystroke and a unique keyboard identifier (0..3) as a pair of values over a serial link.
Actually its probably more of a color space converter thing rather than streamer itself - I think I mentioned the wrong terminology there which may confuse. I'd expect the RGB order can be altered in raw VGA mode without issues, as they look equivalent, however the sync generation on the lower DAC channel looks to be computed differently and probably needs to remain on DAC0. It might be good to pick something that is going to be consistent with the future HDMI order, so code can work with both output types. Also the documentation mentions this..
"It is intended that DAC3/DAC2/DAC1 serve as R/G/B channels. "
Thanks for that follow-up info, rogloh. I'll take that into consideration as I study the docs. Also, if indeed Hsync needs to be on DAC0, then that's extremely critical information. At any rate, what you said about trying to be consistent with potential HDMI usage makes sense. The console's current driver boards don't support it, but there are some available that do (even using the same video chip, I believe). Thanks for the guidance/suggestions.
By the way, with regard to terminology, it looks like I should be saying "DAC channel" (or DAC output channel?) instead of "DAC's" when specifically referring to the DAC functionality of a cog, since all 64 pins have an 8-bit DAC each (disregarding resistance).
Comments
It's really good to hear that you also have hub plans in the future garryj, that will be extremely useful for P2 in addition to all your USB work in general. Great stuff.
I agree!
I'm also wondering whether to put Hsync first or last for each of the groups of pins above. For example, for the group of pins P0-P3 that would be assigned to one cog's DAC (say for Screen 0), I wonder if it's best to put Hsync on P0 or P3. I assume that it could go either way (or to any of those four pins, for that matter). But I'd like to put it on P3 to get it next to P4 with the Vsync signal. But I'd also like to follow the convention, if any, that others are using (or will likely use), where possible.
Similarly, what's the preference for the color channel order? Is it more likely for people to use the DAC's in the order of RGB or BGR? I'd prefer to go in the order of RGB, assuming that it's not swimming against the current. For example, I'd like to assign the RGBHV signals to P0-P4, respectively, with P4 being a non-DAC pin. How does that sound? Now, if it were the case that Vsync was also being handled by a DAC, then I might go with a VHRGB order for P0-P4 (with the pair of sync signals coming first instead of last), but Vsync will be handled separately.
Looks okay to me from what I understand of the DACs.
I think you should go HSYNC, B, G, R (in the low to high pin sequence in a 4 bit group) to match the native streamer order. VSYNC is sort of separate, and you might be able to skip it depending on your monitor's capability to handle a combined sync on HSYNC. If you want to keep things in a nice sequence and together you could have the pins assigned like this...
P0
P1
P2
P3 -VSYNC
P4 -HSYNC (or combined HVSYNC)
P5 -B
P6 -G
P7 -R
(repeat for other groups)
Could someone comment further on how HBGR better matches "the native streamer order"? Would byte shifting be required to do it the way I originally proposed? And if the colors are being reassigned using the LUT's in the cogs, would such shifting still come in to play? I'll go take a look at the docs, but thought I'd post first.
Again, rogloh, thanks a bunch! Even if there are no streamer or hardware reasons to change the order, I think I like your way better. Although, if there were no advantages code/time-wise, I don't know if I'd go VHBGR or VHRGB. But it sounds like you're saying that there is a difference with respect to the streamer.
Yes, the USB standard requires each device to enumerate with a unique address with 127 addresses available. All transfers from the keyboards would be controlled by address. The USB driver would need to make this information available to the input processing routine.
"It is intended that DAC3/DAC2/DAC1 serve as R/G/B channels. "