SD mode is a little different. Only the block read/write commands need a card-busy check before being issued. Other commands can be issued while the card is still busy.
EDIT: There is a separate CMD-ready check for all commands though. Can't issue a start bit if the CMD pin is already low before starting.
@Wuerfel_21 said:
EDIT: So what you're saying is, the busy check should not be at the end of a write, but before issuing a command? Because the audio driver does have a ready check after a block write.
I didn't analyse if that was a vital config but pretty much yes. I've copied how sdmm.cc command sequence does it. That is the more efficient solution anyway since it exits from the driver while the card is known to be in a busy state. Only checking in if more action is requested.
There is a second busy check after CMD24, but before any block data is sent, as well.
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
@Wuerfel_21 said:
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
PS: And why I mention the SD mode driver, sdsd.cc, is because I've implemented it in a similar fashion as well - Only check the card status when the driver really needs to know.
@Wuerfel_21 said:
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
No, I mean wether the audio driver needs to be fixed
Yep. You should be able to remove the leading call #read_byte in do_sdcmd routine. The busy check now performs that duty.
And also should be able to remove the post-write call #sd_busy as well since every command is now effectively checking for that.
@evanh said:
Yep. You should be able to remove the leading call #read_byte in do_sdcmd routine. The busy check now performs that duty.
And also should be able to remove the post-write call #sd_busy as well since every command is now effectively checking for that.
Yeah, but I don't want to change it too much, don't have time to test it on many configurations right now
Oh, yep, you've done better than I thought too. I had imagined a card-busy check was done before each raw block read as well as written but that's not so in sdmm.cc. All good.
EDIT: In hindsight, duh. It is looking for the start token rather than a busy check.
Comments
SD mode is a little different. Only the block read/write commands need a card-busy check before being issued. Other commands can be issued while the card is still busy.
EDIT: There is a separate CMD-ready check for all commands though. Can't issue a start bit if the CMD pin is already low before starting.
The point I was asking about is wether doing it that way is actually a bug? (and given I don't have a lot of time to re-verify right now, what the least invasive fix would be)
sdmm.cc has always been that way. I would imagine it has a proven track record well beyond the Propellers. I only sped up the bit rate when I modified sdmm.cc.
PS: And why I mention the SD mode driver, sdsd.cc, is because I've implemented it in a similar fashion as well - Only check the card status when the driver really needs to know.
No, I mean wether the audio driver needs to be fixed
Ya, the double card-busy check on block transfers seems to be important. One before command issue and another before each raw data block.
Like this?
(Also flexsplorp broke my game
, so had to fix that, too)
Yep. You should be able to remove the leading
call #read_byteindo_sdcmdroutine. The busy check now performs that duty.And also should be able to remove the post-write
call #sd_busyas well since every command is now effectively checking for that.Yeah, but I don't want to change it too much, don't have time to test it on many configurations right now
Oh, yep, you've done better than I thought too. I had imagined a card-busy check was done before each raw block read as well as written but that's not so in sdmm.cc. All good.
EDIT: In hindsight, duh. It is looking for the start token rather than a busy check.