Thread
IBM 1.44M <-> Mac 400k/800k/1.44M or SCSI Hack?
wow, the pc hardware always gets the cool mods first 
That's not PC hardware, that's an upgrade for older Consumer Market Music Hardware with FDDs inside, a relatively small present day market. That's why it's $20, but compared to our market, that's still HUGE. If PC's needed a snail paced floppy emulator . . .
. . . there'd be thirty different versions from China competing on eBay for your $2.98. :-/
. . . there'd be thirty different versions from China competing on eBay for your $2.98. :-/
Hmm...
As is, not without a cable adapter and a firmware rewrite. On the other hand, someone could put the maker in touch with bigmessowires. If the device's firmware can be adapted using his micro code, the maker has a whole second market for their device for minimal outlay.
As is, not without a cable adapter and a firmware rewrite. On the other hand, someone could put the maker in touch with bigmessowires. If the device's firmware can be adapted using his micro code, the maker has a whole second market for their device for minimal outlay.
OK! Three great suggestions in one session, man, you are on a ROLL!
Buy a lotto ticket tonight, B! I was thinking we'd need to do a microcontroller interface hack to get all three Mac FDD protocols & SCSI outta this lil' bad boy.
@ tk: would this be possible using what you've already got started for CF<->SCSI? I'm wondering if the limiting factor for data transfer is the PC's FDD I/O?
With a MicroController emulating the FDD Controller, it may be able bit bang the schiznit outta of this thing . . . just maybe? :?:
@ musical comrades w/compatible KBDs (ebony & ivory UI
) is my assumption that these are bi-directional a safe one to make?
Buy a lotto ticket tonight, B! I was thinking we'd need to do a microcontroller interface hack to get all three Mac FDD protocols & SCSI outta this lil' bad boy.
@ tk: would this be possible using what you've already got started for CF<->SCSI? I'm wondering if the limiting factor for data transfer is the PC's FDD I/O?
With a MicroController emulating the FDD Controller, it may be able bit bang the schiznit outta of this thing . . . just maybe? :?:
@ musical comrades w/compatible KBDs (ebony & ivory UI
) is my assumption that these are bi-directional a safe one to make?
My memory was jogged regarding repair of those older keyboard instruments: most of them take standard PC floppy drives. A quick search on ebay shows a large number of such USB floppy emulators available, some at better prices than the above offering. Some of the listings mention industrial control equipment, embroidery machines, others, musical instruments - but (apart from a few "slimline" ones) they all look identical.
In any case I'd say what we have here is a mass-produced device for standard PC floppy emulation only, and unless the device's firmware is re-writeable (doubtful) not much use to us.
On the other hand, $20-$30 is probably less than building a DIY prototype, so if anyone were so inclined, it could be worth cracking one open for a look-see.
In any case I'd say what we have here is a mass-produced device for standard PC floppy emulation only, and unless the device's firmware is re-writeable (doubtful) not much use to us.
On the other hand, $20-$30 is probably less than building a DIY prototype, so if anyone were so inclined, it could be worth cracking one open for a look-see.
SCSI ... ain't gonna happen. Whatever micro is running this thing will have been budgeted with just enough grunt and just enough pins to do the job demanded of it, and nothing more. SCSI is a much more demanding task on both fronts.
Besides which, what would be the point? If you're doing a "microcontroller interface hack", what does this device add to the solution? A ten cent socket and a case?
Completely unrelated.
As in read/write? I assume so. Ask the seller.
MicroController <-> SCSI interface, firmware and software ought to be directly related actually, I/O availability is another story. In looking at the pinouts, I'm wondering, is a floppy drive a serial interface? Analog or digital? I've never really looked at it before, but had no reason to. The usual references don't even say! There aren't enough read and write pins for it to be parallel at first glance.
I cannot imagine that current MicroControllers or FPGAs that are up to doing this conversion can't communicate faster than a Floppy Controller, but I've been wrong before. It sure would be nice to go from USB to SCSI bi-directionally by hacking this production hack. Getting data onto anything but a pre-SCSI Mac even a little faster than a Floppy Controller can do would be a good thing.
I cannot imagine that current MicroControllers or FPGAs that are up to doing this conversion can't communicate faster than a Floppy Controller, but I've been wrong before. It sure would be nice to go from USB to SCSI bi-directionally by hacking this production hack. Getting data onto anything but a pre-SCSI Mac even a little faster than a Floppy Controller can do would be a good thing.
I do not see the point of attaching this to a SCSI bus for any reason. At that point you aren't at all doing anything useful. If you want speed, why the hell do you want a SCSI interface when you have flash memory? If you want portability, are you implying that USB would be less useful than SCSI?
Correct with my Emax being an exception. Mine takes the annoying 720k half height 3.5" drives whicha re impossible to source and the keyboard refuses to work with much else.
I can't believe there wasn't an off the shelf solution back in the day for attaching PC FDDs to Macs. Wasn't there a BYO Mac trend there for a minute in the early 90s?
Nope, no 1.44 FDD interface that I know of offhand. Back when CatMacs and the Hackintosh were born, the 800k drive was was still standard, even on the SE and Mac II, it wasn't until the release of the IIx in late 88 that the 1.44 Mac drive became standard, after that, the 1.44 FDD became the standard for PCs. BYOM was no longer a viable option at that point.
In 1995, Apple paid lip service to the notion of the Common Hardware Reference Platform. The CHRP systems would have used standard IBM compatible FDDs and other components in Macs for the first time. Apple killed CHRP when they began losing the high ground in the Clone Wars, even before SJ returned in 1997 and killed off the Clones.
This is the way I see it:
0 = Number of IDE or PCMCIA wedges into the NuBus Architecture for Flash Memory until IDE in Quadra 630 and PCMCIA in the BlackBirds, IIRC.
0 = Number of USB solutions for the NuBus Architecture implemented to date.
USB is only available to PCI Architecture Macs.
This IBM FDD Emulator could be half way to the first bidirectional USB storage hack for the NuBus Architecture ever done.
Because of this, if a SCSI Controller can transfer available data at a rate any appreciable percentage higher that of the Wozniak Machines, SCSI makes all the sense in the world to me.
In 1995, Apple paid lip service to the notion of the Common Hardware Reference Platform. The CHRP systems would have used standard IBM compatible FDDs and other components in Macs for the first time. Apple killed CHRP when they began losing the high ground in the Clone Wars, even before SJ returned in 1997 and killed off the Clones.
:?: If the FDD emulator can transfer data to the PC FDD interface any faster than the a floppy controller on a Mac can read that data across its own FDD Controller, SCSI is the only method available for the NuBus Architectur to leverage that increased transfer rate potential.
Because we don't have any flash memory capability until IDE and PCMCIA interfaces appear on the Mac Horizon in the very late Quadra and PowerBook eras.
I don't think I understand the question. The USB dongle would be the portable part of the scenario. The FDD Emulator and MicroController based SCSI or Mac FDD Adapter for that Emulator would be installed on the target Mac.
This is the way I see it:
0 = Number of IDE or PCMCIA wedges into the NuBus Architecture for Flash Memory until IDE in Quadra 630 and PCMCIA in the BlackBirds, IIRC.
0 = Number of USB solutions for the NuBus Architecture implemented to date.
USB is only available to PCI Architecture Macs.
This IBM FDD Emulator could be half way to the first bidirectional USB storage hack for the NuBus Architecture ever done.
Because of this, if a SCSI Controller can transfer available data at a rate any appreciable percentage higher that of the Wozniak Machines, SCSI makes all the sense in the world to me.
Trash80, you can't just wave the words "microcontroller and/or FPGA" around like they can magically solve anything you throw at them. There are a billion and one different ICs that fall under those two categories, and their capabilities vary enormously. Someone has to spec it, design it, build it and code it - and in the case of a production unit, budget it.
This item will have the bare minumum IC required for the task it is designed and budgeted for. I used the words "completely unrelated" because this item is a floppy emulator. If you want to talk about this item, then it has nothing to offer us towards a SCSI solution.
WHY. WHAT DOES THIS EMULATOR BRING TO THE PARTY WHEN YOU HAVE A MICRO OF YOUR OWN CHOOSING RIGHT. THERE. Let alone the triple backflip of data format conversions you're talking about, and choking the SCSI bandwidth down through the incredibly slow floppy bottleneck to reach a fast USB device on the other end.
Whatever you're smoking, I hope you brought enough for the whole class.
There are two useful things that could happen. They are totally unrelated in every conceivable way. I cannot emphasise that enough.
This item will have the bare minumum IC required for the task it is designed and budgeted for. I used the words "completely unrelated" because this item is a floppy emulator. If you want to talk about this item, then it has nothing to offer us towards a SCSI solution.
Sure it would.
Total dead-end, waste of time, talking out your uhoh hat, barking up the wrong tree altogether. Not. Going. To. Happen.
So, you want a micro to convert from SCSI to PC floppy so you can talk to this emulator's micro to USB...
WHY. WHAT DOES THIS EMULATOR BRING TO THE PARTY WHEN YOU HAVE A MICRO OF YOUR OWN CHOOSING RIGHT. THERE. Let alone the triple backflip of data format conversions you're talking about, and choking the SCSI bandwidth down through the incredibly slow floppy bottleneck to reach a fast USB device on the other end.
Whatever you're smoking, I hope you brought enough for the whole class.
There are two useful things that could happen. They are totally unrelated in every conceivable way. I cannot emphasise that enough.
- Hack this device's inbuilt micro to connect to the Mac floppy interface, with hopefully nothing more than some electrical conversion on the back end. ** NB MAY NOT BE POSSIBLE
- Build a direct, full-speed SCSI-USB interface from scratch.
Let's hope so! :approve:
Three lifetimes ago, I used to self-medicate to bring myself down to such levels of consciousness. Modern Psycho-pharmeceuticals seem to be a lot more efficient . . . for the most part. Though I've heard they're getting back to the prescriptive medicinal variety of same for treating my over-the-top symptoms. Go figure!
I'm not worried about being wrong about my suggestions far than I'm right, or of discovering the same without mentioning it. There is a long and colorful history of learning how not to make an incandescent filament. It just took one particularly persistent practitioner's perspective to give such processes legitimacy. [] ]'>
Nope, that's between my ears naturally . . . as unnatural as that might seem to some . . .
Three lifetimes ago, I used to self-medicate to bring myself down to such levels of consciousness. Modern Psycho-pharmeceuticals seem to be a lot more efficient . . . for the most part. Though I've heard they're getting back to the prescriptive medicinal variety of same for treating my over-the-top symptoms. Go figure!
I'm not worried about being wrong about my suggestions far than I'm right, or of discovering the same without mentioning it. There is a long and colorful history of learning how not to make an incandescent filament. It just took one particularly persistent practitioner's perspective to give such processes legitimacy. [
] ]'>*snicker*There is a long and colorful history of learning how not to make an incandescent filament. It just took one particularly persistent practitioner's perspective to give such processes legitimacy. [
I do have to say, Trash, I admire your enthusiasm, but this thread did get *pretty weird* at some points. (At one point I was convinced that you were proposing that the device in the OP was the Holy Grail for bringing a general purpose USB port to ancient Macintoshes....) Oh well, carry on!
On the subject of the device itself, it would be *mildly* interesting to crack one open and see what it comes with. (The documentation is incredibly sketchy) This appears to be the OEM of the incredibly cheap versions that are floating around. Apparently they sell separate versions for 1.44MB and 720k floppy emulation; it would be interesting to know it it's just a software difference or if the devices actually use different clock crystals or something for the different data rates. In any case, they appear to use a custom ASIC for the floppy interface, so it would probably be "somewhat difficult" (read: not going to happen) to retool this to do anything but Shugart/PC floppy emulation. And seriously, the floppy interface is the only thing of worth here. There are scads of microcontrollers out there that have sufficient USB host support to drive a USB memory stick. (If you simply *must* have that instead of, say, SD card, which is even easier to interface to practically *any* MCU.)
If I had a disk controller for my Tandy CoCo I'd probably buy a 720k version just for shniz and giggles.
Nope, no GP USB interface was ever considered, but a thumb drive adapter seems mighty enticing from my, somewhat over-enthusiastic, point of view.
I like your description, BTW, it's a bit more family friendly, if a bit less accurate, than Bat-Shniz Crazy.
"snicker" right back at ya. :lol:
I like your description, BTW, it's a bit more family friendly, if a bit less accurate, than Bat-Shniz Crazy.
"snicker" right back at ya. :lol:
You smarties keep tossing stuff like this around. If it's easy to interface SD cards to stuff, please make a SCSI<->SD thingamabob for us! Please? With sugar on it? We'll pay you and everythingSD card, which is even easier to interface to practically *any* MCU.There is a long and colorful history of learning how not to make an incandescent filament. It just took one particularly persistent practitioner's perspective to give such processes legitimacy. [
I suspect a significant part of this is that no PC floppy drives ever incorporated the disk detection and electrical inject/eject. That and IIRC the 800K drives vary the speed of the spindle to maintain a constant linear velocity. By the time you added all the bits needed to make a PC floppy drive work properly on a Mac, you wouldn't be saving any money over using a real Mac drive and you'd still have a lame manual eject drive.
Doesn't seem to be a great shortage of Mac floppy drives yet though. They're fairly robust and generally easy to repair. There may be some market for a floppy interface SSD, but I suspect a SCSI SSD would cover a far greater range of needs.
It's the SCSI side that's the tricky part. Nevertheless, research continues
Here is the design manual for the NCR 5380 SCSI chip used in the Mac Plus. The manual perfectly summarizes the problem on page 18:
In other words, the issue is that the SCSI bus itself isn't easily amenable to software-driven "bit-banging": it's timing-critical and some of the signal durations are really short, which means a proper SCSI MAC uses scads of latches to make it "friendly" for the microprocessor side. (If you did that with discrete logic instead of a controller chip you're looking at a fair-sized handful of parts.) Ironically newer technologies like SD card (and even IDE) let you be really sloppy by comparison. It's a serious engineering effort to do SCSI *without* using a SCSI chip. And if you DO use a SCSI chip you have to factor the cost and rarity of that into the equation, making it really hard to undercut the cost of commercial solutions that already exist. (They do, they're around a hundred bucks... how much cheaper do you want it?)
Code:
The NCR 5380 is easy to use because of its simple
architecture. The chip allows direct control and
monitoring of the SCSI bus by providing a latch for
each signal. However, portions of the protocol define
timings which are much too quick for traditional mic-
roprocessors to control. Therefore, hardware support
has been provided for DMA transfers, bus arbitration,
phase change monitoring, bus disconnection, bus
reset, parity generation, parity checking, and device
selection/ reselection.Just realized that by using "MAC" in this forum I might have sowed confusion. I'm using it in the networking context:
http://en.wikipedia.org/wiki/Media_access_control
IE, "The layer that turns raw electrical signals into a buffered stream of protocol commands and data".
Ironically IDE (and SD, and USB flash) all use very similar-to-SCSI commands for data handling. It's interesting to compare the commands in the 5380 manual to IDE/Compact Flash documentation, and in fact also compare the microprocessor-facing hardware interfaces of the two devices. Seriously, if it wasn't for the sticking point of having to rewrite the driver it would probably be way simpler to design a hardware wedge that substitutes a Compactflash card directly for the 5380 in a Mac Plus than it is to have to pick it up on the SCSI side.
Regarding 800K floppies: Someone up-thread mentioned that the spindle speed varies, amongst other things, on the Macintosh floppy drive. This is exactly correct and one of the major issues in converting from PC floppy mechanism to Mac floppy mechanism. The PC floppy mechanism has no provision for varying the spindle speed.
Outbound (anyone remember them) did it. They used Citizen brand PC laptop floppy drives in their laptop Macintosh clones. There's a circuit board between the Mac clone and the floppy mechanism though. On the circuit board there is a 37C765 floppy controller, a WD92C32 data separator, a little digital potentiometer, XP9103, an EEPROM and a 20 pin PLD. The external floppy version also has an 85C30 on board, suggesting that the Outbound's external comm bus is some flavor of serial ocmmunication -- maybe. Or it could be a bit of a copy of the HD20's hardware structure.
That same port could accept Outbound's SCSI adapter instead of the external floppy. The SCSI adapter also has an 85C30 on board as the most upstream device. It's simpler than the floppy control board though. It only has an 53C80, an EEPROM and another 20 pin PLD on board -- oh and a couple or dozen transistors.
Outbound (anyone remember them) did it. They used Citizen brand PC laptop floppy drives in their laptop Macintosh clones. There's a circuit board between the Mac clone and the floppy mechanism though. On the circuit board there is a 37C765 floppy controller, a WD92C32 data separator, a little digital potentiometer, XP9103, an EEPROM and a 20 pin PLD. The external floppy version also has an 85C30 on board, suggesting that the Outbound's external comm bus is some flavor of serial ocmmunication -- maybe. Or it could be a bit of a copy of the HD20's hardware structure.
That same port could accept Outbound's SCSI adapter instead of the external floppy. The SCSI adapter also has an 85C30 on board as the most upstream device. It's simpler than the floppy control board though. It only has an 53C80, an EEPROM and another 20 pin PLD on board -- oh and a couple or dozen transistors.
It would be interesting to know how Outbound's solution worked with the IWM driver in the Mac ROMs. (Outbounds used ROMs pulled from genuine Macs, didn't they?) Did the circuit board emulate the IWM, did they patch the software somehow, or what?
It's interesting to contrast Apple's Macintosh drives with Commodore GCR drives; both systems cram a variable amount of data onto different tracks on the floppy disk. The difference is that Apple did it by varying the spindle speed, while Commodores do it by changing the data rate. There is another thread on this board where someone says that essentially the Outbound uses the magic on that board to allow a fixed-speed floppy drive to read and write Mac floppies the Commodore way, and that makes perfect sense.
(Again, I'm just sort of curious if it was software-transparent or involved a patch. They must have already been patching the Mac ROM to use the larger 640x400 screen...)
Apple's floppy drives are really stupidly overly-engineered. Commodore's variable-rate floppy drives predated the Mac by over five years, and it's a better solution; the variable-spindle speed thing was invented for the Twiggy and it's the major reason that device failed. It takes several rotations to change the spindle speed and get it stable (there's this thing called "inertia"), and the problems get worse the physically larger the device. Apple is lucky the Sony mechanism worked as well as it did once they were done with it.