Cloning the IWM (sort of)

[Tashtari]

My understanding of the IWM spec (and the Disk II) continues to evolve, albeit slowly.

In the Disk II, Q3 (2 MHz, twice the clock frequency of the Apple II) is the only clock that exists, so it's used for everything. In the IWM, Q3 is only used for writing data in synchronous mode, FCLK (in fast mode, FCLK/2 in slow mode) is used for everything else. That makes sense, you'd kind of want to use the fastest clock you have in order to have the highest resolution available for clock recovery.

What's still stumping me is "port operation":

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 continuously clock data into external registers. The MSB will be cleared at least six FCLK periods before being set. Except in port operation, in asynchronous mode the latch mode bit should be set (for reliability in clearing the data register after a read).

I would sort of like to know whether this mode was actually used anywhere or whether this was merely a theoretical use case that the IWM supported. More than that, though, I'd like to understand exactly how one was supposed to use it. On a superficial level it makes sense, you're basically using the IWM as a serial-in-parallel-out shift register where the input is asynchronous. But in order to set it up this way, you'd need to write the mode register at least once, which would require flipping the L6 and L7 soft switches and writing the data bus, so the address and data lines would have to be connected to the processor - whose data bus would then be monopolized by the IWM when you hold !DEV low. This makes no kind of sense to me. I'd love to ignore it, but Apple clearly thought it was important enough to include in the spec, and I'm worried that understanding what's going on will be important in order to be able to mimic the behavior of the chip.

 

[Arbee]

I assume you've checked the .Sony driver source in the SuperMario tree to see if that mode was used? I'd suspect any weirdness in the chip was for Twiggy drives, except that no machine with Twiggy drives used the IWM as far as I'm aware. (Lisa 1 had the 6 chips from the Disk II controller card on the logic board, Lisa 2 had IWM but came with 400K Sony drives).

 

[jake18125]

I assume you've checked the .Sony driver source in the SuperMario tree to see if that mode was used? I'd suspect any weirdness in the chip was for Twiggy drives, except that no machine with Twiggy drives used the IWM as far as I'm aware. (Lisa 1 had the 6 chips from the Disk II controller card on the logic board, Lisa 2 had IWM but came with 400K Sony drives).

Except for the prototype twiggy Macintosh 128Ks!

Although they were more like modified twiggy drives than anything.

 

[stepleton]

Lisa 2 had IWM

(nitpick for the record: the 2/10 only has an IWM; the 2/5 uses the Lisa 1 I/O board with a few small edits.)

 

[Tashtari]

I assume you've checked the .Sony driver source in the SuperMario tree to see if that mode was used?

I haven't, actually... don't know my way around that source tree too well, but maybe will dig a little and see if I notice anything obvious.

I no longer think it's realistic to do this in one 1504, I keep bumping my head against the macrocell limit. Going to try two like I originally thought... though how to handle it mechanically is still a question. It might be that this winds up being best suited to wholesale motherboard redesigns than original motherboard replacements.

 

[Tashtari]

Warning, semi-coherent rambling ahead.

I'm stuck for a moment on the two-1504 IWM clone, I believe my abominable wiring job to be at fault for some glitches I've been seeing:



Basically every time I started toggling the !DEV line to imitate the Mac polling the data registers, I started seeing corresponding blips on the clock line between the two 1504s. I'm not enough of an EE to say with any certainty, but I think it might have something to do with the mass of four-inch antennae that I've got plugged into that breadboard. So I spun a PCB and sent it off for fabrication (tariffs, oy), hoping that this will ameliorate the situation. Stay tuned.

In the meantime, I've gone back to the original idea of an IWM semi-clone that emulates drives rather than signals. Trouble here as well. I wrote the design in Verilog, found it didn't fit, then translated it into CUPL (to take advantage of the Atmel fitter's knowledge of the 15xx series's logic doubling capability), found it still didn't fit. Grr.

It's a scary thought to realize I may be one of a very small handful of living people with this much knowledge about the Mac's floppy drive interface. Sometimes I wish I didn't know what I know, because it is truly bizarre. One thing I ran up against when translating the design from Verilog to CUPL was being confronted with the truth that one of the data lines to/from the Mac has forty product terms, and that's after simplification! This is because - have I mentioned this before? - the Mac uses what is, in many ways, the Apple II's floppy drive interface, but repurposes a number of its communication lines to purposes that even Woz couldn't possibly have envisioned. Most notably, the 'SENSE' line, used exclusively to report the state of the write protect notch on the Apple II, has been repurposed to carry one-bit information of anywhere from twelve to eighteen types (depending on the type of floppy drive), selected by the lines that were supposed to control the head servos. Thus, one bit in one register is doing a hellacious amount of heavy lifting - its state depends on many, many things - hence all the product terms.

