The confusion on this one shows the Seagate documentation as being more confusing. The signal in question is the IOCS16- line. This line is defined by both Seagate and Sandisk as being asserted when the IDE controller is expecting a 16-bit data transfer (read or write). Also, both docs show it as an active signal at a negative level. The confusion arises with the Seagate docs as they show a timing diagram with the IOCS16- line at a high level when asserted.... then again on a different page they state that the lines in the diagram are shown high when asserted (meaning a high or low level doesn't matter).
In any case, I found that using this line for the handshake had no affect, i.e., it appeared in software to never change state. So I'll break out the scope for an initial scan on this line. There's also the possibility that WDC have effectively disabled the SO line on newer chips. Their documentation still describes it's operation, but also states it was rarely used in the past and is not recommended for future use. So who knows... maybe I'll find another WDC "feature" like I did with the W65C51 ACIA
As for any partitioning (BillG), nothing has been done in that area as of yet. The first round was to validate that the hardware design was working, which includes the PLD programming for the single glue chip. The design is using a single 32-byte wide I/O select from the C02 Pocket SBC and the PLD breaks this out to handle:
- 18 registers of the RTC (1- select)
- 10 registers for the IDE controller (2- selects)
- Upper byte latch (4- selects)
Fortunately, it's all working, so I'm happy about that.
The BIOS design is to keep it simple. LBA mode is the only supported addressing mode against the CF Card and the commands are also kept simple and few. Obviously it's PIO mode only (no DMA hardware function). I've also limited the maximum LBA count to 8GB, which is 24-bits of LBA addressing at 512-bytes per block. I'll likely pick up some additional CF Cards of different capacities soon, as my current stash consists of 16MB, 32MB, 64MB and 96MB. All are working fine with the adapter and BIOS.
On a previous post, I noted some early data transfer tests using my initial routines which all disabled interrupts. It turns out those weren't correct, as testing for the CF Card controller being Ready requires sensing two bits in the status register. Now that everything is working correctly, I've done a lot of testing for reading and writing sequential blocks to and from memory. The results are very consistent. I'm reading and writing at the same speeds. I can read 56 blocks into 28KB of memory in 0.56 seconds, or write 56 blocks from memory into 0.56 seconds. This works out to 50KB/Second. Overall I think this is quite respectable for the simple hardware design. I know BillG has been doing some of the Flex testing with SD cards (bit-banging hardware?), so I'd be interested to know what transfer rates you're seeing with this setup.
Next is to start working on a BIOS translation layer so it the overall hardware (Console/Timer, RTC and CF-Card IDE controller) can be used by Flex and DOS/65, albeit these will be different layers. Just not sure how long that's going to take.... but I've got the Flex adaptation guide to work with.
Login
Register
FAQ
Search
So... I'm already making some updates to the BIOS code.... will also look at trying to use the /SO line being driven by the IOCS16 signal. I'm also thinking the data transfer rate is being affected by the CPU clock speed, as the code to get data to/fromfrom the CF Card has it's own timing per loop, which reads or writes a word (16-bits). I'll try changing the CPU clock to see if the data rate changes as well. In any case, things just got better... still more work to do on the code and eventually an updated adapter.
Note to self: keep scanning your own code first 
