Hi -
I've just repaired half a dozen Apple IIc motherboards. These are quite notorious to repair, as all the DRAMs are soldered in. So I had to make a diagnostics EPROM which would pinpoint the bad DRAM(s) even when the machine was unable to do anything and even the text screen was corrupted. I might post that EPROM image later if there is any interest - I think diagnostics EPROMs should already exist somewhere in the web, but they eluded me, too many dead links and stale posts. So maybe my work making my own was redundant. But it took me only 20 minutes to derive it from the source code I already had (for the diagnostics page in the PROMs of my famous Apple-1 kits). Less time than I wasted searching for a ready made solution on the web.
Here is the fundamental problem / pitfall with the Apple IIc (BEWARE !):
It seems the machine does not do a POST to check the integrity of the RAM and the ROM before it attempts to boot a floppy disk. Alas, certain kinds of DRAM faults make the boot fail with the message "check disk drive". Which sets in motion a tinkering process (owners taking the Apple IIc apart and messing around with disk drives) which ultimately leads to the destruction of the IWM ("Integrated Woz Machine", the Apple IIc floppy disk controller). Because having no known good Apple IIc disk drive in hand, they plug in a Disk II drive which uses the same 20 pin flat band cable and connector. Alas, the pinout is different. Pooof ! The IWM is dead. Now the poor Apple IIc has two ailments: bad DRAM and the bad IWM.
This did not happen to me, as I use to check schematics before working on anything, but I bought those decrepit Apple IIc at flea markets for a song, maybe 20+ years ago, and lo and behold, all of them not only had one or more bad DRAM chips, but half of them (three) also had blown up IWMs.
So, this story told (hope it helps people to avoid blowing up IWMs), I need 3 IWMs which work but can't find any source. The usual suspects (Chip brokers) list IWMs but I don't want to waste my time with them - they all have minimum orders and I don't need 100 IWMs.
Maybe somebody has an idea where IWMs can be found (other than destroying another Apple IIc or early Mac). I dimly seem to remember there was a card for the Apple II which had one, but I'm not sure if this was the IWM or the SWIM.
Any hint is much appreciated !
(Oh, I also would need the plastic face plate for an Apple IIc disk drive and the screws, as one of the mine came without it - seems the ex owner was too frustrated to put it together again after his attempts to 'fix' it failed. Oh, of course he blew the IWM up, too.)
- Uncle Bernie
P.S.: don't forget to tell me if there could be a need for the diagnostics EPROM.
Unfortunately IWMs are unobtanium. The only source for them is pulls from other boards. And not all of the machines that used the IWM used the DIP version.
I've been saying for a while that someone needs to make an FPGA or CPLD based replacement for the IWM. I think it could be done, provided 5V tolerant parts are available (an issue these days). People have built replacements for the AY-5-3600-PRO keyboard chip used in several Apple machines, and even FPGA based 65816 replacements that fit on a 40 pin carrier. The IWM is a 28 pin package, so a little more of a challenge space wise, albeit, it also means less pins needed on the programmable part.
Two other chips that are unobtanium that should be replaced like this are the IOU and MMU chips. If there were modern replacements for these chips then it would actually be possible to create all-new //e or even //c motherboards.
For the IWM there is a step forward already. Steve Chamberlain of BMOW released FPGA source for an early version of his Yellowstone card (LIRON replacement) and that contains essentially all of what is inside the IWM. Somone would just have to cut the appropriate chunks out to program the chip and design an appropriate 28 pin DIP carrier. I probably make that sound too trivial. I don't have the experience with FPGA design to do it myself...
As rare as some of these chips are these days, there might even be some commercial potential, but it would probably be something more of a labor of love or a quest to achieve fame and notoriety in the retro computing community... for what that is worth.
The DIP28 IWM (344-0041B) is also found on the Apple 3.5 Floppy Disk Drive Interface Card (A2C2002, 820-0117) also known as the "LIRON", the unreleased Apple Universal Controller (820-0215) and unreleased Disk II IWM Controller (655-0108).
The SWIM was only packaged in PLCC afaik. That was on the Apple FDHD "NuMustang" controller (820-0500-01), and post-1988 Macintoshes.
Oh.... the card which contained the IWM chip is the LIRON... However, they are not normally a cheap source for parts for a //c... because they often sell for more than what a complete working //c does. The price of them has come down a little recently though, probably mostly due to the release of the BMOW Yellowstone card which does everything the LIRON can and then some.
I think you are correct. If memory serves me the IIgs and most if not all of the Macs used the PLCC version of the IWM, so they are not a source for parts, plus the PLCC are normally soldered in I believe.
> Maybe somebody has an idea where IWMs can be found (other than destroying another Apple IIc or early Mac).
The first series of Mac SE and Mac II came with the IWM. Later Apple offered an upgrade to the SWIM including 1.4MB drives. There must be places where these IWMs survived. Probably ...
Regards
Ralf
Are those DIP-28 parts? If not, then they won't really do any good as replacements for a //c.
OK, a little googling I found this... which shows the SE used a DIP-28 and it appears to even have been socketed...
https://www.macspecialist.org/macintosh-se/identifying-se-logic-boards.html
Now, if there were IWM pulls from upgraded machines... where they went over the years would be the mystery. I don't think that this upgrade was sold like the //e Enhancement Kit to be user installed... So I don't know what dealers did with IWMs that were pulled... returned to Apple? Discarded? Used as replacements for other repairs? Who knows?
> OK, a little googling I found this... which shows the SE used a DIP-28 and it appears to even have been socketed...
AFAIR: in the Mac SEs there were always DIP-28, in the Mac IIs always PLCC. And they were always socketed because Apple planned to upgrade them.
I'm pretty sure there was a recent thread (maybe here, maybe elsewhere, I can't remember), that people much smarter than me debunked the 20pin disk II drives bricking IWMs on //c computers theory. From what I recall, there is like 1 pin difference, and the concensus was that it would not brick an IWM. It shouldn't matter at all from what I recall.
You might be remembering this thread regarding pin 19.
Short summary of what occurred in that thread:
At first it might seem odd that the Apple //c disk drive would use +12 volts for the activity LED. Why not 5 volts? No doubt that was simply adapted from the original Disk II, which used +12 volts to the LED through a 560 ohm resistor because the drive already had a PNP transistor for switching +12 volts for disk activity. (The BMOW Blog published a schematic that suggests earlier revisions of the Disk II analog board had intended to use the PNP transistor to switch additional +12 volt components.)
That owner's Apple //c was not harmed, apparently.
Yeah, that was exactly it. And in googling this issue while trying to find this, I actually found a couple other cases where disk II drives were connected to a //c internal header with no issues.
So I don't think this is the reason for a cooked IWM on a //c as mentioned by OP. Unless maybe they managed to connect it backwards and that somehow cooked the IWM. But hooked up correctly, it shouldn't be an issue.
I too have had to change memory chips on the Apple //c, they are the same there as on the Macintosh 128k, often have problems with them. I don't know a good source for IWM, but I would be very interested in the contents of your diagnostic EPROM. I use your memory test for the Apple-1, if there was something for the Apple //c that was as handy and easy to understand it would be very nice. The built-in Apple //c test is not very convenient, if I'm not confused it runs automatically if the keyboard is unplugged.
FB_IMG_1669524164426.jpg
FB_IMG_1669523949911.jpg
The issue with the built-in diagnostics is that it requires at least some of the ram to be working. I believe Uncle Bernie's ROM will test the RAM even if there are one or more completely bad (or missing) chips. You could also check out the ROMXc which has a similar memory test; it beeps out the number of any bad chip it finds . If the other features of ROMXc are worth it to you or you do a lot of testing, it's a great addition to the //c.
In post #2, softwarejanitor wrote:
"I've been saying for a while that someone needs to make an FPGA or CPLD based replacement for the IWM. I think it could be done, provided 5V tolerant parts are available (an issue these days). "
Uncle Bernie's take on this is as follows:
a) Myself wondering why nobody did it yet --- so I (wrongly) assumed there must be a plentiful source of IWMs only known to "insiders". Now, I learn from the above thread its "unobtainium". Sigh.
b) I had the idea to make an IWM in a CPLD myself, maybe 15-20 years ago, when I first attempted to repair those Apple IIc (at the time it was five) but at at that time I did not yet have an efficient implementation of the Woz Machine's "State Machine" for PLDs. If you feed the PROM directly into a logic synthesizer, the outcome is (IIRC) 100+ product terms despite of ESPRESSO minimisation. It took me 20 years to reduce the IWM into a GAL16V8 and a 74LS299 (the 74 LS323 are also hard to get, and then at usurious prices, while the '299 are cheap and abundant.) This is the solution I use in my floppy disk controller for the Apple-1.
c) The main obstacle for me why I can't do an IWM is that I don't understand the "extras" the IWM adds to the basic Disk II controller functionality. Some pdfs float around in the web talking about extra modes and extra registers to "relieve the cycle count issues" but none of those I could find go into specific details of that or show a block diagram how all of this works together. Of course I can make conjectures, add a pipeline register each for the read and write data byte to/from the 74LS323 equivalent, but how these are controlled *exactly* I cound not find out.
d) 5V CPLDs are abundant, at least in my basement ;-) . . . the problem is the awkward packages they may have, and unless small enough SMD ones are available, the 'replacement' won't fit into the footprint of the DIL-28.
So I think it could be done. But I'm still too busy designing daughter cards and software for the Apple-1 to have the time to open up yet another project. Too many unfinished projects on my plate already.
- Uncle Bernie
In post #13, macintosh_nik wrote:
"I don't know a good source for IWM, but I would be very interested in the contents of your diagnostic EPROM. "
In post #14, jeffmazur wrote:
"The issue with the built-in diagnostics is that it requires at least some of the ram to be working. I believe Uncle Bernie's ROM will test the RAM even if there are one or more completely bad (or missing) chips. You could also check out the ROMXc which has a similar memory test."
Uncle Bernie answers:
Jeffmazur is right, my memory tests don't need any functional RAM in the machine. It uses two zero page locations for a pointer, but these also are tested whenever they are used, by a STA CMP BNE or equivalent, and the BNE leads to a routine which shows an error message for the offending zero page location.
If an error is detected, it attempts to give to an error message in the text screen. Which may be garbled if the screen RAM area is affected by a bad DRAM, but it shows the 'syndrome' both in binary and in hex, so you can still infer the bad DRAM number in most cases. If that is not possible, you can hook up your oscilloscope and "see" the 'secret message' the diagnostics software gives to you on the address bus. This is quick and easy.
Now, the ROMXc seems to be an alternative that already exists. I could still publish my EPROM image, but is it needed / wanted ? It only tests the lower 48K of DRAM because my take on this is that if that DRAM works, you can boot more sophisticated diagnostics from floppy disk (if the IWM is good). The upside is that since my code only tests the lower 48K, it can be used on any Apple II (but I did not try that yet, only Taiwanese Apple II clones take those 2716/2732 EPROMs).
Comments invited !
- Uncle Bernie
If you are not using a 16k card in your Apple II, then you can use a 2716 with one of the simple adapter sockets. The simple ones of course don't work with the language card because the selects get funky.
Oh, and of course that only works in a ][ or ][+... //e you can actually use a 2764 with no adapter needed. I would assume in a //c as well, but I've never actually owned a //c myself.
Uncle Bernie, is your GAL16V8 logic that works with a 74LS299 shared or available for others to use?
It might be a good basis to pair up with the Softsp rom and some addtional logic and make a cheap smartport only card.
/Rob
This is a great idea. Right now most people are doing softSP with a Grappler+ card with the LIRONGP image burned into the 2732 because the original softSP card is not readily available. And either of these solutions requires a separate disk controller card, meaning it uses up two slots. It would be great to have a solution that would drop right in and just use one slot.
I'm in the same boat, Uncle Bernie. I've got two //c boards - one with no IWM, one with a bad IWM - at the moment. I actually dropped by to ask if you'd released that EPROM image such a thing would be tremendously useful to me. I read the thread twice and didn't see it. Apologies if I missed it!
The IWM isn't a rom, and as such couldn't be replaced by an eeprom. It would have to be recreated in an FPGA. At least that's how I understand it.
Yep! I was referring to the memory test ROM mentioned in the OP.