PDA

View Full Version : Prop + IDE drives?



Spork Frog
01-30-2008, 04:07 AM
Has anyone made an IDE drive interface for the Prop yet?

It seems like it wouldn't be terribly hard to do, we certainly have enough I/O lines and I'm pretty sure enough speed to do it.

A project like the one attatched (this is actually an ad from Jaycar) would be nice too, but I've never come across anything specifically having to do with CD drives, just general IDE hard drives and CF cards.

Ziggy252
01-30-2008, 04:14 AM
I read the articles about this one. The interface implemented is only capable of controlling the audio playback functions of the CD drive (you have to use a CD drive which has an analog audio output on the back - most do) If you wanted to use a hard disk with the Prop you'd be better off using an external USB drive, for which there is a chip that will handle the tough part of the interfacing.

Spork Frog
01-30-2008, 06:35 AM
Would it be possible to do both CD drives and hard drives?

I'm not exactly going for the practicalities of the whole thing here, just as an experiment to try and do it in the first place.

hippy
01-30-2008, 10:31 AM
Spork Frog said...
It seems like it wouldn't be terribly hard to do


Although I've not done it, those are my sentiments as well. It's a 16-bit bus, three address lines for the control/data registers plus read, write and power and that's it ... plus the driver software.

CF in IDE mode is AFAIK exactly the same as for HDD.

Spork Frog
01-31-2008, 10:46 AM
Yeah, seems like IDE is IDE, though CDs have a few more registers and stuff you can set and mess with for controlling various things.

