Did anyone analyze the IWM related Apple IIc firmware ?

10 posts / 0 new
Last post
Offline
Last seen: 2 days 17 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1033
Did anyone analyze the IWM related Apple IIc firmware ?

Hi -

 

I'm making some progress with my "IWMless" project but to proceed I'd need some hints about what the Apple IIc actually does with the IWM, other the "default" configuration it has on power up (basically, in this configuration, the IWM has much the same behaviour as the DISK II controller, but with a few subtle differences regarding disk write operations and the write protect sense).

 

But where I'm stuck right now is the yet open question which other configurations of the IWM does the Apple IIc use ?

 

I don't think it will use all the 16 different configurations possible without considering the motor timer bit and the test bit, otherwise the IWM would have 64 configurations.

 

So the question to you out there is: did anyone of you analyze the code of the various Apple IIc firmware ROMs to find out what it may (or may not) do with the IWM ?

 

I simply don't have the time right now for looking through disassemly listings. I found one file said to contain Apple IIc firmware source code file on the web, but its seems to be garbled or some compressed format unknown to me. I also found this disassembly based work:

 

https://github.com/baldengineer/Apple-IIc-ROM-Disassembly

 

... but so far it did not help to answer my question, which IWM configurations are being used with the Apple IIc. Note that these are not necessarily present in the firmware ROMs. They (or at least some of them) might be invoked by the PRODOS. Since I have neither PRODOS, nor any "SmartPort" device, nor any functional Apple IIc right now, I'm somehow stuck.

 

Maybe some reader can enlighten me about this topic, or point to sources of information which could be useful.

Any hint is much appreciated !

 

- Uncle Bernie

 

