I think that's probably it. That would have been the first (and only) real 8 bit mode board as a target. And the chip select pattern or clock speed may have been tied somehow in that driver, assuming lots of fanout load due to having 6 banks of 16MB. As a sanity test you could try my 8 bit driver with your code on a P2Edge and only use half the data pins. You may still need to tweak the clock timing delay of course.
Might want to try Roger's delay-test reporting programs. They show what "delay" values are suitable. If nothing shows up in the map then that would indicate there is other problems.
@evanh module works with Megayume but not exmem_mini. Think will just wait and hope that @Wuerfel_21 can figure it out...
Going to move on to higher resolutions.
Also thinking about what kind of video your 4-bit uSD driver might be able to deliver...
@Rayman said:
Also thinking about what kind of video your 4-bit uSD driver might be able to deliver...
If you're wanting to push the read speed then disabling the CRC check during reads allows sysclock/2 divider to hit its full capability.
The example speed tester program has the relevant couple of lines commented out. Uncomment them and you'll see the difference.
It uses ioctl() and the device handle to set them so the tester make the setting change at mount time, but in reality those settings can be adjusted on the fly as you like.
Of note is the parameter value to be set must be held in hubRAM, hence the "&". That's just the way ioctl() works, since it is allowed to pass a whole structure. The control numbers, 70 and 72, I chose in the driver myself. Here's the full list:
CTRL_BLOCKREAD_CRC = 70, // Disables/enables CRC processing of block read, default is enabled
CTRL_GET_CLKDIV = 71, // Get the active clock-divider
CTRL_SET_CLKDIV = 72, // Set the active clock-divider
CTRL_GET_CLKPOL = 73, // (Not implemented)
CTRL_SET_CLKPOL = 74, // (Not implemented)
Was testing converting the raycaster to use exmem today...
Starting with the background image (mountains).
Loading the image from uSD, so doesn't have to be embedded anymore.
Anyway, at the start of each frame the assembly graphics drivers draw the background image by copying 100 lines of 320 pixels from exmem to HUB screen buffer.
One interesting thing is how to monitor that exmem is ready for another command.
Seems it would be better to poll the mailbox base just before writing to the base with new command.
But, this doesn't work so well, a couple lines flicker.
Appears better to poll the mailbox base after writing to it.
Guess this is a hair slower, but produces a stable image...
Check out how the Spin exmem_mini code implements this - you check the first long is zero before writing ANYTHING. The longs should either be written last to first or in one go with SETQ+WRLONG (this is generally the fruitful approach for ASM code)
Comments
I think that's probably it. That would have been the first (and only) real 8 bit mode board as a target. And the chip select pattern or clock speed may have been tied somehow in that driver, assuming lots of fanout load due to having 6 banks of 16MB. As a sanity test you could try my 8 bit driver with your code on a P2Edge and only use half the data pins. You may still need to tweak the clock timing delay of course.
No, it's something about how the transfers are chunked up, bad leftover code from the 16-bit driver or smth.
Testing with SWaP's hyperram now... Can't find a setting that works... Missing something?
Trying things like this:
These are settings from MegaYume that work...
Just realized might have to play with clock freq...
Think found the problem in ExMem_mini...
Seems the latency is hard coded to 6 whereas this module needs 7:
exmem_banks[16+i] := HYPER_SELECT+i + HYPER_CLK<<8 + HYPER_RWDS<<16 + 7<<25 '6<<25 ' Latency????Added a "HYPER_LATENCY" constant to exmem_mini and have the code above use that instead.
Seems good now.
@Wuerfel_21 Do you have settings for the EC32 module?
Should just work
Ok, it does:
'Config for Parallax Edge with 32MB PSRAM
exmem : "exmem_mini" | MEMORY_TYPE = 16
Having trouble finding any code that works with 96MB module... Sad...
Ok, @Wuerfel_21 reminded me that the emulators all have suggested PSRAM settings.
Got 96MB working with MegaYume on P2 Eval board.
But, these settings don't work with exmem_mini for some reason. Tried a lot of variations, but nothing works...
Might want to try Roger's delay-test reporting programs. They show what "delay" values are suitable. If nothing shows up in the map then that would indicate there is other problems.
My ram-tester.spin2 is easier to setup and run if you just want to prove the hardware - https://forums.parallax.com/discussion/comment/1569287/#Comment_1569287
@evanh module works with Megayume but not exmem_mini. Think will just wait and hope that @Wuerfel_21 can figure it out...
Going to move on to higher resolutions.
Also thinking about what kind of video your 4-bit uSD driver might be able to deliver...
This one loads the 8bpp bitmap from uSD instead of hub ram.
Using the @evanh bashed3 uSD driver with FAT32 (instead of FSRW this time).
the bmp file has to be on the uSD of course...
Here's with 16bpp VGA bitmap, loaded from uSD.
If you're wanting to push the read speed then disabling the CRC check during reads allows sysclock/2 divider to hit its full capability.
The example speed tester program has the relevant couple of lines commented out. Uncomment them and you'll see the difference.
It uses ioctl() and the device handle to set them so the tester make the setting change at mount time, but in reality those settings can be adjusted on the fly as you like.
clkdiv = 0; _ioctl(handle, 70, &clkdiv); // disable read-block CRC processing clkdiv = 2; _ioctl(handle, 72, &clkdiv); // set CLK_DIV valueOf note is the parameter value to be set must be held in hubRAM, hence the "&". That's just the way ioctl() works, since it is allowed to pass a whole structure. The control numbers, 70 and 72, I chose in the driver myself. Here's the full list:
CTRL_BLOCKREAD_CRC = 70, // Disables/enables CRC processing of block read, default is enabled CTRL_GET_CLKDIV = 71, // Get the active clock-divider CTRL_SET_CLKDIV = 72, // Set the active clock-divider CTRL_GET_CLKPOL = 73, // (Not implemented) CTRL_SET_CLKPOL = 74, // (Not implemented)Oh, huh, the Spin2 libc support doesn't have ioctl(). I'll ask Eric about it ...
Think have the 800x480 4.3" IPS LCD board working.
At least, have something on the screen...
Seems to be a good fit for this exmem driver.
Hopefully, will have it going soon...
Was testing converting the raycaster to use exmem today...
Starting with the background image (mountains).
Loading the image from uSD, so doesn't have to be embedded anymore.
Anyway, at the start of each frame the assembly graphics drivers draw the background image by copying 100 lines of 320 pixels from exmem to HUB screen buffer.
One interesting thing is how to monitor that exmem is ready for another command.
Seems it would be better to poll the mailbox base just before writing to the base with new command.
But, this doesn't work so well, a couple lines flicker.
Appears better to poll the mailbox base after writing to it.
Guess this is a hair slower, but produces a stable image...
Check out how the Spin exmem_mini code implements this - you check the first long is zero before writing ANYTHING. The longs should either be written last to first or in one go with SETQ+WRLONG (this is generally the fruitful approach for ASM code)