@Wuerfel_21 Is slow mode (sysclock/3) with 16-bit bus good enough for all NeoGeo and Megadrive games? I think so, even with 8-bit bus, like the 96 MB board. Just checking...
Thinking about add on board that adds PSRAM, USB, audio, and VGA... Memory might be slow though...
@Rayman said:
@Wuerfel_21 Is slow mode (sysclock/3) with 16-bit bus good enough for all NeoGeo and Megadrive games? I think so, even with 8-bit bus, like the 96 MB board. Just checking...
Thinking about add on board that adds PSRAM, USB, audio, and VGA... Memory might be slow though...
Yes, 8bit/slow and 4bit/fast are just enough for the emulators. Might have more slowdown than there really needs to be. 16bit/slow should be pretty okay.
@Rayman said:
Appears that psram_delay_test only goes to 14, gives error when try to change to 16...
That's probably because it's a 4 bit field containing the clock delay and the half step as its lsb, encoded in a nibble for tighter code. I recall I had also offset it by a small constant somewhere in some attempt to expand its range. This is one of the reasons it doesn't line up with other people's delay values like Wuerfel_21's or evanh's.
I do feel the structures need a lot more opening up in terms of rounding the number of bits for each field up to next power of two. So where there is say 3-bit and 5-bit fields, they should be 4-bit and 8-bit respectively. And where there is multiple 1-bit and 2-bit fields, they should group into 4-bit lots so that 4-bit fields align to 4-bit boundaries and 8-bit fields align to 8-bit boundaries and so on.
@evanh said:
I do feel the structures need a lot more opening up in terms of rounding the number of bits for each field up to next power of two. So where there is say 3-bit and 5-bit fields, they should be 4-bit and 8-bit respectively. And where there is multiple 1-bit and 2-bit fields, they should group into 4-bit lots so that 4-bit fields align to 4-bit boundaries and 8-bit fields align to 8-bit boundaries and so on.
In theory yes and I also try to follow this too, in practice when you have to find another spare long in the code to make your PASM fit or speed it up by removing an instruction you may need to look for gains that require some tighter optimization/packing of data structures. Not ideal but sometimes necessary. Eg, if you need another bit of state to enable/disable some feature but it would take another long to store (or to access it), you may want to fit it into an existing long already present, in a spare bit position (wherever that may fall).
The act of pulling parameters from the structures can consume more instructions when not aligned in clean manner. And at 32 bits each, even one extra decoding instruction more than negates any advantage you get from packing tighter.
Just tested with #define USE_PSRAM_SLOW
Seems to work with delay of 14, 15, or 16.
But, seems that syncs have to be off for all. Maybe sync mode only works in non-slow mode?
Here's an idea for an expansion board that would have all needed for gaming.
One USB would just be to provide power to VGA-to-HDMI adapter.
Second USB could be real and use the pins that would otherwise be chip select for under board RAM. Bit of a conflict with onboard RAM there, might need solder jumpers or something...
Would provide 32 MB that could be used with or without the 64 MB under board RAM.
@Rayman said:
Just tested with #define USE_PSRAM_SLOW
Seems to work with delay of 14, 15, or 16.
But, seems that syncs have to be off for all. Maybe sync mode only works in non-slow mode?
The optional "SYNC" inline flip-flips literally add more latency to the system. This in turn requires a larger "DELAY" to compensate. And since your delay parameter has run out of range it makes sense that you can't use the sync options.
@Rayman said:
Would provide 32 MB that could be used with or without the 64 MB under board RAM.
What would be the exact pin mapping for all of this? I'm unsure you have sufficient total pins for all of these features if combined together.
A single USB sort of wants 4 P2 IO pins, for its repository, power control and D+,D- signals. VGA wants another 5 and stereo audio 2, and a third PSRAM bank needs at least one more chip select pin if you share existing clocks from the main PSRAM. When I checked, it looked like you only have 8 free pins on your connector, using P24-P51, after 16 pins were used for data and another 4 control pins were used for your main board PSRAM.
@rogloh Yeah, this could work but would require special treatment and a lot of explanation...
Now thinking SimpleP2++ is better idea. Gives functional equivalent of Eval VGA, audio, and USB accessories (except microphone).
But, microphone can be this: https://www.sparkfun.com/products/12758
Thinking the regular board in top post can’t really compete with $75 Eval board.
But, this ++ version might be interesting to people, assuming it all works.
Heard some complaints about the cost involved with all the accessories to do some stuff.
This might make some applications a lot more economical...
@Rayman said:
MegaYume starts and can run Sonic for about 10 seconds then dies with some interesting error messages.
If they're interesting, post them There's no runtime error handling in MegaYume and the Sonic games to my knowledge don't have exception handlers, so I really do want to see them.
Checking by weight is interesting idea. I can do that Tuesday.
Trying my luck with Gold Pheonix next. Ordered the "Gamer" variant in 2 oz.
Ordered all three variants with 1 oz via the Pool (cause it's cheap).
Want to see what 1 oz from them does compared to 2 oz.
Could be 1 oz from them will work for NeoYume.
Might be that I'll only make the Gamer variant in 2 oz., no matter the result. We'll see...
The new variant is the "robot" one that I want to upgrade my robots with...
Has two banks of 4 servo headers. Default is to use the power from the extra barrel connector.
But, also possible to use the other barrel connector via solder jumper.
Also possible to power P2 and servos by same barrel if the top three way solder jumper is shorted on both sides.
Each bank can also be powered by 5V, in case doing something besides servos.
Put in a vertical USB connector so doesn't hang of edge. Moved the audio connector away from edge a bit.
Added 3pin headers for Ping, MIC, and RGB lights (sharing P7).
Also added a Quiic connector that normally shares P0 and P1. But, can be jumpered to use header instead where you can run wires to some other pins...
After making a bunch of boards that wouldn't run NeoYume, finally got a couple that do.
It appears that the amount of solder paste on the P2 ground pad makes a difference.
None of about 5 boards made using a 4.7 mil thick stencil worked.
But, I'm 3.5 out of 4 with a 7.0 mil stencil. (.5 is because one board strangely works in PSRAM8 mode, but not PSRAM16).
The 7.0 mil stencil also seems to have a slightly larger opening than the 4.7 mil stencil.
If it holds, would be really great. Was disappointing when the 2oz/4layer boards didn't work.
But, having the 1oz/4layer boards working with NeoYume is even better.
May try preloading the P2 ground pad vias with solder paste to maximize paste there.
Also thinking about getting a thicker stencil, maybe 10 mil.
Do know that if there's too much paste then the P2 chip lifts up, that was a fail...
Preloading the P2 ground pad vias with solder paste with the thick stencil turned out to be a bad idea.
First one had the P2 slide about .4 mm, so pins were almost in between pads.
Seems it can slide more easily when there's too much paste under the ground pad.
Also the P2 pins seemed to be raised a hair above the pads, for same reason.
Second one like this works (i.e., plays NeoYume) though.
Now looking like important difference between stencils was not thickness but paste for the MAX4411 Audio Amp.
Board from thick stencil was doing NeoYume just fine without audio amp. But, once I added MAX4411 by hand, NeoYume won't run anymore.
This is a real puzzle. It can run MegaYume with the audio amp installed but not NeoYume.
Probably some noise issue cause by the DC-DC converter that the MAX4411 uses, I guess.
Doesn't make any sense yet...
See if the shutdown of the amp improves things. Maybe just the extra power draw or added noise it puts onto a supply affects it, or some important P2 signal is shorted to one of the amp connections?
Comments
@Wuerfel_21 Is slow mode (sysclock/3) with 16-bit bus good enough for all NeoGeo and Megadrive games? I think so, even with 8-bit bus, like the 96 MB board. Just checking...
Thinking about add on board that adds PSRAM, USB, audio, and VGA... Memory might be slow though...
Yes, 8bit/slow and 4bit/fast are just enough for the emulators. Might have more slowdown than there really needs to be. 16bit/slow should be pretty okay.
That's probably because it's a 4 bit field containing the clock delay and the half step as its lsb, encoded in a nibble for tighter code. I recall I had also offset it by a small constant somewhere in some attempt to expand its range. This is one of the reasons it doesn't line up with other people's delay values like Wuerfel_21's or evanh's.
I do feel the structures need a lot more opening up in terms of rounding the number of bits for each field up to next power of two. So where there is say 3-bit and 5-bit fields, they should be 4-bit and 8-bit respectively. And where there is multiple 1-bit and 2-bit fields, they should group into 4-bit lots so that 4-bit fields align to 4-bit boundaries and 8-bit fields align to 8-bit boundaries and so on.
In theory yes and I also try to follow this too, in practice when you have to find another spare long in the code to make your PASM fit or speed it up by removing an instruction you may need to look for gains that require some tighter optimization/packing of data structures. Not ideal but sometimes necessary. Eg, if you need another bit of state to enable/disable some feature but it would take another long to store (or to access it), you may want to fit it into an existing long already present, in a spare bit position (wherever that may fall).
The act of pulling parameters from the structures can consume more instructions when not aligned in clean manner. And at 32 bits each, even one extra decoding instruction more than negates any advantage you get from packing tighter.
Just tested with #define USE_PSRAM_SLOW
Seems to work with delay of 14, 15, or 16.
But, seems that syncs have to be off for all. Maybe sync mode only works in non-slow mode?
Think I'll declare victory and post Eagle sources to top post now.
Here's an idea for an expansion board that would have all needed for gaming.
One USB would just be to provide power to VGA-to-HDMI adapter.
Second USB could be real and use the pins that would otherwise be chip select for under board RAM. Bit of a conflict with onboard RAM there, might need solder jumpers or something...
Would provide 32 MB that could be used with or without the 64 MB under board RAM.
Thinking don’t need the ESD chips for USB…
P2 io pins are very tough
The optional "SYNC" inline flip-flips literally add more latency to the system. This in turn requires a larger "DELAY" to compensate. And since your delay parameter has run out of range it makes sense that you can't use the sync options.
What would be the exact pin mapping for all of this? I'm unsure you have sufficient total pins for all of these features if combined together.
A single USB sort of wants 4 P2 IO pins, for its repository, power control and D+,D- signals. VGA wants another 5 and stereo audio 2, and a third PSRAM bank needs at least one more chip select pin if you share existing clocks from the main PSRAM. When I checked, it looked like you only have 8 free pins on your connector, using P24-P51, after 16 pins were used for data and another 4 control pins were used for your main board PSRAM.
@rogloh Yeah, this could work but would require special treatment and a lot of explanation...
Now thinking SimpleP2++ is better idea. Gives functional equivalent of Eval VGA, audio, and USB accessories (except microphone).
But, microphone can be this: https://www.sparkfun.com/products/12758
Thinking the regular board in top post can’t really compete with $75 Eval board.
But, this ++ version might be interesting to people, assuming it all works.
Heard some complaints about the cost involved with all the accessories to do some stuff.
This might make some applications a lot more economical...
Yea, built-in accessories is good.
But always someone requesting one more feature.
Meant to say “can’t compete”
Now fixed
Probably obvious typo
Ordered 25 boards from Seeed and they don't work as well as my US prototypes
MegaYume starts and can run Sonic for about 10 seconds then dies with some interesting error messages.
NeoYume doesn't even work.
Both work if I put an ice cube under the P2, but not exactly a nice solution.
Forced air isn't good enough.
Thinking need to switch from 1 oz to 2 oz copper...
If they're interesting, post them
There's no runtime error handling in MegaYume and the Sonic games to my knowledge don't have exception handlers, so I really do want to see them.
That's no good.
Did you try a heatsink with a small fan or just blow air over the plastic P2 package? You could try one of those cheap Pi heatsinks fwiw.
Were the US ones 2oz copper?
Do you still have bare boards you can compare by weight and maybe measure some track resistance, to check copper thickness ?
That means the Prop2 internally hit 110 °C and PLL would be self-limiting of sys-clock. https://forums.parallax.com/discussion/comment/1551043#Comment_1551043
EDIT: Maybe via plating is a factor too. Transporting the heat to the back side of the PCB is dependant on how good the heat travels down them.
I've wondered about the idea of using extra large vias under the thermal pad and then filling them with solder to provide better heat spreading.
Checking by weight is interesting idea. I can do that Tuesday.
Trying my luck with Gold Pheonix next. Ordered the "Gamer" variant in 2 oz.
Ordered all three variants with 1 oz via the Pool (cause it's cheap).
Want to see what 1 oz from them does compared to 2 oz.
Could be 1 oz from them will work for NeoYume.
Might be that I'll only make the Gamer variant in 2 oz., no matter the result. We'll see...
The new variant is the "robot" one that I want to upgrade my robots with...
Has two banks of 4 servo headers. Default is to use the power from the extra barrel connector.
But, also possible to use the other barrel connector via solder jumper.
Also possible to power P2 and servos by same barrel if the top three way solder jumper is shorted on both sides.
Each bank can also be powered by 5V, in case doing something besides servos.
Put in a vertical USB connector so doesn't hang of edge. Moved the audio connector away from edge a bit.
Added 3pin headers for Ping, MIC, and RGB lights (sharing P7).
Also added a Quiic connector that normally shares P0 and P1. But, can be jumpered to use header instead where you can run wires to some other pins...
After making a bunch of boards that wouldn't run NeoYume, finally got a couple that do.
It appears that the amount of solder paste on the P2 ground pad makes a difference.
None of about 5 boards made using a 4.7 mil thick stencil worked.
But, I'm 3.5 out of 4 with a 7.0 mil stencil. (.5 is because one board strangely works in PSRAM8 mode, but not PSRAM16).
The 7.0 mil stencil also seems to have a slightly larger opening than the 4.7 mil stencil.
If it holds, would be really great. Was disappointing when the 2oz/4layer boards didn't work.
But, having the 1oz/4layer boards working with NeoYume is even better.
May try preloading the P2 ground pad vias with solder paste to maximize paste there.
Also thinking about getting a thicker stencil, maybe 10 mil.
Do know that if there's too much paste then the P2 chip lifts up, that was a fail...
You could also check if black boards help ?
Do you mean help with radiating heat or baking in the oven?
I was thinking mainly run time cooling, but maybe it helps reflow too as a bonus ?
Preloading the P2 ground pad vias with solder paste with the thick stencil turned out to be a bad idea.
First one had the P2 slide about .4 mm, so pins were almost in between pads.
Seems it can slide more easily when there's too much paste under the ground pad.
Also the P2 pins seemed to be raised a hair above the pads, for same reason.
Second one like this works (i.e., plays NeoYume) though.
Now looking like important difference between stencils was not thickness but paste for the MAX4411 Audio Amp.
Board from thick stencil was doing NeoYume just fine without audio amp. But, once I added MAX4411 by hand, NeoYume won't run anymore.
This is a real puzzle. It can run MegaYume with the audio amp installed but not NeoYume.
Probably some noise issue cause by the DC-DC converter that the MAX4411 uses, I guess.
Doesn't make any sense yet...
See if the shutdown of the amp improves things. Maybe just the extra power draw or added noise it puts onto a supply affects it, or some important P2 signal is shorted to one of the amp connections?