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