Verilog is really, really nice to work with. It was hard to go back to CUPL after having been coding in Verilog even for only about a week. It should be possible to use Verilog for more, but it seems like the tools - at least the open-source ones - aren't there yet. The Atmel fitter (the most capable fitter available for the ATF15xx series CPLDs, which is frustrating because it's also horrible) can take an EDIF file and produce a file that can be used to program a chip, but getting an EDIF file from a Verilog program seems to be an only semi-solved problem. Apparently there's a tool called "yosys" that can almost do this, but when I tried it on my code, I got an unsettling warning about tristate logic not being fully supported yet. Kinda hard to do something that sits on a microprocessor bus without tristating the pins sometimes. Maybe it's possible to use a proprietary Verilog synthesizer of some kind with the Atmel fitter, but I'm not sure what that might be as of right now.

The state of the tooling for working with ATF15xx CPLDs is pretty woeful at the moment, which sucks because they're the only 5-volt programmable CPLDs still made. The most pleasant design flow appears to be to write in Verilog or VHDL using a 12-year-old version of Altera's Quartus II development environment (the last to support Altera's MAX7000 series chips that the ATF15xx chips are able to emulate) and use a converter from Atmel to convert its output to a form that can be used to program the ATF15xx. Failing that, you appear to be stuck with WinCUPL and the Atmel fitter and all their quirks and shortcomings.

I'd like to learn more about programmable logic, but everything not made by Atmel feels so hard to access - made exclusively in unsolderable packages with voltage levels that don't even seem to reach as high as 3V3 anymore, and in most cases, vast overkill for the scale of projects on which I like to work. I said above that Verilog was nice to work with, and it is, but with all things programmable logic it seems to be very hard to know where you stand. You've no idea whether the next module you develop is suddenly going to require twice the resources your chip has left, and the only way to find out is to forge ahead and hope. I'm somewhat used to this, most of my PIC projects have to get pretty far into development before they can be tested at all, but this feels like it's on a whole other level.

No wonder I'm the PIC whisperer and not the PLD whisperer. =P

I'll get somewhere with all of this, I'm sure. Where that is, I'm not at all sure. But I'm having fun, and that's what counts, right?

 

[mdeverhart]

Basically every time I started toggling the !DEV line to imitate the Mac polling the data registers, I started seeing corresponding blips on the clock line between the two 1504s. I'm not enough of an EE to say with any certainty, but I think it might have something to do with the mass of four-inch antennae that I've got plugged into that breadboard.

If you’re seeing sharp pulses that line up with the edges of adjacent signals - yep, that’s the problem.

It's a scary thought to realize I may be one of a very small handful of living people with this much knowledge about the Mac's floppy drive interface. Sometimes I wish I didn't know what I know, because it is truly bizarre.

It would be a great service to the community if you could write up what you’ve learned, maybe as an addendum to the Apple IWM document that clarifies, corrects, and adds more detail where needed. Maybe host it on GitHub or somewhere like that so it’s not lost in forum threads over time?

Maybe it's possible to use a proprietary Verilog synthesizer of some kind with the Atmel fitter, but I'm not sure what that might be as of right now.

I’m not sure about commercial Verilog synthesizers that will target the ATF primitives, but commercial synthesizers (such as Synplify) can definitely create EDIF netlist files from VHDL/Verilog input. Licenses, unfortunately, are quite expensive unless you can get a version bundled with another tool (such as the free versions of Lattice’s and Microchip’s tools), but those bundled versions are usually locked to only support their devices.

The most pleasant design flow appears to be to write in Verilog or VHDL using a 12-year-old version of Altera's Quartus II development environment

That doesn’t surprise me. Quartus is actually pretty usable in my opinion, once you get used to it. It’s largely scriptable with TCL, and you can run the tools in command line mode, so it’s possible to run the build process from build scripts or Makefiles if the GUi based project flow isn’t to your liking.

I'd like to learn more about programmable logic, but everything not made by Atmel feels so hard to access - made exclusively in unsolderable packages with voltage levels that don't even seem to reach as high as 3V3 anymore, and in most cases, vast overkill for the scale of projects on which I like to work.

Yeah, PL design can be hard to get into for a lot of those reasons, especially for retro computing given the lack of 5V compatible devices. The good news is that while 3.3V IOs are getting deprecated on the highest end, newest devices, there are still a lot of industrial and automotive applications that need 3.3V logic. In my opinion the biggest challenges for hobbyists is the need for a ton of 5V level shifters, BGA packages, and the cost of many CPLDs and FPGAs. After watching some BGA rework videos I think it may be doable with a pre-warmer, hot air, and a lot of practice, but I haven’t tried it myself yet. PL design for retro computing would be a good topic for another thread.

I’m glad you’re enjoying yourself despite the headwinds. Hopefully the new PCB helps resolve the issues you’re seeing and you’re able to get the design to fit!

 

[Tashtari]

It would be a great service to the community if you could write up what you’ve learned, maybe as an addendum to the Apple IWM document that clarifies, corrects, and adds more detail where needed. Maybe host it on GitHub or somewhere like that so it’s not lost in forum threads over time?

Way ahead of you. =) If you see any topic that isn't there, do let me know, I'm definitely interested in knowledge sharing.

