2014-01-18 11:45 UTC
In my first 6303 based computer I used floppies for secondary storage. Even though it worked very well floppies are relatively small, fragile, slow and, above all, they are outdated. Today there are easier and more convenient ways of storing large amounts of data. Even for a small 8-bit system. A while back I investigated the possibility to use IDE/ATA hard drives. Commonly available IDE drives are cheap and easy to obtain but they have 16-bit interfaces and needs some clever latching to make use of all 16 bits in an 8-bit system. Not really a big issue once you have your hardware done and driver written but it slows down disk access considerably (usually around a factor of two unless you do some kind of DMA). Older IDE drives for IBM-XT had an 8-bit mode that would effectively disable the upper 8-bits of the interface and pass all data through the lower 8-bits meaning they could be directly attached to an 8-bit system. Problem is that those drives are hard to find, small and old. Not a good solution for a new design.
Today compact flash cards ("CF-cards") are commonly used in digital cameras and media players etc. They are in many situations replaced by the cheaper secure digital cards ("SD-cards") but CF-cards are still widely available and in use. Especially in systems needing high performance storage such as professional cameras, measure instruments and such. The interesting thing about CF-cards is that they can be configured for an IDE/ATA mode meaning that they would work just like an IDE hard drive. But one thing is particularly interesting. The old 8-bit mode from the XT-days is back!
This makes the hardware interface ridiculously simple as the card acts just as a regular Intel-bus peripheral device.
Above is my 8-bit interface for IDE/ATA mode. It is based on a design i found in an old SanDisk white-paper and connects directly to my MC3 I/O bus. The CF-card maps into the address space using three address lines for a total of eight registers. When using the card in LBA mode the register map looks like this (table taken from Motorola assembly code).
CFREG0 EQU CFBASE+0 DATA PORT
CFREG1 EQU CFBASE+1 READ: ERROR CODE, WRITE: FEATURE
CFREG2 EQU CFBASE+2 NUMBER OF SECTORS TO TRANSFER
CFREG3 EQU CFBASE+3 SECTOR ADDRESS LBA 0 [0:7]
CFREG4 EQU CFBASE+4 SECTOR ADDRESS LBA 1 [8:15]
CFREG5 EQU CFBASE+5 SECTOR ADDRESS LBA 2 [16:23]
CFREG6 EQU CFBASE+6 SECTOR ADDRESS LBA 3 [24:27 (LSB)]
CFREG7 EQU CFBASE+7 READ: STATUS, WRITE: COMMAND
Just like a usual IDE hard drive. The 8-bit mode is activated by writing $01 to the FEATURE register (CFREG1) and then issuing the SET FEATURE command by writing $FE to the COMMAND register (CFREG7).
The trickiest part of a CF interface may be to solder the CF socket. All sockets that I know are made for surface mounting and the pins are packed together really tight. I soldered thin wire-wrap wires to the pins to make my adapter.
Picture of the finished CF interface for the MC3 bus.
I wrote a quick test program for verifying the interface that reads card information and sector of choice.
Firmware: HDX 6.03
Model: SanDisk SDCFH-004G
LBA size: 00 77 38 00
I'm working on a very simple file system for use with the CF-card but that will be presented in a separate article.
by Mikey 2014-05-14 11:51 UTC
Could this be used to replace failed IBM-XT drives (which as you say are nigh on impossible to find working!), I'm not sure I understand the differences between MC3 and IBM-XT 8bit.
by Daniel 2014-05-15 11:35 UTC
Hi Mikey! Thank you for reading. Interesting thought. I think it may be possible. Some intelligent adapter may be needed to initialize the CF-card into an XT compatible state on powerup but I'm not quite sure. I will have to check the specs more closely.
by Daniel 2014-05-22 11:49 UTC
I'm afraid an intelligent adapter is needed but if you mean to replace drives in an IBM PC XT/AT there may be a clean solution.
I found this: http://www.lo-tech.co.uk/wiki/XT-CF-lite
by Peter 2015-06-28 10:43 UTC
for several projects I have used the standard 16-bit IDE interface to interface
my 6502 computers with compact flashes and that worked fine. Then I learned that
CF Cards also have a 8-bit mode to read and write the sector buffer and started
using the 8-bit interface in one of my projects. However I had various stages of
success. Then about 1 month ago I saw your articel and what I saw in your source
code is that you first select the mode and drive (write $E0 to UNIT register) and
then set the feature (1 to the FEATURE register) and then the command ($EF set feature
to the command register). As it seams many CF-Cards will not work when you change the
order (1 to FEATURE, $E0 to UNIT and $EF to COMMAND register). So your source code
solved quit a lot of issues. So thanks a lot.
I still have problems with some CF Cards but a set of CF Cards I pulled of from
old routers work now perfectly.
by Daniel 2015-06-29 11:01 UTC
Hi Peter! Thank you for sharing your discoveries. It took me some trial and error before I got it right also. I suspect that changing mode via REG6 in mid-flight is a bit shaky. I read somewhere that the SET FEATURE command should be issued directly after every FEATURE written. The documentation I've found so far is also pretty vague about the 8-bit mode. Perhaps it's not even supported on all cards. It would not surprise me. I have used only SanDisk (4GB and 8GB) and Kingston (2GB) and they have all worked fine so far.
by Mikey 2015-09-03 08:04 UTC
Another year older....
I was thinking, to emulate an old XT drive, would it be possible to intercept the RDY signal (i.e. don't pass it on to the host), wait until it's ready, initialise it into 8 bit mode, then just pass through the RDY signal after that transparently?
That way the host doesn't see it as ready until after the card has been initialised into 8 bit, so, as you say, a "smart controller" that only has control until after the card is initialised, and after then merely mirrors the ready signal?
So, the ready signal would be cut and (say) passed through a PIC, but not mirrored through until after the card is in 8 bit mode.
And (I was thinking), this would be a potentially easy hack by using an IDE -> CF adaptor and either cut a trace or intercept the RDY (and then inject into the other lines).
Of course, this may all be moot - I was thinking this might work for old kit (like Amiga A590 enclosures) but it may not understand the disk geometry as they were only 20/40mb drives back then.
What do you think?
by Daniel 2015-09-06 10:24 UTC
From what I can see while digging deeper into the specs it looks like the XTA interface uses a different register set than ATA. Most obvious difference is that XTA has 4 registers while ATA has 8. Looking at the old XTA pinout also I noticed that the connector is missing address line A2 that is used in ATA. Thus an XTA controller can not cannot reach the upper 4 register of an ATA drive (or CF) since A2 will be tied to ground. Setting a CF-card to 8-bit mode only changes the data transfer width. It's still using the ATA register set. What we would need is some form of true XT emulation mode that also changes the register set but I'm not sure if such a thing exists.
If I'm not mistaken the Amiga A590 has both an internal XTA and SCSI interface. Since SCSI drives are still somewhat obtainable that may be the easiest solution. I know there are SCSI to ATA adapters but they can be a bit pricey. I also know these adapters work with CF-cards in ATA mode so if you really want a CF card in an A590 that is the only of-the-shelf solution I know of.
Another approach is of course to rewire the A590 and find a free I/O pin somewhere to use for A2. That way I believe an ATA drive could be directly connected. It does however require a substantial modification to the firmware!
by Mikey 2015-09-29 12:15 UTC
I think you're right, it's probably the death knell for any chance to practically revive the A590 XTA! I'm a big fan of cheap hacks! there's a cool project which is a SCSI to SD card (kind of perfect for the A590 not the cheapest but as you say, SCSI to ATA are available but £££) I still have some 50 pin SCSI around, although they do sound like a Vulcan passing overhead.
by JG 2016-09-21 16:42 UTC
A friend and myself were bouncing around the idea of using an AVR and some tri state buffers to set the thing into 8 bit mode so we can use the CF on an XT-IDE type system. Should be done on power up by the AVR (it'll then activate the buffers so the host can see it) and it'll be initialized long before the host system posts.
by Daniel 2016-09-22 09:02 UTC
I like the idea! In theory I think It should be possible but what I don't know is how compatible the CF registers actually are when compared to the XT-IDE. One other way may perhaps be to connect a really fast AVR in line all the time to emulate an XT-IDE command set and control the CF separately.
[host] <--> [AVR] <--> [CF]
The big question is though if we can find an AVR fast enough to satisfy the bus timings on the host side. Perhaps an FPGA is the only way to go.
Write a comment