Announcing the 'IWMless' IWM substitution - call for beta testers

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

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

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

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

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

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

As announced in post #18,  I've wrote something more technical up about the motor timer issues which cause TOTAL REPLAY to freeze (after a few hours of running fine). This writeup is available in the "IWM Reverse engineering" thread:

https://www.applefritter.com/content/iwm-reverse-engineering

in post #98. This is just meant to document the progress of the development work, and preserve for posterity the difficulties encountered. So if for bad reasons like a stroke or "sudden death" of yours truly, I can't finish that work, others can dodge these problems. (No, I didn't take that fraudulent "vaxx",  I am just that old where bad things can happen at any time, especially while sleeping).

All prospective beta testers are well advised to look at the current (the "call for beta testers") thread at least once a week:

https://www.applefritter.com/content/announcing-iwmless-iwm-substitution-call-beta-testers

... because the actual beta test phase may start soon. I've already started building a few beta test units, and expect the SMD components for the RC motor timer next week. Then, some lab work will be needed, and if unlucky, I need to order different resistors to get the timers on target. So there may be some delays. But the sooner I can get these beta test units into your hands, the better. The feedback from you - the beta testers - will be decisive whether the 'IWMless' will ever enter production.

Stay tuned ! (And feel free to ask any beta test related question in this thread, and technical questions in the "IWM reverse engineering" thread.

- Uncle Bernie

This is why I have chosen to deviate from my rule to never release any 'imperfect' product:

 I got some emails / messages from Apple II aficionados who said that even if it just brings their Apple IIc back to life, it would be worth a try and the risk of the money ($10 plus postage).

As far as I'm concerned, I'd really hate to put the 'IWMless' project on the back burner for the next two years or so, until I can find time to continue working on it. I have more important projects to finish at certain deadlines (like the 50th anniversary of the Apple-1, and before my irreplaceable atomic frequency standard reaches its end-of-life).

We could of course argue that if the Apple II crowd has waited for 40 years for an IWM substitute / replacement, they probably could also wait for 42 years, but believe me, I'd rather have the 'IWMless' released now, even if it is somewhat imperfect, than to have yet another unfinished project on the back burner - it's getting crowded there.

Last but not least, if one 'IWMless' gets into the right (competent) hands, meaning some programmer familiar with the SmartPort stuff, it might be that this guy or gal finds out what is going wrong and causes the freezes, which I only observed with TOTAL REPLAY, and never with PRODOS, when accessing the emulated HDD. (Hmmmmm ...)

I'm waiting for the missing SMD components to arrive, and once I have them, I can proceed with building the beta test specimen, at the moment they are in an incompleted state:

beta_test_gang.jpg

Just showing you how "the sausage is being made". It's not easy to build them and it requires fine motor skills few people have. Sure, the SMDs could be pick-and-placed by a robot, and the whole thing then be reflow soldered, which is the standard way the industry builds SMD based PCBs, but if you have ever looked into the setup costs charged by assembly houses able to do that (so-called "NRE" for programming and set-up of these machines), it is doubtful that it ever would become economically viable, at least not for the small production numbers anticipated. The 28 pins must be put in by hand in any case, and then hand soldered. Which does not require advanced fine motor skills, but still, some soldering experience and the right tools is needed. It's not for beginners. And I can't build them in quantity myself, as I just don't have the time, and due to age related issues, such as shaky hands and poor eyesight requiring wearing magnifiers I could not make more than one per day, even if I had the time available, which I don't. And in two years, if I make it until then, shaky hands and poor eyesight certainly won't get any better.

So I think it's high time to get a few of them out into the hands of people who will run them through their paces, and maybe can find out why TOTAL REPLAY occasionally freezes.

Not all of the 'IWMless' seen in the above photo have been spoken for, so you still have the opportunity to sign up (just send me a PM). Note that the lower two are some of my 'lab rats' and these I'll keep, as they have the quick programming connector. So seven beta test specimen are available, no more, and no less.

- Uncle Bernie

Hi fans -

good news !

Yesterday the postman brought a parcel containing an Apple IIe motherboard, as a loan from Applefritter member 'softwarejanitor' --- my own Apple IIe has a bad MMU, so for many months, I could not test the 'IWMless' on a Liron card which plugs into the Apple IIe. An empty Liron clone PCB was donated to me by Applefritter member 'bradleyb'.

Lots of thanks & praise to these two gentlemen who contributed this important hardware to the 'IWMless' project !

I built the Liron clone weeks ago, but could not test it without a functional Apple IIe. Here is how it looks:

LironCloneWithIWMless.JPG

The ugly resistor and the SMD mess are just provisional RC motor timer components for which I could not order the right values yet. "Lab rats" never are beautiful !

Now, after I got the Apple IIe from 'softwarejanitor' I plugged everything together to make a functional Liron card equipped 128k RAM Apple IIe system with a BMOW Floppy Emu hooked up to the Liron clone emulating a 'SmartPort' HDD.

And lo and behold, TOTAL REPLAY now runs even on the Apple IIe and with the 'IWMless' substituting the original IWM in the Liron card. Here is a screenshot of the TOTAL REPLAY splash screen:

TotalReplayLiron.jpg

And here is a photo showing my whole (crowded) lab bench:

AppleIIe_w_Liron.jpg

You may spot the BMOW Floppy Emu which emulates a 'SmartPort' HDD (I do not have any 'official' Apple SmartPort device to test anything, so don't expect the 'IWMless' to support 'official' Apple devices - the beta testers will find out, if they have them, but I won't change the 'IWMless' design anymore).

In the next week, I will let this experiment run to see if it "freezes", which has been a problem with the 'IWMless' and TOTAL REPLAY for the past two months or so, but it is hoped that at least on the Apple IIc, it's fixed, as I could run it 24/7 with no "freezes" (the technical background will be told in the "IWM Reverse Engineering" thread, once I have the time to go over my notes and write it up).

Please have some patience with me, all these tests take time, "24/7" is a whole week, and before they are done to my satisfaction, I simply can't release the beta test units. There also were some recent, "last minute" improvements to the 'IWMless' which shuffled logic around:

COMPATIBILITY MODE IS BACK !

I was finally able to put back the compatibility mode I had planned in the beginning but could not fit anymore during the experiments seeking a solution to the "freeze" problem. As I have the compatibility mode back, I now must repeat all the tests of all the software titles in my "copyprotection test suite" a second time, but with the compatibility mode turned on.

This is a feature the original IWM does not have, which I hope will be useful to give the Apple IIc better compatibility with legacy copy protections which came out before the IWM.  I will write more about the inner workings of the compatibility issues in the main thread, see here:

https://www.applefritter.com/content/iwm-reverse-engineering

Oh, and believe me, I discovered horrible issues with the original IWM and with the "SmartPort" firmware routines, which have nothing to do with the 'IWMless' as these bugs were planted by Apple 40+ years ago, but I must put them under scrutiny as the 'IWMless' uses a CMOS CPLDs which might be more sensitive to these issues. All this requires lab work and planning measurement setups to prove and quantify the problem, and this extra work shifts the beta test release further into the future.

So, stay tuned, and visit this thread maybe once a week to see if there is some new announcement.

- Uncle Bernie

Hi Fans -

As you all know, there have been some delays with the beta test launch of the 'IWMless': my original plan was to launch in early May, about four weeks after the initial annoucement on 1st April 2025 (see post #1 of the current thread). Alas, during testing, I ran into the bad surprise with the "Serpentine" freeze in the TOTAL REPLAY automatic demo mode, which spawned a larger investigation with numerous contributors, see this link:

https://www.applefritter.com/content/asking-you-do-small-experiment-needs-liron-card-or-clone

But this was not the sole reason for the delays - I had to add a resistor to implement the 'shorter' motor timer runtime in the LATCH mode configuration of the IWM, and this looked to be easy at first, by cutting a PCB trace and soldering the resistor over the gap so achieved: if you look at the photo in post#1 of the current thread, you see that I had checked this out with a 'MiniMELF' resistor, which worked fine, but then I ran into mechanical (clearance) issues in the Apple IIc and had to substitute the original capacitor of the motor timer circuit to a physically smaller one, and for this one, having only half the capacitance of my original design, I had no suitable MiniMELFs in stock, and when I tried to order them, I found out that they are heinously expensive, and rare, and not all values I wanted to cover the tolerances of the circuit were in stock at the usual distributors.  So I ordered 0805 resistors which were 10 x cheaper and were available with all the values I wanted to have - but this substitution of SMD package types turned out to be a mistake.

Because when I tried them out in the 'IWMless', they turned out to be too finicky to solder in and due to soldering them onto a cut trace, mechanically too fragile to be something I could release. So there was another order at Mouser needed, to get MiniMELFs, alas, with less values to choose from, and this order had to wait for more components --- it makes no sense to pay their shipping fee for components worth only a few dollars. This caused more wait / delay than the "Serpentine" affair itself.

Here is how the 'IWMless' beta test units now look with the MiniMELF added:

IWMless_added_R.jpg

The red arrow points to the MiniMELF added and not present in the PCB layout. You might also be able to see that I decided to put a epoxy blob over that resistor (and adjacent components) to make it even more mechanically robust. Despite I do never use minimum trace widths unless absolutely unavoidable, these traces are no "official" SMD landing pads and any solder connection using just the trace width is not exactly super strong. You may also see some other component substitutions, if you compare this photo to the one in the first post of this thread. These were done to "center" everything, making the timing uniform over all the beta test units.

But with the protective epoxy blob, it is impossible to exert finger forces on the MiniMELF which are strong enough to "peel" away the PCB trace from the PCB surface. (Just as a side note / hint: if you ever design a PCB layout for your own hobby purposes, avoid using the minimum trace width offered by modern PCB manufacturers if you can - with narrow traces, you will not be able to make any mods to your circuit by scaping off the solder mask and then soldering extra components or flight wires to these narrow traces. And so, if there is a mod needed, you can't do it, and you have to throw away all your prototype PCBs. Just because you needlessly used narrow traces. So don't do that unless absolutely necessary. I see this mistake made by hobbyists all the time.)

Outlook:

In the next days, testing will commence and if I'm satisfied with the current (and final !) version V0.99 of the 'IWMless', I will launch the beta test phase. There is a very narrow time window to sign up for a beta test unit, so stay tuned and look at Applefritter every few days for news in this thread.

- Uncle Bernie

Here is a photo how the Liron clone I did use looks with the 'beta test' version of the 'IWMless':

IWMless_Liron_Clone.jpg

Everything seems to run smoothly and due to the 'IWMless' not having the bugs of the original IWM, you can use these 'IWMless' equipped Liron clones in an Apple IIe having a NMOS 6502. The original Liron card with the original IWM required a change of the NMOS 6502 against a CMOS 6502 - at least this is what Apple recommended back in the day.

 The empty Liron clone PCB was donated to me by Applefritter member 'bradleyb', thanks again !

As this Liron clone is a faithful reproduction of the circuit of the original Liron card, I have no doubt that 'IWMless' is a direct drop-in replacement for dead original IWMs in original Liron cards.

The only "mod" necessary to the Liron card (or clone) is to bridge the 390 Ohms resistor going to the Q3 input of the IWM - Apple did that half-baked kludge to dodge a critical race between the M7 aka FCLK signal and the Q3 signal, and as I saw that race very early in my project, 'IWMless' has its own, more sophisticated de-racing circuit on board, which of course assumes that there is no additional series resistor in the Q3 signal.

This critical race has been lurking in the Apple II since the beginning and never went away, and I think it may have gotten worse with the introduction of the timing HAL. It's a trap for unwary slot card designers who want to use both clocks, as the IWM does. But when knowing it's there, it can be dodged by adding delay to Q3.

Testing of the 'IWMless' with the Apple IIc is still ongoing. The problem I have here is that I can test only about 20 original copyprotected floppy disks and about 80 WOZ images on the BMOW Floppy Emu. And not all of these images work, and proving that the 'IWMless' is NOT the culprit involves swapping back an original IWM and then retry. This is very tedious and the main reason why I need beta testers.

There are more than 2700 different WOZ images out there ....

Stay tuned !

- Uncle Bernie

Hi Fans -

After more than a month of intensive tests, I'm satisfied with the 'IWMless', and deem it ready for BETA TEST.

Why a BETA TEST and What is the BETA TEST supposed to do ?

The problem with a prospective product like the 'IWMless' is that it replaces the original IWM, which is a poorly documented and poorly understood device and to make matters worse, there are literally thousands of copyprotected software titles on floppy disks out there which play weird tricks with the floppy disk controller. So unlike a normal, thoroughly specified product, which can be tested whether it meets the specifications, the 'IWMless', like any other device attempting to substitute the original IWM, is fraught with lots of risks and unknowns, and cannot be fully tested by the producer before it gets released for sale. Normally, no mentally sane producer would ever attempt to launch such a risky product. But as we all know, within the Apple II user community there is great pain caused by dead IWMs, and lots of Apple IIc don't work because of that. So there is a real need for a remedy. Despite it's so risky to try that.

The question is: how to mitigate the risks when launching the 'IWMless' ?

It's understood that I can't pay a fortune to have lots of them built by an assembly house just to find out that buyers would be disappointed, then complain and want their money back.

"Beta Test" can find out if that could happen:

A small group of beta testers who volunteered after my "call for beta testers" in this thread will get the opportunity to buy a 'IWMless' for a very cheap price (just covering the Bill-of-Materials and the postage) and it is hoped that this "Skin in the game" will motivate them to thoroughly test the 'IWMless' and tell us all (by posting on Applefritter) what they find out, and what they think about it. If they are satisfied, fine, I will make a few more just to prove the waters further. If major issues are found, I will not make any more of them.

As far as I'm concerned, I'm satisfied with the performance and compatibility of the 'IWMless' - but I also understand that this does not mean that every other 'IWMless' user will be satisfied.

Based on the number of volunteers this thread did lure in, I made seven beta test units:

IWMless_Beta_Test_Gang.jpg

Each beta test kit comes in a small plastic jewel case and contains one 'IWMless', one special ultra low profile DIL-28 socket, and a bag with four stainless steel washers and some spare pins (just in case a pin breaks off, they can be replaced easily, only a soldering iron with a fine tip is required to do that).

The washers are for the possible case that the specific Apple IIc of the beta tester has issues with headroom of the 'IWMless' to the base plate of the floppy disk drive stepper motor - there is a simple test to find out, and if the test indicates a head room issue, the washers will fix it and the Apple IIc shell still can be closed.  (Note that without an IC socket, there is never a headroom issue and no washers are needed in any case - production units of the 'IWMless', if it ever comes to that, should be soldered in, but this of course means that can't be sent back to be reprogrammed).

There are six volunteers chosen as beta testers (sorted by their post #):

#7  rjustice: has a IIc to resurrect

#8  schafferm: has IIc to repair

#10 CT100: has IIc to repair

#12 javster: eager to test it on his channel

#15 mochatea390: wants to repair his IIc

#17 Verault: has a bad IWM in IIc

All of the above have been contacted by Applefritter PM and if they don't react within a week, their 'IWMless' becomes available to another beta tester.

These three volunteers were not chosen (yet) and the reason is given:

#3 xot: has his IIc in storage and could do tests only months later (his own words)

#4 baldrick: has a IIgs ('IWMless' is not suited for IIgs, sorry)

#13 Appeelicious: has two good IIc (I want to keep these in their unadultered condition)

To be fair to those who were not chosen for the beta test, despite volunteering, I reward you by offering you a discount on the "production" versions, if it ever gets to this point. The beta testers will decide that !

HOW TO GET YOUR BETA TEST UNIT

I've changed my mind on the postage, I will charge an average postage of $6 for every beta tester living in the lower 48 USA, and $10postage  for every beta tester in Europe - only if you live elsewhere, you need to pay the full postage for your location. This saves me some time and if I can't ship it for the quoted postage, I'll swallow the difference myself.

Add the $10 for the BOM and we have $16 for USA lower 48, and $20 for Europeans. This is non-profit for me.

You might ask where the 7th 'IWMless' went: this one was reserved for a beta tester who contacted me direcly by PM and who is able to test the 'IWMless' with a Liron card and various Apple peripherals meant for the Liron.All other volunteers want to test it in an Apple IIc, but I need at least one test suite done with the "Liron".

PLANNED TIMELINE

I am currently working on the 'IWMless' manual for beta testers which explains how to remove a dead IWM and then how to install the 'IWMless', and suggested tests to be done, as part of the beta test. When this is finished (expected end of the next week) and the beta test units have been paid for, I plan to send them out at summer solstice day (20th of June), those to Europe a bit later, but I expect that all beta testers have their kit in early July, and will start to provide us with their feedback and critcism (or praise !) on an extra beta test thread soon afterwards. If the results are good enough, then I can make a few more 'IWMless' in August or September this year, to test the waters further. But these will not be as cheap as the beta test units - I probably will have to pay somebody to do the assembly work, as I'm too busy with other projects to do that myself. Any larger scale production would get even more complicated to organize - 'IWMless' is a mechanically tricky device to make and some of the work, such as soldering in the golden pins, can't be automated, and who can do this manual work requiring fine motor skills at a reasonable price ? Who knows. These issues will be adressed in due time, after the beta test is done.

ANY QUESTIONS / COMMENTS ?

If you are interested in the 'IWMless' and if you have any open questions not answered already, feel free to ask here. You also can tell us what you think about the 'IWMless' project by posting comments in this thread (comments invited !)

- Uncle Bernie

On post #26, 'softwarejanitor' wrote:

" Anyone know where I can find Gerbers or a KiCAD file for this board ? "

Uncle Bernie comments:

'bradleyb' donated an empty PCB of his 'Liron' clone to me for the 'IWMless' project and he told me that he did not publish the Gerbers due to him getting second thoughts about the risk that people might cannibalize Apple IIc or early Macs to get at the IWM needed for populating this board.

And I fully agree - this concern is justified and I do not endorse any cannibalization of functional historic Apple hardware just to make Liron clones. I even don't endorse 'IWMless' experiments with 100% functional Apple IIc (what 'Appeelicious ' suggested in his post #13). I think that we should treat still functional historic Apple II hardware with some respect, and preserve it in unadultered condition unless repairs are needed.

What I would endorse however is some "open heart surgery" involving "organ donors", this is when somebody has an  an Apple IIc with fully functional original IWM, but wants to repair an Apple IIgs or early Mac having a dead original IWM, they could carefully salvage the original IWM and transfer it to the "transplant receiver" to make it whole, and then use the 'IWMless' to undo the damage to the donor.

All this hinges on the acceptance of the 'IWMless' by the beta testers. They must find the 'IWMless' to be fit for service in its intended role.

Another issue - the firmware-in-ROM of the Liron card and the Apple IIc does horrible things to the IWM by causing bus driver fights. This is NO good and should be fixed. In the Apple IIc I can't fix it, but if I would design a new "Liron" substitute card, I could fix it even without modifying the firmware.

Yet another issue (or non issue, depending on the demand for the 'IWMless') is the use of these precious and rare Lattice ispLSI1016 in TQFP packages. I think I have enough of them to supply all 'IWMless' ever needed, but I recon that the demand for 'Liron' substitute cards may be higher. So I think when doing a new 'Liron' substitute card based on my 'IWMless' work, we should use a ispLSI1016 in PLCC, of which I have thousands in my basement, all of them having been in a desperate search for a "job" since many decades.

So let's see what the 'IWMless' beta testers say. Only "total customer / user satisfaction" is acceptable for me. Same as it ever has been with any other product I have ever released for sale.

In a few months we will know more.

- Uncle Bernie

In post#29, 'sigma7' wrote:

" Not mentioned so far on AppleFritter (that I have seen) is that the Apple Lisa 2/10 also uses the 344-0041-A IWM."

Uncle Bernie comments:

I appreciate any and all praise and enthusiasm towards my  'IWMless' project, but you may have noticed the "less" part of the project name implies that it ain't no 100% substitute for the original IWM. I had to make some tough design choices which functions of the original 'IWM' need to be kicked out to make the design fit into the target CPLD (a mid 1990s Lattice ispLSI1016 with only 64 macrocells). There are many good technical reasons for using this long obsolete device, but also the fact that I wanted to find a "job" for all the "unemployed" ispLSI1016 in my basement. For which I paid a fortune back in the day.

But if you have followed my work on the IWM, i.e. in this thread:

https://www.applefritter.com/content/iwm-reverse-engineering

you would know that I do have RTL which supports all functions and modes of the original IWM and is able to run in lockstep with a real IWM in my hardware test bench.

So if I knew there really is a demand for a IWM substitute for the Lisa (or early Macs, or the Apple IIgs) I could leverage this RTL to make a version for them, but based on a larger CPLD.

The big obstacle I'm facing with this is that I don't have any of these "other" machines. So I could not test my IWM substitute on the real hardware. I would need "donations" of the target hardware to do that.

But let's be a bit patient. The 'IWMless' beta test phase just has started and once it is completed I can do other things. I'm a retired IC designer and have nothing else to do to keep my brain from rotting away. And I found the Apple custom chips are quite interesting projects to reverse engineer ...

- Uncle Bernie