Hi fans -
it has been a tradition for me that on every April fool's day, April the 1st, I would present one of my ongoing projects to the Applefritter crowd.
And here it is my project for April fool's day 2025: the 'IWMless':
Those of you who have followed my "IWM reverse engineering" thread will recognize that this one has no programming connector anymore, and no flight wires. This is how the finished version would look (if it's using the RC motor timers).
What is the 'IWMless' ?
It's a small and cheap module that goes into the place of an original but dead IWM of any Apple IIc or Liron card for the Apple IIe. As the tongue-in-cheek name implies, it's l e s s than a real, original IWM, so it can't be used in the Mac nor in the Apple IIgs, nor in the Apple IIc+. The technical reason is that the M8 / FAST modes of the original IWM are of no use with a 6502 CPU running at 1 MHz, so they were left out of the 'IWMless' which is meant only to repair Apple IIc and Liron cards, and nothing else. The advantage of trimming these excess functions away is to get to the finish line sooner and to be able to use a low end CPLD which costs less. Or are you one of these fools who want to pay more of your hard earned money to buy features you will never use ? (Oh, the consumer product industry l o v e s these fools - I don't).
So, why do I publish this on April fool's day ?
Same reason as with all of my previous projects I presented on Applefritter in the last five (or so) April fool's days: these are foolish projects which don't make me a dime of profit, and which - typically and so far - use to draw immense crowds ("crowds" size 3 to 5 people from 8+ billion people worldwide) who are interested in acquiring one of these foolish gadgets I've put together as a foolish hobby to kill my spare time - every useless retiree like me has plenty of.
Interested in getting your own 'IWMless' ?
So, if you are interested in acquiring one of these 'IWMless' modules to fix your Apple IIc or Liron card, comment here, ask any questions you have in mind, and let's see if this time it's more than 3 people, worldwide, who are interested.
You can also state (with no obligations, this post is not a trap) how much you would want to pay for one of those - this is worth to discuss openly as if it ever comes to production involving assembly service companies, an acceptable price point must be known in advance. I can only hand solder maybe half a dozen together by myself, and these will go exclusively to beta testers (you can volunteer).
- Uncle Bernie
P.S.: No obligations for any side and no warranty or fitness for anything given or implied - I don't guarantee I'll make any of them available to anyone, and I can't guarantee they are a good replacement for the real IWM. If you become a beta tester, you will find out sooner or later, and at your own discretion and your own risk. Testing such poorly documented peripherals is very tedious and time consuming, and the sooner beta tests start, the better.
The only thing I know for sure at this point in time is that my three 'lab rats' work well enough to fix my own Apple IIc and to build one or two Liron card clone(s) for my Apple IIe. If I had gotten a dime for each hour I put into this project I could have bought a BMOW "Yellowstone" controller, which, IIRC, seems to support FAST mode on 1 MHz machines using the same trick I used on my Apple-1 floppy disk controller (pulling the RDY line to replace a polling loop). But replacing the "Yellowstone" never was my mission objective. All I wanted is to fix my Apple IIc. And here we are ! I can fix it now, by putting a 'IWMless' in, and the open question is what happens with the leftovers of this project. You decide !
I wish I had a //c to help test. I have a LiRON, but the IWM is soldered on it and I'm not gonna desolder it unless it fails, which hopefully it won't.
Maybe there is someone out there with the bandwidth to create a KiCAD project with Gerbers for tabbing LiRON clone PCBs? If so then IWMless would have a pretty significant interest from a lot of people I'd think.
I'd also love to see a clone of Apple's 5.25" controller card that used the IWM of which prototypes exist but never went into production. With the mod of using a 2716 instead of the BiPolar PROM the original carried over from the Disk ][ and Apple 5.25 Controller card that used 74LS and the Woz state machine in another PROM like the Disk ][ Controller Card.
I'd love to test one but my Apple //c is in storage until I find a new place to settle. Maybe in a few months.
How do we buy one?
I would love to test this in a IIGS...
Someone here made an adapter board for installing the DIP version of the IWM into a IIGS and I have one with a damaged IWM.
You did read that this is only a partial substitute for the IWM (thus IWMless)? Uncle Bernie specifically said it won't fully work on a IIgs, like it won't support Apple 3.5 drives.
Edit to add, that was in another thread, so maybe you hadn't seen it.
Anyway, this is intended to replace the IWM in a //c or maybe a LiRON card or to be used for that functionality in clones thereof.
In post #4, 'baldrick' asked:
" How do we buy one ? "
Uncle Bernie comments:
Purpose of this thread is to lure in beta testers for the 'IWMless'. Once I think the design is ready for beta test, beta tester volunteers will be able to buy a 'IWMless' for $10 plus postage (I will even try to support beta testers outside the USA, but be aware the postage will exceed the price for the 'IWMless' by far - and those to the EU must be smuggled in, no way to clear EU customs if sent as a parcel, because use of non-RoHS 'certified' vintage parts).
And just to make sure: you can't use the 'IWMless' to fix Macs or IIgs, as these need the FAST mode not implemented in the 'IWMless'. I have made this clear in every thread on my IWM work. But what a typical collector could do is to use an Apple IIc or Liron card as the 'organ donor' for a real IWM, use it to fix the Mac or the IIgs, and then put the 'IWMless' into the IIc or Liron card, which don't use FAST mode (AFAIK, tell me if you can prove it does).
On the (very) long run, I may make a 100% compatible IWM substitute, which has all the modes implemented, and I do have the RTL for that, coming from my IWM reverse engineering project. This RTL is able to run in lockstep with a real IWM in all modes. But synthesizing it into a CPLD or FPGA and testing all these modes in all machines (IIgs, Mac, all I don't have) is so time consuming I can't do it before Y2027 even if I had the target machines (IIgs, Mac).
Still looking for more beta testers !
- Uncle Bernie
I'd be interested in testing one. I have a iic that needs resurrecting and this would be great for that. It would need to be shipped down under, happy to pay whatever the shipping ends up.
/Rob
Always on the hunt for one of these as I repair my IIC's an inevitably I find it's a bad IWM!! Please count me in on the beta.
Excellent !
Once the 'IWMless' is ready for beta testing, I will contact you all via PM.
Shipping to down under is so expensive that I'd recommend 'rjustice' of post #7 to wait a little bit until the first beta testers have done some tests and the first results are in.
U.S. based beta testers have the advantage that the could send me their 'IWMless' for reprogramming, if this is necessary. See, I can't test it very much as I have no 'SmartPort' peripherals except for the BMOW Floppy Emu, and I also don't have many original floppy disks with legacy copy protections to test if they work on the 'IWMless' - which they should, as it is no IWM, but a DISK II substitute onto which the IWM specific functions needed for 'SmartPort' were grafted. This strange, hybrid animal promises some advantages (better compatibility with legacy copy protections ?) but also bears some risks to be incompatible with original Apple II "SmartPort" devices, which I can't test as I don't have any.
But I think if you have a useless ('dead') Apple IIc (or Liron card) because of a blown up IWM, just bringing back the ability to read and write real 5.25" floppy disks is worth it (IMHO). If some obscure Apple II 'SmartPort' peripheral does not work, I could try to find out why, but for this I'd need that peripheral to do tests, so very likely, such an issue, even if it could be fixed, won't be fixed due to lack of that peripheral.
My own tests are ongoing, I run TOTAL REPLAY 24/7, but I'm still struggling with moving the design from an ispLSI1016E to a ispLSI1016, which has a smaller GRP (global routing pool) and hence has fitting issues for the same logic ! So what I do is to reconstruct the design step by step - there are many ways to skin a cat. The real irony is that if I do the design morphing by hand and turn the optimizer OFF, I can fit more in than if the optimizer does the partitioning and fitting, where it fails to fit, for the same logic, except partitioned by hand into different equations. But if I take these and merge them again, the optimizer / fitter fails to find a solution. So it is a P.O.S. - if I can find a solution by hand, the software should be able to find it too - or is all this CAD stuff a scam ? - Who knows.
The reason for this struggle is that I have lots of ispLSI1016, leftovers from back in the day, but only a few ispLSI1016E which I bought recently just for this project. These ispLSI1016E are not rare (despite they were discontinued about 15 years ago), but they are expensive if sourced from U.S. based IC brokers, and since I refuse to buy any ICs from Chinese sources (risk of counterfeits too high) there is no cheaper alternative. (This is not an exaggeration, as each and every time I bought ICs from China they turned out to be re-labled counterfeits, and it's simply not worth my time and effort, despite I always was able to claw back the money via the credit card company).
So , stay tuned !
Oh, and I need more U.S. based beta test volunteers !
- Uncle Bernie
I'm game. I'm in the US, have a stack of //c's I can test with, including one that has a dubious IWM. Count me in if still available.
In post #10, 'CT100' wrote:
" Count me in if still available. "
Uncle Bernie answers:
Great ! But please be aware they are not available yet ... I'm still moving the design from the 1016E to the 1016 which is tedious and I don't know if it is feasable. If I need to stay with the 1016E, further delays for buying a few more of them. I also need to do some other lab work to investigate if I could use a physically smaller capacitor so no washers on the disk drive posts are needed to increase headroom. The problem with this is that decreased physical size means decreased C and increased R, which already is in the Megaohms, so leakage currents start to play a role and the whole RC motor timer gets sensitized to that. Not a big deal, but still requires careful lab work to get it right.
So please be patient ... and continue to volunteer as a beta tester - I need more such volunteers !
- Uncle Bernie
I'm eager to test it and review in my channel, and the apple II Facebook group, let me know if possible, I'm based in the US.
If you are still looking for testers, I am a new owner of a couple of Apple IIc computers. I have a rev 255 and a rev 3. I plan on experimenting as I am excited and new to the community. Both my Apples run fine, but i don't mind experimenting and taking notes.
In post #13, "Appeelicious" wrote:
" Both my Apples run fine, but i don't mind experimenting and taking notes."
Uncle Bernie comments:
Although I salute your courage to offer to put your perfectly functional Apple IIc on the operating table (where they might die, as may happen also for humans who get surgery), I advise against doing so.
The 'IWMless' is strictly meant to repair Apple IIc (or Liron cards) with a bad / dead IWM, which are worthless due to that fact. They are "dead" anyways, so if anything goes wrong with the "surgery" (removing the dead IWM, putting a socket in), no innocent Apple IIc gets killed.
When I operated on my Apple IIc having dead IWMs (and I'm a very skilled electronics "surgeon" with the right, professional tools) I did notice some signs of elevated risks (offgassing / solder bubbling of the PCB) which spells t-r-o-u-b-l-e. I can't say of this is due to poor base material they used 40 years ago, or if the material does that due to age (partially decomposed) but if the Apple IIc works, better leave it alone.
For my beta testers in the USA, I'd offer to put that socket in, but you have to pay the postage to send the disassembled motherboard both ways (the IIc is too heavy for cheap postage) and have to sign a waiver that keeps me free from any liability for damages to that Apple IIc. Sorry, but this is the way in a lawyer infested country. Still much better odds for you unless you also have the skills and the professional desoldering equipment - the type which has an electrical vacuum pump and a temperature regulated soldering iron with a hollow tip.
- Uncle Bernie
This is good news. Count me in. I have several IIcs and 2 have boot issues and I think the IWM might be the cause. Hence they've been sitting for months. Are there clearance issues? I know the IWM, even being soldered directly to the board is litterally right below the bottom of the floppy drive. But I'm definetely game!
In post #15, 'mochatea396' wrote:
" Are there clearance issues ? I know the IWM, even being soldered directly to the board is litterally right below the bottom of the floppy drive "
Uncle Bernie comments:
Yeah, there always have been clearance issues with the IWM, this is why Apple could not use a socket for it.
When I designed the 'IWMless', I was well aware of this problem and took careful measurements on several Apple IIc I had, and then I did the mechanical design even before I did any coding work for the logic. This is why the ispLSI1016 sits on the bottom side of the PCB and why there are only few SMD components on the top which are small enough to cause no trouble, as long as no socket is used. For my testing (and for the beta testers ;-) I have procured special low-profile DIL-28 sockets which theoretically allow the use of socketed 'IWMless', but alas, it turned out to be a very tight fit, as the largest SMD, the capacitor for the RC based motor timers, touches the bottom of the stepper motor when the Apple IIc is assembled. It's a matter of some thousands of an inch. I have tested two ways to solve this, either by adding thin washers on the floppy disk drive posts (a bit tricky to do), or by choosing a smaller sized capacitor. So there are solutions.
The last weeks I was struggling with re-writing the RTL such that it would fit into a ispLSI1016 (the older, first, Y1994 version without the "E" suffix) but now I'm close to have a solution that fits, but not being there yet. The original design of course did fit, until it was discovered that the LATCH config bit shortens the motor timer runtime, and so this bit and associate logic had to be added. I want to use the ispLSI1016 because I have plenty left over from back in the day, and ironically these were left over because of fitting issues - the improved version ispLSI1016E with the "E" suffix has a much better global routing pool and far less fitting problems. But these I don't have in quantity - I had to buy a few of them just to get going and to avoid running into fitting problems just from the start. This saved me some time (and I could use more powerful later Lattice development tools, too) but I really wanted to be able to use up the older leftover ones.
At the moment I still have a few minor open issues revolving around the motor timer and under which conditions the CONFIG register gets updated and the current simple (and small) solution that fits into the ispLSI1016 is not perfect: this means that my test runs using TOTAL REPLAY runs only for a limited time (maybe 16-24 hours) before a 'freeze' occurs and the automatic demo freezes. Typically, it's not a crash, though, because it still accepts the ESC key and then returns to the TOTAL REPLAY splash screen, and proceeds to run the automatic demo.
I'm not 100% sure what the exact mechanism of this behaviour is, so it's basically educated "hacking" of the 'IWMless' logic until - hopefully - it finally works and the freezes are gone.
For those of you who did not follow the main thread (https://www.applefritter.com/content/iwm-reverse-engineering), there was a lot of confusion and wild goose chases for the perfect, cycle exact motor timeouts, but in the meanwhile I was able to prove that the exact motor timeouts are not needed, but the "freeze" is influenced by them. Sounds like a contradiction, but isn't. What I know for sure now is that the absolute motor timer runtimes can vary widely and cause no "freeze". But there seem to be vulnerable / sensitive sections in the SmartPort code, which, if "hit" by a motor turn off event at the wrong time, may go wrong, and my current working hypothesis is that they then proceed to wait for something from the IWM which does not happen anymore, or they proceed without having the IWM reconfigured properly. This is related how the "motor off" and "motor on" events unlock or lock the access to the CONFIG register of the IWM.
I have three versions of the 'IWMless', one using a RC timer, one using a PIC microcontroller (6502 cycle exact motor timeout), and one using a piggybacked original IWM as the motor timer timeout source (the ENBL1, ENBL2 outputs are a combinatorial function of the inner MOTOR ON signal and the drive select bit, so MOTOR ON is directly observable). The latter version has the least number of freeze events, it may run 24/7 for maybe 2 weeks, the PIC version runs for days, and the RC version runs for maybe 16-24 hours. As far as I can tell, PRODOS operation and SmartPort devices never froze, but there may be internal retries which are invisible to the user. The whole inner IWM timing is much like Schoedinger's Cat, unfathomable and unpredictable until you look inside the box, and the transistor level schematic (see post #47 of the main thread) reveals a lot of skullduggery going on (yes I found where these Schroedinger Cats hide within) and yes, there are critical races and weird added logic attempting to mitigate their effects. In the meanwhile, I also wrote some little machine language test programs which prove that these "Cats" are indeed there and may cause some (quantum mechanical ? ;-) randomness in the behaviour of the IWM related to motor turn off and motor turn on events and the update of the CONFIG register associated with these events. My current conjecture is that even the developers at Apple had no idea what really was going on inside the IWM, and so they just may have hacked their SmartPort firmware (the so-called "Protocol Converter") until it appeared to work, and after that nobody at Apple may have dared to touch that code anymore, lest it would explode right into their face (figuratively speaking).
This may be why there are occasional "freezes" unless it's a real IWM for which the "healing" software hacks have been experimentally found and were implemented by the original developers (I could write more details about the horrifying things I found when finally, after a lot of procrastination, I started reading the transistor level schematic a few days ago - I even was right with my conjectures about the motor timer LFSRs (post #46 of the main thread), except for the difference that the designers of the IWM did not multiply out the polynomials as I suggested, but just use a specific state of the shorter LFSR to make a gated clock for the longer LFSR. Alas, the automatic extraction process screwed up on properly analyzing this gated two phase clock generator (as shown in the schematic it would get stuck until a RESET occurs), so I can't know the fine details of what happens in the silicon. (There may be other errors in that schematic, too.)
So my work is ongoing and making progress, but this progress is very slow, as I only have one Apple IIc to run tests, and at the moment it looks like this: I wake up and look for it (and find it did freeze over night), then try to restart it with the ESC key (most often works), then I make me a breakfast and put a small mod into the CONFIG register update logic, reprogram the ispLSI, plug it back, launch TOTAL REPLAY, and then work on other projects for the rest of the day, until I go to bed. So far it rarely happens that it freezes during the day. So, basically I have one attempt per 24h to get it right. I have a test matrix of all combinations of all signals involved, and I've covered about one third of the possible interactions. This is brute force trial-and-error. Once I found a combination of signals which masks the very rare 'bad, ouch, freeze' event, then I can go into the beta test phase and make a few units for beta testers - I don't think it would make any sense to send beta test units out which still have the TOTAL REPLAY freeze issue, although they could discover other possible issues, such as with real Apple peripherals using the "SmartPort" - I have none of those, I only have the BMOW floppy emu.
But if any of my prospective beta testers read this and absolutely, desperately wants a unit, this can be arranged even before I am satisfied with the state of the work. Just comment on this.
- Uncle Bernie
(P.S.: Just to avoid wasting time of volunteers, I did already inspect the source code for TOTAL REPLAY, it is on github ("4cade-main"), but so far I found nothing suspect in the relevant routines (like prorwts2.a) which could cause the freezes).
I would be willing to try. I have a bad IWM in a IIc.
In post #17, 'Verault' wrote:
" I would be willing to try. I have a bad IWM in a IIc. "
Uncle Bernie comments:
I appreciate (and need) every volunteer for the beta tests. But as I have disclosed in this thread, the 'IWMless' is far from being perfect: I still haven't found out why TOTAL REPLAY freezes / crashes after running for (typically) more than 24h hours.
Alas, this is the only SmartPort test I can do other than launching TOTAL REPLAY from PRODOS.
I do have some working hypothesis why these freezes / crashes happens, and I'm working on finding a remedy, but what if no such remedy exists ? It seems to be the motor timers and their lock/unlock action on the CONFIG register of the IWM, but with a single ispLSI1016, I simply can't put the LFSR based motor timers seen in the original IWM in - this would require about 26-27 macrocells more, which I don't have, as a '1016 only has 64 macrocells.
The big question here is: "How good is good enough" ?
Would you (and I mean you all who read this thread) accept an imperfect solution which can't run TOTAL REPLAY for extended periods of time ? Is a 'IWMless' which can bring a dead Apple IIc back to life with the normal internal floppy disk functions working good enough ? Even TOTAL REPLAY boots fine and you can run the games (and play them), it seems it's just the automatic demo which has the freeze problem. So what I suspect here is that every few 100000 SmartPort operations something gets misconfigured and the software does not detect this and so it does not initiate a retry and gets stuck.
For me, being a perfectionist, this is totally unacceptable. Even if we would adopt the notion that the 'IWMless' is a prosthesis for an Apple IIc whose "legs" got blown off and enables it to "walk" = work again, although not as good as before, with the original "legs" = original IWM.
All industries deal with this kind of problem all the time: they have some imperfect product(s) which can't be fixed. So they declare the bugs to be a feature. And if that does not fly, they blatantly claim that "worse is good" or "worse is better".
I'd like to see your opinion on that. I fully understand that an Apple IIc with a dead IWM is a dead Apple IIc, so even if we only can give it a prosthesis to bring it back to life, despite of the shortcomings, this may be better than just having a dead one.
Comments invited !
- Uncle Bernie
(P.S.: when I have more time, I will post something about the inner workings of this problem in the 'IWM reverse engineering' thread. It is an astoundingly complex problem despite of the apparently simple rules it is based upon.)