To the best of my knowledge, the IWM used by the Mac is functionally identical to the ones used by later Apple IIs.
Cloning the IWM (sort of)
- Thread starter Tashtari
- Start date
Thank you very much for clearing。I’ll give it a try.
I've been at work on this project again, and I think I might've gotten to the point of being code complete (though not yet perfectly functional).
The current approach is targeting an ATF1508 using the Verilog→Quartus II→POF2JED workflow. I don't know how portable my Verilog code is, it makes fairly heavy use of Quartus II's "dff" and "tff" primitives and it's not terribly pretty besides...
I've been over and over and over the IWM spec sheet and I've been slowly arranging things into a remotely-sensible order. One thing I learned (though, looking at this thread, it seems I learned it previously and forgot it) is that Q3 is literally only used for writes in synchronous mode, FCLK does everything else. This makes sense, considering that this is how the Apple II does disk writes with a carefully cycle-timed loop. Another thing I learned (through inference, anyway) is that the IWM doesn't exactly imitate the behavior of the Disk II except in synchronous write mode, where it has to. Synchronous read mode is where the sequencer ROM on the Disk II really shines. Once the shift register has a full byte, the Disk II takes pains to keep it there as long as possible so the slow-as-cold-molasses CPU has time to read it, not clearing the shift register until the first two bits of the next byte have come in - a minimum of 11 Q3 ticks in my analysis. The IWM, by contrast, stalls the shift register for "a period of two bit times plus four CLK periods", which is actually a fair bit longer than the Disk II permits. I haven't looked at the code of the Disk II driver, but the description in Understanding the Apple II (an absolutely marvelous book) implies that it polls the shift register, waiting for the MSb to be set, indicating the reception of a full byte, then waits for it to be clear again, rinse, repeat. Hopefully that means that as long as I err on the side of generosity, I don't have to match the Disk II's timing, either.
Which brings me to my current problem... testing. I have a design, I have a board, I even have a test harness of sorts for poking at it, but I need to convert my understanding of the IWM's expected behavior into tests. That's hard enough (if you've written the code as cleverly as possible, you are definitionally not smart enough to debug it), but once I'm reasonably satisfied of its functionality by that metric, there are a lot of production cases to test, as well. The Macintosh, of course, which uses an 8 MHz (nominal) FCLK, asynchronous mode, latch mode, and connects Q3 to something that isn't a clock... the generic Apple II, which doesn't provide an FCLK, uses synchronous mode without latch mode, and provides a 2 MHz Q3... and the Apple IIgs and IIc+, which sometimes acts like a generic Apple II and sometimes like a Macintosh with a 7 MHz FCLK and possibly other mode settings. Scary.
Anyway, enough rambling/complaining. Hope your day's going well. =)
The current approach is targeting an ATF1508 using the Verilog→Quartus II→POF2JED workflow. I don't know how portable my Verilog code is, it makes fairly heavy use of Quartus II's "dff" and "tff" primitives and it's not terribly pretty besides...
I've been over and over and over the IWM spec sheet and I've been slowly arranging things into a remotely-sensible order. One thing I learned (though, looking at this thread, it seems I learned it previously and forgot it) is that Q3 is literally only used for writes in synchronous mode, FCLK does everything else. This makes sense, considering that this is how the Apple II does disk writes with a carefully cycle-timed loop. Another thing I learned (through inference, anyway) is that the IWM doesn't exactly imitate the behavior of the Disk II except in synchronous write mode, where it has to. Synchronous read mode is where the sequencer ROM on the Disk II really shines. Once the shift register has a full byte, the Disk II takes pains to keep it there as long as possible so the slow-as-cold-molasses CPU has time to read it, not clearing the shift register until the first two bits of the next byte have come in - a minimum of 11 Q3 ticks in my analysis. The IWM, by contrast, stalls the shift register for "a period of two bit times plus four CLK periods", which is actually a fair bit longer than the Disk II permits. I haven't looked at the code of the Disk II driver, but the description in Understanding the Apple II (an absolutely marvelous book) implies that it polls the shift register, waiting for the MSb to be set, indicating the reception of a full byte, then waits for it to be clear again, rinse, repeat. Hopefully that means that as long as I err on the side of generosity, I don't have to match the Disk II's timing, either.
Which brings me to my current problem... testing. I have a design, I have a board, I even have a test harness of sorts for poking at it, but I need to convert my understanding of the IWM's expected behavior into tests. That's hard enough (if you've written the code as cleverly as possible, you are definitionally not smart enough to debug it), but once I'm reasonably satisfied of its functionality by that metric, there are a lot of production cases to test, as well. The Macintosh, of course, which uses an 8 MHz (nominal) FCLK, asynchronous mode, latch mode, and connects Q3 to something that isn't a clock... the generic Apple II, which doesn't provide an FCLK, uses synchronous mode without latch mode, and provides a 2 MHz Q3... and the Apple IIgs and IIc+, which sometimes acts like a generic Apple II and sometimes like a Macintosh with a 7 MHz FCLK and possibly other mode settings. Scary.
Anyway, enough rambling/complaining. Hope your day's going well. =)
Similar threads
