A2 5.25" drive on a PC?
Tim Haynes
MFM/GCR differences.
What about the possibility of putting together a specialized cable that
would adapt a standard A2 5.25" drive to a PC's serial port? The cable
would also have to pull power from somewhere - possibly from a molex
connector hooked into the PC's power supply? And then we'd need some
specialized PC software to actually do the reading/writing.
Does this seem at all feasible? Any thoughts?
Linards Ticmanis
> We all know that a PC cannot read/write an A2 disk because of basic
> MFM/GCR differences.
>
> What about the possibility of putting together a specialized cable that
> would adapt a standard A2 5.25" drive to a PC's serial port?
You need a data rate of 255,682 bits per second, and you need to keep
that rate quite exactly; that's beyond the capability of standard PC
serial ports. Plus, the drive can't deal with the start/stop bits which
the serial port expects. Plus, the voltages are wrong.
On the paralell port, maybe; but at least write timing will be
problematic, and still some voltages will be wrong.
> The cable
> would also have to pull power from somewhere - possibly from a molex
> connector hooked into the PC's power supply?
If you don't mind that the drive will always spin, this will be easy;
otherwise you need to build something to switch the motor power on and
off. Standard PC ports can't source enough current by far to run the
drive motor on a switchable line without external electronics.
> And then we'd need some
> specialized PC software to actually do the reading/writing.
Right; and it would in all probability run only in pure MS-DOS mode.
Otherwise correct timing is probably impossible to get.
> Does this seem at all feasible? Any thoughts?
Maybe it's doable, but it wouldn't be too easy.
--
Linards Ticmanis
Linards Ticmanis
> On the paralell port, maybe; but at least write timing will be
> problematic, and still some voltages will be wrong.
Come to think of it, hooking up a Disk-II controller card to the PC, and
then connecting the drive to that card as usual, is probably a good bit
easier.
--
Linards Ticmanis
Michael Black
I just thought of this last week, with the recent thread about reading
Apple disks on a PC.
But when I gave a quick glance for the disk controller manual, I couldn't
find it. So I didn't take a close look at the schematic.
BUt it would be the parallel port that would likely be the useuable
port, because various control lines are needed, and you have more control
over the lines than with the serial port where it's all pretty fixed.
The Apple II was a pretty limited system compared to current computers.
There may have been a good reason to shift some of the work to the controller
card back then, while today there is bound to be enough computer power to
handle just about anything.
One would have to look over the controller schematic, figure out what's
being done, and how to do that in software. There may be no way to
eliminate all the hardware; I think of those LS125 drivers that at the
least may be needed (or something like that) to provide enough drive for
the signals going to the actual drive.
Given the simplicity of the original controller card, even if some of
it was needed it wouldn't be much.
MIchael
Bryan Parkoff
"Michael Black" <et...@FreeNet.Carleton.CA> wrote in message
news:dlvhhj$jgj$1...@theodyn.ncf.ca...
I do know someone who they already wired Disk II Drive to parallel port.
The problem is that 6502 CPU must be involved to manipulate Disk II Drive to
capture bit by bit at 1MHz timing. 80x86 has minimum 8MHz which all
instructions do not match to 6502 instructions using exact cycle by cycle.
They tried to use x86 instructions to capture bit by bit through
parallel port at exact timing, but they got the wrong data in the bit
stream. It would be better to build simple few chips like Disk II
controller. It can be installed in PCI slot or USB port. Capture data in
the bit stream per second would be the memory buffer so x86 instructions are
able to capture memory buffer and transfer to the memory space.
Bryan Parkoff
Paul Schlyter
Linards Ticmanis <ticm...@gmx.de> wrote:
> Tim Haynes wrote:
>> We all know that a PC cannot read/write an A2 disk because of basic
>> MFM/GCR differences.
>>
>> What about the possibility of putting together a specialized cable that
>> would adapt a standard A2 5.25" drive to a PC's serial port?
>
> You need a data rate of 255,682 bits per second, and you need to keep
> that rate quite exactly; that's beyond the capability of standard PC
> serial ports. Plus, the drive can't deal with the start/stop bits which
> the serial port expects. Plus, the voltages are wrong.
>
> On the paralell port, maybe; but at least write timing will be
> problematic, and still some voltages will be wrong.
By adding some transistors, one can get the voltages right. But that
extra electronics would probably need its own power from somewhere.
>> The cable would also have to pull power from somewhere - possibly from
>> a molex connector hooked into the PC's power supply?
>
> If you don't mind that the drive will always spin, this will be easy;
> otherwise you need to build something to switch the motor power on and
> off. Standard PC ports can't source enough current by far to run the
> drive motor on a switchable line without external electronics.
When adding some transistors to get the voltages right, one could as
well add a few more transistors to let some suitable pins on the
parallell port switch the drive's motor on and off, and also control
the stepper motors.
>> And then we'd need some specialized PC software to actually do the
>> reading/writing.
>
> Right; and it would in all probability run only in pure MS-DOS mode.
> Otherwise correct timing is probably impossible to get.
Not impossible - just a bit harder. One would need a kernel mode
device driver running on Win32 (or Linux). And one would also need
to turn interrupts off at least while writing to a sector (a sector
read can always be retried if an interrupt destroys the timing).
If we add some transistors to that cable, perhaps we could as well
add a microcontroller which can read or write (and buffer) the
nibble data of one sector on the Apple II floppy. That microcontroller
should have all interrupts turned off to ensure accurate timing in
the instructions. Then the software on the PC side could be written
at the application level and wouldn't need to be kernel mode device
drivers.
And if one really wanted to be fancy, one could make that microcontroller
board for the Apple II disk drive connect to the PC through a USB
cable rather than a parallell port. That would of course be even
harder, but more convenient to use when it's all finished.
>> Does this seem at all feasible? Any thoughts?
>
> Maybe it's doable, but it wouldn't be too easy.
I fully agree on that.... :-)
> --
> Linards Ticmanis
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/
Tim Haynes
Sorry, just to correct myself: I mean parallel port, not serial port.
I liked the idea of hooking up a Disk II controller card rather than
just the bare drive. That definitely seems like it would simplify things.
Ed Eastman
> Maybe it's doable, but it wouldn't be too easy.
The hardware would be fairly easy.
So if I build an adapter to hook the data and control lines from a
floppy disk to the parallel port and also to the standard power
connector of a PC, would someone write the software to operate it?
Lemme see, 8 data lines on a parallel port, a latch to hold
signalling... Now where'd I put that disk drive schematic...
Thankx,
Ed
Sean Fahey
>
> I liked the idea of hooking up a Disk II controller card rather than
> just the bare drive. That definitely seems like it would simplify things.
C:>pr#6
Bad Command or Filename
Scott Alfter
Hash: SHA1
In article <dlv9lt$kv8$1...@rumours.uwaterloo.ca>,
A serial port would be way too slow (maximum speed is only 115.2 kbps), and
they're disappearing from many computers. (Macs haven't had 'em since
whenever the iMac was introduced, and they're disappearing from x86 boxen as
well...neither of my HP notebooks have them.)
What would be more interesting would be a USB-to-Disk-II dongle that has
enough hardware (a 6502-compatible processor or core and some software to
read/write/format GCR). You could ask it to read or write a particular
block and it'd do so. For dealing with the various anti-fair-use schemes
that were devised, the firmware for the dongle would be transferred in from
the host at runtime so it can be changed from the default if needed.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( http://alfter.us/ Top-posting!
\_^_/ rm -rf /bin/laden >What's the most annoying thing on Usenet?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDg9NlVgTKos01OwkRAk1MAKDpG9VSW9K1aczuvcAaC4KlYi4cvgCg7n9H
fCJrhlxnl/9PQKVQK+X4Kx8=
=EWKR
-----END PGP SIGNATURE-----
joseph...@gmail.com
Scott Alfter wrote:
> What would be more interesting would be a USB-to-Disk-II dongle that has
> enough hardware (a 6502-compatible processor or core and some software to
> read/write/format GCR). You could ask it to read or write a particular
> block and it'd do so. For dealing with the various anti-fair-use schemes
> that were devised, the firmware for the dongle would be transferred in from
> the host at runtime so it can be changed from the default if needed.
This is the first post in this thread that made much sense at all.
On the other hand, the use of a widely available Apple II system with a
serial port attached is pretty competitive. And there are tolerable
development environments for the Apple II, versus a roll-your-own
system.
For a dongle to work, you still need the equivalent of a Woz machine
for your microcontroller to talk to the Disk II, and you need enough
RAM to store a sector or a track, and enough CPU to de-nibblize or
nibble-analyze if you want to handle non-standard disks. Sounds pretty
much like an Apple II with a nibble copier in that dongle.
The idea others mentioned of driving a Disk II directly with a parallel
port is just nutty. You need clocking (the Disk II controller uses 2
MHz) and a synchronizing circuit to get the read pulses to make sense.
You might be able to manage to talk to a Woz machine without too much
hassle.
Lyrical Nanoha
> What would be more interesting would be a USB-to-Disk-II dongle that has
> enough hardware (a 6502-compatible processor or core and some software to
> read/write/format GCR).
Thankfully, I think WDC still makes the 65C02.
-uso.
Mark Frischknecht
They make a W65C02S a lower powered version of the 65c02... 1.8 to 5.o
volt... ideal for usb..
sicklittlemonkey
desirable
for this sort of device.
> Sounds pretty much like an Apple II with a nibble copier in that dongle.
More like an Apple II drive card (AKA Woz Machine) and a driver on the
host
PC to interface it to an emulator. The WM could be implemented in
software
on a microcontroller with enough RAM (say 8 or 16k) to buffer a track
of nibbles
(plus some timing info to handle nonstandard disks).
The rest would be up to the driver and emulator/ disk app.
Sean Fahey
>
> The rest would be up to the driver and emulator/ disk app.
>
Maybe some ideas can be borrowed from this project:
sicklittlemonkey
Indeed. He's halfway there (from the PC side). ;-)
Just needs to emulate a WM and interface to a real drive.
Thanks for the link.
Nick.
joseph...@gmail.com
sicklittlemonkey wrote:
> This is a neat idea, and I don't think the 6502 is necessary or even
> desirable
> for this sort of device.
>
> > Sounds pretty much like an Apple II with a nibble copier in that dongle.
>
> More like an Apple II drive card (AKA Woz Machine) and a driver on the
> host
> PC to interface it to an emulator. The WM could be implemented in
> software
> on a microcontroller with enough RAM (say 8 or 16k) to buffer a track
> of nibbles
> (plus some timing info to handle nonstandard disks).
Yes but microcontrollers that support so much RAM in an efficient
enough way to handle a whole-track buffer are pretty much on an equal
level with a 6502, but with the disadvantage that the cycle timings are
all different, so you have to redesign an RWTS routine that is
equivalent to the 6502 version in order to support writing, except in a
"track-at-once mode" or something. Implementing the woz machine state
controller in software on a microcontroller is also going to be *very*
tricky. The hardware version runs absolutely cycle-for-cycle
predictably at a 2 MHz clock rate.
That pretty much means you are making a microcomputer roughly as
powerful as the Apple II+Woz machine in your dongle, or giving up
single-sector writes.
For read-only purposes, you could basically dump the read pulses
sampled at a 2 MHz rate or so, into a FIFO, then process it on the host
PC.
Bill Garber
"josepho...@hotmail.com" <joseph...@gmail.com> wrote in message
news:1132764690.9...@z14g2000cwz.googlegroups.com...
>
> sicklittlemonkey wrote:
>> This is a neat idea, and I don't think the 6502 is necessary or even
>> desirable
>> for this sort of device.
>>
>> > Sounds pretty much like an Apple II with a nibble copier in that
>> > dongle.
>>
>> More like an Apple II drive card (AKA Woz Machine) and a driver on the
>> host
>> PC to interface it to an emulator. The WM could be implemented in
>> software
>> on a microcontroller with enough RAM (say 8 or 16k) to buffer a track
>> of nibbles
>> (plus some timing info to handle nonstandard disks).
>
> Yes but microcontrollers that support so much RAM in an efficient
> enough way to handle a whole-track buffer are pretty much on an equal
> level with a 6502, but with the disadvantage that the cycle timings are
> all different, so you have to redesign an RWTS routine that is
> equivalent to the 6502 version in order to support writing, except in a
> "track-at-once mode" or something. Implementing the woz machine state
> controller in software on a microcontroller is also going to be *very*
> tricky. The hardware version runs absolutely cycle-for-cycle
> predictably at a 2 MHz clock rate.
Being the read/write cycle for the drive itself is so tight,
I recommend dropping direct read/write completely.
> That pretty much means you are making a microcomputer roughly as
> powerful as the Apple II+Woz machine in your dongle, or giving up
> single-sector writes.
Giving up any direct access to the drive and file systems is
most advisable.
> For read-only purposes, you could basically dump the read pulses
> sampled at a 2 MHz rate or so, into a FIFO, then process it on the host
> PC.
Memory cost and size nowadays is such that reading the
entire disk to ram would be the way to go, then manipulate
the data in ram, and write it all back to a fresh disk or
formatting the one read (if it is not an original) and
you'll have something you can actually use efficiently.
Also, the best connection to the PC/Mac would be USB,
being that is the trend now. Serial, too slow, and
parallel, almost non-existant in newer machines, are
not feasible. A memory device attachment?, maybe, but,
the software would be very complex. These would be,
just a few, SD/MMC/CF, etc......... Or better maybe
would PCMCIA.
Bill Garber
Patrick Schaefer
> For a dongle to work, you still need the equivalent of a Woz machine
> for your microcontroller to talk to the Disk II, and you need enough
> RAM to store a sector or a track, and enough CPU to de-nibblize or
> nibble-analyze if you want to handle non-standard disks.
You can build the basic Woz machine with a shift register and a prom. As
mentioned before, the access timing is critical, but you don't need to
use a 6502 - any other controller will do the same job.
There are many microcontrollers with USB, and at least the 8051 based
should have enough RAM for the de-nibbelizer.
Patrick
John
Apple II like a disk drive. To connect the PC and Apple II hardware you
have to construct a simple communication cable. A small ProDOS driver
program will manage the data transfer by the Apple II side.
(from the help file, jk)
sicklittlemonkey
This is pretty much enough to cover what people want from such a
device.
The all too frequent "How can I get my old Apple II disks onto a PC?"
and
occasionally the reverse. Anyone needing regular use of an Apple II
disk
with single sector writes could probably use either a real Apple II or
a disk
file with an emulator.
> That pretty much means you are making a microcomputer roughly as
> powerful as the Apple II+Woz machine in your dongle
As Patrick Schaefer posted, many microcontrollers would be more than
up to the task, even if a couple of extra chips would make it cheaper.
Moreover, we could grab better images (think .nib++) of protected disks
to preserve, rather than the cracked and hacked ones that abound.
Cheers,
Nick.
Jerry
What would be great is to use a fast(er) microcontroller that has enough
time to read whole tracks AND count sync-bits at the same time, so that
the whole track, including all sync bits can be transferred to the PC
for analysis. Do no decoding of the data on the microcontroller, and
instead do it all on the PC. This way all disks, copy-protected or not,
can be read!
--
Jerry Penner e-mail: remove the blips and _