Cloning the IWM (sort of)

[Tashtari]

Ladies and gentlemen, my next trick is impossible improbable...

It seems like the IWM is the only (or at least the biggest) thing standing in the way of a Plus or SE made of entirely new parts - and possibly also the biggest problem for those trying to revive an old board. For completeness's sake, I will acknowledge that there are a few projects (pldSCHWIM, Shim-IWM, IWMLess) that approximate a "null" IWM well enough to make a Mac boot... but don't actually emulate its functions. I want to go further. What I have my sights on is something that walks and talks like an IWM as far as the Mac's bus is concerned but, instead of connecting to a real floppy drive or HD20 or a simulacrum thereof, emulates drives within itself - a Floppy Emu with the middleman cut out, if you like. I've been doing some reading about the IWM and the Disk II and I'd like to start a conversation about this, if you guys will indulge me.

I didn't realize this before now, but the IWM is more than just a single-chip Disk II. Each bit in the IWM's "mode register" that is set to 1 enables a feature that the Disk II didn't have - to wit, the ability to run with an 8 MHz clock (instead of a 7 MHz one), the "fast mode" that enables a 2 µs bit cell (instead of a 4 µs one), the asynchronous mode that buffers the shift register, and the optional disabling of the one-second timer. I suppose my main curiosity is, does the Mac just set-and-forget all these bits? That is, can I safely drop the Apple II mode of the IWM? Doing so would make the task quite a bit easier...

I'm skeptical that it's possible to do this without two chips working in tandem - a microcontroller and a programmable logic device of some kind - so a true drop-in replacement à la the SE's ADB controller is out of reach, but perhaps a PCB module that sits in place of the 28-pin DIP is possible. That and/or integrating a two-chip solution is relatively painless on a wholly remade board such as @max1zzz 's ITXPlus...

Thoughts? =)

Oh, and by the way, if you can afford it, do chip a few bucks to the Internet Archive, it is impossible to overstate how valuable the stuff they've archived is to hackers and hobbyists like us...

 

[SuperSVGA]

If you're not intending to connect a physical disk drive you could probably just leave the programmable logic out and just use the microcontroller alone. You could fit the entire IWM on a CPLD, but there's no point if having the microcontroller talk directly to the bus is an option.

 

[SuperSVGA]

The DIP-28 could definitely fit everything you need in roughly the same footprint.
Here's a rapidly put together render:



The PLCC-44 form factor would take a bit more but is still doable if you stack boards:

 

[Snial]

Again, a Raspberry PI PICO is an obvious choice for either an IWM (or SWIM ) that can interface to a real Mac FDD or an SD card. The PIOs would do the hard real-time work the CPLD would otherwise do, but at 125MHz+, you could probably manage a lot of the work directly using one of the CPUs. I'd target a PICO 2040 so that it can be easily targeted at the PICO 2. In addition, with 256kB or 512kB of RAM it can buffer a high proportion of a disk, thus compensating for latency issues and caching disk operations too! Also, there's easy development tools and hardware available. Also, another R-PI PICO is used on the recent Mac Plus ITX design:

https://68kmla.org/bb/index.php?threads/itxplus-a-itx-sized-macintosh-plus-logicboard-reproduction.49715/

 

[Tashtari]

Again, a Raspberry PI PICO is an obvious choice for either an IWM (or SWIM ) that can interface to a real Mac FDD or an SD card.

Thanks for the suggestion, and I know it comes from a good place, so please don't take what follows as an attack, it is not meant that way. (Also, please forgive the string of ham-fisted metaphors.) I die a little inside every time someone tells me to use an RP2040 or STM32 or whatever the flamethrower-du-jour is to kill my mosquito. I'm sure it's up to the task, but it's overkill, it feels wrong. Sure, a portrait painter would save loads of time if they just whipped out their smartphone and snapped a photo, but that's not the point of the exercise. What I do here, I do because the journey is fun, not because I want to get to the end as quickly as possible. As such, I'm going to stick to my PICs and SPLDs. For all their flaws and shortcomings, they feel right to me.

