PDA

View Full Version : parallel port floppy interface for disk imaging?



nige the hippy
March 29th, 2007, 05:06 PM
Just having a thought regarding backing up & imaging odd floppy disk formats, and came up with the idea of using a parallel port as a disk interface, to get round the limitations of the PC floppy disk controller.

at first i thought that the speed of the parallel port might be a problem, but apparently it will transfer up to 2 megabytes a second, so the 500k bits per second of a floppy data line shouldn't be a problem. I also think that there are enough lines on a parallel port to handle the necessary signals.

Apparently the amiga just grabs a track's worth of completely raw data, and processes it in software.

I just wondered if anyone had done a software (& cable) only imager already?

(Brief pause in post as wife's waters break.... nothing major happening yet!)

I know that there's a program to hack the floppy controller with a second drive and a formatted disk, but although fiendishly clever it does seem to be a bit of a cludge. possibilities???

(will put a post in O/T when anything more happens!)

SwedaGuy
March 30th, 2007, 04:50 PM
My solution was to get a parallel port floppy drive...

Sounds obvious, I know...

Your problem is a bit more difficult, though, as I have to load drivers to make the floppy drive work this way. It would be the classic "cart before the horse" problem if you are trying to copy off of anything but a DOS machine...

Hmmm, though it makes me wonder if a driver could be created for whatever platform you happen to be using. I may have to dust that thing off and see what kind of information I can come up with.

I'll keep you posted....

nige the hippy
March 31st, 2007, 02:48 AM
actually, when i was doing quite a bit of control stuff using PCs, I used DOS and didn't need drivers, just peeked and poked to &H3BC etc. The idea was to use a single line for each of the interface lines, and do all the PLL ing etc in software, possibly even machine code. Actually thinking about it, it would be difficult to do under windows, as (after failing miserably to do real-time apps under windows before) I learnt the hard way that windows spends too much time buggering about doing unneccessary things, rather than doing the job you need it to do.

p.s. girl, 7lb 10oz, 5:30 am all ok! ZZZZzzzz

mbbrutman
March 31st, 2007, 05:04 AM
I think that one of the appealing parts of doing the interfacing yourself instead of using a pre-packaged parallel port solution is that you can record the data coming from the drive at a more raw level. (You are interfacing the parallel port directly to the drive, not to an external drive controller.) The concern would be the speed of the parallel port - you can only hit 2MB/sec using the advanced ECP and EPP features of the parallel port.

The parallel port solutions won't handle non-standard types or copy protections at all.

PS - You are a new father? Congratulations! No time to be posting here anymore! (I noticed the edit time after the post, and presume you will anxiously awaiting when you made that post, and edited it after you calmed down from the big event.)

SwedaGuy
March 31st, 2007, 07:05 AM
Actually thinking about it, it would be difficult to do under windows, as (after failing miserably to do real-time apps under windows before) I learnt the hard way that windows spends too much time buggering about doing unneccessary things, rather than doing the job you need it to do.

You certainly hit the nail on its proverbial head there!

Congratulations on the new member of your family...you've got quite a journey ahead!

Terry Yager
March 31st, 2007, 07:09 AM
Grats, Nige!

--T

nige the hippy
March 31st, 2007, 08:07 AM
I think that one of the appealing parts of doing the interfacing yourself instead of using a pre-packaged parallel port solution is that you can record the data coming from the drive at a more raw level. (You are interfacing the parallel port directly to the drive, not to an external drive controller.) The concern would be the speed of the parallel port - you can only hit 2MB/sec using the advanced ECP and EPP features of the parallel port.

That said - hardware is hardware! theoretically the gates should be still writeable to, and readable from, at the maximum bandwidth the interface can handle - I wish i was familiar with assembler on the PC, someone who is could possibly look to see the max frequency they can detect???



The parallel port solutions won't handle non-standard types or copy protections at all.

The pre-packaged ones- definitely no



PS - You are a new father? Congratulations! No time to be posting here anymore! (I noticed the edit time after the post, and presume you will anxiously awaiting when you made that post, and edited it after you calmed down from the big event.)

Ach! it isn't so much the new daughter, as the 22 month old one who just runs off and hides anything portable & technical (and therefore interesting) was in the process of getting a breakout box and leads together to answer Nathan's Altos question (and satisfy my own curiosity (the terminal has a faulty mains switch )) when i discovered that she's run away with the key to the desk drawer I locked to stop her running off with my test adaptors!

New one took a while arriving, but is just totally heart-melting!

Thrashbarg
March 31st, 2007, 06:53 PM
My immediate thoughts for a parallel port floppy is to use a WD1772 floppy disk controller, have it attached to a fast microcontroller of some sort (Atmel?) and some RAM for buffering, then use the parallel interface to read from the RAM.

I suggest the WD1772 because it is much easier to use than the 8272 used in the PC's and can read whole tracks, header information and everything. Provided you can find one. I got mine from an Atari ST that died.

And congratulations Nige!

nige the hippy
April 2nd, 2007, 02:03 PM
my initial thoughts were to bypass the disc controller (because I didn't want to restrict formatting types, also it's all digital signals which don't need conditioning) and also use a microcontroller (+ram)to do part of the job that the disc controller was doing, i.e. handling the stepping in and out, reading the position of the index pulse, and recording the position of flux transition pulses relative to the index pulse(s) (i appreciate some formats don't need an index pulse, but the idea is to record and copy data, not to (immediately) interpret it, the index indicates a complete track's worth of data has been recorded)

But then I realised that there is a hulking great micro the other side of the perfectly accessable parallel port that can run at a few hundred mips so why bother making things complicated by putting another micro in the way? (only prob is, that I can program pics, atmels, and 8051s etc, but not a P3!)

Thrashbarg
April 3rd, 2007, 05:29 AM
Just a thought, what if you modified an old Apple Disk ][ for parallel port operation?

As I understand it all the disk did was read the magnetic fluxes and convert them to some sort of TTL level.

Svenska
April 7th, 2007, 04:59 PM
Hello,

it might be not exactly what you are searching, but there is a project called LPTISA around: http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/LPTISA/

This interface allows you to connect a 8 Bit ISA-Card to a parallel port (in ECP/EPP/PS2 mode), if the software is able to run in a Windows 3.x Dosbox and doesn't use DMA. Included is a Windows 3.x driver in source and binary form.

This might save you some work if you really want to build some kind of floppy controller. :-)

(Sorry that it is in German; I could translate it for you.)

Kind regards,
Svenska