Source for IWM Chips?

[bigmessowires]

Does anybody know where I might find IWM chips (the Integrated Wozniak Machine disk controller), other than by desoldering them from old motherboards? I'm 99.9% sure there's no other source, but it can't hurt to ask.

I'm considering designing a disk controller card for the Apple II that needs an IWM. It would be a lot easier to use a real IWM than to make an IWM work-alike in an FPGA...

 

[rsolberg]

Just in case you haven't come across it already in research, this document may be of interest: https://www.brutaldeluxe.fr/documentation/iwm/apple2_IWM_Spec_Rev19_1982.pdf

 

[bigmessowires]

Yes, thanks. I already made a partial soft-IWM in an FPGA as part of my Plus Too project, a few years ago. But it's a pain compared to just dropping in a real chip.

 

[superpete]

According to the MESS guys the Quadra 660AV/840AV/Centris 660AV used an NEC uPD72070GF which is an NEC765-derived FDC with added GCR support. I recall finding a datasheet for it one point - I'll check my archive.

EDIT See here https://drive.google.com/file/d/0B7Z23kbbiG5JeFQtSjl2WWZKZk0/view?usp=sharing- I'm guessing it's from bitsavers though i didn't note where it came from in my collection.

EDIT2: Amazingly it looks like there's still "suppliers" with stock (2)! Whether you want to base a product around them or not is another thing. Or even if it'll work for an Apple 2 application rather than a Mac...

 

[360alaska]

Finding a new one seems impossible, maybe you can use a newer one from a mac like I did here: https://68kmla.org/forums/index.php?/topic/25854-alaskas-collection/

 

[Gorgonops]

I'm considering designing a disk controller card for the Apple II that needs an IWM.

