IWM reverse engineering

Hi fans -

This afternoon I was able to boot from a DOS3.3 disk using my "IWMless" prototype (first announced in post #48 above):

IWMless_booted.jpg

Here are closeup photos of the "IWMless" which is to be understood as a "lesser IWM substitute":

IWMless_top.jpg

The CPLD which holds all the logic sits on the bottom side of the small PCB:

IWMless_bottom.JPG

Disregard all the ugly headers and flight wires, these are only on the 'lab rat' to allow for quick in circuit programming turnaround cycles. The 'production' version will use a custom made programming fixture with pogo pins, so it will look nice and clean. There is a solder option on the back side which needs to be closed after programming. On the 'lab rat' this is replaced by the small plug which goes into the programming header, visible in the above photo.

CPLD USED

The CPLD is a Lattice ispLSI1016 in a 44 pin TQFP package, which is tricky to solder. But IMHO it is the only still human solderable package which fits between the pin rows of a DIL-28 footprint. This is why it was chosen for this project, aside from the fact I have plenty of them left over. Yet another plus is that it's still a 5V device. These were built on a 0.6um CMOS process, which was leading edge when Lattice designed them in the early 1990s (the next step down the "shrink path", 350 nm, made its debut in Y1993) and alas, the last 0.6um fabs are currently being shut down forever. A 350nm technology can't take 5V, and all the 5V I/O available for 350nm and beyond is done with extra process steps (dual gox) which drive costs substantially over single gox processes. So, byebye 5V process technologies. We had a good time together !

THE DRAWBACKS OF USING A SMALL 1990's CPLD

The downside of using such a small CPLD is that I think it's impossible to fit all the IWM functionality in it. My bet is that juuuust enough of the real IWM functionality, limited to what the Apple II needs, might be shoehorned in. None of the Mac related functions of the original IWM are needed in this case. And I'm not interested in "healing" any Mac having a dead IWM. I'm only interested in the Apple-1 and Apple II family up to the Apple IIc. The Apple IIgs is not in my collection, so I'm not interested in it either. Sorry for that, but being retired I now only work towards my own hobby's ends and needs.

CURRENT STATE OF THE WORK

What I have implemented right now is a DISK II compatible floppy disk controller with the added IWM functionality of being able to read and write the CONFIG register of the IWM, turn the motor delay off and on, and look for the bit which tells if the motor is running or not. These IWM functions seem to be necessary to satisfy the IWM detection routines as specified by Apple in some of their published technical briefs. None of the other IWM functions related to the M8, FAST, ASYNC, and LATCH configuration bits are implemented yet. I do have the RTL for them, but it does not fit into the ispLSI1016. I have a hunch that most of them may not be needed in the Apple II. For instance, FAST mode: a 6502 running at 1 MHz is just too slow to transfer a byte per 16 us, or 16 CPU cycles, as long as polling loops are used. With some foul tricks like loop unrolling it maybe could be done, but only barely, and it would be ugly and inefficient in terms of code space. I don't think that Apple used such foul tricks for the "SmartPort" functions.

THE BIG OPEN QUESTION

Now the big open question: what exactly is the SmartPort in the Apple IIc and on the Liron card, which IWM configurations / features does it really need to work ?

PROJECT IS ON HOLD

I can't continue with the "IWMless" project before somebody points me to the specific information sought. And no, don't point me to some binary or disassembly listing of the Liron card or such. I just don't have the time to look through that to find which IWM configs are invoked by the SmartPort. My RQLT ("Residual Quality Life Time") is too valuable to repeat analysis tasks which have already been done by others, perhaps several times, again and again, over the past 40 years.

If you happen to be one of those, and want to get this project making progress, please speak up in this thread or send me a PM.

Comments invited !

- Uncle Bernie

In post #55, 'baldrick' wrote:

" Forgive my ignorance here, but I think using an obsolete IC from 30 years ago is problematic.  It's just not available from the usual suppliers. " 

Uncle Bernie answers:

My "usual supplier" is my basement and I have so many ispLSI of various types left over from the time where I did designs for customers that I somehow need to find a good use for them. However, I did buy a few ispLSI1016 in TQFP-44 recently, just for this project. These should be enough for the maybe half a dozen people who would want a "IWMless" to fix their Apple IIc. Most of my ispLSI stash is PLCC. Some of the larger types are quoted by greedy IC brokers for $100-$350 a piece. Hilarious ! 

You are wrong with your assumption that more modern CPLDs or FPGAs are "more appropriate". The problem with them is exactly what you state as being an advantage ("newer = 3.3V and faster"). The "faster" is the problem. Which makes these newer FPGAs (or CPLDs) much more sensitive against a wonky host environment. See the struggle of Applefritter member "frozen signal" with his MMU and IOU replacements. It has been how many years since he started work on them ? IMHO he is not struggling with his logic ("RTL"), but he is struggling with the implementation. The problem with FPGAs being that for even small changes in the RTL, the P&R may be totally different, leading to different timing issues on every iteration. Timing issues which are coming from the wonky host environments the FPGA is supposed to work in.

With "wonky host environment"  I mean the Apple II motherboards, their non existing ground planes, ringing signals with dubious rise and fall times,  and the overall system architecture being too old (1970's-ish) for fast, modern ICs. It is not Woz' fault, mind you. The 6502 bus architecture as such  is just wrong (from a modern point of view) and has so many pitfalls built into it that it would never work when implemented in modern CMOS technologies. I don't have the time to explain all this so take it as a piece of wisdom from a seasoned full custom IC designer. Also, keep in mind that the NMOS 6502 is a design that dates back to 1974/75 and back then everything digital put around it was too slow to even notice the inherent, lurking problems found in any 6502 based system (and others, based on other microprocessors of the same time period, too). Don't misunderstand my criticism - I don't say the 6502 design is faulty. IMHO is a clever design appropriate for the mid to late 1970s. The designers probably did not foresee that their brainchild (the 6502) would live much longer than that on the marketplace. It was a tremendous success - IIRC, more than a billion 6502 and their derivatives have been sold. The more recent CMOS based versions from Western Design Center also appear to have taken some internal circuit design measures to avoid the pitfalls with the 6502 family bus architecture (I think I can read this into their datasheets). This is why they do work.  Just as a side note, during my work on the MMU, IOU and IWM reverse engineering / reimplementation I stumbled over plenty of potential race conditions and - lo and behold - also found circuit measures to dodge them in the transistor level schematics of these ICs (as far as such schematics were available). So even back in the early 1980s, digital design engineers at Apple already struggled with the pitfalls I mentioned. And when using faster and faster technologies, it gets worse and worse, and more and more circuitry needs to be added to dodge the issues.

MANUFACTURING ?

No, I don't plan to have anything manufactured on a larger scale. If somebody could sell 100 or 1000 of the "IWMless" then maybe it would make sense to pay up for the NREs of automated assembly, but as I see it, I might make a dozen of them and these I can hand solder myself. At my age I'm not interested in earning more money anymore, to the contrary, I am concerned about how to spend it all before I croak. And how to put my huge stash of long obsolete ICs to good use. Why pay real money for "modern" ICs when my basement gives me all ICs I'll ever need for free ! The sunken costs for buying them have long been written off. I still made enough profit. Despite of having these "leftovers".

And if there happens to be a real worldwide demand for the "IWMless", I will see if I can find some entrepreneuring spirit who wants to mass produce them, and of course it then could make use of more modern ICs.

Before we get there I must tackle the ASYNC mode and put it in. Theoretically, this should give the 'IWMless' full "SmartPort" capability even with Apple's original firmware. Let's see how this works out.

- Uncle Bernie

I finally succeeded to graft the logic for ASYNC LATCHED read mode onto the legacy Woz Machine. This of course deviates from what the original IWM does (it has a different read state machine). But I think it may be worthwhile to try out if the "SmartPort" functions could work with such a hybrid solution, for reasons of full compatibility with legacy copy protections that came out before the Apple IIc. Some Apple II aficionados (and some "crackers", too) have occasionally dropped statements over the past 40 years which imply that some copy protections did not work on the IWM, but proof is hard to come by for me, not being in possession of the original copyprotected floppy disks, and not remembering any title that was mentioned decades ago. What I know for (almost) certain is that Jordan Mechner had to rework the copy protection for his "Prince of Persia" game just before it was released, because in its original form it did not work on the IWM. I do have some writeup from him somewhere which I copied from the web when I found it, and IIRC he described what particular feature did break it on the IWM, and how the remedy was found. Since he did not "invent" this copy protection (IIRC), it is highly likely it came from the publisher ("Broderbund") and was used on their earlier titles, and then, they also must fail to load on the IWM equipped Apple II.

Based on this reasoning, I'd prefer to have the "legacy" WOZ Machine in the IWMless. If it breaks the "SmartPort", more work is needed - I could use the ASYNC bit to switch between the legacy WOZ machine and the modified one seen in the IWM.

Ironically, my first attempt to graft the ASYNC read mode onto the legacy Woz Machine did fail miserably, because I just copied the RTL I got out of my IWM reverse engineering effort. It turned out that this RTL is not compatible with the legacy WOZ Machine, and I think this is due to the fact that the legacy Woz machine has a special path through the state transition diagram when the MSB of the shift register is set. This special path delays the clear of the shift register long enough that the 6502 can cycle once through the test loop for MSB being set, while at the same time gathering the next two bits from the floppy disk read data stream. It turned out that this essential feature for "legacy read mode" broke the RTL for the IWM ASYNC LATCHED read mode. I had to completely redesign this sub-state machine for this mode.

But now it works. I now can turn on ASYNC LATCHED mode on the IWMless and DOS3.3 reads from floppy disk happily, despite the whole thing now behaves as if it was the IWM in said mode. Funny. They (Apple) could have used this all the time (reading only in ASYNC LATCHED mode), as long as a honest DOS3.3 formatted floppy disk is involved. I know of some copy protections which would definitely not work in ASYNC LATCHED mode, just from the way they work (they peek at intermediate states of the shift register).

WORK YET TO DO

Now, the next step is to implement ASYNC LATCHED write mode. This will take longer as I need to develop test software for it. DOS 3.3 is not able to write (or format) anything in this mode. This is due to the way DOS 3.3 generates the SYNC bytes (40 CPU cycles instead of 32 CPU cycles) and the IWM will just turn off the write mode if this happens and flag a "Write Underrun Error".

So, please be patient and stay tuned !

- Uncle Bernie

Hi fans -

After running the 'IWMless' substitute on my Taiwanese Apple II clone for a while (used as a debugging platform, as my original Apple IIe is defunct), I finally found the sad remains of one of my remaining Apple IIc. And put the IWMless into it, just to see what would happen - the worst would be, of course, smoke to spill.

As it turned out, no smoke, but no boot either. Something really weird is going on there, the machine does not even show the familiar "Apple IIc" line and it does not clear the screen either. On RESET it just turns the floppy motor on briefly, which may or may not be an artifact of my 'analog' motor off delay circuit.

But whatever I tried, it did not boot.

So what I did is the following (don't try that at home): I put the IWM back and booted a DOS3.3 disk I prepared. And it booted fine (so it's probably not a problem with the Apple IIc being defective). Then I hot swapped the original IWM against the 'IWMless' (Again, don't do that at home, it may damage the computer). But for me it was worth the risk as I then - finally - could go to the monitor progam ("CALL -151") and then excercise the 'IWMless' manually, and everything appeared to work.

Finally, I brought the 'IWMless' back into a sane state, and started the legacy bootstrap loader (C600G) . . . and lo and behold, the disk spun up, the head seeked, and DOS3.3 was booted, on an Apple IIc and on the 'IWMless'.

Here is the photographic proof:

IWMless_in_A2c.JPG

The upper yellow oval indicates the "C600G" command and the result of the successful DOS3.3 boot, and the "HELLO" from the hello program, with the following CATALOG command given manually.

The lower yellow oval is around the 'IWMless' module sitting in the IWM socket of this gutted Apple IIc.

So I know, that in principle, the 'IWMless' should work in the Apple IIc, as it does in my wire-wrapped floppy controller card I use for the Apple II clone. But somehow, there is something going on, specific to the Apple IIc, which crashes its bootup process on the 'IWMless'. My current conjecture is that the Apple IIc does certain things with the IWM, such as probing if it is the real IWM, even before clearing the screen, and it seems that this test fails, and then the system hangs.

This of course requires further investigation which - I fear - may consume a lot of time. Since I don't have an ICE for the 6502, it's like flying blind. I think the best way is to develop some firmware EPROM which mimics the Apple IIe on an Apple IIc, and then see if it would boot.

If anyone reading this has made such a 'downgrade' EPROM which turns an Apple IIc into a IIe or knows about such a hack, please tell me.

- Uncle Bernie

In post #61, 'jeffmazur' wrote:

" I just tried the first approach and it booted the disk fine! Here's the image if you just want to burn your own (UNENHANCED W/C600)  "

Uncle Bernie comments:

thanks a lot for offering this help, but before I saw your post on high noon, I already had found the culprit and now the Apple IIc is able to start up and boot with the 'IWMless', even when using the unchanged Apple IIc firmware ROM.

But I still think that your solution will find some use in my ongoing projects, such as the 'Replica 2e' which currently can only use original Apple DISK II slot cards, because of the bootstrap PROM on them, which is missing from my current EPROM image.

- Uncle Bernie

Hi Fans -

after a good night of sleep, and breakfast, I had an epiphany: what if I would "use the force and read the source" ?

With "source" I mean the SmartPort functions to which Applefritter member 'rjustice' pointed me in his post#9 of this thread:

https://www.applefritter.com/content/did-anyone-analyze-iwm-related-apple-iic-firmware

... which two weeks ago has been immensely helpful for me trying to implement juuust the minimum ASYNC functionality of the original IWM believed to be needed for the SmartPort function - Disclaimer: as I have no Apple SmartPort device, the jury is still out if this attempt to implement SmartPort was successful, or ever will work.

THE PROBLEM

The most recent problem (see post #59 above) was that my Apple IIc wreck did not start up as expected when the 'IWMless' was in it. It just did 'hang'. A foul (and dangerous for the hardware) trick was needed to make it boot.

As of yesterday evening, I already had a hunch that the 'hang' may be caused by the SmartPort routines of the Apple IIc hitting some incompatibility in the ASYNC mode of the 'IWMless', which deliberately is somewhat different then the ASYNC mode in the original IWM - as there simply is no room in one ispLSI1016 to do a 100% faithful implementation of all modes of the original IWM (see footnote at the end of this post).

THE ENDLESS LOOP

Reading the SmartPort code, on page 196, see here:

https://archive.org/details/Apple_IIc_Programmers_Guide_to_the_3.5_ROM_part_2/page/n195/mode/1up?view=theater

. . . I found the culprit: it's the "Wait for /BSY to go low" routine beginning at address $CD36.

I immediately saw that this loop never would be left in case of the 'IWMless', because its SENSE input has a PULLUP, and hence, when there is NO 'SmartPort' device connected, the loop will always read MSB = SENSE = 1 and always take the BMI, and never terminate. And endless loop. Not exactly an example of sound peripheral driver design. IMHO here should be a timeout in any such waiting loop.

THE FIX

It's laughably simple to fix this: I just added a PULLDOWN resistor, see here:

IWMless_Resistor.jpg

... and PRODOS boots fine even with the 'IWMless':

IWMless_booted_PRODOS.jpg

Never mind it's the German version, it's from the original Apple system floppy disk set which came with an Apple IIc I bought from a German seller - I don't have any English version of PRODOS on floppy disk yet, but I'm working on it.

YET ANOTHER ISSUE DISCOVERED (unrelated to IWMless)

This is totally unrelated to the 'IWMless', it's a problem with this particular piece-of-junk Apple IIc (which is the NTSC version): it has "Made in the USA" DRAMs (Type uT4264-15, date code 8511N) in it, see this photo:

A2c_MicronTech_DRAMS.jpg

... and from the symptoms I see I can conclude that these seem to have used wafers of a quality being far too high (the opposite of what you would expect).

Now, the problem with such high quality silicon wafers is that the leakage currents are very small, and for DRAMs this has the consequence that they turn into "almost" non-volatile memory.

This means, if the Apple IIc is turned off, the bits in the DRAMs start to crumble only slowly, and some memory locations may keep their contents many seconds, or even minutes, especially when the DRAMs are still at room temperature.

And this behavior has catastrophic consequences for the dumb "warm start" detection software routines in the Apple IIc firmware: after a RESET, these look if the contents of RAM locations $3F3 and $3F4 meet certain criteria, assuming that a power down period would make that test fail, indicating that a cold start is needed. Alas, at least on my machine, the DRAMs keep these locations intact for more than a minute, even with power off, and so the Apple IIc attempts a "warm start" based on most other DRAM contents being at least partially crumbled. This makes the machine "hang", too, and trying to chase this Gremlin in the "IWMless" leads to nothing, except losing time. And I lost a lot of time to this effect. Be aware !

One remedy is to replace one or more of the lower bank DRAMs with types which used higher leakage wafer material and these can be found from Japanese manufacturers of 1980s DRAMs (the opposite of what you would expect). But even some Japanese DRAMs of the time hold the data longer than expected with power off - so some screening is required.

What a nasty problem - it did not only affect Apple, but also Atari - in the mid to late 1980s there was a flood of "refurbished" Atari 600XL and 800XL sold at discounters, in torn up boxes, for cheap. They did power up fine once, if coming fresh out of the box. But unless having been turned off for several minutes, they wouldn't do this favor anymore. Imagine disappointed owners bringing it back to the store for a refund . . . refurbish, rinse and repeat. This explains the torn boxes.

Today, some 40 years later, this lesson is almost forgotten. It took me a while to remember, and stop chasing the non-volatile DRAM "Gremlin" in my own designs. My "Replica 2e" project also is affected - I did find a DRAM which is leaky enough to make it work, but this is no solution for other hobbyists trying to build one.

NEXT STEPS WITH THE 'IWMless'

I need to somehow get a real "SmartPort" device which plugs into the 19 pin connector on the Apple IIc, to continue with test and development of the 'IWMless', the verify and make work its "SmartPort" functionality. I do have the BMOW Floppy Emu, but so far I seem to be unable to make it mimic a HDD. Or my very early version of PRODOS does not support this. Or there is still a bug in the IWMless. Who knows. Time will tell.

- Uncle Bernie

FOOTNOTES:

What if the ispLSI1016 turns out to be too small to implement the required "SmartPort" functionality ?

Would this be the end of the 'IWMless' subproject ?

The answer is, no, there is a way out: you may have noticed from the photos of the 'IWMless' that it is designed to be a stackable module. At least when the added programming connector is gone, or, with the 'lab rat' which has the connector, if a standoff adapter is used.

By stacking two 'IWMless', I then have two ispLSI1016 devices to distribute the functionality, and this is a certain fit, as the fitting problem comes from signal routing congestion, not from lack of macrocells, and having the complete IWM data path with all its registers in one ispLSI1016 just won't fit (if I would do the fitting manually, it would fit, but the automatic fitter is just too dumb, and I have no time to give it hints). The only downside of this approach is the costs which would double, as two PCBs then would be needed per 'IWMless' module.

The irony here is that everything would fit in a single ispLSI1016 easily if the "write data hold" and "read data hold" registers were external to the device. They consume only 16 macrocells, but use up a lot of routing ressources for their 8 bit wide data paths. The ispLSI1000 family GLB has 16+2 input signals into the PTERM array, but there is a catch known to company (Lattice) insiders since these CPLD came out near the mid 1990s: their "Global Routing Pool" which connects all the possible signal sources in the device to the GLBs is "sparse", so it can't connect every signal to every GLB in every possible way.  This saves a lot of silicon area and it is the key trick which made these devices commercially viable.

What the "fitter" does is to stuff logic into GLBs until it can't route more of the needed signals into the GLB, and then uses another GLB. This is very inefficient, as typically, as I have found out, half of the GLB input columns go unused, because they can't be connected to a wanted signal despite the signal is there, in the "Global Routing Pool".

I think they made the "Global Routing Pool" a bit too sparse. Or the they made their "fitter" too dumb. With the whole ispLSI family long being discontinued, there is no hope that this ever could improve. But I don't care. I have enough ispLSI stockpiled to last me for the rest of my life.

Oh, and don't recommend me to use some other CPLD or FPGA. The whole CPLD/FPGA world has been a mess and what I would call a "toxic technological battlefield" since their beginning, with whole product families disappearing too soon, development software disappearing, or customers who once bought "eternal" licenses getting defrauded by a sudden bait-and-switch to time limited licenses, numerous issues with the circuits (in the CPLDs, not with the user's designs) and so on and so on, I was there as a "warrior" and after I saw it's a unrewarding, uphill battle, with "rules" ever changing, I decided to get out of CPLD/FPGA and only do full custom ICs. A decision I never did regret. Now I'm back to CPLD, but as a hobby.

In post #64, 'robespierre' wrote:

" I wonder if placing a radioactive source near the DRAM would solve the cold-start problem ? "

Uncle Bernie comments:

Maybe you are joking, had a good laugh, thanks !

I dimly remember when I worked in the Central Research Labs of a major semiconductor and computer manufacturer, they just  had started to figure out how to do the lithography for the 1 Mbit DRAM. They did endless experiments with long parallel polysilicon lines of minimum size and minimum distance, and they were struggling because at some point down that "river", all too often there was a bad spot, either a gap or a short.

But the biggest concern was the radiation. Especially alpha emitters which back then were found in the packaging materials, the ceramic packages were the worst in this respect. The nasty feature of alpha particles is that they leave a lot of ionization in their wake, and these vagabonding charges could flip a bit in a DRAM. The solution was purer package materials and a polyimide coat on the silicon die - essentially a plastic foil just thick enough to swallow the alpha particles before they reached down into the silicon. At least this is what I was told. I always found this explanation somewhat dubious.

But the bottom line is, radiation is bad for semiconductors, and especially bad for dynamic storage nodes. I still wonder how they can build space probes / robots which land on the moon or on Mars, using modern semiconductors. They should get the equivalent of a "blue screen of death" often enough to turn the mission into a failure. But maybe, earth is really flat, the moon landings never happened, and all the four nations who claim to have taken photos from the Apollo landing sites using their automated probes flying over the sites before landing are in on the scam. Wouldn't it  be tempting to divert all the billions for alleged space flight into the pockets of corrupt politicians, instead of squandering all that good money on real space flight hardware and space flight missions ?

Well, before you laugh, I do believe that the manned moon landings were real, so I was joking when I wrote this ;-)

However, nuclear radiaton is bad for ICs and it is also bad for you. Just a week ago I saw the movie "Radium Girls" on DVD available from our local library. A must watch for everybody interesting in the health effects of radiation and in the criminal energy of capitalistic exploiters who care a damn about the health of their workers. Back then there also has been a scam with  radioactive "patent medicines", the follow up on Wild West era "Snake Oil", and there have been cases of people consuming this poison until their jaws rotted away and fell off (literally - it's online somewhere but the photos are gruesome).

So, no radioactive sources near me nor my electronics. I always measure the radiation of my food, though. And from time to time I find a radioactive specimen which I don't want to eat. But of course, the Bq/kg of that tainted radioactive "food" is much less than the radiation the "Radium Girls" were exposed to by just one "lick" on their brushes to make the tip pointy. Unbelievable, the company knew about the dangers, and still claimed it was safe to do so.

- Uncle Bernie

In post #65, 'jeffmazur' wrote:

" Or you can always just hold the open-apple key while turning on; that will also give you a cold boot every time. "

Uncle Bernie comments:

Thanks for this tip ! Had I known this earlier it would have saved me a few precious hours which I squandered on dealing with the problem. But now knowing it, testing of the 'IWMless' will be faster !

- Uncle Bernie

... see how PRODOS 1.9 booted and shows both the disk #1 and the HDD (with TOTAL REPLAY), the latter being emulated by the BMOW Floppy Emu:

PRODOS_2Volumes.jpg

The yellow oval shows the two lines from PRODOS system utilities command 'list volumes'. Here is a closeup:

PRODOS_2Vol_Closeup.jpg

I'd like to know how I can boot TOTAL REPLAY from the PRODOS menu. I have no manual for PRODOS. If you know how it is done, please tell me. So far I help myself with removing the PRODOS floppy disk from the drive, but this is probably not the only way how to do it (brute force method, not user friendly).

TOTAL REPLAY as such also boots and runs fine from the emulated HDD, here is the proof:

TotalReplayBooted.jpg

I have removed the floppy disk drive for this experiment to be able to get both screens into the picture.

This proves that 'IWMless' has matured to a point where it gets close to be ready for primetime.

There is a catch, however. If you look carefully, you can see that a real IWM is 'riding' on the 'IWMless' module, which I designed such that this trick is possible. See the FOOTNOTE for more background info on how this came about, it's simply part of my reverse engineering methods.

What remains is the question: if 'IWMless' now works with SmartPort, why is that real IWM still sitting there ?

Is this all a hoax by Uncle Bernie ?

The answer is: no, it's not a hoax. All the functions for disk access and SmartPort access are indeed done by the 'IWMless' which is able to override the data bus of the real IWM. The WRDATA and WRREQ pins (8, 9) of the real IWM also are disconnected, see this closeup:

IWMless_NC.jpg

So where is the problem why the real IWM still is needed ?

Seems it's a motor timer problem !

This is super weird. Remember the discussion above (posts #39, #46) about how I painstakingly analyzed the motor off timer of the real IWM and by a few mathematical tricks came up with a LFSR which would have the same cycle length as the LFSR in the real IWM  ? That it is a LFSR can be seen in the die photos of said posts. I also did mention that I would replace this LFSR with an external RC delay, to save macrocells of the CPLD. In other words, the LFSR would not fit into the small CPLD along with the other required logic.

An intentional trap set by Apple to thwart copycats ?

And lo and behold, it turned out that somewhere, in a yet unknown location in the Apple IIc firmware, there must be a function which - either intentionally or unintentionally - checks for the run time of the motor timer, and if this one is off target, the firmware stops any further attempt to find SmartPort devices. If it was done intentionally, it's just plain diabolical, a trap set for cloners targeting the Apple IIc. But it also could be unintentional - any wait for an event loop should have some timeout, and if the programmers just made it work with the real IWM, and if my motor timer runs longer, and hits the timeout, this is an unintended side effect. To confirm, I'd need to find the code where the SmartPort firmware waits for the motor timer to expire. So far I had no time to look for it.

Intermediate solution adopted:

The most expedient remedy I found so far is to 'steal' the MOTON information from the ENBL1 and ENBL2 output pins of the real IWM, because these convey a cycle exact state of the LFSR based motor timer of the original IWM.

And after I did this, 'IWMless' was able to do all the SmartPort operations like a charm.

This is why I still need to have the real IWM in the system. All it does is to provide the motor timer, because the system does not work with my own RC delay based motor timer. I still had no time to investigate this any further. There seem to be some other side effects of the motor timer, too, as it influences the WOZ machine which I lifted from the original DISK II floppy disk controller. In the original IWM, the read channel appears to be independent from the state of the motor timer - except that once the disk drive is disabled, it will of course stop to produce RDDATA pulses.

Intentional differences between the 'IWMless' and the real IWM:

I did not attempt to implement a 100% exact functional equivalent of the original IWM. Instead, I completely redesigned the ASYNC mode logic of the original IWM and grafted it on the legacy Woz Machine as seen in the original DISK II controller card. There are good reasons to do this - I found several sources on the web which claim that the Apple IIc was not 100%  compatible with all copy protected Apple II software titles which were released before the IIc came out. I know for certain that Jordan Mechner, the author of "Prince of Persia", had to do changes to his copy protection check so the game would run on the Apple IIc. Jordan wrote about this, you can find the story on the internet. I think that the copy protection method as such and the required check routines came from the publisher  ("Broderbund", long defunct now) and if these were used in the original, unmodified form on earlier Broderbund games, their copy protection check would fail on the Apple IIc with the original IWM. I had no time yet to investigate this any further ... finding proof for this hypothesis ... but I might not even try to spend time on this topic as the 'IWMless' cannot be discerned from an original DISK II floppy disk controller, unless it is in ASYNC mode of the IWM. Yet another reason to avoid exact functional equivalence with the original IWM is the MSB data setup or hold time bug, which is documented by Apple in the spec sheet of the Rev B IWM - they claim this bug makes the IWM work unreliably with a NMOS 6502, and this is the reason why the Liron card for the Apple IIe came with a CMOS 6502, to swap the NMOS 6502 out. I did experiment with the original IWM both with NMOS and CMOS 6502 and could not see this known bug to manifest itself as poor read performance. But somehow, Apple came to the conclusion there is a problem. From my reverse engineering work, I see it's definitely there and may strike every so often, but somehow it still seems to work OK even with a NMOS 6502. I don't want to spend any more time on investigating this - the bug may need some other conditions to manifest as trouble, such as a highy loaded system bus (many slot cards in).

Further work to do

Of course, I first need to fix the motor timer problem, such that I can remove the real IWM from my lab rat. Alas, this is not as trivial as it seems, as the motor timer interacts with many internal functions of both the real IWM and the 'IWMless' ... and I have seen some issues with the way my current motor timer is implemented (the one which was replaced by taking the timeout info from the real IWM). It seems that these interactions of the motor timer with the rest of the IWM is tricky ... especially when it comes to the functions which are different depending on whether the motor timer has expired or is still running. In other words, the motor timer can't expire at inopportune times. Taking the motor timer of the real IWM dodges this problem, because the programmers at Apple very likely have tweaked their software such that it just works and never does certain things at "inopportune times".  Still, some "Technical Brief" documents from Apple lament about possible pitfalls involving inadvertent change of the IWM's CONFIG register which may depend on the motor timer enable and disable bit and the motor enable bit on top of this. It's easy to see that there are plenty of opportunities to get this wrong, and any software that inadvertently changes the CONFIG register may lose floppy disk access, and in case of legacy software, knows no remedy for that.

Hope this showed to you that the motor timer in the IWM context is not as trivial to fix as it seems at the first glance, there are many moving parts and side effects.

But a  solution is in the works and I hope I can get rid of that original IWM motor timer soon.

Stay tuned !

- Uncle Bernie

FOOTNOTE (about the 'piggyback' technique)

This method is part of my 'secret sauce' on how to reverse engineer ICs and then test their replacements running in lockstep with the real IC in the target system. The rationale behind this approach is that only in the target system, all the nooks and crannies of a given IC relevant for that target system may be exercised. You can write a bazillion of test vectors and simulation test benches which will cover most of the terrain, but as these are based on what you know about the IC to be replaced, they may miss some fine points relevant for the correct operation on the target system. Hence, the use of the 'lockstep' approach is not only necessary for the test vector platform, but also for the target system adapter. When running in lockstep on the target system, the substitute IC does not drive any pins but only observes what the original IC does, and then compares this with its own internal state which must match to what is observed. If there is any difference, the substitute will set an alert pin, which normally triggers the ICE connected to the CPU socket of the target system. The ICE will then freeze its tracking, and you can then go in and see exactly in which segment of the code the mismatch was spawned. This is a very powerful technique which was fine for the 1980s and 1990s. It became obsolete when CPUs got so fast and their packages so tricky that no ICE could be plugged in anymore. This is where "smart" Logic Analyzers came to the rescue - they would observe the system bus and record what happens. After the trigger event they would upload the trace data to a host machine which had a CPU specific software package to display the chain of events as a disassembled listing (at least, I have seen systems where it could be linked to the original source code). Very powerful, no ICE needed anymore. This meant the death of ICE equipment. And then the CPUs got so blazing fast and complex that the Logic Analyzers could not follow what is going on in them (i.e. it is impossible for the Logic Analyzer to "look at" what the CPU executes from its internal cache). Of course, accesses to the IC still could be tracked - but this is only a subset of information compared to what the old ways on previous generations of systems could provide. CPU manufacturers added internal debugging hardware - but how can the trigger event be passed down to the CPU internal debugging engine ? Of course, there is a way, such as interrupts, but these disturb the usual program flow. So you can see how debugging of substitute ICs on more and more complex systems got more and more difficult and less and less viable. This is one reason why I exited this field of (reverse) engineering and went for full custom IC design. Design and development of substitute ICs was all nice and dandy as long it was for legacy systems which were as outdated as the long obsolete and "unobtainable" IC that had to be substituted. Such as simple PMOS or NMOS peripheral ICs from the early 1970s which the manufacturer just stopped making. Oh, and even back then there were greedy IC brokers who rang up moon prices for such out-of-production ICs. At some point the pain got bad enough for the user of these ICs (or if the stock at the IC brokers was gone) to contract me to make a  substitute -  which was either PLD or CPLD based or later turned into small scale gate array or semicustom designs, if the quantity needed justified the latter. Otherwise it was just a small piggyback PCB full of PLDs. But technical progress made this less and less viable. Now, story told how all my methods came about.

in post #69, 'softwarejanitor' wrote:

" It will be interesting for people to be able to give this a try. "

" It's too bad that LiRON cards have the IWM soldered on.  "

Uncle Bernie comments:

Once I have a solution for the motor timer issue, I will do a thorough test of the 'IWMless' lab rat with all the Apple II software titles I have in my possession, just to make sure there are no flaws in this implementation of the legacy "Woz Machine", which has a few more functions bolted on than the original one seen in the DISK II controller (these add-ons are needed to make the IWM ASYNC modes work).

When this test passes, then I will make a call for beta testers here on Applefritter which will be able to purchase a handbuilt 'IWMless' for a low price, and I will throw in a special low profile DIL-28 socket which makes the whole thing fit into an Apple IIc (the flat form factor is absolutely needed to make the internal disk drive fit). These kits are meant for repairing Apple IIc suffering from a defective original IWM.

And once these beta tests yielded satisfactory results, then I can plan how to make more of them.

As for the LiRON card, I would not recommend anyone owning an original to desolder the IWM . . . unless it is defective, of course. Then the 'IWMless' could be used to repair that LiRON card.

No need for designing a new LiRON card layout, there are already Gerbers out there for  a LiRON substitute which essentially is the same as the original, and needs an original IWM, and a 2732 EPROM, but the TTLs may have been replaced with a GAL or so, IIRC, this is from memory, and I'm not sure if I'm not mixing things up. I definitely saw a PLD for a LiRON clone somewhere, but I'm not sure, from memory, if this is for the same LiRON clone for which the Gerbers can be found.

Since the 'IWMless' is a drop-in replacement for the original IWM, as long as only the $00, $04 and $07 configurations of the IWM are used, which at the time of this writing appear to be sufficient for full SmartPort functionality on the Apple IIc, these LiRON clone projects finally could become more popular than they currently are. The problem with them, as I see it, is their need for an IWM. Which is almost "unobtainium" nowadays. Unless somebody butchers an Apple IIc or early Mac as an "organ donor" for the IWM. Not nice. I think these motherboards should be repaired, and not be butchered.

My own "lab rat" wire wrap slot card I used for the intital development of the 'IWMless' has been designed such that I could turn it into a LiRON substitute with just a few ICs and WW wires added. But this is one of the steps after the 'IWMless' is ready and fully qualified.

One nice feature of the 'IWMless' I did not mention yet is a jumper option which turns off all the IWM modes. So the 'IWMless' in this state is essentially the same as the Woz Machine on the DISK II slot card, and it is protected against any inadvertent change of the CONFIG register . . . I suspect there has been trouble with that, as Apple has published some documents lamenting about this problem of the original IWM. So there must have been cases of legacy software triggering this problem, I'd think. Otherwise Apple would not have published warnings. I also guess that some of the alleged incompatibilities of the Apple IIc with  legacy copy protections may be rooted in inadvertent changes of the IWM's CONFIG register by sloppy handling of the MOTOR OFF state.

The jumper option of course could get wires and a switch. I think the nasty DVORAK switch on the Apple IIc keyboard could be disconnected from the keyboard encoder and be used for that purpose.

Oh, and I can guarantee that the 'IWMless' does not have the MSB setup/hold time bug of the original IWM, which prompted Apple to put a CMOS 6502 in the LiRON upgrade kit for the Apple IIe. And nudged me not to do a slavish copy of the original IWM functionality.

Still, more work to do !

- Uncle Bernie

P.S.: one thing I stumbled upon during my work on the SmartPort functionality is their use of read-modify-write instructions (like ROL) to read from the IWM. We know that the IWM does not have a R/!W signal input but uses the address line A0 to signal read (A0 = 0) or write (A0 = 1) cycles to the IWM. So unless the device select logic of the IIc or the LiRON card (which I did not investigate yet) keeps the DEV turned off during the inevitable write cycle of said read-modify-write instructions, there will be a data bus driver fight, which the IWM will lose (bipolar always is stronger). This does not look nice to me !

Did anyone reading this thread ever investigate this issue with the possible data bus clash ?

In post #71, "S.Elliott" wrote:

" Here's a somewhat-related novelty... "

Uncle Bernie comments:

Thanks for bringing up this fine point of the DISK II. I will test it in due time, whether the IWMless conforms to that, which it should, as the 'Woz Machine' was taken from the DISK II controller card. The story for this is that maybe 20-25 years ago I had a bad DISK II controller with a bad sequencer PROM, and did not have the right PROM blanks. So I made a 22V10 PAL which, with a small adapter, drops right into the IC socket of said sequencer PROM and is supposed to do exactly the same thing.

Later I made DISK II substitute cards based on this 22V10 design but slightly modified to use the registers within. This allowed me to use a 74S74 for the RDDATA synchronizer, which has better metastability behaviour. This, and not the 2 MHz clock speed, is the reason why Apple (the corporation) were not satisfied with the read performance of the original DISK II and increased the RDDATA sampling speed when they designed the IWM.

Where I am still stuck is the damn motor timer. I did some experiments this morning and replaced the fixed resistor of the RC timer of the 'IWMless' with a trim pot, and finely adjusted it to be as close to the IWM motor timer as possible (measured with a 6502 assembly language program). After this, the 'IWMless' did work on its own (piggyback IWM removed) but SmartPort still did not work satisfactory - it did work as far as PRODOS  finally 'seeing' the emulated HDD, and TOTAL REPLAY booting and running (I found out the PR #5 starts it from BASIC) but it was much slower than normal (normal = with the exact IWM timer). This can also be seen on the green LED of the BMOW Floppy Emu . . . normally it would flash very fast and the program would load very fast, but with my RC timer, even when adjusted, it only blinks slowly at about the same speed as the motor timer runtime is. Hmmmm. I then made another hardware mod where the motor timer information is taken off a real IWM by means of a diode AND gate with a pullup resistor, and this, in its undisturbed form, works like a charm.  Here is a photo of how the real IWM is rigged with the diode AND (note that all IWM output pins are bent such that they don't connect into the socket, this is to prevent drivers of IWMless fighting them):

IWM_with_AND.jpg

But, alas, when I introduce a little bit extra delay (i.e. adding a capacitor to the diode AND gate having a known pullup resistor . . . so I can calculate the time constant) then the SmartPort functions again slow down . . . but only by a little bit, i.e. if I only add a 20 ms extra delay (which is only +1.7%), then the flicker of the LED is not as fast anymore, and the current hypothesis is that unless the motor timer is exact within very narrow bounds, the firmware might add another such motor timer interval doing nothing else. Hence, slow blinking with my original RC timer, and somewhat slower flicker when 20 ms is added to the original IWM motor timer.

Whether this is based on evil intent or some inadvertent artifact from the firmware I can't say until I find the segment of code where the motor timer cycle count is measured. This is NOT in the PRODOS (although there may be yet another such test there) but in the ROM firmware itself. This is based on the observation that with a disconnected internal floppy disk drive and just booting from the emulated HDD,  the same slowdown effect is seen.

I'm currently trying to whip one of my HP signal generators into shape as a high precision timer, so I could further investigate this behaviour.

If somebody reading this knows where the motor timer measurement routine is, please tell me !

- Uncle Bernie

Hi Fans -

to get to the bottom of the IWM motor timer mystery, I rigged a precise digital timer based on a CD4040 counter and a HP 33120A Function Generator. Here is the CD4040 circuit:

IWMless_digital_MOTIM.jpg

I verified this setup by running tests with my motor timer measurement code on an Apple II clone, and this confirmed my theoretical calculations at which frequency the digital timer would run for exactly  the same number of CPU cycles as with the real IWM.

Now the 'IWMless', equipped with this digital timer, is able to load TOTAL REPLAY:

IWMless_w_digitime.jpg

... but, alas, with seeing much the same slowdown issues as before, despite of the now exact timing. This proves that all my previous attempts with adjusting the RC time constant were a futile exercise: even the exact timing only possible with the digital timer does not bring any remedy for the unwanted slowdown.

Playing with the frequency I found out that if I increase it much, then the flashing on the BMOW floppy emu gets faster and faster, until it doesn't work anymore. It seems it never gets as fast as with the motor timer of the real IWM. And at the fast frequency setting, the system would not boot at all . . . it would end with a "check disk" message. This frequency change trick only works when TOTAL REPLAY has already booted.

What is the conclusion ?

These experiments and the results obtained indicate that the "IWM Motor Timer" rabbit hole is deeper than expected.

It might be that the motor timer behaves differently in ASYNC mode than in the legacy mode.

Alas, I never investigated the motor timer of a real IWM in ASYNC mode. This is not lazyness, it was based on knowing the original Apple IWM spec which does not spell out any difference.

But as the prior experiment where the real IWM only provided the motor timer information - and did not even drive the ENBL1, ENBL2 signals to the motherboard - showed that all of my own related logic is OK if the motor timer interval as such is  correct (when taken from the original IWM), so the most likely conjecture at this state of the investigation is that the ASYNC mode changes the motor timer behaviour, despite this is not mentioned in Apple's documentation.

So, I will put back the real IWM into my test rig and exercise the motor timer more thoroughly, to find out what the yet unknown differences might be. If we are lucky, there is a simpler and more harmless explanation other than the SmartPort routines possibly having evil checks for genuine IWMs. I am prepared to put a PIC10F200 MCU into the 'IWMless' to get whatever motor timer behaviour necessary, it has the same SOT23-6 footprint as the currently used dual Schmitt Trigger, but I don't like that, as some trace cuts and flight wires still would be necessary.

Stay tuned ! More to come !

- Uncle Bernie

In post #73, I promised:

" I will put back the real IWM into my test rig and exercise the motor timer more thoroughly  "

And so I did that. My IWM test rig is very powerful, I did not have to change any software, just enter a different CONFIG code for the motor timer run time measurement.

And indeed, it turned out that there is a CONFIG bit in the original IWM which does change the motor timer, and this is not what you would have expected: it's not the ASYNC bit, but the LATCH bit ... and when the LATCH bit is set, the motor timer period is reduced from 8322815 FCLKs to 4063 FCLKs (this was done on a Rev. B silicon). And as usual, the whole motor timer goes away when the MOTIM bit is set.

I don't think this is documented in any of the Apple spec sheets on the IWM. At least I did not find this spelled out. Maybe it was due to quick reading skipping over this factoid. I'm too tired now to re-read the IWM Spec Rev 19 (the latest one available on the web) again, but tomorrow I will read it during breakfast. Maybe I find a hint about this peculiar LATCH bit function which I overlooked in the past. If it's not there, I may have made a discovery.

In any case, I now see that I have to upgrade the IWMless to support all three cases of motor timer delay. Which may be tricky, as I have almost no macrocells left in the small ispLSI1016. But if I can't shoehorn this extra function into the ispLSI, I can always add the external PIC10F200 microcontroller to handle the motor timer function.

I wonder if anyone who already has succeeded to make a IWM substitute has ran into the same issue with the motor timer and instead of telling the user community about this finding, kept his or her mouth shut. If you are reading this and are this person, shame on you ! Other than depriving the Apple II user community about critical information, you stole one week of my life, which I had to waste on fruitless experiments.

Comments invited ! (Would be curious if there is anybody out there knowing about this IWM motor timer behaviour).

- Uncle Bernie

In post #75, 'robespierre' wrote:

" The LATCH mode is only useful with the 3.5" drive, which doesn't need a motor delay, so it's unsurprising that the delay timer doesn't function fully in that mode. Why it has any delay at all is a mystery, though. "

Uncle Bernie responds:

Interesting info about the 3.5" drive, but your conclusion about the LATCH mode effect on the motor timer is a fallacy, aside from the fact that the SmartPort firmware does indeed use the ASYNC LATCH mode. But why does the LATCH bit affect the motor timer ? See, changing a timer on an IC with a control bit costs added engineering effort and money. And it's not peanuts: the shortened timer polynomial (assuming it's a LFSR, which it very likely is) needs to be found, simulated, one or more extra gates need to be put into the circuit to effect the change to the timer, and a wire needs to be added from the LATCH bit to the motor timer. Then the whole contraption must be  simulated, layouted, extracted, and simulated (with the extracted parasitics) again. The test program needs to be updated to test this new function. Which entails having the silicon and a test engineer sitting at a tester which costs a lot of tester time (these machines are not cheap). No manager would allow such shenanigans without a good reason. Which means this complication of the LATCH bit was intentional and was added on purpose.  Which may have been for a sinister purpose.

Here is my take on it:

In post #74, I promised I would re-read the IWM spec during breakfast  this morning to see if I have missed something. And lo and behold, a hint is right there, on sheet 10 of the IWM spec Rev. 19 (Apple drawing #343-0041-B, dated September 24, 1982):

" If the latch mode bit is set, the timer is not guaranteed to count up to 2^32"

Note that the version I have is the one with 14 sheets, there are other versions in which the "guaranteed"  is wrongly spelled as "guarantied". The version I have can be identified by having the Apple engineering cover sheet calling it "drawing", as above. It seems that various scanned versions of this document exist, some of which have different page numbers, such as the one from "Digibarn", and this one and others lack the Apple engineering cover sheet.

Anyways, I did not see the danger lurking in this hint. When I read it during my reverse engineering process, I thought this is just a bug in the IWM which they decided not to fix, and that this bug somehow affects the motor timer if the LATCH bit is set. Fair enough, they did warn us about this side effect of the LATCH bit . . . except that now, having more experimental evidence, I think it never has been a side effect at all, but most likely was a secret feature that was designed in to thwart IWM copycats, and to keep it a secret, they weasel worded around it, not telling the reader of the spec sheet how many cycles the motor timer would run in LATCHed mode.  Which is a violation of ISO9001 standard procedures, BTW. (Of course we could argue that ISO9001 came 5 years after  Apple had developed the IWM, but the point I want to make is that company internal specification documents must describe everything known, and not hide certain functions behind weasel words. The risks when doing so are known: further development and migration of the product to newer processes may end in failure because the new team does not know about the hidden but necessary features of the old product).

I see the peculiar behaviour of the LATCH bit in the IWM on the motor timer as a trap planted intentionally to thwart copycats. Not one of the worst traps for copycats, as for instance the Z80 CPU from Zilog had worse traps built in, which allegedly (I was told by one of their IC designers after the "Wall" came down) did cost the Communist East German copycats from VEB Mikroelektronik "Karl Marx" Erfurt more than a year to detect, analyze and remove, and only then their unlicensed U880 copy of the Z80 did finally work. Any Capitalistic company falling in the same trap could be bankrupted by that, but  these rules obviously do not apply to Communist economies where the workers essentially are slaves of the ruling political/oligarch class and these slave workers are "paid" with Communist confetti "money" which is worthless as it does not buy anything in the shops with empty shelves. Under these conditions you can afford to reverse engineer anything, even complete computer systems like the DEC VAX.

In my own professional career I have seen many foul tricks in ICs which were put in to thwart copycats, but there always is a danger that the knowledge about these boobytraps gets lost in time, and then this astute company can't migrate their own product to a newer process. Which may cause a lot of financial mayhem. Some smaller semiconductor companies allegedly went under because of such tricks - they did shoot themselves in their own foot.

SO, what is the possibly story about the IWM motor timer and the LATCH bit ? There is enough evidence now which implies it's a trap put in on purpose, but this is only a conjecture based on said evidence and the peculiar wording how they describe this on the IWM spec.

What we know for certain is that this feature of the LATCH bit shortening the motor timer run time is used in the SmartPort firmware, and it serves a purpose there.

Remaining open questions (notes to self):

- Can we remove the motor timer in LATCH mode ?

- If no, how to put the extra functionality into the IWMless ?

- How exact does the timer runtime need to be ?

The latter is very important. If it needs to be exceedingly precise because the SmartPort firmware would check for exact timing, I need an external PIC microcontroller to implement the exact timing digitally. If no such precision is needed, I can do it in the analog way by adding one resistor and one factor added to an output enable product term, other than putting back the LATCH bit, too. The one factor costs nothing and the resistor costs 3 cents. Analog gets you more bang for the buck - but can't be as precise as digital timers are.

I'm working on this today and hope to have the answers until nightfall. This IWM reverse engineering thread started exactly one year ago. It's high time to get to the finish line - it took me much more time than expected.

- Uncle Bernie

In post #77, 'robespierre' wrote:

" The LATCH mode needs FF space to hold the output of the shift register (in the normal mode, the CPU only has about a microsecond to load the shift register output before it gets clobbered). "

Uncle Bernie comments:

This could indeed be the case. I have speculated about that possibility before, it might even be mentioned somewhere in the earlier posts on this thread, the ones where I was searching for the motor timer in the die photos. But all this was just conjectures based on the economics of 1970s NMOS process technologies . . . they did use a 'trailing edge' process for the IWM, this is obvious from the die photos. However, there are significant differences in transistor expenditure between plain straight dynamic shift registers, static latch banks, and shift/hold/clear capable "universal" shift registers, such as needed for the read channel deserializer. My money was on the possibility that they might turn the deserializer shift register into a LFSR as part of the motor timer, but only if the timer is enabled and the motor enable mode bit is cleared. But this was only a conjecture.

Now, thanks to post #47  by 'ggb', I have access to the transistor level schematic of the IWM and could find out. Alas, the schematic is huuuuge and somehow embedded in google maps (????) and can't be downloaded, at least I did not find a way to do it. So I can't print it out on paper (it would probably be something like 6 ft x 6 ft to be readable) and without having the schematic on paper I can't scribble into it to trace functions. So I did not even try to analyze these schematics. I'm close enough to the finish line (I hope) that this is not necessary anymore, unless there are unforeseen complications while solving the motor timer riddle.

There was some progress with that this morning, I added a prescaler counter to my external digital counter / timer and cranked up the frequency by the prescaler factor. This allows me to produce the shorter motor timer delay for LATCH mode with 100 times  better accuracy, here is the photo of the new digital timer, now two ICs:

Dual_Prescaler.jpg

And the result of this experiment was that SmartPort now works with PRODOS without stalling / slowing down. Yet another result was that PRODOS indeed checks something with the motor timer(s), this happens after the "PRODOS" message appears on the screen while booting PRODOS. At this point, they turn off the motor and it stops, and then they turn it on again to continue booting PRODOS. If the motor timer is grossly off, a message will appear like "PRODOS can't be loaded" or something like that. But unless the timer is too wrong, PRODOS loads fine, and the SYSTEM UTILITIES will also "see" and report the SmartPort HDD emulated by the BMOW Floppy Emu. I tested the sensitivity of all this by varying the frequency setting the motor timer delay over a very wide range, and it worked over a wide range that easily could be done with analog RC delays using cheap components and no trimming at all.

However, I also want TOTAL REPLAY to work, and this turned out to be finicky. If the motor timer is off target, it shows the weirdest symptoms after being booted. Sometimes it just crashes. Sometimes it just hangs. Sometimes it seems to want to tell me somthing, like flashing the word "REPLAY" of its still text mode startup screen, or, on one occasion, it showed a blank text screen with only one message in the center. This message was "GLU". I don't know what this means, but there is a "GLU" chip in the Apple IIc, a HAL20X4, the mask programmed version of the PAL20X4. I don't know why TOTAL REPLAY complains about that. Maybe it is just too finicky about the motor timer, or, a possibility I can't rule out, my Apple IIc is too wonky due to age. But this is not very likely to be the culprit, it's only a possibility. More investigations are necessary over which range of frequencies the TOTAL REPLAY would boot and work fine. I also saw that I need to keep my Apple IIc wreck turned off for a longer period of time, before TOTAL REPLAY boots and works even for the exact frequency setting from theoretical considerations (and confirmed with a cycle count routine on my Apple II clone).

Here is a photo of the current rig:

TotalReplaywithPrescaler.jpg

Note that the frequency counter is set to 182.01 kHz. This clock has a period of 5.5 microseconds, so it may be too coarse - the problem is that at the moment I do not have phase locking to any internal clock of the Apple IIc. Which means that a firmware routine may start the LATCHed mode motor timer with an uncertainty of 5.5 CPU cycles. This difference could be detected by software. And it may be the reason why TOTAL REPLAY acts up. But if it is so, it means that I can't use analog, RC based, motor timers, and have to use the PIC microcontroller to implement them.

I'm still working on this topic and I'm looking for expedient solutions  . . . but so far it seems that the HP33120A Option 001 can only phase lock to a 10 MHz reference signal. So it could not be phased locked to any signal in the Apple IIc. I could rig a 60 MHz oscillator and divide it by 4 to get 15 MHz (close enough to run the IIc) and divide by 6 to get 10 Mhz to which I could phase lock the HP33120A. Then I could set the motor timer timeout with perfect accuracy and still could investigate the operational margins. I also could use a second HP33120A, phase lock the two, and use one to make the 14.3181818 MHz master clock for the Apple IIc. I could also add yet another prescaler and use only one generator. But this means more soldering work and moving everything to my lab again.

But I'm working on it. And until nightfall I will have the answers to all my open questions, unless something else pops up.

Anyways, I find it quite curious that the harmless looking motor timer functions of the IWM are the "hard part" to implement / copy, and the rest (the read and write channels) are almost laughably simple to write in a few lines of RTL.

- Uncle Bernie

As I announced above, I sought an expedient way to increase the accuracy of my motor timer further, based on my somewhat paranoid suspicion that the SmartPort software might check for it to impair its operation on systems where the IWM is a knockoff.

After some pondering I decided to add another prescaler, despite I had to move everything upstairs in my lab again to be able to calibrate the new timer. The alternatives listed in my previous post #77 from earlier this afternoon would have been more elegant but would have required to take instruments and coax cables away from my atomic clock project which is running downstairs.

Here is a photo of the new motor timer, now comprising three ICs:

OneMorePrescaler.jpg

The yellow oval shows the 2nd prescaler added to whole motor timer counter chain. This of course increases accuracy of the motor timer by the factor of the prescaler (in this case, factor 16, it's an old 74LS93 I found in my lab). The whole timer chain is held in the reset state by the motor enable signal coming out of the IWMless and begins counting once this signal is deasserted. Now, running at 2.8 MHz input clock speed to the counter chain, the uncertainty of the motor timer runtime is only 357 ns --- no 6502 running at 1 MHz can detect this small remaining error, ever. Note that using phase locking techniques could reduce this uncertainty without increasing the clock frequency and without adding counter stages.

With the calibration software on the Apple II clone in my lab I was able to get a truly cycle exact motor timer interval out of the 'IWMless', provided that the frequency generator is set properly. There is a very narrow frequency band between 2.822 Mhz clock and 2.826 MHz clock where the 'IWMless' shows exactly the same weird behaviour as the real IWM (in this case, a Rev A silicon). This weird behaviour is seen in the MSB of the IWM status register, but only when the software turns off the motor enable and then looks exactly at the CPU cycle where the "motor on" status bit ($20) turns off. The state of the SENSE line is not stable at this point in time because the external floppy drive just has been disabled and released this line, which floats up thanks to a pull up resistor. The actual sampling of the SENSE line during this rise time sometimes gives a "0" and sometimes a "1". This is nothing spooky, it's just how a sloppy voltage ramp may produce a logical 'maybe'. Which, if the system design is not robust against this, may cause weird "gremlins" which seem to depend on the moon phase and the local weather. Hunting these "gremlins" down can cost so much money that you will regret to have taken your "gremlin" infested car to the local stealership. Setting it on fire would have been cheaper and more satisfactory ...

Now, we understand how evil these electronic "gremlins" can be, and how difficult and time consuming to hunt down.

But interestingly, things did improve over the the previous state of the system used as a test platform. TOTAL REPLAY now boots fine, more often than not at  least, and it crashes less often - I had it running for hours. Then I dialed around on the frequency generator and much to my surprise found out that it's not super sensitive anymore to the clock frequency being off target (meaning the motor timer timeout also being off). Still, this can't be overdone because TOTAL REPLAY still may hang if the timer interval is too far off target. I had not time yet to put numbers on this. I'm still hoping it might be doable with analog RC based timers. If I need to put the PIC10F in to implement exact motor timer intervals, then I need a PCB layout revision ... a very little one, but still, nasty, as I would have to throw all the PCBs I have from the current version into the trash can. This would drive up the unit costs per 'IWMless'.

Yet another observation: after playing around with cold spray I had a hunch that there may be a timing or signal integrity issue with this particular wreck of an Apple IIc. I changed the CMDu G65SC02P-2 CPU in it (date code 8823) against a modern W65C02S6TPG-14 from Western Design Center. This one is rated for 14 Mhz clock speed but I've ran them at more than 20 Mhz in other experiments. And lo and behold, so far, TOTAL REPLAY did not crash anymore, not once ! I ran it the whole afternoon, and it still runs.

So, it might be that all the noise about motor timers being checked by suspected diabolical firmware to find out if it's an original IWM or not may have been rooted in "gremlins" from marginal system timing, who knows. I need to further investigate this, and if it turns out my Apple IIc is too wonky and gremlin infested, I need to procure a better specimen of Apple IIc to continue this work.

So, progress has been made !

Stay tuned !

Oh, and before I forget - does anyone reading this know about diagnostics / test software from back in the day which exercises an Apple II  SmartPort HDD ? What I mean is the typical routines which would write random data to random places and then after a while verify it to still be there, all while keeping statistics about bus errors, bus retries, read/write retries within the HDD, and data block mismatches found. This type of diagnostics / test software is mandatory for professional computer systems and so I wonder if Apple ever had one of those.

- Uncle Bernie

In post #84, 'robespierre' wrote:

" The uploader of the schematic used a Google Map script to make it zoomable. But here is the whole thing as a black&white PNG.  "

Uncle Bernie says "Thank you !" for this nice "gift". Alas, at the moment I'm working with a downgraded notebook where any attempt to open the file ends with "not enough memory" message. I once had 4 GB of RAM in this notebook, but it started to act erratically, and then I put the old 2GB module in and it worked again. A new 8GB module is in the mail . . . ordered it last week.

'IWMless' made some progress during the last few days, see next post !

- Uncle Bernie

After dusting off my PIC programming skills which had been unused for almost 20 years, I programmed a PIC10F202 I had bought for the YAAK keyboard project as a cycle accurate motor timer for the IWMless. It produces two output signals, MOFFS and MOFFL, for the short and the long motor timer intervals.

"Cycle accurate" in this context means the timing interval is accurate to one PIC instruction cycle, which is close to one microsecond, much the same as with the 6502 instruction cycle in the Apple II.

The whole thing is not as trivial as it seems, as the PIC10F2XX family has no crystal clock and always uses an internal RC oscillator which is factory trimmed to 4 MHz, which, divided by 4, yields the PIC instruction cycles.

Despite Microchip (the PIC manufacturer) did a great job with making this on-chip oscillator as good as it gets, it still has a small, unavoidable inaccuracy even after the factory trim, and also some residual tempco, which however is not bad at all. So by just using the PIC's internal oscillator, the motor timer interval could never be cycle accurate from the Apple II standpoint.

So what I did is to use the internal timer of the PIC10F202 to get the time intervals more accurate (yes, it indeed has one 8 bit timer / counter able to count external events, with a programmable prescaler for powers of 2 division factors, who would have thought to find such elaborate peripherals in a MCU costing only 55 US cents  ?)

I chose to clock this timer with the Q3 clock of the 6502 which happens twice per 6502 instruction cycle, prescaled by a divisor of 32. This means that the TMR0 in the PIC increments every 16 PIC instruction cycles, and this is the maximum expected delay that may need to be added based on the internal RC clock of the PIC (it is too slow to sample Q3 by software, so everything needs to be done by inspecting the timer count value). This internal RC clock of the PIC is accurate enough  that within a mere 16 PIC instruction cycles, no large enough error can be produced to foil the "one cycle accuracy" design target.

What remains is a one Q3 clock cycle random element, because the PIC, running at half that speed, can't sample its timer with one Q3 accuracy. I could fix that only with adding another flipflop in the 'IWMless', which I want to avoid, as I'm already struggling with fitting problems.

Those who are familiar with the PIC, most of its instructions execute in one PIC instruction cycle. Only those instructions which modify the program counter use two such cycles. Still, it is no mean feat to look at the timer value and then derive a PIC instruction cycle accurate delay from it. This requires some advanced PIC programming tricks, as the ambiguity of the wait-for-timer-value loop must be compensated. The PIC10F202 has no timer interrupts. What would be needed to do the "PIC instruction cycle accurate" timing would be a timer with a compare register which, if the timer reaches the compare value, would wake up the PIC from a "sleep" instruction. If you have a brain, you will be able to tell why a timer interrupt could not do this with one PIC instruction cycle accuracy, just by the information provided in this paragraph. One of my famous riddles.

So, it took me three afternoons working with this lab setup:

Lab_Setup.jpg

until I got everything right. For those interested in the actual hardware hookup, see here:

IWMless_PIC_lab.jpg

The PIC sits in the red socket, which also has a few resistors and a NPN BJT to gate the timer startup.

The whole work took me four days, one to build the hardware and set the lab up, and three to do the actual programming work.  If I had an ICE I could have done it faster. But I have no ICE, neither for the PIC nor for the 6502. So how do I "look" into the PIC for the more subtle things going on there, such as the number of timing compensation cycles the algorithm has found out ? Here is another 'Uncle Bernie' trick:

Oscilloscope_Message.jpg

I telegraph the number of compensation cycles to the oscilloscope. Easy.

On the HP 5325B "Universal Counter" (built in Y1969) I can measure the actual time delay down to 100ns resolution. For the long motor delay, I can use it only to verify if the delay is constant (as measured) but that does not help with hitting exactly the number of 6502 instruction cycles of the Apple II - because the crystal oscillator in the Apple II, not being ovenized as the crystal oscillator in the HP 5325B, drifts much worse over temperature than the HP 5325B does. And at more than a million CPU cycles, even a small oscillator drift may cause a difference of one or two cycle counts. To solve this problem, all this was supported by a 6502 cycle accurate measurement routine running on the Apple II clone. Which tells me if the timer is short, on target, or long, 6502 cycle wise. But could not tell me a number. Hence, the HP 5325B counter.

After I was satisfied with the two motor timing intervals, I put the 'IWMless' with the PIC back into the Apple IIc test platform, and so far it seems that everything runs fine now, including TOTAL REPLAY:

IWMless_PIC_Timer.jpg

The PIC is in the red socket within the yellow oval. This is much nicer to work with than the previous setup which needed a function generator (and never could hit the exact 6502 cycle count, despite of having  a very precise timebase - the issue is that the Apple IIc crystal oscillator itself has enough temperature drift to foil any attempt to get the exact cycle count by adjusting the much more precise generator).

So it's now much more accurate in terms of the motor timer than any previous attempt was.

Alas, I still see has some occasional initial boot problems which need further investigation under which conditions they happen. At the moment it seems that these boot problems can be avoided if the Apple IIc was kept turned off for a while. So it may be a problem rooted in this particular wreck of an Apple IIc itself. Alas, I'm out of cold spray to find out if it is a thermal problem (the long wait in the powered down state would help with that, allowing the ICs to cool down).

I'm not sure now if the whole motor timer sensitivity conjecture was nothing but a wild goose chase. But with the RC based motor timers there indeed have been conditions (timer runtime) where PRODOS refuses to boot, and even gives a nasty message "Unable to load PRODOS" or the like, I did not attempt to memorize the exact words.

I think that unless the whole PRODOS and SmartPort code has been inspected for where the motor timer timeout is checked and how and why, we can't be sure what the truth is. But I don't have time to do this. I spent a few minutes looking for motor timer tests in the Liron firmware but found none. But this was just a quick search looking only for a AND #$20 instruction which - I guess - a typical programmer would use to test the MOTOR ON bit in the STATUS register. Of course, they also could test for the whole value which includes the SENSE input bit and the IWM configuration bits. This would render the code less versatile and non robust against configuration changes. But maybe this was their intent, finding out if the IWM configuration was corrupted while at the same time checking the MOTOR ON bit.

So there are many possibilities why the system behaves weird if the motor timers are off target.

Further investigations and experiments are necessary to find out root cause. But at least, I now do have the solution to get cycle accurate motor timing, if it turns out to be absolutely required by the system. This means that the RC motor timers are not off the table yet. If possible, I will use those, as the PIC10F200 (the smaller brother of the PIC10F202) costs $0.31 more than the SOT23-6 Dual Schmitt trigger IC needed for the RC timers.

Comments invited !

Does anyone have annotated disassembly for the SmartPort routines in the Apple IIc ROM 4 ($FBBF = $04) ? I work with that latest and greatest ROM version known for the Apple IIc (IIc+ is different) and its SmartPort routines do not seem to fully match the source code seen in the link of  post#9 of this thread: 

https://www.applefritter.com/content/did-anyone-analyze-iwm-related-apple-iic-firmware

... which may be an earlier version of these routines.  I can find lots of similarities but there are enough differences which thwart any attempt to follow the code in the ROM using the monitor program and referring to the source code mentioned.

I still think that to prove or disprove my "IWM motor timer runtime is critical" hypothesis, the SmartPort code must be thoroughly inspected for clues if it is so. Maybe a "smoking gun" can be found within this code.

- Uncle Bernie

In post #87, 'robespierre' wrote:

" ... since it is auto extracted from the die photomicrograph there could be errors. "

Uncle Bernie comments:

Depends on who has done this die level reverse engineering job, and how much was paid for it (assuming it was not just a hobby project). There are several reverse engineering companies out there who do this for paying customers but all their software tools are proprietary, so nobody outside these companies can access these tools.

I'd like to know more about the who, when, and how of that work which yielded that schematic.

This morning I finally got the 8 GB RAM module and put it into my notebook. It now works like a charm and is much, much quicker in responses than ever before. Oh, and I was able to open the schematic you provided and took a brief tour through it. The NMOS circuitry in it looks pretty standard to me, typical for the 1970s, no fancy tricks. For a more thorough analysis I indeed would need to find a business which can print it out on wider paper. But at the moment I'm not inclined to spend my time on it. Only if I get stuck with my IWMless project and can't make it work.

I've put the newest version of TOTAL REPLAY into my BMOW Floppy Emu and my Apple IIc is currently running the demos with a real IWM in it. I want to see if it crashes. If so, the 'IWMless' isn't the culprit, but possibly the decrepit Apple IIc motherboard I use, or, worse, a bug or oversight in TOTAL REPLAY itself. As far as I found out, TOTAL REPLAY was prepared and tested on an Apple IIe using a Liron card, at least that is what I think I saw in the photos that can be found on the internet. So there always is a possibility that it works fine on the IIe but the IIc being different, it would be no surprise if some of the demo programs don't work on the IIc.

This kind of wait-until-it-crashes experiments are very time consuming. The older version of TOTAL REPLAY typically ran for maybe 2-5 hours with the 'IWMless' before it crashed or got stuck. In some cases, the green activity LED on the BMOW Floppy Emu was lit but did not flicker. So I suspect these 'hangs' did occur while accessing the emulated HDD, which involves the 'IWMless', so it might be some incompatibility that still needs to be diagnosed and fixed.

I could turn my 'lab rat ' slot card into a Liron clone if I wanted, but my Apple IIe also is out of order and needs a new MMU. The only MMU replacement I have is the slot card for my 'Replica 2e' project. From which I don't want to take it out until the next revision of that card is ready (using a different set of PLD types to make it cheaper).

So at the moment I'm stuck with doing all these tests on the wreck of an old Apple IIc. And as always, when working with 40 year old electronics, the results may be dubious.

- Uncle Bernie

In post #89, 'bradleyb' wrote:

" I'm pretty sure that the person who did the die reverse engineering is Olivier Galibert, who also contributed much of the IWM support in MAME. You could try reaching out to them with questions.

For the firmware, I have it in my repository here: https://github.com/btb/ProtocolConverter"

Uncle Bernie thanks you for this info !

I'm not sure if I need to bug Olivier with questions (but I have a hunch he may have already analyzed the NMOS transistor level schematic he has made, and so he should know more about the inner workings of the original IWM than me, including its bugs, hehehehe ... which however never can be fixed if slavishly copying the original IWM, so I need to deviate from the original circuits, and this causes its own problems, see next post).

The firmware you put on github will save me a lot of time building test software for my 'IWMless' - which made some more progress the last days, see my next post. At the moment, my testing of the SmartPort functionality is limited to TOTAL REPLAY, and although this is a nice test case as it runs automatically without any user interaction, and pumps a lot of data via SmartPort, it is far from being a thorough test for the 'IWMless'.

- Uncle Bernie

Hi fans -

I've investigated the motor timer issue for a while now, but even if the timing was made CPU cycle exact it only reduced the number of hangs and crashes of TOTAL REPLAY. (The PRODOS SmartPort routines worked fine, however, and even could load and run the LAUNCHER of TOTAL REPLAY without a hitch).

Typically, if the motor timers were off target then TOTAL REPLAY would refuse to even boot, I often saw the message "Check Disk", and this is even more confusing as it normally (outside SmartPort use) hints either at a bad floppy disk that can't be booted, or, a bad DRAM in the machine, which has the same effect (if bad at the right locations, the checksum of the sectrors having been read is incorrect, but not due to bad data from the floppy disk, the reason is bit flips due to bad DRAM).

So there are lots of symptoms which point to various possible causations. So I designed a series of crafty experiments to zero in from where the problem is originating: a DRAM issue, some read channel issue, some write channel issue, some configuration issue, some status read issue, or some incompatible coding in TOTAL REPLAY itself ? (Incompatible with my flavor of IWM functions, not incompatible with the real IWM, where TOTAL REPLAY works fine).

And it turned out that there indeed was some incompatibility in a very unexpected place. Which came from the interaction of the ASYNC mode state machines I grafted on the legacy DISK II controller 'Woz Machine'. These, of course, are a completely different animal than the ASYNC mode state machines seen in the original IWM, for which I also have reverse engineered state diagrams, but could not use them with the legacy Woz Machine - the clocks and the timing is much different between the two, and when running with half the clock speed, and still producing the same output at the same time, the state machines controlling the read channel can't be the same anymore. So I had to craft my own.

The bug was an "improvement" (ouch !)

And so it happened that a small bug was lurking there: if the software looked at the STATUS register while a newly received (via SmartPort) byte was pending and waiting in the read data hold register, the ASYNC mode state machine proceeded to a state where the next incoming byte, once finished, could kick the previous data byte out of the read data hold register and replace it. This feature I had put in intentionally to have an easy way out of read data hold register lockup conditions where stale bytes that have not been taken from it by the CPU would block it for new bytes, losing these new bytes. I've seen these read data hold lockup conditions on the original IWM and with the DOS3.3 RWTS these lockup conditions happen quite regularily because at some point, the RTWS does other work and is not taking any bytes from the IWM (or DISK II). In SYNC mode, there is not issue with that, because SYNC mode has no data lock mechanism for the read data hold register. But ASYNC mode does. So if the IWM is manually set into ASYNC mode (with the built in monitor program) and then C600G invokes the boot-from-disk sequence on a regular Apple II, DOS 3.3 will load, but very very slowly, with a lot of invisible retries inside, although not to the point that it does head recalibrations.

I considered this a bug of the original IWM and fixed it by providing automatic unlock of the read data hold register whenever the CPU did a data read or status read operation. And for some unknown reasons this well meant "fix" caused TOTAL REPLAY to act up. I ruefully took the "fix" out of my HDL and now TOTAL REPLAY runs fine with the 'IWMless'.

The lesson learned from this:

Another example where unnecessary product improvements make the product perform worse than without the "improvement" - something we have to deal with on a daily basis, because every manufacturer "improves" their product all the time. In case of "food", until it becomes inedible. In case of cars, until it won't do what the driver wants it to do - we are now back in the horse age, as far as these cars now have their own will, and "spook" from time to time, or do unexpected things which may cause accidents. And then, class action lawsuits. Nice "improvements", all of that.

How the motor timers come into play

So how is the motor timer related to this ? The jury is still out on this as I am still using cycle exact motor timers but I have some experimental evidence that the motor timers being right on target (CPU cycle wise) helped to "mask" the problem in most cases. So TOTAL REPLAY would run for a while before it did crash or hang. With the motor timers being off target, it would crash or hang almost immediately. More experiments are needed to confirm this - if we are lucky I can fall back to the RC timer based solution I originally had in mind. This would prevent throwing away all the 28 or so 'IWMless' PCB made for the RC timer solution. Not a big deal, but throwing them in the trash and ordering new ones for the PIC timer based (cycle exact) solution would increase my per-unit costs, as the costs for the thrown away material must be factored in. And, of course, such a PIC10F200 costs a few dimes more than the dual Schmitt Trigger in SOT23-6 used for the RC timer solution.

Testing continues !

So there is hope at the horizon, meaning: 'IWMless' will eventually work. In the next weeks I will continue testing and if none of the planned tests fail, I will make a few hand built units available to beta testers, at my own component costs plus postage.

Call for prospective beta testers !

You may send me a PM (the 'Send PM' button) as soon as possible if you have an Apple IIc or a Liron card with a dead IWM. These are the ideal test platforms for the 'IWMless' as they are worthless without a functional IWM (or IWM substitute).

So if you send me a PM, please also specify which platform you have (Apple IIc or Liron card).

For me it is important to know how many prospective beta testers are out there - if its only two or three, I will not build a dedicated programming rig suitable for production of larger quantitites, but do the programming with microhooks.

.

Comments invited !

- Uncle Bernie   

Hi fans -

just a clarification about the 'IWMless' if you did not read the whole thread: 'IWMless' is a side project from my IWM reverse engineering process. It is specifically intended to be used to fix Apple IIc and Liron cards suffering a dead IWM, and I think it will work fine for that, from the current results of my own tests. But it does not have the FAST configuration bit needed for 3.5" drives (1 MHz 6502 could not support FAST mode data rates anyways) and it also does not have the M8 clock select bit needed for the Macintosh. It never has been my intention to support Apple IIgs or Macintosh repairs with the 'IWMless'. A bit surprised that there are 3.5" drives out there which also have dead IWMs, but I did not know that these exist - how the hell could somebody blow up an IWM in a closed box intelligent 3.5" drive ? (For the Liron and the IIc, it's easier to do, I succeeded with blowing up Apple IIc IWMs, and more than one !).

So please, don't ask for a 'IWMless' beta tester status if all you want to do is to repair a 3.5" drive, a IIgs, or a Macintosh. These are not the 'patients' for which the 'IWMless' was designed.

Some prospective beta testers also asked for pricing of the beta test specimen (if they become available at all, let's wait for the outcome of my own tests). All I can guess right now is that I can make one for less than $10 worth of parts. So if you live in the USA, the postage will probably exceed that, and even more so if you live overseas, and you are really screwed if you live in the EU which since Y2024 refuses to let non RoHS-certified electronics into the EU - even if it is no merchandize and just a hobby item sent among hobbyists. Still, if you live in the EU, there may be a way but you need to be patient - so you can send me a PM anyways, there is hope even if you live in the EU gulag, the latest bad news I heard about the EU was that they (the EU) want to take your savings accounts away from you to buy weapons for a war with Russia they seem to be hellbound to start. Criminally stupid, mass murderous fools or just corrupt grifters who want to embezzle billions for themselves and then make an escape to a foreign country having no extradition treaty ? Who knows.

But back to the 'IWMless'. My own tests are ongoing and so far (the last few days) no crash or hang despite running TOTAL REPLAY around the clock. So far, looks good !

Oh, and more prospective beta testers are wanted / needed. Just send me a PM so I can stay in touch with you. No obligations for anyone here. I just need some numbers to plan the beta test campaign.

- Uncle Bernie

In post #93, 'Khaibitgfx' asked:

" ... how close are you to replacing the IWM, ..."

Uncle Bernie answers:

I'm very close to the finish line of the 'IWMless' design effort. I now have a version that works fine in an Apple IIc, including the BMOW floppy emu emulating a SmartPort HDD, no crashes, no problems, running 24/7.

The only open question: which flavor of motor timers ?

The only open question (as far as the design effort goes) is if I want to use this version (it uses a PIC10F200 microcontroller for the motor timers, to make them CPU cycle exact). If I use it, I must throw away about 25 PCBs, and I hate waste. The other version I have made uses the RC timer as originally planned, but having only one Apple IIc to run these tests, I had no opportunity yet to see if the accuracy of the RC based motor timer is good enough.

If you have followed this thread, since ~2 weeks I have worked on the hypothesis that the motor timers must be cycle exact to make the 'IWMless' work, and they indeed did make it work, but this may be a fallacy that came up because cycle exact motor timers may just have masked a bug in my RTL which was put in believing that it's an improvement, but turned out to make matters worse. (This masking effect has been proven by experiments).

Now this bug has been fixed and it might be, if we are lucky, that now the RC motor timer turns out to be accurate enough. And then I could use the PCBs I already have, and start the beta test a few weeks earlier, i.e. as early as next month.

Remaining risk / problem: the PCB

 But if it turns out the cycle accurate motors timers indeed are needed, I must edit the PCB layout and order new PCBs, which now is much more complicated due to the new tariffs recently slapped on Chinese made goods. I don't accept any tariffs on the stuff I need for my hobby purposes, so finding alternate sources for these PCBs would  mean extra delays. I've stopped ordering ICs from China years ago, simply because of too many counterfeits made by crafty Chinese outfits ("Fool me once, ...") but so far I've not found an American manufacturer of PCBs able and willing to make my prototypes at an acceptable price. It's an irony ... the shipping costs from China have increased so much over the recent years that they typically cost more than what the PCBs are worth. So even if American PCB manufacturers would charge twice the price of JLCPCB, they still could win my business. But like with all hobby electronics projects, the low quantities and the low technology level we need conspires against that. I got the impression that the few American PCB manufacturers which are left prefer to make complex high layer count PCBs and aerospace / military stuff where price does not matter. They just laugh at hobbyists like us.

So let's hope that upcoming experiments would be able to prove that I can use the RC timers, and don't need a PCB revision. I plan to do these experiments over the next days.

Stay tuned !

- Uncle Bernie

In post #96, 'Torpecillo' wrote:

" Here's the PCB and schematic, the Apple 3.5 interface, and the 3.5 unidisk drive "

Uncle Bernie comments:

Thanks for finding them ! These may answer a few open questions about these devices, which, alas, I don't have to do tests.

And just as a status update on the project, I'm getting closer to the finish line. I now have experimental proof that the motor timer does not need to be 100% CPU cycle exact to make the 'IWMless' work, but I'm still seeing some rare "hangs" of TOTAL REPLAY affecting all of my three 'lab rats' AND also affecting the original IWM - the difficulty here is to nail down a culprit for such a "hang". All of them may run for days, and then, a "hang". This does NOT occur with the same games or spash screens - it appears to be random. And I'm competent in statistics enough that I can tell you there is NO WAY to find out by these trial runs if some of these versions is worse or better than the others - it would take   y e a r s  to collect enough statistical data on runtimes-until-hang before any such conclusion could be made with any amount of useful confidence intervals.

So I decided to proceed with preparing beta tests, and to see if any "fish" bite, I will post one of my April fool's announcements today in a  separate thread.

Still, I'm not sure which form and version these 'IWMless' will be. I discovered an unexpected mechanical issue when testing the "fit" of the prototype - the first one without the programming connector. And despite I did my homework when I planned it, it turned out that even when using a very low profile socket, the motor timer capacitor is high enough that in the assembled Apple IIc it will contact the bottom plate of the floppy disk stepper motor. And this is not good - on the long run the fragile capacitor will be crushed, especially when the Apple IIc gets bumped on a table or on a floor. The remedy is to insert washers under the floppy disk drive, and this juuuust fits and allows closing the Apple IIc shell. But it is a rotten solution to the problem. This may nudge me into making another PCB not having the tight mechanical fit, and if I do so, I can go with the cycle exact motor timer solution based on a PIC microcontroller anyways.

I intend to furnish the beta test specimen of the 'IWMless' with a special low profile DIL-28 socket, so they could be unplugged and sent back to me for reprogramming, if necessary due to issues being discovered. But all the mechanical problems go away when no socket is used and the 'IWMless' is soldered in directly, as is always the case with the real IWM - even Apple could not use a socket due to the cramped interior of the Apple IIc. With a little bit more planning and thinking they could have avoided this mechanical issue (by repositioning the IWM on the PCB), but back then, there were no PCB CAD tools which would do 3D modelling of the finished PCB.

Stay tuned !

(And look for my April 1st post ;-)

- Uncle Bernie

This complex has been plaguing me for more than a month, and stole far more of my time than expected.

The problem:

The problem manifests itself as follows: when I run TOTAL REPLAY from a BMOW floppy emu  in its automatic demo mode, it will rune fine for many hours, and then it will freeze (often recoverable with the ESC key, it waits for this input) or, rarer, it will crash, and not react to the ESC key. None of this is seen when using PRODOS and its SmartPort functions accessing the emulated hard drive of the BMOW floppy emu, which is the only SmartPort device I have - but this is proof enough that the BMOW floppy emu ain't the culprit.

The time-to-freeze depends on the nature of the motor timer: if the motor timer information is taken from a real IWM riding 'piggyback' on the IWMless, there are almost no freezes, TOTAL REPALY may run for many days and nights. With the cycle exact PIC microcontroller motor timer, it runs for maybe 24-48h before a freeze. With the more sloppy RC based motor timer, it typically runs half of that time, but even this is not all too catastrophic, IMHO.

So what is going on ?

By experiments I have proven that the SmartPort system as such (which includes the "Protocol Converter" firmware) may work fine over a wide range of motor timeout settings, so this can't be the root cause, and the somewhat paranoid earlier conjecture about malevolent routines hidden deep in the SmartPort code to check for an original IWM can be dismissed - if such a booby trap would have been planted, it likely would get triggered more often, especially with motor timer settings that are grossly off from what the real IWM does.

How can it be, with no such booby trap, that the motor timer runtimes can cause freezes ?

My current working hypothesis is that this is related to an pitfall with the IWM discovered by Apple and warned about in some technical briefs they sent around in the mid 1980s to software developers. It boils down to inadvertent changes to the CONFIG register within the IWM. Apple's IWM specifications say that the proper way to change the CONFIG register is to turn the motor off, then wait for the motor timeout (by waiting until bit #5 of the STATUS register is zero) and then set L7 and L6 until both are set - and at this point in time, there must be a write cycle providing the new CONFIG setting. The example code given by Apple then proceeds to clear L7 (this gets the IWM into STATUS register read mode, L7L6 = 01), at the same time reading from the IWM, and then checking the lower 5 bits (bits #0...#4) of that STATUS value for being the wanted CONFIG. If there is any mismatch, write CONFIG again by setting L6 with a write cycle. Note that this is a very specific sequence of events prescribed to change CONFIG.

This works perfectly fine and fail safe both with the original IWM and all development versions of the 'IWMless'. But any deviation from the prescribed sequence may cause trouble. And where it really gets risky is if some legacy software keeps the write mode L7L6 = 11 turned on and then gives a "motor off" command: once the motor timer expires, any following access to the IWM may change the CONFIG register to whatever is present at that time on the data bus, which, if that access is a read access, may be some undefined bit vapors (I mention this because the 'vaporlock' screen synchronizer technique uses bit vapors coming out of the video memory scan and lingering on the data bus as volatile electrical charges, not really a very predictable and dependable method !).

How the motor timer runtime comes into play

Now, imagine that somebody wrote some half-baked routine to change the CONFIG register, or some piece of code deep inside legacy software keeping the L7L6 = 11, or at L7L6 = 10. Now imagine the game (or whatever software is running) exits demo mode and wants to initiate some SmartPort protocol, and tries to look at the STATUS register of the IWM.

With L7L6 = 11, and expired motor timer, any LDA L7CLR or LDA L6CLR would select the IWM and the IWM would change the CONFIG register to whatever is present on the data bus. Unless the downstream code fixes that mishap and brings CONFIG back to where it should be, any SmartPort activity will either stall (a "freeze") or go astray (a "crash").

Now, here is why a very precise motor timer timeout can reduce the chance of this to happen: with the original IWM, both motor timer timeouts are FCLK cycle accurate. So from the 6502 instruction which turns off the MOTOR ENABLE bit, to any activity with the IWM later, there will be an (almost) exact number of 6502 CPU cycles until any further accesses to the IWM can happen. If these further accesses happen at non-critical points in time (MOTOR ON status does not change at any such point) and don't do risky things with the IWM afterwards, nothing bad may happen. Any software author (those who wrote the PROTOCOL CONVERTER at Apple included) can always 'tweak' his code such that it always dodges such critical points in time and avoids to access the IWM at these critical points (where the MOTOR ON status changes). Just one added NOP may suffice. And since the motor timers in the original IWM are (almost) CPU cycle accurate, this may yield code which runs fine without any trouble - until a 'IWMless' comes along where the motor timer timeouts are slightly different, or, in case of the RC timers, have some uncertainty interval due to the analog nature of these timers. (One interesting aspect of this is the nature of wait-for-motor-off loops, if such a loop is used at all, the point in the loop where the STATUS register is read, and the number of CPU cycles from the motor turn off command to this read event - this generates a "picket fence" of samples over time, and it is obvious that if these "pickets" never hit a critical transition in the IWM's motor timer and CONFIG register machinery, then nothing bad will ever happen - but only if the motor timer runtimes are exactly the same as in the original IWM. Small deviations where the read cycles stay between the "pickets" also are safe. But with analog RC timers, staying in this safe zone never can be guaranteed, and a "picket" may be hit).

Current approach to fix the problem

I've added a LOCK/UNLOCK state machine to the CONFIG register, and the idea behind this is to require a specific sequence of events (as mentiond above, as prescribed by Apple) to happen before the CONFIG register may be updated. If the "specific sequence of events" is designed such that it covers  a l l  of the unintentional changes to the CONFIG register which do lurk in an unknown number of software titles out there, but covers / blocks  n o n e  of the intended changes, then the resulting system will work fine. And like with any sort of combination lock, there are many different combinations to explore.

A large number of experiments needed !

This is why I have written up a test matrix of experiments which covers all the possibilities of the combination to unlock the lock (the "specific sequence of events"). This looks like brute force / trial and error, but is still based on careful design - for instance, I checked every such experiment against the known CONFIG related code in Apple's "Protocol Converter", to rule out those combinations which would not work anyways. This saves some time, but not much - the Apple IIc does some checks for an IWM before booting from disk, and if it can't reconfigure the IWM, it will just get stuck at a point before it even clears the screen !

Which has some consequences for the "DISK II" mode of the 'IWMless': it can be turned on only after the Apple IIc got past that test. The best time to flick that switch (it's optional anyways) may be just after the floppy disk based software has taken over the control of the boot / load process. Once the switch is flicked, the CONFIG register is locked, and no legacy software can disturb it anymore.

Will the 'combination lock' succeed to avoid the 'freezes' ?

Frankly, I don't now. I can do one or two experiments per 24h and then tick off those entries in my test matrix which did not work to my satisfaction. Once I happen to find a combination that works, fine, I can start the beta test phase of the 'IWMless'.

What are the alternatives ?

If I find no such combination (which means no suitable combination exists) then I either have to convince 'IWMless' users that "worse is good" and that "bugs are a feature", like many corporations do when they have faulty products they can't fix, or, I'd bite the bullet and throw away the current 'IWMless' PCBs and make new ones, but with two ispLSI1016 on it. And with two of them I could implement the exact same FCLK cycle accurate motor timers as seen in the real IWM. They just "eat" ~26 macrocells of the 64 macrocells in an ispLSI1016. So there is absolutely no way to put them into the current hardware platform having only one such CPLD. The RC timer solution only needs 5 macrocells, including the LOCK/UNLOCK state machine. (Of course, having two ispLSI1016 on the 'IWMless' would almost double the costs to make them, and a commercial vendor might need to ring up $50-$60 a piece plus postage, and for less money you can buy an old, early Mac motherboard and salvage the IWM from there).

Is it appropriate to add such a locking mechanism to the 'IWMless' ?

Well, it think it is. The basic(manual switch) CONFIG lock was there from the beginning, as I wanted a way to block the CONFIG register for those legacy software titles which were released before the IWM came out and have code that inadvertently brings the IWM into a configuration where the system does not work anymore (I don't know which software titles these are, but they must exist, otherwise Apple would not have written their technical brief warning about that pitfall).

The addition I am doing to this locking mechanism to hep with avoiding TOTAL REPLAY freezes is to add some automated parts not using an external, manual switch.

Apple may have added a CONFIG  locking mechanism to the original IWM, too !

And, lo and behold, my recent investigations of an IWM Rev B which I did to probe deeper into this problem gave me some clues that it may be that Apple themselves may have added an automatic CONFIG locking mechanism to that "B" revision of their IWM - at least I seem to have found some IWM command sequences which do not change the CONFIG register anymore, despite they have L7L6=11 at the "MOTOR OFF" state. It's still not proven beyond any shadow of doubt, and further work is required to construct watertight proof experiments (no, you probably won't find a Rev B IWM in any original Apple IIc or Liron card - all I've ever seen have the Rev A IWM).

But if the suspected "lock" function indeed has been added by Apple in their IWM Rev B, it means that they had enough trouble with inadvertent changes to the CONFIG register, and decided to do something against it. I intend to write more about that suspected locking mechanism once I've done all the experiments and have solid proof for the lock (by Apple !) being there. Alas, all such investigations cost time and bind ressources in my lab. But it's exciting (for me at least), when I investigate this IWM related issues I feel like Sherlock Holmes investigating a crime scene !

So stay tuned, and have no doubts that eventually, at the end of this long and winding development road, a 'IWMless' will emerge which we can deem satisfactory.

- Uncle Bernie