And I found this -> www.retroleum.co.uk/ide_interface.html (http://www.retroleum.co.uk/ide_interface.html)
Looks like for the most part IDE is somewhat similar to SPI, but with 16 data lines instead.

OzStamp
01-31-2008, 02:38 PM
Hi Spork Frog..

It is very possible.. a guy I know has a MP3 player and stores files on a HDD and he used a smallish PIC chip.
Also seen an article in an Elektor magazine a few years ago.. from memory there it was done with a 8051 chip..

cheers Ron mel oz.

Peter Verkaik
01-31-2008, 04:18 PM
Attached is a schematic that uses I2C to access a CF card.
I built this one once around the javelin module, but it was very
slow, because of I2C and the javelin interprets bytecodes.

At this link you can find all the java classes required.
http://tech.groups.yahoo.com/group/JavelinCode/files/Javelin%20Stamp%20IDE/lib/stamp/peripheral/memory/compactflash/


regards peter

Matthew Hay
01-31-2008, 05:11 PM
Yeah connecting a micro to a HD is very simple, the rough part is usually making sense of the filesystem :P (which is not really all that difficult if you use FAT since it's documented rather well accross the internet)

I've connected a HD to an 8051 variant (been a while though) attached is a picture of the mess I made.

One issue I kept having was the power up time for the HD, I was not giving it enough time to power up and finish its POST.

Spork Frog
02-03-2008, 08:43 AM
Looking through a lot of the spec stuff, all IDE really boils down to is 8 registers to read and write from the drive, and handling the timing of doing it. Now to figure out exactly how to handle the timing, but that doesn't look too terribly difficult.

EDIT: I got it wrong the first time, I just figured out the "Clock" signal was just a reference in the guy's timing diagrams. Whoops.

So... more like this then:
1. Put the data on the data bus, or set the pins as inputs to get ready to read.
2. Set A0-A2.
3. Set CS0 low and CS1 high (can these be held permanently like this?)
4. Pulse either "RD" or "WR" low.

Post Edited (Spork Frog) : 2/3/2008 2:49:48 PM GMT

hippy
05-03-2008, 09:32 AM
As I'm thinking of trying this soon I was wondering if anyone has yet tried it with a Prop ?

I'm thinking of using a non-Propeller to start with to avoid any 5V interfacing issues, then I
can wind the PSU down to 3V3, add some current limiting R's and see what happens. I'm
only going to be looking at the low-level stuff, sector read, sector write.

AFAICT, the 16-bit data bus can be just 8-bits ( only needs to be 16-bits for data transfers )
if losing half the disk capacity is acceptable. That would screw drive identification and FAT
but would still work if a new file system were designed. It looks like ATAPI only uses 8-bit
command packets so no problem for controlling CD-Rom for playing music.

8-data plus 8-control is far easier than 16-data plus 8-control with the hardware which I
have.

As an aside; does anyone know if it's possible to burn WAV / CDA / whatever to DVD and
use a DVD drive controlled via ATAPI as a standalone super-sized CD-Rom music player ?

hinv
05-03-2008, 11:04 AM
It's funny that this came back up today. I was just reading in my newest issue of Circuit Celler where they are doing just the opposite.
The article describes using a PC motherboard as a microcontroller. They key is that they are using the same IDE bus to do it because of low latency. It has some pretty good descriptions of the IDE bus as well.

Just FYI

Matthew Hay
05-04-2008, 01:28 AM
That sounds pretty cool.·

I was/am (on hold) working on an IDE object (raw·IDE·interface no·FS support, FS support is something that I wanted in its own object later)·but unfortunately the HW I had tried to use for level shifting did not work as I thought it would.· The sad part is that most of the code has been written, I just have to make the HW to test/debug it.· Currently unemployed so that is very much on hold :P

Attached is a couple of pics from the top of my code that might help someone else.

simonl
05-04-2008, 01:50 AM
If FAT was needed, wouldn't it be possible to nick the relevant code from Tomas Rokicki's SD card object (http://obex.parallax.com/objects/92/)?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

Matthew Hay
05-04-2008, 02:04 AM
FAT technically is not that hard but I believe that it should be in its own object (not cog) not in the object with the IDE drivers, in that way you could easily use a different FS with the drive or even use the FAT object with a different hw driver.

But that is just my way of looking at it, the great thing about people is that we can all look at the same thing in different ways.

hippy
05-04-2008, 02:05 AM
@ Matthew : Thanks for that. I've got CS1- marked as tied high, CS0- the active one, so I'm
going to have to double check that. To start with I'd control both just to avoid any problems.

@ simonl : The SD Card FAT code should help, should be possible to hack perhaps so every
16-bit wide sector were split across two 8-bit wide sectors. Not sure what the upper size limit
is for the SD Card - 2GB ( haven't checked it ) ? No problems if there are enough free I/O's
to do a 16-bit bus. With RESET-, CS1- and CS0- hardwired that gets the I/O down to 21 I/O
lines which leaves enough for normal Prop use.

Matthew Hay
05-04-2008, 02:21 AM
@Hippy

Here is a table that might help:

IDE reg: A0-A2: /CS0: /CS1: Use:

· $0 000··· 0··· 1···· IDE Data Port
· $1 001··· 0··· 1···· Read: Error code
· $2 010··· 0··· 1···· Number Of Sectors To Transfer
· $3 011··· 0··· 1···· Sector address LBA 0 (low byte)
· $4 100··· 0··· 1···· Sector address LBA 1
· $5 101··· 0··· 1···· Sector address LBA 2
· $6 110··· 0··· 1···· Sector address LBA 3 (high nybble in 0:3) **
· $7 111··· 0··· 1···· Read: "Status", Write: Issue command to drive
· $8 000··· 1··· 0···· Not Important
· $9 001··· 1··· 0···· Not Important
· $A 010··· 1··· 0···· Not Important
· $B 011··· 1··· 0···· Not Important
· $C 100··· 1··· 0···· Not Important
· $D 101··· 1··· 0···· Not Important
· $E 110··· 1··· 0···· Not Important
· $F 111··· 1··· 0···· Not Important

It was copied from this page (which was very helpful for me back when I was working with the 8052)

http://www.retroleum.co.uk/z80-ideinterface.html

Since there is nothing of any real importance (verified with the ATA spec) I just tied it high to cut down on the number of pins needed.

Attached is a pic of the connections to the prop I was using (the unmarked lines at connected to the left side are connected to the data lines)

They are techincally all you need to use the drive.


EDIT:
Because I confused myself a bit I've attached the page from the ata spec concerning the CS lines






Post Edited (Matthew Hay) : 5/3/2008 7:33:03 PM GMT

heater
05-04-2008, 11:01 AM
I hope someone here can brew up an IDE interface. I'd love to have my old Quantum Big Foot hard drive (1GB) clunking away on the CP/M emulator. Sadly I don't think I have time to look into this myself. Just simple sector level access would be brilliant.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

hippy
05-05-2008, 03:38 AM
Well, that was far easier than expected, at least on a 5V micro (PICAXE). Everything working
except recovering after an error - I'm resetting the IDE devices so something odd / I'm missing
is going on.

For the record CS0- and CS1- can be tied high/low; IDE Pin 37 = 0V, Pin 38 = +5V. However,
if necessary to issue a soft-reset after the errors they'll have to be controlled.

Making the 8-bit wide sectors PC compatible; the best option I can think of is formatting the disk
so it's one ( or more ) files filling the disk then run a virtual file system inside those files, similar
to how Virtual PC etc .VHD files work. Should be fairly easy to write an App which can copy files
into and out of the files.

Obviously 16-bit wide sectors would make everything far easier, but 8-bit wide has far less I/O
line requirements. With likely needing to do level shifting for the Prop it would probably be just
as easy to level-shift and multiplex an 8-bit Prop to 16-bit IDE bus.

simonl
05-05-2008, 09:07 PM
Hi Hippy,


said...
Not sure what the upper size limit is for the SD Card...

AFAIK the upper limit is a function of the FS, and then it's the limit on a partition's size. In the case of rockiki's code; I believe he's written it for FAT16, which limits a partition size to 2GB.

I found this page of FAT & drives (http://home.teleport.com/~brainy/fat16.htm) which may be of interest.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,

Simon
-------------------------------
www.norfolkhelicopterclub.co.uk (http://www.norfolkhelicopterclub.co.uk)
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style http://forums.parallax.com/images/smilies/smile.gif

RobotWorkshop
05-05-2008, 10:21 PM
If possible it is definitely preferable to read/write all 16-bits. You can certainly control the drive and use it by ignoring the upper 8-bits. It has already been mentioned that this will cut the capacity in half. The other downside is that you can't get the drive information. You'll loose half of that too and as a result you won't be able to read the geometry of the drive to get the capacity. If you know ahead of time you can hard code the parameters in you code though to get around that.

A while back I made an IDE interface board for a HERO 2000 robot. It is based on an 8088 CPU with an 8-bit data bus. The system but isn't quite the same as an IBM PC but I implemented a circuit similar to the one here:

www.mylinuxisp.com/~jdbaker/oldsite/documents/xtide.txt (http://www.mylinuxisp.com/~jdbaker/oldsite/documents/xtide.txt)

It will latch the upper 8-bits so that by doing two writes or two reads you can get all 16-bits and easily interface it to an 8-bit port. I'm sure something like this could be used to make the IDE work with the Propeller.

Having all 16-bits available will enable a driver to query the IDE device for the parameters. It will then know what the drive specs are and will be able to use the full capacity of the device.

Robert

Post Edited (RobotWorkshop) : 5/5/2008 3:41:23 PM GMT

bambino
05-06-2008, 12:09 AM
Hippy,
Have you considered the 8255PPi chip?
I have collected all the resources to build the circuit, I've just got too many other projects with precidence over this one to have made much head way.

I have thought many times how neat it would be to just use the propeller, but the components involved can't beat the one chip 8255 solution!

hippy
05-06-2008, 01:13 AM
@ RobotWorkshop : Drive geometry determination isn't too bad as long as the HDD supports the
Identify Disk command. Although only the LSB of cylinder count comes back, it's easy enough to
keep adding 256 and reading sectors until the drive throws a 'doesn't exist' error. Same can be
done with sector count but I'm not sure if that can go above 256 anyway.

Even without Identify Disk support it would be possible to do that but would take a little longer.
Once determined the data can be stored in Eeprom, at turn on it should be a simple case of
checking the last sector exists and the next doesn't, otherwise one knows the disk has been
swapped and geometry can be determined again.


@ bambino : An 8255 or any register / latch should do the job although direct to I/O pin I find
far more pleasing. To get the level-shifting the Propeller will need something, and the 8255 could
be a single chip solution.

A micro could do the job and a serial ( I2C ? ) interface would minimise the Propeller I/O required
if speed wasn't crucial.

bambino
05-06-2008, 04:19 AM
Here has been my inspiration if you decide to go this way!
http://www.pjrc.com/tech/8051/ide/#schematic
http://www.pjrc.com/tech/8051/ide/wesley.html

Both however did not use port C for control lines to the hard drive, this would be my suggested improvement as bit minipulation is possible with port C only. Using port A or B only allows for byte manipulation!


PS. I have a book on the 8255, if you get any specific questions I'll try to look them up for you.
·And also the author reccomends one invertor chip as well to keep the Hard drive from resetting when resetting·the 8255 control registry.

Post Edited (bambino) : 5/5/2008 9:25:26 PM GMT