This little job has been a LONG time coming. We knew several years ago that we wanted at least SDHC support (and ideally, SDXC, as well) for the MEGA65.
The limitation was in the open-source VHDL SD card controller that we were using. Fortunately, some nice people have improved that controller, so that it now supports SDHC cards, i.e., SD cards between 4GB and 32GB in size. SDXC begins from 64GB and goes up to 2TB, which seems to be rather larger than one might need for the MEGA65, however, SDHC cards will start to be harder to get in due course, so we want to add support for SDXC. For now, the job is about SDHC cards, however.
The first step was to pull in the new version of the SD controller in VHDL. This proved to be not too hard, as it really is a re-vamp of the old one we were already using. There were some changes to the handshaking, which took a little work to get right, and it also assumed you knew at compile time whether you had an SD or SDHC card -- whereas we want to be able to work out what is plugged in when you turn on the computer.
With all that working, it was then time to fix FDISK/FORMAT, and Kickstart itself. With a little effort, both of these now reliably detect whether you have an SD or SDHC card, and can prepare and boot from either. Of course, the SDHC cards are quite a bit faster as well, which is nice. I am using only a class 4 card, and it is very noticeably faster than the old 2GB SD card I was using.
Also, preliminary testing suggests that the unrealiability issues I was seeing with the SD card interface have also been resolved with the use of this new interface, which is very welcome, since they were stopping me from making a functional freeze function. So, finally, I can get back to doing exactly that.
Really nice :) Now, as on "I/O register level", do we have block or byte addressing, or we must know if the card is SDHC or not, and taking that account? Ideally - AFAIK - the best would be the same values always and let the interface "bridge" the differences, so just a program for M65 does not need to know about different card types, if it wants to use direct SD-card ops (not via hypervisor DOS calls for example, and yes, I have some half-ready stuff using features like this). From xemu perspective, I wouldn't say it's a big deal, as the speed is the same as it's emulated ... And maybe no need for more than 2G on Xemu. But anyway, maybe it's still useful to emulate SDHC in Xemu too (for example to test software/the KS itself, whatever ... oh yes, and KS must work on Xemu, so if there is difference, I should know ... oooops).
ReplyDeleteAt the moment, you still need to know which is which, to get the sector address correct. I want to fix that, but at the moment, it is a little tricky because of the magic of detecting the card type is not transparent to the hardware. There is a flag in $D680 you can read, though, which tells you which it should be. I'll think about how we can deal with this, as I quite agree simple is better for software.
ReplyDeleteIs there a reason the SD is not just represented as a simple SPI interface and let the SW handle all the lifting?
ReplyDeleteHi Jim,
DeleteThere are several reasons. One, it is a pain to have to talk SPI. Two, the controller I have implemented DMAs the sector read/writes to/from a sector buffer, so the CPU can be doing other things while a read/write is occurring, and get an IRQ when complete. Three, to use the SD card for F011 emulation disk images, we need the whole thing to be automated anyway. Four, we really want to keep the Hypervisor ROM as small as possible, so hardware acceleration is helpful on that front, too. For the enthusiastic, there is an option to take control of the SPI lines, so that you can bit bash to your heart's content. However, I don't see many use-cases for that. Was there a particular use-case you had in mind, or just thinking to avoid unnecessary hardware development?
Paul.