I’m not sure about commercial Verilog synthesizers that will target the ATF primitives, but commercial synthesizers (such as Synplify) can definitely create EDIF netlist files from VHDL/Verilog input. Licenses, unfortunately, are quite expensive unless you can get a version bundled with another tool (such as the free versions of Lattice’s and Microchip’s tools), but those bundled versions are usually locked to only support their devices.

Yeah, that's the impression I get as well. Microchip's "ProChip Designer" (seemingly a legacy of Atmel) comes with an HDL synthesizer of some kind, but it doesn't seem to have a free version, so that's out - if they have something else that comes with one, I don't know what it is. I am legitimately a student, though, so maybe there's some way I can get an educational license for something?

 

[saybur]

Way ahead of you. =) If you see any topic that isn't there, do let me know, I'm definitely interested in knowledge sharing.

I have nothing to contribute on the IWM project but thank you for keeping notes there on this and your other projects, they have been super useful!

 

[mdeverhart]

Way ahead of you. =) If you see any topic that isn't there, do let me know, I'm definitely interested in knowledge sharing.

Awesome! I might have stumbled on that earlier when I was looking at one of your other projects, but I’d forgotten it. Thanks!

 

[Tashtari]

While I wait for my PCBs, I've been trying to see what I can fit in a single 1504, and I seem to have arrived at a design that will (in cooperation with a PIC) simulate an IWM with two 800 kB floppy drives... but still no DCDs. I had logic to support them initially, along with a rather nice state machine that would handle all the potential transitions between them, but I couldn't fit that and a data register into the same chip... and a data register, you might correctly guess, is quite important.

I'm a little stuck deciding what to pursue at this point. I'm definitely interested in seeing if I can pull off a full-featured IWM drop-in replacement in two 1504s (that's what the PCBs are for), but whether I want to try to write the firmware for a 'soft' IWM that only supports 800 kB floppy drives, I'm not sure. The potential market seems more limited - I'd think most people would rather replace the dead/missing IWM in their SE/Plus/512/128 and pair it with a Floppy Emu that they can use on other machines.

Speaking of Floppy Emu, I've still got TashFloppy on one of my numerous back burners. The "backend" half of it is basically complete at this point, but it needs to be paired with a frontend that reacts sufficiently quickly to events from the backend (when the Mac says 'step the heads', it means now) and I'm not yet sure what meets my requirements. I am, however, in a class on real-time embedded systems this summer, and the target platform is a Raspberry Pi 4, so maybe I'll learn something on how to make Linux act like a proper RTOS. The dream would be to be able to distribute an SD card image and say "just slap this into an RPi and connect it to your TashFloppy backend and away you go". Bonus points if the card's Linux install has some other classic Mac-relevant functionality already set up.

In other news, the state of open-source HDL tools might be the only thing sadder than the state of Microchip's dev tool support for the ATF15xx chips. I've tried running my Verilog code through both yasys and iverilog, and it seems like both are gagging on my use of bidirectional pins. That's fairly disappointing considering you kind of need bidirectional pins on your data bus when making an MPU peripheral (unless you've got pins to spare and are willing to separate the input and output functions, and I don't, and I'm not).

I reached out to Siemens from my .edu email address to see if they had any sort of educational license deal they'd be willing to make on Precision RTL, since theirs is the synthesizer packaged with Microchip's ProChip Designer. No response yet, and I'm not super optimistic anyway, but it must be tried...

 

[jake18125]

I would personally say that there is likely a market for both - full IWM functionality with DCD would be nice, but I'd imagine people would be happy with just floppy support.

