IWM reverse engineering

54 posts / 0 new
Last post
Offline
Last seen: 4 days 1 hour ago
Joined: Dec 19 2008 - 21:01
Posts: 424
robespierre wrote:The only
robespierre wrote:

The only other computers I'm aware of that use a DB-19 connector are the Atari ST/TT for its ACSI port, and the NeXT for connecting the monochrome monitor or sound box. Seems like it would have been hard to get those confused?

But in any case, it's not so simple to design a replacement board that can be soldered into a PLCC28 footprint. That's just too small to fi

This was actually a disk drive (non-Apple branded) with a 19-pin connection. I don't know if it was for another type of computer, or it would have worked with an old IIe disk card, but not the IIgs. I will get the part number if you are interested.

 

Offline
Last seen: 3 hours 14 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1031
Some progress with the "IWMless" subproject was made !

Hi fans -

 

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

 

 

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

 

 

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

 

 

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

 

Online
Last seen: 1 hour 41 min ago
Joined: Feb 27 2021 - 18:59
Posts: 650
not needed

I don't think the special modes of the IWM are required for SmartPort functionality. There just needs to be a driver recognizable to ProDOS. There is a replacement ROM for the Grappler+ called "SoftSP" that makes SmartPort devices like the wDrive accessible through the standard Disk II. A new recreation called the "Grappler Minus" does the same thing, but omits the vestigial printer interface. It's just an EPROM and some latches.

Pages

Log in or register to post comments