You could fit the entire IWM on a CPLD, but there's no point if having the microcontroller talk directly to the bus is an option.

It is possible, but the capacity is somewhat limited. What I'm thinking of for a target platform here is a PIC with a parallel slave port for the data register and an ATF1502 for the rest of the registers (particularly the weird 'soft switches' that the IWM uses, because it's based in the Apple II world).

Here's a rapidly put together render

Good to know, I'm pretty sure the Plus and SE use the 28-pin DIP form factor, and this would just be the IWM, not the SWIM, so it wouldn't be of much interest to any machine newer than those. Besides, after the Plus and SE, you start getting into ASICs that are difficult to duplicate, so the ultimate objective of enabling a new-chips-only clone ends up thwarted before it starts.

 

[jake18125]

Hey, DosFox here!

The Shim-IWM (SCHWIM if you will) was always just meant to bypass the IWM enough to get the system to boot from something else. For saying DB19 connectors are ruddy expensive (let alone the floppy drives!), I felt just a bypass was enough for my Macintosh Plus clone project. It's still quite surprising that it works on systems as advanced as the LC ii!

I've also always wanted to experiment with dropping an IWM into something like a Macintosh ii or SE with FDHD ROMs. I have a feeling it should theoretically work, as if I recall correctly, the SWIM is basically just an IWM with an MFM disk controller bolted onto it. I believe that 400k/800k disk access theoretically should still work - but I've never tried it so I don't know!

Additionally, I would also suggest taking a look at the floppy controller on the IO board in the Lisa 2/5 - as I feel it's a lot closer to the IWM than the original disk ii controller. It can handle Sony 400k drives (and 800k with a ROM upgrade!), whilst still being based off the PROM and latch method that Woz designed for the Apple ii.

Either way, this definitely sounds like an interesting project and I'll definitely be following along!

 

[Snial]

<snip> I die a little inside every time someone tells me to use an RP2040 or STM32 or whatever the flamethrower-du-jour is to kill my mosquito <snip> As such, I'm going to stick to my PICs and SPLDs. For all their flaws and shortcomings, they feel right to me.

I more than understand your aversion to over-engineering hardware solutions. I feel the same way in that respect: I hate it when people throw a more powerful SBC as a hardware fix than the original computer. I think hardware solutions should be appropriately matched to the target. For example (maybe not an example you've heard of): The original ZX Spectrum computer (3.25MHz Z80) could do a rudimentary, one channel beep sound (that took up all the CPU too!) and in part of the ZX Spectrum's manual there's a little Basic program that plays a bit of Mahler's Symphony #1. Then as a joke the author suggested getting a whole bunch of ZX Spectrums to play the entire symphony. I mean, it'd sound awful, but you know, it's a challenge.

So, about 35 years later someone did do it. The real problem was to keep the ZX Spectrum's synchronised, but rather than devising a super-simple piece of synchronisation hardware, they used multiple Raspberry PIs. Good grief, a single Raspberry PI could have done the whole of the Symphony and much better than a ZX Spectrum, so I think that's cheating, I was appalled.

At the same time though I'm from the other tribe when it comes to 8-bit PIC vs AVR, so I have an aversion to 8-bit PICs. If I'd known about your anti-over-engineering philosophy I'd probably have suggested an 8-bit AVR, because they're better CPUs.

A good question though is whether a CPLD is really needed anyway (it might be). If I've read the document at least a little bit correctly, then the bit rate from the drive can't be better than one bit every 2µs, giving 500kbit/s. A 20MHz AVR would have about 40 cycles to process a single bit (or 32 cycles on a 16MHz AVR, equivalent to more than a 64MHz 8-bit PIC), but you could probably use the SPI port to handle the shift register work. You'd need a 40-pin MCU for sure.

There's more info about the IWM here:

Linux/m68k for Macintosh - home

If I understand the behaviour of the IWM at least a little bit, then D7-D0 are used to write GCR encoded bytes and the IWM just shifts the bits out, it doesn't do any encoding itself.

It is possible, but the capacity is somewhat limited. What I'm thinking of for a target platform here is a PIC with a parallel slave port for the data register and an ATF1502 for the rest of the registers (particularly the weird 'soft switches' that the IWM uses, because it's based in the Apple II world).

