Just the four DAT pins have to be in order as either the high or low four pins.
Either way-- if it keeps a single header, I'll be looking to resolve that 240R speed-bump!
I note the existing #64009 pinout is such it can be used as the primary boot when slotted into accessory header P56..P63. And hence the 240R in case there is also a boot EEPROM in place.
This particular pinout precludes a 4-bit pinout on the same header.
Thanks evanh... Also, yeah, that primary boot resistor is a PITA requirement. I intend to come up with a better workaround this time.
I got pinged to re-order the Parallax microSD breakout (#64009)
Feels like if I'm doing that, I should add 4-bit support and the power control FET ?
Anything else preferable?
Yes, a card detection input pin, activity LED, power LED when FET is active. If you have 8 pins on the breakout why not use them - they are optional in the driver so you don't have to use them but are useful if you want them. My circuit in post #1 of this thread showed how I did it.
Yes, @rogloh has a clever design where inserting the uSD turns on the power by default.
And, it works in 1-bit mode just fine.
An official Parallax version would be very welcome.
Not sure what they would do for code though...
Guess @evanh helped out with a new 1-bit and 4-bit version of the "bashed" code that can work with both FSRW and FAT32.
Maybe there's no reason not to use FAT32 with P2 given the vastly increased resources.
But, FSRW keeps things dirt simple.
Still for the super high speed, appears need to use FlexProp at the moment.
Was just doing the numbers on what should sell my version for...
Looking like $11.99
@evanh said:
Nooo! not the dastardly $xx.99 pricing!
And do add a little headroom, there's always unaccounted costs.
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
Meanwhile most mass market electronics have some ~400% profit margin and the OS is full of ads and spyware...
Maybe you could preload your P2 boards with ads :P
@Rayman said:
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
If you're feeling generous, Eric and Ada could both really benefit from a freebie each.
A little self serving of me of course. I'm quite chuffed and want to see others enjoy it.
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
@Rayman said:
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
You can do all of these things in a single ffmpeg command, btw. Something like (untested) ffmpeg -i source_file.whatever -vf scale=640:364 -f rawvideo -pix_fmt rgb565le output.bin
LOL, those decimal places reminded me, I once converted an Amiga demo video, acquired off Youtube, into a selection of different frame rates so as to test the behaviour playback with a "Variable Refresh Rate" capable monitor. The nice part about using a video of an old demo is they contain smoothly frame sync'd text scrollers that don't judder. The old CRT monitors, being analogue, just beam sync'd to the computer. And someone had gone to the trouble of making such recording to put on Youtube as well.
Anyway, the point was to not remove, add, telecine, or interpolate any frames. Keep every original frame but lie about the frame rate so as to convince the player to play back at that specified frame rate and see if the monitor adapted to it. The audio track I just left as it was. There wasn't any need to stay in lip-sync when it was just a chip-tune playing.
Regarding the outcome: Testing on my Linux box produced as expected - the copy that was set to 60 Hz (Original being 50 Hz) ran smoothly but faster than original. All others had various degrees of judder from added or dropped frames. I don't have a VRR capable monitor so off I went to a shop ... Sadly, my tests on a Windoze box at the shop was no different. M$'s Media Player didn't appear to use VRR at all. Alas, I wasn't allowed to fiddle with any settings. Maybe VRR is only a D3D games thing on Windoze anyway. Dunno.
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
This is a great first result and what I sort of wanted to be able to do with uncompressed video and a P2. Eventually I'd like to try it out with PSRAM enabled and 24bpp colour depths (possibly using YUV 4:2:2) at similar or higher resolutions. I know my video+memory drivers and some PSRAM will have the bandwidth to display and capacity to store the increased frame size and we can use another COG write the frame data from an SD card, as long as the card can sustain its requirements - that's the last real unknown right now.
Comments
Thanks evanh... Also, yeah, that primary boot resistor is a PITA requirement. I intend to come up with a better workaround this time.
Yes, a card detection input pin, activity LED, power LED when FET is active. If you have 8 pins on the breakout why not use them - they are optional in the driver so you don't have to use them but are useful if you want them. My circuit in post #1 of this thread showed how I did it.
Yes, @rogloh has a clever design where inserting the uSD turns on the power by default.
And, it works in 1-bit mode just fine.
An official Parallax version would be very welcome.
Not sure what they would do for code though...
Guess @evanh helped out with a new 1-bit and 4-bit version of the "bashed" code that can work with both FSRW and FAT32.
Maybe there's no reason not to use FAT32 with P2 given the vastly increased resources.
But, FSRW keeps things dirt simple.
Still for the super high speed, appears need to use FlexProp at the moment.
Was just doing the numbers on what should sell my version for...
Looking like $11.99
Nooo! not the dastardly $xx.99 pricing!
And do add a little headroom, there's always unaccounted costs.
As I understand it, the updated adapter will be a springboard for a certain genius to get working on new code!
Don’t really care about profit, just trying to be reasonable…. Somebody once advised to count actual cost and just double it…
Meanwhile most mass market electronics have some ~400% profit margin and the OS is full of ads and spyware...
Maybe you could preload your P2 boards with ads :P
Probably should test the flash boot with something... @Wuerfel_21 Excellent idea!
Ideally something that's fun for the user (i.e. not an ad).
Maybe I could make a Bad Apple demo that fits exactly on the 16MB boot flash...
@Wuerfel_21 that would be great
If you're feeling generous, Eric and Ada could both really benefit from a freebie each.
A little self serving of me of course. I'm quite chuffed and want to see others enjoy it.
Did a more extensive video test...
Used Handbreak to render the free Sintel movie from Blender to 640x364 (so as to have correct aspect ratio when stretched on 16:9 HDTV.
Then, used ffmpeg to create 16bpp, vertically flipped, bmp frames.
Used custom code to extract bmp data from ~9000 frames into one ~4 GB file.
It plays perfectly on the TV. The upscaler is definitely doing something...
Didn't see a single dropped frame and calculated frame rate was 29.99 fps.
You can do all of these things in a single ffmpeg command, btw. Something like (untested)
ffmpeg -i source_file.whatever -vf scale=640:364 -f rawvideo -pix_fmt rgb565le output.binLOL, those decimal places reminded me, I once converted an Amiga demo video, acquired off Youtube, into a selection of different frame rates so as to test the behaviour playback with a "Variable Refresh Rate" capable monitor. The nice part about using a video of an old demo is they contain smoothly frame sync'd text scrollers that don't judder. The old CRT monitors, being analogue, just beam sync'd to the computer. And someone had gone to the trouble of making such recording to put on Youtube as well.
Anyway, the point was to not remove, add, telecine, or interpolate any frames. Keep every original frame but lie about the frame rate so as to convince the player to play back at that specified frame rate and see if the monitor adapted to it. The audio track I just left as it was. There wasn't any need to stay in lip-sync when it was just a chip-tune playing.
Regarding the outcome: Testing on my Linux box produced as expected - the copy that was set to 60 Hz (Original being 50 Hz) ran smoothly but faster than original. All others had various degrees of judder from added or dropped frames. I don't have a VRR capable monitor so off I went to a shop ... Sadly, my tests on a Windoze box at the shop was no different. M$'s Media Player didn't appear to use VRR at all. Alas, I wasn't allowed to fiddle with any settings. Maybe VRR is only a D3D games thing on Windoze anyway. Dunno.
Wishing exFat was enabled in FlexProp, so could have entire video in one file...
Might have to try that out soon...
This is a great first result and what I sort of wanted to be able to do with uncompressed video and a P2. Eventually I'd like to try it out with PSRAM enabled and 24bpp colour depths (possibly using YUV 4:2:2) at similar or higher resolutions. I know my video+memory drivers and some PSRAM will have the bandwidth to display and capacity to store the increased frame size and we can use another COG write the frame data from an SD card, as long as the card can sustain its requirements - that's the last real unknown right now.