Cloning the IWM (sort of)

[finkmac]

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?

i think the best he can offer is an autograph on a floppy

 

[Tashtari]

i think the best he can offer is an autograph on a floppy

Yeah, I don't think Woz has much control over what Apple releases, that'll be squarely in the court of the legal department, and sadly, it's much easier to say no than it is to potentially open yourself up to some form of legal liability. At least they've allowed the release of the IWM spec, which (while rather jumbled) does seem to document the chip well enough to allow the creation of a workalike.

...If I can get CUPL to stop acting weird and illogical, anyway.

 

[obsolete]

May be a dumb question, but why two 1504s vs one 1508?

 

[Tashtari]

May be a dumb question, but why two 1504s vs one 1508?

No great reason, but two 1504s are actually cheaper than one 1508.

 

[Tashtari]

May be a dumb question, but why two 1504s vs one 1508?

The more I think about this, I am starting to wonder, maybe it would make more sense to target one 1508. I'm thinking that thanks to a fatal bug in the Atmel fitter, I might have to start over and implement this in Verilog instead of CUPL (which is going to be interesting as I don't actually know Verilog) so maybe it's a good time to rethink some other design choices too.

 

[obsolete]

Yeah, I see what you mean. The 1508s are cheap in 3.3V, but then you need an extra regulator and level shifters.

 

[Snial]

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...

This is certainly an interesting project, especially if it's done on a CPLD. If people are willing, it might function well as a CPLD and IWM tutorial for software-oriented people like me. As a preamble, I have actually designed a synthesizable, practical, 16-bit CPU in Verilog. I think this means I'm not entirely clueless, but my lack of overall experience means I'm likely to ask a lot of dumb questions. If that can be tolerated, it'd be wonderful. Any insights from @bigmessowires would also be educational for me. So, if I can kick off with a couple of points:

The Shift And Buffer Regs

One of the most significant parts of the IWM is the shift register and buffer. Since the IWM can't both be reading and writing at the same time and can't be reading from one disk while writing to another, it makes me think that the IWM only has a single 8-bit shift reg and a single 8-bit buffer.

So, most shift reg bits can either come from the previous shift reg bit (for both reading and writing), or from the corresponding buffer reg. Conversely, buffer reg bits can come from the corresponding shift reg bit (for reading) or from the corresponding IO pin (for writing). Most of the Data buf I/O pins again are either outputting the corresponding buffer register or inputting from the data bus D<7:0>.

There are some exceptions to this. ShiftReg<7> can output to WRDATA in output mode; ShiftReg<0> can input from RDDATA. D<7> can be outputting a bit from a status reg or the RDSense.

I find FPGA architectures easier to understand than CPLD architectures, because they tend to consist of a LUT and flip-flop whereas a CPLD macrocell seems to be quite convoluted. Nevertheless, to my mind, it looks to me like a single 16 macrocell logic block can implement both the 8-bit shift and buffer regs.


The individual product terms should be able to select the right source for a shift reg bit (shifting & ShiftReg<n-1>) | (loading & BufferReg<n>) the product term for the clock input should be obtainable from the asynchronous clock or synchronous lock (which would be coming from a different macroblock). So, that's 3 product terms for most of the shift regs and something similar would apply for the BufferReg.

So, obviously I know a CPLD isn't normally programmed directly against it's underlying specific architecture, unless that's what CUPL does, but a decent HDL compiler should be able to achieve something like that efficiency I would have thought?

Clock Rate Puzzle