P.S.: as far as I seem to understand the IWM after nearly one year of on-and-off reverse engineering work, some of its configurations are not useful at all (even Apple documentations says if the ASYNC mode is used, always use the LATCH mode, too, because otherwise it won't work properly), and some of the weirder behaviour I have seen may only be needed for applications in a 68000 based system - the way they have implemented the 'handshake' via MSB  in ASYNC read mode - at least to me - looks as if they anticipated some 68000 bus error events where the 68000 tries to repeat a memory (or peripheral) read cycle, and the proper state of the MSB must still be there. I think all these presumably 68000 related complications can be dispensed with in a 6502 based system. And, of course, I also want to throw out all the modes and configurations the Apple IIc never uses. This will help to make the logic fit into the small ispLSI1016 CPLD I'm using in the IWMless module. I do have a few larger ispLSI devices, but these won't fit mechanically. So for what I have at hand, the ispLSI1016 was the best choice. I'm quite sure that the original DISK II controller can fit into it, but anything "more" than that may get tight. Hence, the desire to strip my IWM RTL down to what the Apple IIc really needs.

Yet another open question of course is have important the support of "SmartPort" devices is for the Apple IIc. I've seen the opinion that almost nobody has them. Because all the legacy Apple II software came on 5.25" floppy disks . . . so most Apple IIc owners did only use the "dumb" 5.25" floppy disk drives, and nothing "smart".

 

CVT
CVT's picture
Offline
Last seen: 2 days 10 hours ago
Joined: Aug 9 2022 - 00:48
Posts: 1200
UncleBernie wrote:...Yet
UncleBernie wrote:

...

Yet another open question of course is how important the support of "SmartPort" devices is for the Apple IIc. I've seen the opinion that almost nobody has them. Because all the legacy Apple II software came on 5.25" floppy disks . . . so most Apple IIc owners did only use the "dumb" 5.25" floppy disk drives, and nothing "smart".

 

Maybe it was not that important back in the day, but it has become very important in the last 5 years with all the new devices like wDrive, FujiNet, etc.

Offline
Last seen: 2 days 17 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1033
On the "new" devices using the IWM

In post #2, "CVT" wrote:

 

" ... it has become very important in the last 5 years with all the new devices like wDrive, FujiNet, etc. "

 

Uncle Bernie comments:

 

This is duly noted. So I'll have to look into these devices, too, how they use the IWM. My current idea is to provide a stripped down version of the IWM which still has all the functionality required by these "new devices". I think this can be done as only a  subset of the 16 major IWM configurations does something useful. However, some of the "useless" configurations may become useful in context of a "smart" devices which implement handshake / X-ON / X-OFF - alike protocols to as to avoid overrun of the slow 1 MHz 6502 in the Apple IIc. I've analyzed the FAST modes of the IWM very thouroughly and came to the conclusion that for floppy disk work it's utterly useless as a 1 MHz 6502 just can't keep up, unless all the read and write loops are unrolled, and these would be unwieldy monsters spanning many kilobytes of RAM. But if handshakes are introduced by a smart peripheral then FAST mode may be used even on a slow 1 MHz 6502. This is just an example for the conundrum of which IWM modes to implement and which can be dropped. This is not so much a limitation of the target CPLD device, but of testing and verification time needed. Half of the modes implemented means half of the man-months saved. However, implementing the weird 68000 related behaviour would be a tight squeeze or even won't fit. It involves 14 stage shift registers, which "eat" a lot of ressources when implemented in a small CPLD.

 

Anyone out there knowing more about these "new devices" and where their source code can be found for inspection ?

 

- Uncle Bernie

Offline
Last seen: 3 hours 2 min ago
Joined: Feb 27 2021 - 18:59
Posts: 654
MIG

The Apple IIc+ is interesting in this regard, because it runs its 6502 at 1 MHz during floppy access, but can still keep up with the fast 800KB floppy drive. It does this by using an ASIC called "MIG" to move data directly from the IWM into the cache static RAM.

Online
Last seen: 48 min 57 sec ago
Joined: Jul 5 2018 - 09:44
Posts: 2615
CVT wrote:UncleBernie wrote:.
CVT wrote:
UncleBernie wrote:

...

Yet another open question of course is how important the support of "SmartPort" devices is for the Apple IIc. I've seen the opinion that almost nobody has them. Because all the legacy Apple II software came on 5.25" floppy disks . . . so most Apple IIc owners did only use the "dumb" 5.25" floppy disk drives, and nothing "smart".

<

 

 I completely agree that SmartPort has become important, especially for the //c in recent years.  The only two devices Apple ever sold for the //c floppy port back in the day were the original dumb //c 5.25" drive and the Unidisk 3.5.  The 5.25" drive obviously used only the standards Disk ][ modes, but the Unidisk 3.5 had it's own 65C02 on board to handle the higher data rate from the 3.5" drive so it was probably using at least one of the SmartPort like modes.  I'm not an expert on that though, but I imagine someone else understands it in detail.

 

However all that said, there were 3rd party devices like the Chinook hard drives that were sold for the //c which attached to the floppy port and I would imagine at least some of these devices used the SmartPort modes.  Again, someone else probably knows more about it than I do.  I've never actually owned a //c or //c+ so I never really learned as much abuot them as other models and most of what I know or knew is memory over 30 years old.

 

Offline
Last seen: 2 days 17 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1033
Yikes ! - Yet another nasty Apple custom chip !

In post #4, 'robespierre' wrote:

 

" The Apple IIc+ is interesting in this regard, because it runs its 6502 at 1 MHz during floppy access, but can still keep up with the fast 800KB floppy drive. It does this by using an ASIC called "MIG" to move data directly from the IWM into the cache static RAM.  "

 

Uncle Bernie comments:

 

Thanks for this info, and the link. I started looking into it. Seems to be yet another "can of worms" which, once opened, will "eat" a lot of time.

 

IMHO the solution adopted by Apple - designing the MIG custom IC - is brute force. A few months ago when I analyzed the IWM functions for their usefulness in an Apple II and came to the conclusion that 'polling' would not be fast enough unless using  complete loop unrolling, I devised a simpler way to support FAST mode on a 1 MHz 6502, which is based on manipulating the RDY signal to replace the polling loop(s). Once the RWTS would transfer a byte to or from the IWM, and FAST mode is on, a very simple state machine which could fit in a small PLD would deassert RDY to make the 6502 wait until the transfer can happen. On the NMOS 6502, RDY would of course not work for write cycles, but the 'phantom read' cycle just before the write cycle can be stalled by RDY. The CMOS 6502 fixed that RDY issue, so it works with write cycles, too, but removed the 'phantom read' cycle. The small PLD could handle both types of CPUs but would need to know which CPU it has to serve. This method with RDY is proven in my Apple-1 floppy disk controller, where the "Time Flux Compensator" aka "TFC" GAL uses RDY to compensate for DRAM refresh cycles which can happen in any number of 0...4 during the critical timing loops of the RWTS. Since I had this solution long before venturing into the IWM reverse engineering, it is obvious why I was able to see it and Apple didn't. They never designed a DISK II compatible controller for the Apple-1. The thread is here:

 

https://www.applefritter.com/content/uncle-bernies-woz-machine-based-apple-1-floppy-disk-controller

 

I'm astounded that Apple did not follow the KISS principle and went for a custom IC instead, which certainly did cost them a lot of money. I dare a guess they never got that sunken money back ... but not knowing the number of Apple IIc+ sold and not knowing the nature of the MIG (gate array, full custom, which process technology) I can't estimate any tentative numbers.

 

Still, another Apple custom IC to keep in mind for my IWM substitute project. The problem for me is, I don't have any Apple IIc+. Sigh. I don't have any Mac either, which is the primary reason I opted for the "IWMless" substitute which does not even attempt to work in a Mac. Despite I have the full RTL for all the IWM functionality I have reverse engineered.

 

- Uncle Bernie

 

Online
Last seen: 48 min 57 sec ago
Joined: Jul 5 2018 - 09:44
Posts: 2615
From what I've heard the //c+

From what I've heard the //c+ was one of the least produced Apple II models which isn't surprising since it wasn't on the market very long and was really targeted to the home market which Apple was already starting to lose by then while the //e was still selling reasonably well in the education market and the gamer market was mostly buying the IIgs due to the far superior graphics and sound.  Plus slots, etc.

The //c+ was also going head to head against the VTech Laser 128EX and 128EX/2 which had similar clock speed at a significantly lower price tag.  I had a couple of each of the VTech models at various times as I was selling them as a side gig back then.  VTech had their own custom IC for 3.5" control that was an independent development from the IWM.  Their original plug in card for the //e used 74LS and maybe some PALs, the later versions used I believe the same VLSI custom chip that was used internally in the 128EX and 128EX/2.

 

 

Offline
Last seen: 2 days 20 hours ago
Joined: Sep 9 2021 - 01:43
Posts: 25
The Floppy Emu

The Floppy Emu is a SP device also.

Online
Last seen: 1 hour 26 min ago
Joined: Jul 31 2014 - 17:48
Posts: 86
The IIc firmware is using the

The IIc firmware is using the IWM's Asynchronous mode in its Smartport/Cbus firmware. This removes the need for the code to be cycle accurate for sending data to the external drive. You can see the mode value mentioned in this page of the firmware:Apple_IIc_Programmers_Guide_to_the_3.5_ROM_part_2/page166 

And then the code that does the init here:

Apple_IIc_Programmers_Guide_to_the_3.5_ROM_part_2/page173 

There is the modified versions of the smartport firmware around, ie softsp, that has been updated to not use this async mode, but instead time the sending of the bytes to be every 32us by cycle accurate code. It's quite a bit of work to get the timing right in that firmware, a really great job to fit it in around the original code.

Offline
Last seen: 2 days 17 min ago
Joined: Apr 1 2020 - 16:46
Posts: 1033
Thanks a lot, 'rjustice', for the fish !

In post #9, 'rjustice' wrote:

 

" The IIc firmware is using the IWM's Asynchronous mode in its Smartport/Cbus firmware."

.

. . . and he also pointed me to exactly the information ("the fish") I sought to catch with this thread.

 

Based on this information, I can continue to work on the "IWMless" and I am in the process to put in just that configuration needed for these "SmartPort" routines. The ASYNC read already seems to work and I hope I can soon make it work with DOS3.3 when booting, as there seem to be subtle issues. Theoretically, the ASYNC LATCHED read mode should work with the normal RWTS routines, as these just look for the MSB being set, grab the byte, and come back to look again, but I'm not yet there. ASYNC write mode is more difficult to implement as it has two extra status bits (handshake and write underrun) and this will foil any attempt to use the standard RWTS of DOS3.3 to write anything ... the SYNC bytes which are 40 CPU cycles long would trip the "write underrun" and switch off the write mode. So I need to write more 6502 code to test this mode.

 

During the past days I've seen a few really weird side effects which are not fully understood yet. For instance, the IWM is supposed to read 'all ones' when the motor is off, and it is in read mode (L7,L6=00). When I put this feature into the RTL (it's just a "& MOTON" term added), then when manually exercised by the built in monitor program, all is fine, and DOS 3.3 still boots, but when I try to INIT a floppy disk, then it seems to work, but actally writes garbage at some places, and CATALOG does not work. It boots, however, only to bomb with a "I/O error" just before loading the "HELLO" program. My current conjecture is that something bad happens when MOTON is able to influence the data coming out of the read register. If I remove the "& MOTON" term, the "all ones" read exception is gone, and everything works again.

 

