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.
by Oldman 2018-10-03 18:57 UTC
I was wondering can this be sub inplace of a SRAM that is currently in the system for booting. The SRAM connects via an IDE on the board. It kind of replaces the old way of booting off a floppy disk.
by CrafterOfWorlds 2018-10-12 04:39 UTC
Thanks a ton, man! Helped a lot with my Z80 based single board
by Francois Laagel 2019-04-17 16:48 UTC
This is very nice, conceptually. However, you wire WE- to Vcc in your schematics, which is weird. One would expect you to be able to write data to the device... Also you do not specify which type of connector you're using. I recently bought ($60) a copy of the ATA4 standard (1998). Unfortunately, programming a content of #1 in the FEATURE register is considered a 'RETIRED' thing. In effect, this may or may not work depending on how old your target device is. Furthermore, there is no such thing as A03-A10. Are you referring to a more recent thing than the ATA4 standard?
That being said I like what you did, a lot. I am working on a similar design myself, targeting the 6309 (Hitachi's improved version of the 6809). The stuff runs at 3 MHz and I have the 63B05 ACIA working fine at 15200 bps.
My next step should probably be to go for an I2C interface for RTC support. The next thing after that will be the CompactFlash interface (128MB Transcend industrial, coupled to an adapter I found at proto-advantage.com--the old Sparkfun breakout board is no longer available).
Is your filesystem implementation in any way public? I'd be interested in not re-inventing the wheel.
All the best.
by Daniel 2019-04-20 19:28 UTC
Hi Francois! Thank you for your interest in my ideas. In this design I use the CompactFlash card in ATA mode. In that case the WE pin is not needed and should be tied to Vcc. IOWR and IORD is used as read and write strobes which complies with the ATA standard. I have used the "SanDisk CompactFlash Memory Card OEM Product Manual" (2010) as design reference in this case.
One very nice thing about CompactFlash cards is that 8 bit transfers in ATA mode are still part of the modern specification. That's one of the reasons that I opted to implement CompactFlash interfaces for my MC3 computer instead of IDE/ATA.
My latest file system, MCFS2, design and specification including all source code is here on the website. Please refer to the articles titled "MCFS". Most recent release is MCFS 2.0.2. Source is for the 6303 but I've have compiled and tested it on 6309 also. Good luck with your project! Always fun to hear about new constructions!
by Francois Laagel 2019-04-30 16:47 UTC
I apologize because I was not using the correct standard! ATA-4 is not the relevant document. ftp://ftp.wintel.fi/manuals/General/CompactFlash.pdf has The CFA CompactFlash specification version 1.4 (and it's free) and documents the actual pinout of the 50-pin connector!
I hope you are correct with respect to the 8-bit mode. I plan on using a Transcend CF300 Industrial (128MB). And I will definitely start from your design and probably even your code, since the 6309 supports the 6800 instruction set.
Your file system may also be of interest to me later on.
Keep it up, man. That's really cool stuff.
by Daniel 2019-05-01 05:31 UTC
I wouldn't worry too much. I have yet to find a CF card that does not support 8-bit transfers. The 8-bit feature (01h) is mentioned on page 85 in the 1.4 CF spec sheet (table 45). It's pretty straight forward. My biggest problem with breadboarding CF cards is actually soldering those tiny connectors :)
Please also have a look at my MCFS2 writeup. Besides the file system itself it also contains an improved hardware interface.
by Francois Laagel 2019-05-02 15:23 UTC
You're very brave soldering tiny SMT sockets like this. For the rest of us, breadboarding or wire wrapping like myself, there is always https://www.proto-advantage.com/store/product_info.php?products_id=2800021.
All the best.
by John Gay 2019-08-01 20:21 UTC
I am currently expanding on a 68000 based machine and was looking for an external storage solution when I found you article.
Since my system has a 16 bit buss, I am guessing that I could just use the 16 bit outputs with just a few modifications to the source code. Is this correct?
by Daniel 2019-08-01 21:54 UTC
Hi John! Yes, you are correct. Without setting the 8-bit feature command, the card will operate in the default 16-bit mode.
by Francois Laagel 2020-03-17 10:31 UTC
It is refreshing to see someone who still uses ASCII EOT to terminate strings! About decoupling, since a CompactFlash device can use up to 200 mA in bursts, what kind of capacitor would you recommend?
by Daniel 2020-03-17 17:46 UTC
I like mixing old with new and in order to stay compatible with MIKBUG the ASCII EOT lives on! :)
Regarding capacitors I have found that most modern CF cards are surprisingly tolerant actually under these circumstances. On my MC3 OS card I did not even need any extra decoupling for the two CF sockets. On that board I only have one single good quality 100uF aluminium electrolytic across the main supply along with decoupling on all ICs, 100nF each. The access pattern greatly affects the supply requirements. My slow ~1MHz bus machine will only load the cards to a fraction of what they are capable of. SanDisk specify 500mA current requirements for the cards I use but I come nowhere near that. Way below a tenth of that peak per card during access with an idle current of just over a mA. Perhaps if I used older and more power hungry CF cards things would be different. If I were to have issues I would probably add something like 10uF + 100nF across the power rails as close to the CF sockets as possible to leave some headroom for different card requirements. The choice of aluminium vs. tantalum capacitors would depend on the rest of the design and especially the power supply. Using tantalums will generally yield lower ESR and the construction can be made smaller but one must take into account that tantalums tend to fail short when going bad so the power supply must be designed with that in mind to keep the magic smoke from escaping.
Write a comment