Out of curiosity, is this disk controller supposed to support real drives, or is this going to be a directly slotted Apple II virtual drive, ala Floppy Emu? If it's the latter I'm not actually sure what the point of using a real IWM would be. There's just not much to it, particularly if you're only looking to emulate the "low density" Disk][-compatible functionality.

 

[Gorgonops]

It's unfortunate how the documentation for this project has disappeared off the web. It appears it used a single CPLD as the "glue" between a microcontroller emulating a Disk ][ and the Apple bus. Presumably it roughly emulated an IWM or, at least, the discrete Disk ][ controller of which the IWM is a superset.

 

[unity]

I wonder if Woz himself would be of any help. I know, sounds silly. But he is a pretty active guy and you know how he still loves projects like this. It would not hurt to ask.

 

[rsolberg]

I thought of the Woz angle too, but he wasn't directly involved in the design of the IWM- Wendell Sander was. Woz's original disk controller design used a whole bunch of discrete logic and requires a number of components on the card. Wendell's IWM integrates all of the logic of the card into a single IC.

Does the IWM have any features you require compared to the Woz Disk II card? If not, would it be feasible to replicate its functions with off the shelf TTL ICs rather than going the single chip or programmable logic route?

 

[Gorgonops]

Woz's original disk controller design used a whole bunch of discrete logic and requires a number of components on the card.

A "whole bunch"? The Disk ][ controller has like six chips on it and I believe two them are PROMs holding the boot code.

To be clear, neither Woz's original design nor the IWM (prior to the SWIM, which incorporates significantly more hardware to handle MFM support) actually do a whole lot. It's little more than a primitive UART, basically everything it does is software driven by the main CPU.

 

[rsolberg]

Perhaps "handful" is a better quantitative adjective.

Five 74-series ICs, two PROMs, a NE556 timer, and a sprinkling of passive components.

 

[bigmessowires]

The project is a clone of the Liron disk controller for the Apple II+ and IIe. It's basically an IWM on a card, with a small ROM and a few glue chips. With this card, the II+ and IIe gain a "Smartport", which was originally used to talk to an 800K Unidisk 3.5 inch drive. With a Liron card, it's possible to use the Floppy Emu in hard disk emulation mode on the II+ and IIe, so you can get multiple 32 MB virtual hard disks. With a standard floppy controller card, it's only possible to emulate a 140K floppy drive on those two Apple II models. 

The trouble is that the Liron card is fairly rare. If they were widely available at a reasonable price, it would make the Floppy Emu a more compelling device for II+ and IIe owners. I don't really care about Unidisk 3.5 support, so for me a Liron clone would basically be a Floppy Emu accessory.

I have all the information I need to make a clone card, if I had a source of IWM chips. I may build a prototype with an IWM stolen from another machine, just to confirm that everything else works the way I think it does. But then I'll need to create an IWM replacement somehow. That shouldn't be crazy difficult, since it's well-documented, but it's not exactly easy either.

To Gorgonops' point, for my purposes it's not strictly necessary to make an exact Liron clone or have an IWM. I just need some way of getting the Floppy Emu to function as a hard disk on the II+ and IIe. Maybe there's a simpler solution, but when I've thought about what that might look like, it ends up being quite a lot like the Liron. So cloning something existing may be a simpler path than designing something entirely new.

 

[Gorgonops]

Ah, that makes sense.

I guess one thing that is worth at least considering is how, basically, you probably already have in the FloppyEMU almost all the hardware you need to interface it straight up to the Apple II bus sans any controller. That PsuedoDisk device I linked to earlier was just an AVR microcontroller, a CPLD to act as a decoder/buffer, and an EPROM for the Apple software. (The design of the II's slots, with pre-decoded memory spaces, makes it easy to hang things off it with minimal glue.) You already use a CPLD in the FloppyEMU, right? Ignorantly speaking I can't help but think that making a FloppyEMU board with a 50 pin card edge and EPROM socket would pretty much reduce this down to a coding exercise.

(I found the PseudoDisk creator's web page on the Wayback machine, and he described it as open-source. Maybe you could borrow from his CPLD and bus interface code?)

 

[bigmessowires]

Yes, it's definitely possible to turn the whole device into a card that fits an Apple II slot, and forget about all this Liron and IWM stuff. That's what the popular CFFA3000 card does, as well as a couple of other similar cards. I've thought a lot about doing that, and might do it, but there are some business reasons it might not be a great idea in my situation.

The biggest concern is it would splinter the audience. Instead of a single disk emulator that works on Mac, Lisa, and Apple II, a disk on a card would be a separate product that's Apple II-specific and would pull sales from the other product. The second reason is there are already a couple of good solutions for Apple II disk on a card, and it's probably smarter to spend my time developing retro-stuff in areas where there's nothing now (video? networking?) instead of competing head-to-head with other existing products. Before I went down that road, I'd want to be sure I could make something substantially better or cheaper than what's out there now. The third reason is that any Apple II card development that's not a straight clone of some pre-existing card would need custom code developed for its ROM, and that's not my strength. I know very little about the Apple II's internals and software. It would be fun to explore, but also probably a huge black hole of time and effort.

 

[Gorgonops]

The third reason is that any Apple II card development that's not a straight clone of some pre-existing card would need custom code developed for its ROM, and that's not my strength. I know very little about the Apple II's internals and software. It would be fun to explore, but also probably a huge black hole of time and effort.

So... here I suppose it depends on how well you think you can emulate the IWM chip. If you can "fake it" sufficiently to be register-level compatible then there shouldn't be any need to rewrite the ROM code. Here's a pull from archive.org of the Pseudodisk designer's website that explains the theory of operation of his board, which sort of split the difference; he designed the CPLD interface to essentially be "register compatible" with the Disk ][ card, so in "nibble mode" it can operate with unmodified DOS 3.3 images and the ROM off the Disk ][ controller card. For Prodos, however, he opted to skip raw disk emulation and write an alternative ROM that allows the Apple II to directly use the device as block storage through the Disk ][ registers. (In other words it does basically the same thing as SmartPort support, just cutting out the middleman of having to use the IWM for serial transport.) There's no reason in principle you couldn't just extend the "nibble mode" to also handle the Smartdrive protocol; all of that would be on the Floppy Emu side. This would let you use the Liron ROM.

With regard to "splintering the market"... hm. Here's another ignorant question: how much latitude do you have for reprogramming what the I/O lines on the 20 pin connector on the Floppy Emu? Crazy idea: Make an Apple-II card-edge board that has a ROM chip for the Liron firmware on it (plus maybe a bit of 74-series logic or another CPLD if you need it), a 20 pin connector, and a place to clip/screw a Floppy Emu to it? (Or just include a 20 pin cable and keep it external.) Then just spin a new alternate firmware for the FloppyEmu so it emulates the complete IWM+Disk II-or-SmartPort-disk *system* as efficiently as possible? (You'll be freed from having to emulate the IWM's "serial interface" between the host and target, so you can use the cycles otherwise spent on that to emulate the IWM's internal state machine so it can do a convincing job lying to the Apple II directly.)

Doing that would let you sell the "Apple II Direct" card as a separate item for existing customers in addition to bundling it with a FloppyEMU as a complete Apple II storage solution. (I'd be interested in such a card myself, especially if I could put it in Slot 5 to use the FloppyEMU as a "hard disk" alongside my physical Disk ][s.) It does have the downside compared to recreating the Liron of not also supporting real drives, but... can the FloppyEMU in SmartPort mode reside on a chain *after* a physical floppy drive anyway? I thought it had to be first.

 

[Gorgonops]

For Prodos, however, he opted to skip raw disk emulation and write an alternative ROM that allows the Apple II to directly use the device as block storage through the Disk ][ registers. (In other words it does basically the same thing as SmartPort support, just cutting out the middleman of having to use the IWM for serial transport.)

BTW, just to note, the Apple II assembler code for the ProDOS ROM *is* in the archive.org dump, so... in theory if you wanted to experiment with using the FloppyEMU hardware as a ProDOS device in "direct mode" via a prototyping card that might be... interesting? (Mostly thinking it could be a way to smoke-test a direct Apple II bus interface prior to working on the IWM emulation code to layer on top.)

Anyway, don't mind me. I have this bad tendency to blather.

 

[bigmessowires]

Not blather - I think about these things a lot, but normally it's all in my head. 

I believe I can emulate the IWM behavior well enough that the Liron ROM code can work unaltered. That makes the job much easier, because I won't have to write a custom driver. A couple of other hardware designers on the Facebook Apple II group also mentioned potential plans for a Liron clone, so maybe I've started a trend? 

One downside of the Liron is it doesn't work with 5.25 inch drives, and I don't think it's DOS 3.3 compatible. It only does smart Prodos drives. Some kind of hybrid like the Pseudo Disk would be nice, and I believe that's how the CFFA3000 works.

My murky understanding is that ProDOS defines some sensible API for disk I/O, and programs that want to read a block from disk can jump to a known address in your disk controller's ROM code. From there it's all up to your ROM code to determine how to fetch that data. So the task of doing I/O is nicely abstracted and separated from the details about how and where the data is stored. That makes it comparatively easy to write the ROM code for an emulated disk.

I don't believe DOS3.3 has anything like this. I suspect the bulk of the disk access code is actually part of DOS itself, and not in the disk controller ROM. Certainly that's true for many DOS-based games. It reads/writes to specific addresses in the card's memory space, in order to directly step the disk head and turn the motor on and off. Obviously none of that really makes sense if the disk is some emulated storage instead of a real 5.25 inch drive. So you need a microcontroller to observe the pattern of accesses and decide what they mean. If it observes that the software tried to set the phase 0,1,2,3 signals sequentially high then low, then it can conclude it wants to step the disk to a new track, and it can offset the current position in the emulated disk image accordingly. It's a lot of hassle.

If I've understood your suggestion, your idea is to eliminate the IWM from the Liron card, and connect the card directly to the Floppy Emu, such that the Emu emulates the IWM and the disk. That might work, and it does seem conceptually cleaner. But it would require some new ROM and new firmware that both wouldn't be needed for a "simple" Liron clone. 

If you have a Liron card, you can put it in slot 5 like you described, and use it as a Floppy Emu hard disk alongside your real Disk II's in slot 6. It might only work for ProDOS software though, depending on which disk you boot from, I'm not sure.

In general the Floppy Emu can be daisy chained behind other Apple II drives, and works fine that way. But it doesn't work when it's set for Smartport emulation mode, and daisy-chained behind another Smartport device like a Unidisk 3.5. It's not clear why, and I was actually working on that very issue yesterday. I don't have any real Smartport drives like a Unidisk 3.5, so I probably need to borrow one from somebody to get to the bottom of it.

My trouble is that I have too many projects, so I don't really need another one, when I have a million other competing priorities. A week ago the Floppy Emu didn't work with the Liron and couldn't emulate a hard disk for the II+ and IIe, and nobody much cared. Now it works, but suddenly the sketchy availability of Liron cards is a problem, and has me pondering cloning them or designing a new disk controller card.

 

[Gorgonops]

One downside of the Liron is it doesn't work with 5.25 inch drives, and I don't think it's DOS 3.3 compatible. It only does smart Prodos drives

Are you certain of this? I don't have one, but my vague understanding is that the Liron is essentially a copy of the Apple IIc's disk system on a card, and the IIc uses ROM magic to allow both the ProDOS/SmartPort drivers and a dumb DOS 3.3-register-compatible mode for accessing 5.25" floppies share the same IWM.

 

[bigmessowires]

Yeah, I've tried it, and the 5.25 drive doesn't show any signs of life at all. I was also told by a couple of other people with Lirons that it wouldn't work.

I've been thinking a bit more about your suggestion, because I like it in principle. If something like the Pseudo Disk is basically a CPLD and a microcontroller on a card, and Floppy Emu is already a disk and a microcontroller, then why not connect it more-or-less directly to the Apple II bus? It would only need a physical adapter and probably a small amount of glue logic. So the options are:

1. An “Emu controller card”, with minimal on-board logic, that communicates with the Emu using some custom signaling method.
2. A Liron or UDC clone card, that communicates with the Emu and/or other real drives, using real disk signals (my original idea)

Advantages of #1: Hopefully cheaper to build, with fewer parts, and easier to design?

Disadvantages of #1: Can’t be used with real disk drives, requires new Emu-side firmware, requires writing a custom card ROM

The big advantage of #1 is that it might require fewer parts and be cheaper. So I tried to guess what hardware would be needed for each one, and it's actually pretty much the same.

- A small ROM. Something needs to hold the card's ROM code, and a real ROM is still the easiest solution. A big enough FPGA could maybe store the ROM image internally and function like a ROM on a subset of its pins, but that's likely more expensive. A fast enough microcontroller could maybe emulate a ROM, by triggering an interrupt whenever the address lines change and quickly changing the value on the data lines, but I'm not convinced it would be fast enough. Even with a high speed microcontroller, interrupt latency can be substantial, and there's no true parallelism, so if ROM access interrupted some other time-critical task it wouldn't work. 

- A CPLD or FPGA. Design #2 needs the CPLD to emulate the IWM. I don't think it's possible to emulate the IWM entirely in a microcontroller, for the same speed reason as the ROM. Design #1 also needs a CPLD to act as basic glue. There are too many signals on the Apple II bus to send them all over that 20-pin floppy cable without some kind of intermediate buffer or logic.

- A microcontroller? I'm not convinced either design needs one. #2 might benefit from one if the IWM emulation is too complex to do entirely within a small/cheap CPLD. But the IWM is basically just a fancy shift register with some GPIOs hanging off it.

If the card hardware is mostly the same either way, then the advantage of design #1 evaporates. 

I wish programmable logic were cheaper. A medium-sized CPLD or FPGA starts around $4, and that may not be enough for this design. Meanwhile a very powerful microcontroller can be $1, and for 99% of applications it'll beat the pants off that small CPLD or FPGA. I guess that's the premium we have to pay to get true parallelism and nanosecond-level responses.