I recently rescued a IIgs from someone, but they had plugged something wrong into the disk port and completely blew the IWM chip. It is actually cracked and has a small hole in it!
I removed it, planned on just possibly using a hard drive or a disk II card in it, but it doesn't come up at all. Does the board need an IWM installed to even boot up? I get nothing on the screen at all, no beep. I do get power everywhere.
I checked the ROM and CPU are good in another IIgs, but those are the only (easily) removeable chips.
Does anyone have a spare board they might want to part with?
Oh, ouch. Ouch.
No, the GS hardware does not depend on the IWM for any basic functions. The IWM's connections to the rest of the computer are all input wires, except for the connections to the data bus which are just used to put data onto the bus when requested. If the IWM was entirely missing then it simply wouldn't put data onto the bus when the CPU attempts to read it.
Other than the IWM, the disk port is also connected to the VGC -- that huge chip at position F2. A bad IWM wouldn't kill a GS, but a bad VGC sure would.
In post #1, 'rittwage' asked:
" Does the board need an IWM installed to even boot up?
I get nothing on the screen at all, no beep. I do get power everywhere. "
Uncle Bernie comments:
I don't have an Apple IIgs, so I all I can tell you for sure is that the Apple IIc firmware-in-ROM does check for the presence of an IWM, and will 'hang' just as you described if no IWM is present (and functional). I found that out when my 'IWMless' had only the basic DISK II functionality but no IWM specific functions yet. I did some experiments with reprogramming the firmware EPROM and there is a JSR which, if knocked out, will make the Apple IIc boot DOS 3.3 just fine, with an IWM substitute that only has plain DISK II functionality. PRODOS may or may not boot ... it seems to need more "IWM-ish" functionality.
We have reason to assume that if Apple did such a IWM check on the IIc, it is very likely such a check also is in the IIgs, but unless proven by hacking the firmware, it's just an assumption. 'S.Elliott' may be right that the IIgs does not need the IWM, though (post #2), but the IIc definitely does, as it tries to change the configuration of the IWM and when it's only a DISK II functionality with no configuration register, the firmware hangs in an endless loop writing the non-existent configuration register, and then checking if it properly reads back, and there is NO other exit from that function. In my eyes that is poor programming - there should be a limit of retries / a timeout. Maybe Apple fixed that in the IIgs.
Alas, the 'IWMless' is not a full IWM substitute, so it can't be put into the IIgs. This is because the IIgs uses the FAST mode of the IWM for the 3.5" floppy disks (so I was told, not having a IIgs myself).
Your best way to fix it would be to use an adapter PCB having castellated holes (if necessary) to put a real DIL-28 IWM into your IIgs. This IWM could be salvaged from a Liron card or an Apple IIc. And then be replaced in that 'organ donor' by an 'IWMless', once these are ready to be released.
Neither Liron card nor the IIc uses the FAST mode of the IWM, based on (superficial) inspection of their firmware. I don't see how a 1 Mhz 6502 could keep up with the FAST mode data rate when a polling loop must be used. With loop unrolling it would be possible, but then the code grows in size so much that it makes no sense to do it. Still, because the possibility is there, it can't be ruled out that somebody wrote a utility program for the IIc which would use FAST mode of the original IWM to read or write dumb external 3.5" floppy disks. Since I never will use 3.5" floppy disks in an Apple II environment I couldn't care less about FAST mode lacking in the 'IWMless', but I intend to do a full IWM re-implementation at some later point in time, when I have nothing more important to do. It probably would need a ispLSI1032 of not ispLSI1048.
- Uncle Bernie
If we can find and patch this out of the ROM, I can burn an EEPROM to test it.
A sensible approach would be to change the ROM's reset vector to the cold-start address used in the original Apple II, $FF59. (aka: OLDRESET or OLDRST) That's the original cold-start routine from before the Autostart ROM -- it just plays an old-style 'beep' through the speaker, initializes text mode input/output routines, and goes directly to the 8-bit Monitor prompt. It doesn't test for Apple keys, doesn't scan slots, doesn't test for auxiliary memory, doesn't initialize onboard devices, nor do any other enhanced initializations that were added in the Autostart ROM and subsequent versions.
But there's a potential catch. Changing to OLDRST will bypass all GS-specific initialization at startup, but the GS's hardware might need some of the initialization routines that are being skipped. Does the GS need to have its firmware initialize ADB to make the keyboard work? Does the GS need its firmware to initialize the VGC to make the video output work? Does the GS need to initialize its SOUNDCTL register before playing old-style Apple-speaker sounds?
But even with those uncertainties, I think it's a worthwhile experiment because it might reveal something about the computer's fitness. It might put a Monitor prompt on the screen, or make a 'beep' sound. Or both.
FWIW, the IWM chip out of a Mac II (and IIx and IIfx) does work in a IIGS.
You occasionally see Mac II boards out there that have severe battery damage and are good donors for the IWM chip.