I understand that the clock rate can be synchronous (at 7MHz or 8MHz) or asychronous. However, the bit cell rate is 0.5MHz or 0.25MHz in synchronous mode (and I'm presuming FCLK/16 for Asynchronous mode). Why does the IWM need so many cycles per bit? Is it averaging them, or clocking each bit cell in the middle of a cycle? (the latter is my guess).

But even that's a bit of a puzzle, because surely disk data is asynchronous w.r.t IWM clock cycles?

 

[Snial]

Clock Rate Puzzle

I understand that the clock rate can be synchronous (at 7MHz or 8MHz) or asychronous. However, the bit cell rate is 0.5MHz or 0.25MHz in synchronous mode (and I'm presuming FCLK/16 for Asynchronous mode). Why does the IWM need so many cycles per bit? Is it averaging them, or clocking each bit cell in the middle of a cycle? (the latter is my guess).

But even that's a bit of a puzzle, because surely disk data is asynchronous w.r.t IWM clock cycles?

OK, I think this page is explaining that:



Don't understand it yet admittedly.

 

[Tashtari]

Clock Rate Puzzle

I understand that the clock rate can be synchronous (at 7MHz or 8MHz) or asychronous. However, the bit cell rate is 0.5MHz or 0.25MHz in synchronous mode (and I'm presuming FCLK/16 for Asynchronous mode). Why does the IWM need so many cycles per bit? Is it averaging them, or clocking each bit cell in the middle of a cycle? (the latter is my guess).

But even that's a bit of a puzzle, because surely disk data is asynchronous w.r.t IWM clock cycles?

The input clocks are 2 MHz on Q3 and either 7 MHz or 8 MHz on FCLK (I don't believe FCLK existed in the Disk II, or at least, it wasn't used for bit cell timing). Q3 is only used in the synchronous mode for bit cell timing and eight periods of it in slow mode (4 µs) or four periods in fast mode (2 µs) constitute a bit cell. FCLK is used for bit cell timing in the asynchronous mode and the timing is as described on the page you linked above (which I agree is confusing).

Whatever it's using for bit cell timing, I don't believe the IWM actually does anything each Q3 or FCLK cycle except count the appropriate number of cycles in order to create a bit cell clock, which is then used to clock the shift register. What sets the IWM apart from an ordinary shift register is that it can be clocked by the bit cell clock or by a falling edge on RDDATA. In the former case, a zero is clocked into the shift register, while in the latter case, a one is clocked into the shift register; in either case, the bit cell clock is reset. This allows the IWM to constantly adjust itself to keep pace with the drive every time there's a flux transition on the media (and why GCR allows a maximum of two zeroes to pass between ones), allowing it to compensate for things like speed variation between drives and peak shift on the media.

Does that make sense?

 

[Snial]

The input clocks are 2 MHz on Q3 and either 7 MHz or 8 MHz on FCLK (I don't believe FCLK existed in the Disk II, or at least, it wasn't used for bit cell timing). Q3 is only used in the synchronous mode for bit cell timing and eight periods of it in slow mode (4 µs) or four periods in fast mode (2 µs) constitute a bit cell. FCLK is used for bit cell timing in the asynchronous mode and the timing is as described on the page you linked above (which I agree is confusing).

Whatever it's using for bit cell timing, I don't believe the IWM actually does anything each Q3 or FCLK cycle except count the appropriate number of cycles in order to create a bit cell clock, which is then used to clock the shift register. What sets the IWM apart from an ordinary shift register is that it can be clocked by the bit cell clock or by a falling edge on RDDATA. In the former case, a zero is clocked into the shift register, while in the latter case, a one is clocked into the shift register; in either case, the bit cell clock is reset. This allows the IWM to constantly adjust itself to keep pace with the drive every time there's a flux transition on the media (and why GCR allows a maximum of two zeroes to pass between ones), allowing it to compensate for things like speed variation between drives and peak shift on the media.

Does that make sense?

It certainly makes more sense !

So, a 1->0 transition on RDATA clocks a 1, but a 1->1, 0->0, 0->1 transition clocks a 0 (because the bit cell timer essentially has a timeout). And obviously 1->1 and 0->0 aren't really transitions. I guess the reverse must happen on output, a 1 in ShiftReg<7> generates a 1->0 transition.

So, in 6:2 encoding[1], the 6-bit value: 0x3f, gets encoded into a GCR of 11111111₂ which means WRDATA must be outputting a 10 transition for each 1 bit, making the media output: 1010101010101010₂ . Also, the 6-bit value 0x00 => GCR of 10010110₂ which is encoded as media transitions: 1000001000101000₂ . Where, underline denotes a transition generated by the logic; green is the first 0 allowed (read in as a timeout), red is the second zero allowed (also read in as a timeout).



[1] https://en.wikipedia.org/wiki/Group_coded_recording#Apple

 

[Tashtari]

It certainly makes more sense !

So, a 1->0 transition on RDATA clocks a 1, but a 1->1, 0->0, 0->1 transition clocks a 0 (because the bit cell timer essentially has a timeout). And obviously 1->1 and 0->0 aren't really transitions. I guess the reverse must happen on output, a 1 in ShiftReg<7> generates a 1->0 transition.

So, in 6:2 encoding[1], the 6-bit value: 0x3f, gets encoded into a GCR of 11111111₂ which means WRDATA must be outputting a 10 transition for each 1 bit, making the media output: 1010101010101010₂ . Also, the 6-bit value 0x00 => GCR of 10010110₂ which is encoded as media transitions: 1000001000101000₂ . Where, underline denotes a transition generated by the logic; green is the first 0 allowed (read in as a timeout), red is the second zero allowed (also read in as a timeout).



[1] https://en.wikipedia.org/wiki/Group_coded_recording#Apple

I think you understand more or less correctly, yes, though the IWM's WRDATA output actually toggles to represent ones, as differentiated from the RDDATA input, which interprets falling edges as ones. I'd be lying if I said I understood exactly why this is or what it translates to on the disk media, but it's enough for me to understand that the media has "flux transitions" on it, which are for practical purposes equivalent to ones, which are read as falling edges and written by either rising or falling edges. (I think it has something to do with them there electrons.)

 

[jake18125]

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/

most of my stuff is on Mastodon, but the half completed project was picked up by Toms Hardware and Apple Insider.
My github (https://github.com/DosFox1?tab=repositories) contains info on my SND and Shim-IWM - both of which were used in the ITXplus! Max1zzz is a hardware wizard.

 

[jake18125]

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.

you would be better off talking to Wendell Sander, or Daniel Kottke!

 

[Tashtari]

Well, I spent an interesting morning teaching myself Verilog and translating my CUPL design into it, and... success! The clock generator side of the IWM appears to be working perfectly. There's more to do, of course, but this is a big step and definitely proves out the workflow of using Quartus II and POF2JED instead of the nasty, buggy Atmel CPLD fitter. Kind of mindblowing that that's Atmel's officially supported workflow for developing for their products. Products that they presumably want people to buy. (Maybe they don't? Maybe they're hoping people will stop buying the ATF150x series so they can stop manufacturing them? Who knows.)

 

[mdeverhart]

Well, I spent an interesting morning teaching myself Verilog and translating my CUPL design into it, and... success!

Congrats! Verilog is definitely a good tool to have in the toolbox.

definitely proves out the workflow of using Quartus II and POF2JED instead of the nasty, buggy Atmel CPLD fitter

Good to know! I haven’t done any CPLD designs for Classic Mac hacking, but I’d been considering taking that approach since it’s about the only 5V CPLD available in production anymore.

 

[Tashtari]

I’d been considering taking that approach

If you're interested, I'd grab Quartus II 13.0sp1 before Intel takes it down (they're real jerks about keeping downloads available), that's the last version that supports the MAX7000 series with which the Atmel 150x chips are compatible.

 

[Tashtari]

I wish I understood better what the "latch mode" bit in the IWM was for.



Apparently the latch mode bit "should" be set in async mode, but the spec sheet also says "In port operation, which is asynchronous mode true and latch mode false with /DEV held low indefinitely, read data will appear and change as if the IWM were being continually read. In port operation the MSB can be used to continually clock data into external registers. The MSB will be cleared at least six FCLK periods before being set." I can't quite understand what this means, nor what "port mode" would be used for, nor whether any Apple II or Mac ever actually used the IWM in this mode...

 

[Tashtari]

Am realizing that it will be at least useful and at most necessary for me to get an actual IWM to test with... ideally a test machine with a ZIF socket where the IWM should be, too. Guessing I'll just have to keep my eyes peeled for someone selling a Plus or earlier in good condition (not sure if the pre-FDHD SE has a DIP IWM or a PLCC one?) and try to find someone to work on it for me, since I lack the necessary soldering tools and skills.

Am realizing, too, that if I outsource the one-second timer logic (with its requirement for 23 DFFs), I could potentially fit the whole IWM in a single ATF1504. Wouldn't that be lovely? I'm not sure if it's possible, but it needs to be tried.

 

[mdeverhart]

If you're interested, I'd grab Quartus II 13.0sp1 before Intel takes it down (they're real jerks about keeping downloads available), that's the last version that supports the MAX7000 series with which the Atmel 150x chips are compatible.

Thanks. I knew they were bad about that, but I hadn’t considered grabbing a copy for this purpose, and I hadn’t looked into the MAX7000 support. Time to grab it and throw it onto my NAS.

not sure if the pre-FDHD SE has a DIP IWM or a PLCC one?

From the Service Source it looks like it’s a socketed DIP right next to the socketed DIP ROMs.

 

[Tashtari]

it’s a socketed DIP

Aha, you're right. Must be because Apple knew they'd be offering the FDHD upgrade. Maybe I can do some experimentation on my pre-FDHD SE...