Are you able to program an ATF1502 with a Mac?

 

[Snial]

The Shim-IWM (SCHWIM if you will) was always just meant to bypass the IWM enough to get the system to boot from something else. For saying DB19 connectors are ruddy expensive (let alone the floppy drives!), I felt just a bypass was enough for my Macintosh Plus clone project.

Do you have a link to these things? I was quite intrigued about the miniITX Mac Plus, but I realise that's not your project. It uses PI-PICO for VGA video.

https://68kmla.org/bb/index.php?threads/itxplus-a-itx-sized-macintosh-plus-logicboard-reproduction.49715/

 

[Arbee]

I've also always wanted to experiment with dropping an IWM into something like a Macintosh ii or SE with FDHD ROMs. I have a feeling it should theoretically work, as if I recall correctly, the SWIM is basically just an IWM with an MFM disk controller bolted onto it. I believe that 400k/800k disk access theoretically should still work - but I've never tried it so I don't know!

The ROM code should detect IWM vs SWIM on any machine that would've had a SWIM. It definitely works in emulation. SWIM has a complete IWM inside for GCR (400K/800K) disks. Software can switch which of the two chips inside the chip is active and detect if the switching worked (which it of course won't on a plain IWM). SWIM2 is basically SWIM minus the built-in IWM because they figured out how to read and write GCR disks with the MFM controller.

 

[Snial]

The ROM code should detect IWM vs SWIM on any machine that would've had a SWIM. It definitely works in emulation. SWIM has a complete IWM inside for GCR (400K/800K) disks. Software can switch which of the two chips inside the chip is active and detect if the switching worked (which it of course won't on a plain IWM). SWIM2 is basically SWIM minus the built-in IWM because they figured out how to read and write GCR disks with the MFM controller.

I was always under the impression that the host CPU converted the GCR, because I'd heard that on the Apple ][ the controller card, the non-Integrated Wozniak Machine, went through a number of software improvements where they started with something like 5:3 GCR, but pushed it to 6:2 GCR. I thought the IWM worked the same way, with the CPU doing the GCR conversion.

And just to refresh on GCR, basically one needs periodic flux transitions in the read/write head data stream. You can't have too many 1s or 0s in a row so 8-bits of data means those 8-bits are added to the shift register; the first 6-bits are converted to 8-bits of GCR code; then the shift register outputs those bits, leaving 2 more of the original input bits, which the next 8-bits of data get added to. Then every 3 bytes of 8-bit data, the GCR encoder ends up with 2x 6-bit sets to convert:

Step
Ld	D7	D6	D5	D4	D3	D2	D1	D0	--	--	--	--	--
GCR	D7	D6	G7	G6	G5	G4	G3	G2	G1	G0	--	--	--
>>	--	--	--	--	--	--	--	--	D7	D6	--	--	--
Ld	D15	D14	D13	D12	D11	D10	D9	D8	D7	D6	--	--	--
Gcr	D15	D14	D13	D12	G15	G14	G13	G12	G11	G10	G9	G8	--
>>	--	--	--	--	--	--	--	--	D15	D14	D13	D12	--
Ld	D23	D22	D21	D20	D19	D18	D17	D16	D15	D14	D13	D12	--
GCR	D23	D22	D21	D20	D19	D18	G23	G22	G21	G20	G19	G18	G17	G16
>>	--	--	--	--	--	--	--	--	D23	D22	D21	D20	D19	D18
GCR	--	--	--	--	--	--	G31	G30	G29	G28	G27	G26	G25	G24
>>	--	--	--	--	--	--	--	--	--	--	--	--	--	--

