Huh, that sentence is a bit hard, isn't it?
Yup... and I wanted to say it many messages ago.
Look at the commands a disk controller handles. Step in, step out, there's a status, and you can tell it to read and write. Not much more.
Different controllers have the ability to change density and some other settings but they are generally pretty simple and the rest is left up to the software. You don't tell it to read a specific track, you tell it to step a certain number of times and you keep track of the drive track. Basically you step down until it's at 0 and count your way out.
You may even have to tell it to step two times to go from one track to another. The servo can step half tracks but there has to be space between the tracks so you don't overwrite any neighboring data. You also have to delay between steps to give the servo time to step from one track to another. Then there's settle time before you can read data, finding the start of the track, etc...
A controller *may* tell you where the start of a sector is but some don't and you time how long from the index or from the start of the track to start reading a sector.
Now, to emulate a controller you may not need all of that but I would think you still need something emulating how a track/sector is read.
You have just to send commands to this controller with I2C
http://www.esacademy.com/faq/i2c/general/i2cproto.htm
You are suggesting replacing a serial interface with... a serial interface.
And what does that do for us? You seem to have skipped the software support part required by USB which treats a plug in SD interface as a mass storage device on top of a USB stack. You have now made it even worse. You need a USB stack, a file system, and the drive controller emulation.
<edit> I checked the links after posting this. There is no need for those chips. There is FAT file system source out there that would run on a microcontroller if you take the drive emulation approach.
You save a little ROM space on the direct interface but the SD controller simplifies the software enough it should allow you to add the FAT code to the ROM. IF it wouldn't fit that might be a good alternative but at a higher cost and more complex design. </edit>
What we were discussing was using an internal serial interface on a MCU to attach to an SD drive but have an interface to emulate a drive controller and an additional interface for directly accessing the file system for access as a mass storage device.
The point of using a small programmable device was to interface between serial and parallel to directly control the SD from the Oric. Small programmable devices in any kind of quantity are probably around $5 or even less and it can also handle part of the addressing logic you HAVE TO HAVE! Such a device would even be desirable to interface an MCU to the Oric since fixes could be made without changing the board.
The small device on one Speccy interface actually has two SD interfaces and can have a joystick interface as well. The entire board plugs into the Z80 socket and is about twice the width as the Z80 with the SD socket on the board.
Some comments for some of the people adding their 2 cents.
1. Stop looking at the C64 SD interface that comes directly off the computer to the SD card. The C64's CPU has a built in serial port! No driver code has been released for that and the build in DOS does not support it.
2. Don't look at the nice little devices for the C64 and Atari that use a nice little drive emulator done in an MCU. Those machines use a serial bus to interface to their drives and an MCU can talk to two separate serial interfaces without added hardware. One for the bus, one for the SD card.
The Oric DOES NOT DO THIS and has no built in DOS! You will need some sort of ROM for the DOS no matter what and the interface will be more difficult! (BTW, if you look at the Atari Serial Bus protocol it looks similar to USB... and yet USB deserved patents?)
3. "You just need an MCU",,, and you can just build a cold fusion plant to solve the world's energy problems. Sounds simple but in practice it's a little more complicated.
Any MCU needs code to talk to the SD card and the Oric.
Have you ever programmed a line of code in your life that talks from one CPU to another let alone processes dozens instructions on the MCU fast enough to give a response to the other CPU within 1 clock cycle of the other CPU? That last one is a must to emulate a drive controller unless you use a larger FPGA to do the interface.
4. Don't think it's easy because the Minimig does it. The minimig is a poor example since the Amiga controller works very different than other controllers. The entire track is read in and decoded once in memory. Totally different than the Oric's controller. Trust me, I worked on a driver to read CoCo disks on the Amiga 5.25" add on drive. It's ugly.
5. If you think this will be cheap, think again. Getting 50 boards printed that are large enough to hold a connector that will attach to the Oric and is large enough for a ROM, PLD, MCU and SD connector will probably cost you $50 US each. If you are lucky, $25 on a special. Then you'll want to print prototypes before you ever go to production, there's parts, assembly cost, lots of hours of development... it adds up. If you want it in a box that will probably be the next most expensive item after the board (not counting labor/development).
The Amiga ROMatic ROM switcher my company produced was just over $2 per board in 1000 quantity... and it sold in the hundreds so we didn't even break even. But that board was barely bigger than two ROMs... I couldn't get it any smaller. If we had produced it in the 100s it would have been more expensive and it would have sold in the dozens. If we had produced 100... we would have had to pay $20 a board somewhere else for prototype quantities and that board didn't have solder mask.