68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | |
| Cloning the IWM (sort of) | |
| Posted by: adespoton on 2025-06-06 12:01:56 I didn't realize that edge sensitive events would be an issue at this speed and density; is that just yosys being cautious, or is the 1504 more temperamental than I thought? I have to admit, most of my experience is with slower parts. I haven't done much in the past 15 years in this space and the tools seem to have improved significantly. | |
Posted by: mdeverhart on 2025-06-06 18:38:22this time complaining of "multiple edge sensitive events found for this signal" while trying to synth the clock generatorCan you post the code for the clock generator? I’m happy to look on GitHub too if you want to post the code there. | |
| Posted by: Tashtari on 2025-07-27 03:44:28 Oh boy, it's been a while since I updated this thread. I haven't forgotten, I promise! It's just that my mental stove has an awful lot of back burners... At this point I'm all in on producing a design that will work with @max1zzz 's ITXPlus board - though, of course, once that's working, it should be a simple matter to adapt it to other Mac situations. I've got two irons in the fire (to mix a metaphor) - one, to just straight up produce an HDL clone of the IWM, and two, to produce an IWM workalike for the Mac that mimics the UART protocol of what I'm now pretty well resolved to call TashFloppy. The HDL clone of the IWM is proving difficult. The IWM is just such a weird design - as I think I have said before, the Disk II was genius, but the IWM takes it and makes it weird. It's hard to know what in the spec is "it needs to work this way" and what is "it happens to work this way". This would probably be the more generally useful outcome so it's difficult to dismiss, but I'm worried about a long tail of corner cases. The IWM workalike that mimics the TashFloppy protocol is interesting me more lately. For one thing, I believe I've got the logic to fit in a single ATF1504 rather than two, so that's nice. For another, it raises the possibility of floppy-but-faster since the IWM won't be constrained by having to exchange data at ~500 kHz. This depends on the ROM not making assumptions about the inbound/outbound data rate, though, which is a substantial unknown... but if it actually works, how cool would that be? Plus, it's got me thinking about TashFloppy again, which is a project I really don't want to let die on the vine. Can you post the code for the clock generator? I’m happy to look on GitHub too if you want to post the code there.Sorry for not responding to this... code's just in such a state of flux right now, plus I've kind of given up on the open source toolchain idea. Everything out there is just in such a half-baked state that I feel like I'd wind up spending more time working on my tools than I would on the actual project. I was hoping that prjbureau would provide something I could use with yosys, but it seems like it's just information - a wealth of information for anyone wishing to create a toolchain, no doubt, and full props to those who are working on it - but that's ultimately not what I want to do. Unfortunate state of affairs, but so it goes. POF2JED and Quartus II is it for now. | |
Posted by: Snial on 2025-07-27 08:58:11<snip> two irons in the fire (to mix a metaphor) - one, to just straight up produce an HDL clone of the IWM<snip>My preferred one. @MIST , is this your bag too? <snip> I've kind of given up on the open source toolchain idea. Everything out there is just in such a half-baked state<snip>That's the kind of problem I'm facing with Retro68 development. In the past, a dev environment needed stdlib, and a few, basic include files (e.g. stdio.h, string.h). These days even the simplest stuff needs every library under the sun. In my case, Boost, a C++ library which isn't linking properly. I suspect it's somehow tied itself into an x86 library path (and possible include) when it should be ARM64 (because in fact I have installed Boost for ARM64). Unfortunately it's very hard for me to diagnose why it won't link, because I'd have to delve into all the autoconfig stuff that's best left alone. | |
| Posted by: harrowm on 2025-07-27 09:47:23 If you want to use verilog with the atf1504 then you can use yosys and this: https://github.com/hoglet67/atf15xx_yosys.git It works well. Tri-state gates have to be at the top level (as they do in wincupl). | |
| Posted by: harrowm on 2025-07-27 18:08:31 Maybe that is a bit brief - the "oe" and the tristate have to be top level. The repo above has some tri-state example and a guide on how to install the scripts, the ATMEL fitters and yosys. It also includes wrappers so that you can run from a shell script and it will invoke wine etc to run the fitters. POF2JED and Quartus also works ok .. you just have to put up with a very old buggy Windows program. Save frequently ! | |
Posted by: Tashtari on 2025-07-28 03:13:15My preferred one.It certainly would be the most straightforward solution from a user's perspective, and it could be incorporated easily into "Mac in an FPGA" type projects. I just don't know if I can actually do it. =) I haven't given up yet, though. you just have to put up with a very old buggy Windows program.True, though the Atmel fitters are also very old and very buggy (as @zigzagjoe will attest) Windows programs, so it seems like damned if you do and damned if you don't. Quartus II has crashed on me a couple of times but in general the flow with that and POF2JED seems relatively dependable - whereas the Atmel fitters have in the past produced JED files that straight-up don't do what they're supposed to when downloaded into the CPLD... | |
Posted by: zigzagjoe on 2025-07-28 07:08:25It certainly would be the most straightforward solution from a user's perspective, and it could be incorporated easily into "Mac in an FPGA" type projects. I just don't know if I can actually do it. =) I haven't given up yet, though.Yeah, the workflow for the Atmel chips is depressing. I really like the capabilities of the chips themselves, but the fitter is hugely problematic. Atmel's supported languages use the same workflow: high level language (CUPL, etc) -> fitter (place and route) -> JED. I have not run into the issue Tashtari reported with incorrect jed files, but I've run into a pile of other issues. It's not a lot of fun to make a trivial change and have the fitter either blow up entirely or start making major changes in the logic layout with major implications on propogation delay. And by not a lot of fun I mean it's incomparably frustrating and 100% why I've taken a break from my cached NeXT accelerator. The fitter is also absolutely riddled with bugs - I've run into cases where one change can cause the fitter to entirely stop using cascade logic across the chip without clear cause even across entirely unrelated logic. Switches that do nothing or even cause exactly opposite effect. Opaque functionality and cutesy behavior ("optimizations") that just break things .... I could rant for days, but I'll stop here. Quartus -> POF2JED is the only route that fully avoids the fitter software, but in turn you give up all the additional features of the atmel chips over the altera chips they're a superset of. Additional clocks, routing resources, etc. Not that this doesn't allow you quite a bit of room to work, but for what I've been working those additional clocks and routing are terribly useful / mandatory. prjbureau is a replacement for ATMISP which turns a JED file into a SVF file (series of JTAG instructions) for programming. It has some interesting insights into the chip architecture but is limited to ATF1502 at this time, and does not replace the awful fitter software. | |
Posted by: mdeverhart on 2025-08-12 19:37:50Sorry for not responding to this... code's just in such a state of flux right now, plus I've kind of given up on the open source toolchain idea. Everything out there is just in such a half-baked state that I feel like I'd wind up spending more time working on my tools than I would on the actual project.No problem, makes sense to me. I can't help with the toolchain problems (no experience with any of the Atmel tools, yosys, or the POF2JED flow, though I do have some Quartus experience), but I can potentially help with Verilog or VHDL questions and issues. Happy to help if there's anything I can do (though my time is limited and it's been 2 months since I logged in here...) | |
| Posted by: xporadio on 2025-09-22 16:14:36 It's been about 40 years and patents expire. Can't we just make a go-fund-me to hire Steve Wozniak to recreate one? As stupid as that sounds it's probably more promising 😀 | |
| Posted by: jake18125 on 2025-09-22 23:44:19 I mean, Woz wasn't really involved in the IWM. It was mainly Dr Wendell Sander. | |
| Posted by: sstaylor on 2025-09-23 02:38:07 I had always understood that the initialization stood for "Integrated Wozniak Machine" | |
| Posted by: jake18125 on 2025-09-23 02:45:44 Earlier in the year, Wendell Sander, the designer of the Apple III and one of Apple's best engineers, did a small custom chip that crammed all the functionality of Woz's disk controller into a single chip. It was called the "IWM" chip, which stood for the "Integrated Woz Machine", since Woz's disk controller is really an elaborate state machine, but it also stood for the "Integrated Wendell Machine". From Folklore: Folklore.org: Five Different Macintoshes
www.folklore.org
| |
| Posted by: ironborn65 on 2025-09-23 02:56:45 from https://archive.computerhistory.org/resources/access/text/2024/08/102809005-05-01-acc.pdf An interview with Wendell Sander, page 20: "... Spicer: Yeah. Now one of the technologies that I want to talk about because you had a big role in it is the disk controller, and the IWM, which is the Integrated Wendell Machine. Sander: No. The Integrated Woz Machine ...." | |
| Posted by: Arbee on 2025-09-23 13:03:48 It's called "Integrated Woz Machine" because it's the 6 chips from Wozniak's original controller integrated into a single chip (and with some additional features added). | |
Posted by: wskjinfen on 2025-10-22 00:47:19Oh boy, it's been a while since I updated this thread. I haven't forgotten, I promise! It's just that my mental stove has an awful lot of back burners...Hello😀, do you have the communication protocol documentation for the IWM (344-0041-B)? I haven't found a complete guide online, and I'd like to try rebuilding the IWM myself using an MCU or FPGA to repair Mac 128K and Plus motherboards.Thinks. | |
Posted by: Tashtari on 2025-10-22 02:06:18do you have the communication protocol documentation for the IWM (344-0041-B)?Have you seen this already? As far as I'm aware, this is the most complete documentation for the original IWM. There's also Understanding the Apple II's chapter on the Disk II, which fleshes out the technical details of the hardware on which the IWM is based. (If you find these useful, maybe chip a few bucks to the endlessly useful archive.org, they face no shortage of legal threats and lawyers aren't free...) | |
| Posted by: jake18125 on 2025-10-22 02:14:44 It's also worth noting that if you just need to confirm the functionality of a Plus/128k - there is my SCHWIM GitHub - DosFox1/Shim-IWM: A simple electronic "shim" to replace an Integrated Woz Machine in a Macintosh. It contains just enough hardware to pass the initial boot check, and boot into Mac OS via SCSI.A simple electronic "shim" to replace an Integrated Woz Machine in a Macintosh. It contains just enough hardware to pass the initial boot check, and boot into Mac OS via SCSI. - DosFox1/S...
github.com
Alternatively, the IWM in the SE is compatible with the Plus and the 128. I even have a feeling an FDHD SWIM will work (just without the ability to read 1.44mb disks) | |
Posted by: wskjinfen on 2025-10-22 02:47:48Have you seen this already? As far as I'm aware, this is the most complete documentation for the original IWM. There's also Understanding the Apple II's chapter on the Disk II, which fleshes out the technical details of the hardware on which the IWM is based.Thanks, I've seen this document before, but it's for Apple IIC IIGs (probably 343-0041). I've heard it's different from Mac's 344-0041. Can Mac use 343-0041? If so, I'll refer to this document. I just started studying IWM, so please forgive me if I ask stupid questions. | |
Posted by: wskjinfen on 2025-10-22 03:48:48It's also worth noting that if you just need to confirm the functionality of a Plus/128k - there is my SCHWIMThanks, I need to restore the disk to function without the old parts. | |
| < 4 > |