A 1.44MB drive has twice as many tracks as a 720kB/800kB drive, which means that the data rate is the same, but access times are slower, because there's more head steps on average. And on the GCR 800kB disks, the data rate is still the same because although more bits are stored at the outer edges, the rotation speed is slowed down: this is what the other 'audio' byte does on the Mac Plus's audio buffer, it stores PWM data governing the disk motor. But different PWM tables could force 720kB support (if you could encode for MFM).

So, now I'm a bit puzzled. If the IWM, SWIM and SWIM2 do the GCR and MFM conversion in hardware and the data rate is the same for both; while the Mac just does normal 8-bit disk data, I don't really see how you can feed disk data into an MFM converter such that it's encoded into GCR.

I can see how, if the Mac's CPU does the GCR and/or MFM conversions in software, then it might well be possible to feed in data which after an MFM conversion is equivalent to the GCR data:

MFM⁻¹(GCR(data)) -> SWIM2 -> MFM() -> GCR(data)
And GCR(data) -> MFM⁻¹() -> GCR⁻¹() -> Data.

 

[Arbee]

GCR is always done in software (although the 13/16 sector Disk II upgrade did involve a new state machine PROM for the controller). But whereas IWM is essentially just a real-time shift register showing the most recent 8 bits to spin by the read/write head, SWIM does some extra processing required by MFM disks (but not the actual nibble encoding/decoding). I don't know the details, but there were things to overcome to make GCR work through that pipeline.

SWIM3 and NewAge actually do the encoding and decoding for both GCR and MFM, since that's necessary for DMA to work. (SWIM1 and 2 do have vestigal DMA capability, but the raw GCR/MFM disk bytes are what gets DMAed and only the IOP driver on the IIfx and Quadra 900/950 made use of that ability).

 

[Tashtari]

I've spent a bunch of time trying to nail down the logic side of this, and after several false starts, I think I have a working strategy. I hope one day to use a Renesas GreenPak or two in one of my designs, but it won't be this time, sadly - I'll be using an Atmel ATF1504 CPLD for the CPU interface. It will handle the tasks of emulating the IWM's somewhat bizarre relationship with the address and data buses and buffering communication with the PIC. The PIC will be a PIC16F1789 or possibly 1787 or 1784, depending on how much memory and code space I need - what I'm thinking is that it will communicate over UART with a 'frontend' (similar vein to what I was thinking with TashFloppy) where the user will insert their SD card and pick the image they want to insert.

Now, the caveats! First, this will only emulate an IWM, not a SWIM, so no 1.44 MB disks. Further, at least initially, it will only emulate one 800 kB floppy drive, no dual drive support, and no HD20/DCD support. I'm a little disappointed about that, but there's a lot of layers of weirdness in the Mac's floppy interface that have to be contended with in only so much logic. Maybe in the future, depending on how things go. Oh, and no Apple II support, either. The IWM is almost a totally different beast when it's in Apple II mode, and supporting it would be a bit much to ask for, at least at the outset.

Trying to figure out how to emulate the IWM led me down the path of learning about the Disk II, which has been an interesting experience. The Disk II was an extremely clever feat, but seemingly like everything else Apple, the cleverness developed into weirdness. The IWM nominally has a 16-byte address space (four address lines), but that doesn't mean there are 16 registers. No, there are something like six, all either read-only or write-only (except for one write-only register that is partially readable through one of the read-only registers, but nevermind). The most important of these isn't actually written using the data bus at all. Rather, it's written one bit at a time through the address bus alone - the upper three address lines select the bit to write and the lower address line selects the value to write - so you write a 1 to bit 5 by reading the 11th byte in the address space that isn't an address space. Writing-by-reading certain bits in this register selects which of the five other registers you're reading or writing when you actually read or write the data bus. Oh, and this is all separate from the 1-bit registers you read from the drive, which you read by writing-by-reading the phase lines (originally used to step the drive heads in the Disk II), writing a bit in the VIA, which is completely separate from the IWM, and then selecting-by-writing-by-reading the IWM's status register and reading its MSb, the 'sense' bit, that was originally used to sense the write protect notch in the Disk II. What? That doesn't seem logical to you? Then you're in the wrong hobby.

 

