• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Cloning the IWM (sort of)

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

mdeverhart said:
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.
Click to expand...
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.
 
Tashtari said:
<snip> two irons in the fire (to mix a metaphor) - one, to just straight up produce an HDL clone of the IWM<snip>
Click to expand...
My preferred one. @MIST , is this your bag too?
Tashtari said:
<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>
Click to expand...
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.

 
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 !
 
Snial said:
My preferred one.
Click to expand...
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.

harrowm said:
you just have to put up with a very old buggy Windows program.
Click to expand...
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...
 
Tashtari said:
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.


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...
Click to expand...
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.
 
Tashtari said:
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.
Click to expand...
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...)
 
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 :D
 
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 www.folklore.org
 
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).
 
Tashtari said:
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.


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.
Click to expand...
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.
 
wskjinfen said:
do you have the communication protocol documentation for the IWM (344-0041-B)?
Click to expand...
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...)
 
It's also worth noting that if you just need to confirm the functionality of a Plus/128k - there is my SCHWIM
github.com

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 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)
 
Tashtari said:
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...)
Click to expand...
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.
 
Last edited:
jake18125 said:
It's also worth noting that if you just need to confirm the functionality of a Plus/128k - there is my SCHWIM
github.com

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 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)
Click to expand...
Thanks, I need to restore the disk to function without the old parts.
 
You must log in or register to reply here.

Similar threads

pizzigri
adding 4mb SGRAM to PowerPC 5500/6500 ... and possible ATi Rage Pro upgrade
Replies
16
Views
2K
croissantking
croissantking
superjer2000
Apple IIgs PCTransporter Saga
Replies
0
Views
144
superjer2000
superjer2000
zigzagjoe
Macintosh 68060 Redux
4 5 6
Replies
103
Views
13K
croissantking
croissantking
pizzigri
It's here: the Color Classic LCD Project is complete!
Replies
19
Views
3K
CC_333
CC_333
eharmon
24-bit graphics on Wombat's DAFB?
Replies
12
Views
4K
terrier
T
Back
Top