Yes I've seen that approach as well. Because the command interface to IDE is 8-bit only this works well. I thought about to take this approach when I first had the idea to emulate a DISK-II, as it uses 256byte sectors and thus you could avoid a 512-byte sector buffer to cache writes. But you lock yourself out if you want to exchange data with systems using 16-bit IDE data interface. Then still I would use a buffer to separate the system bus from potentially long IDE ribbon cables. Also leaving D8..D15 open is not a good idea. And with fast CPUs and thus short bus cycles you need to add logic to create wait-states. At the end using 2 74LS652 and some glue as I did on the other IDE interface for a fast bus does not really make the interface complex. I personally do not like the 8-bit-only approach.

For the dual-scan LCD interface I just did that. The RAM is organized as 16bit. During PHI1 16-bits are read and during PHI2 A0 is used to select the appropriate bus-driver and for writes A0 selects the WE for upper or lower byte. My current logic does not currently support 16-bit writes (of course a LCD display would never write to RAM ) but that's not the challenge. When using this approach for 16-bit DMA only make sure your IO-buffer is aligned to even addresses. 16-bit is also nice, a 512byte sector needs 256 cycles so a 8-bit counter is all you need. I would really like to see DMA for a 6502 system. Only I would go for a cycle steal mode. All designs that use PHI1 for memory access require the memory to be much faster than required by the CPU clock speed. DMA for IDE always can afford to wait for the next falling edge of PHI2 and then lock-out the CPU, pull BE, RDY low and have unobstructed access to the bus. You not only have to access RAM but also the Data Register of the Interface and you can't allow the CPU accessing the IO registers during PHI2 when at the adjacent PHI1 DMA accessed the same controller.

Using a DMA for IDE need to solve some problems:
1) command data to IDE are only 8 bit and issued in PIO-mode by host.
2) DMA transfers are 16 bit and IDE interface need that /IOR, /IOW/, /CS0 and /CS1 signal will be deasserted (still in high level during DMA)
3) DMA will be handled only with DMAREQ (from IDE) and /DMACK (to IDE) signal. These signals can be connected to one of 4 channels of 8237. When IDE is ready to accept data or to send data assert DMAREQ line and wait for assertion of /DMACK line from host. DMA will stop transfer when IDE deassert DMAREQ line (this can happen in middle of transer too).

Using IDE in PIO-mode only is easy (see for example my implementation http://65xx.unet.bz/images/mb01/mb/p06ata0.pdf), even if ofcourse this need of 2 read/write cycle by CPU for handle 16 bit transfer. In addition, basis of my test, is better to use interrupt line of IDE interface for safety handle: when IDE is ready for a block transfer (512 bytes), assert interrupt line. Also, for issuing command is better to use interrupt line that signal IDE accepted command.

_________________
http://65xx.unet.bz/ - Hardware & Software 65XX family