I mean hey, if you take it from the perspective of people making Macintosh Clones - the less components to deal with the better .

 

[adespoton]

Has anyone thought about creating an SD caddy in the shape of a 3.5" floppy? So you snap the SD card into the "floppy" and insert it in the disk slot, and the "floppy" gets mechanically connected to a Floppy Emu.

Sure, it Goldberg's the entire process, but it'd be neat sleight of hand, especially on systems that have lost their IWM and/or original floppy drive.

You could even hide the SD card inside the shutter, so at first glance, it's a regular floppy.

 

[finkmac]

Has anyone thought about creating an SD caddy in the shape of a 3.5" floppy? So you snap the SD card into the "floppy" and insert it in the disk slot, and the "floppy" gets mechanically connected to a Floppy Emu.

Sure, it Goldberg's the entire process, but it'd be neat sleight of hand, especially on systems that have lost their IWM and/or original floppy drive.

You could even hide the SD card inside the shutter, so at first glance, it's a regular floppy.

@AEChadwick had something spiritually similar

 

[Tashtari]

The blue box from China arrived, aaaand... reading the latched data register works!



Funny what making everything (a bit) less spaghetti-like will do. I think I might end up ready to test this in an actual Mac soon... at which point I'll find out whether this heckin' chonker of a three-board stack will actually fit inside my SE.

It's also kind of power-hungry. The ammeter is reading 150-190 mA and the 1504s are warm to the touch. The IWM's spec sheet says its maximum current consumption is 200 mA, though, so perhaps that's not a worry.

 

[mdeverhart]

I've tried running my Verilog code through both yasys and iverilog, and it seems like both are gagging on my use of bidirectional pins.

Can you post a small code snippet somewhere? Is the tristate/bidir code constrained to the very edge of the design at the IOs?

 

[Tashtari]

Can you post a small code snippet somewhere? Is the tristate/bidir code constrained to the very edge of the design at the IOs?

This is the kind of thing I'm doing:

module handshake_register
  (
  input wire underrun_n,
  input wire write_data_ready,
  input wire oe,
  inout wire [7:0] data
  );
 
  assign data = oe == 1'b0 ? 8'bZZZZZZZZ : {write_data_ready, underrun_n, 5'b11111};
 
endmodule

Then there are multiple such modules, each of which has 'data' connected to the data bus. Their 'oe' inputs are set up so only one is high at a time and Quartus seems fine with this.

 

[jake18125]

The blue box from China arrived, aaaand... reading the latched data register works!

View attachment 87508

Funny what making everything (a bit) less spaghetti-like will do. I think I might end up ready to test this in an actual Mac soon... at which point I'll find out whether this heckin' chonker of a three-board stack will actually fit inside my SE.

It's also kind of power-hungry. The ammeter is reading 150-190 mA and the 1504s are warm to the touch. The IWM's spec sheet says its maximum current consumption is 200 mA, though, so perhaps that's not a worry.

Looking good! Might be a case of hanging the logic board out of the back of the SE though to test it

 

[mdeverhart]

This is the kind of thing I'm doing:

module handshake_register
  (
  input wire underrun_n,
  input wire write_data_ready,
  input wire oe,
  inout wire [7:0] data
  );
 
  assign data = oe == 1'b0 ? 8'bZZZZZZZZ : {write_data_ready, underrun_n, 5'b11111};
 
endmodule

Then there are multiple such modules, each of which has 'data' connected to the data bus. Their 'oe' inputs are set up so only one is high at a time and Quartus seems fine with this.

Instead of handling the tri-state in each module, try only handling it at the top level right before the chip IO. Each module will have a data_in, data_out, and oe port which you can use at the top level.

If the part actually supports internal tri-states then this will be less efficient than the way you have it coded now, because you’ll have multiple data out buses and a mux at the top level to select which one is driving the data pins. Modern parts almost never have internal tri-states, so this may be why the open source tool chains aren’t supporting your current approach well.

 

[Tashtari]

Instead of handling the tri-state in each module, try only handling it at the top level right before the chip IO.

Well, I tried this approach with the 'north' 1504 code, to mixed success. Centralizing the tristate (along with hand-unrolling a generate block) got iverilog's V95 code generator to run successfully, but yosys still died, this time complaining of "multiple edge sensitive events found for this signal" while trying to synth the clock generator. Unfortunately, yosys is the one that is able to produce an EDIF file that the Atmel fitter can process, so iverilog doesn't get me much of anywhere unless I actually follow through with writing a target for it that writes CUPL equations... I filed a discussion post asking about that here and the prospect seems kind of intimidating.