[Trash80toHP_Mini]

Next year is the 40th Anniversary of the Plus. Maybe someone can get in touch with the Woz? He might be up for releasing IWM for that milestone and new build project in the ITXPlus? He might even create/recreate a new version for old times sake/posterity?

Gotta love a guy with the stones to go on Dancing With the Stars, you'd never catch that other Steve doing that.

 

[Arbee]

Oh, and this is all separate from the 1-bit registers you read from the drive, which you read by writing-by-reading the phase lines (originally used to step the drive heads in the Disk II), writing a bit in the VIA, which is completely separate from the IWM, and then selecting-by-writing-by-reading the IWM's status register and reading its MSb, the 'sense' bit, that was originally used to sense the write protect notch in the Disk II. What? That doesn't seem logical to you? Then you're in the wrong hobby.

In fairness to Woz, the VIA bit stuff is because the Disk II didn't need a head select, and there was something wrong with the drive select on the IWM that never got fixed. Drive select on the Disk II did work, and on SWIM1 the built-in IWM's drive select does work.

Bonus Apple weirdness: lacking a VIA, the IIgs put the head select and drive select pins in the video ASIC, because that was where they had gates and pins to spare.

 

[Tashtari]

there was something wrong with the drive select on the IWM that never got fixed

Like the !ENBL1 and !ENBL2 lines? I know the IWM has no head select mechanism but I've never heard there was anything awry with the drive select lines...

 

[Arbee]

You're right, /ENBL1 and /ENBL2 do work, unless you're mixing drive types in which case external help is necessary.

 

[Tashtari]

So I've been playing around with this for a bit and I've started wondering, why make a minimal, corner-cutting clone of the IWM when I can make a full-fledged clone of the IWM? And I think I might be able to, all in logic. The target platform is a pair of ATF1504s, one as the clock generator and the other as the souped-up shift register. I'm hitting some headaches with WinCUPL, but that's pretty much par for the course. Watch this space!

 

[Snial]

So I've been playing around with this for a bit and I've started wondering, why make a minimal, corner-cutting clone of the IWM when I can make a full-fledged clone of the IWM? And I think I might be able to, all in logic. The target platform is a pair of ATF1504s, one as the clock generator and the other as the souped-up shift register. I'm hitting some headaches with WinCUPL, but that's pretty much par for the course. Watch this space!

Sounds good! I was hoping you might go down that route, because as per your philosophy, the IWM can't have a high gate count, because it's mostly based on the Disk ][ and that's mostly a couple of PALs isn't it? OK, so it had a ROM with a 6502 machine code driver, but that didn't need to be replicated for the IWM, because the equivalent code would be part of the Mac ROM.

Hmm, 64 macro-cells, 5 product terms per macrocell, 1 flip-flop per cell. Fairly decent.

 

[SuperSVGA]

he IWM can't have a high gate count, because it's mostly based on the Disk ][ and that's mostly a couple of PALs isn't it?

The Disk ][ card did not have any PALs, it was all general logic and two PROMs. I fit it all into a single ATF1504 at one point, including the PROMs.

 

[Tashtari]

IWM can't have a high gate count, because it's mostly based on the Disk ][

Well, ish. =D It is backward compatible with the Disk II, but some features are entirely new. Some of these are relatively trivial (slow/fast mode just halves/doubles the clock, for example), but the asynchronous mode that the Mac uses is a bit more complex...