Not sure yet if the MOTON signal within the CPLD is faulty. But the equations are simple enough. They should work. There is one twist, however, which is a slight difference to the real IWM (where DOS3.3 works). Unlike the real IWM, I do not allow the internal MOTON signal to change while the CPU is in the process of accessing the IWM. This has to do with a protection mechanism to prevent inadvertent change of the configuration register by sloppy RWTS routines. So there is a slight difference to the original IWM which was put in with good faith. And it breaks DOS 3.3 !  Sigh ! Alas, this is part of the game when venturing into designing substitutes for legacy ICs. When I was active in this field more than 25 years ago,  I had many such cases where the application software would refuse to work despite the substitute was believed to be faithful to the original. Most of this was due to the software exploiting undocumented side effects of the original IC, which, for instance, might do the same thing when given a RESET and a CLEAR command by the software, but the datasheet said that some bits inside would only be initialized by RESET, and stay the same in case of CLEAR. But what the programmers had done is to just give a CLEAR command, and never a RESET command, because contrary to the datasheet, the IC treated CLEAR the same as RESET. This is why I always built a wire wrapped "lab rat" using PLDs, which would plug into the customer's target system, to see  if it works, before committing the design to a gate array or full custom implementation. This kept my customers happy and my bank account full ! (All the ICs I designed during that time fully worked in first silicon).

 

I wonder how many iterations Apple had to do on the IWM (a full custom NMOS IC using cheap, trailing edge technology) until they had dodged all the quirks of the target system (Apple IIe and IIc) and its legacy software (like DOS3.3). They probably had a TTL mockup / lab rat for their IWM design, though. Much the same design verification method I used in the 1980s. Except that I used programmable logic devices instead of plain TTL.

 

This said, any venturing into reimplementing / substituting ICs is fraught with risks due to unknowns, and there are many components which must work together to arrive at a viable solution. Some of these components being unfathomable software (well, "unfathomable" in the sense of limitation by time available to "fathom" it in all depths and nooks and crannies).

 

- Uncle Bernie

Log in or register to post comments