I've got an Apple IIe that had started to misbehave, culminating with it giving up entirely.
It had been working fine. I'd previously swapped out the keyboard Rom as that had given up the ghost, and there had also been an issue with the PAL encoder chip (the name of which escapes me now, but was a swap out replacement).
I had it out today as part of an exhibition, and it had been sitting there running Pac-Man. I noticed the machine had hung and restarted it. No problem, it came right back up, but after a while it stopped again.
The crashes became more frequent with less time between restart and hanging. Then, one reboot resulted in a screen full of inverted @ symbols and no startup beep. The subsequent reboot was fine but crashed very quickly, and now the @s are all I get.
Doing a Control-SolidApple gave me
IOU FLAG: 1 2 3 4 5 8
but sometimes I get different numbers (into the hex digits on some occasions).
In desperation I did remove the IOU chip, gave it a good squirt of contact cleaner and then reseated the chip, but it made no difference.
Is this likely to be the IOU? Any advice would be welcome.
All the best,
Paul
Thankfully we are on the cusp of a time when there will be newly made FPGA based replacements for the IOU and MMU chips for the //e. For a long time those have basically been "unubtanium". Since they haven't been made since the early 1990s and new old stock of them dried up years ago the only source for replacements was donor motherboards, which aren't that common. If you search here on AppleFritter though you will find that the project to develop a replacement is very close to being completed and the parts available. Probably only a few months out from being able to order them, probably from ReActive Micro.
I received a package on Monday containing FPGA based replacements for both the MMU and IOU chips.
Initial testing is that they work great! I'm super excited!
Not sure how far these are from being available to order, but this is going to offer a new lease on life for a lot of //e units with bad chips.
It also opens up the possibility that new //e motherboards and complete new //e units will be possible to build with mostly all newly manufactured parts. For the first time in over 30 years, the //e could be back in production.
Would you check them with larger, well populated RAMWorks vintage card, and possibly with more peripheral cards in the slots?
I have tested them with a vintage "Super Expander" which is a Taiwan clone of the original RAMworks card with 512MB and a 512MB add-on card. I have a repro Mockingboard in slot 4, a Dan ][ in slot 5 and a Disk ][ controller in slot 6. I can try adding a couple more cards. Alexandre and Ralle have asked me to test with a variety of hardware which I have.
This sounds all very promising!
Meanwhile, I managed to find a "working but bad RAM" IIe motherboard on ebay. Apple 8-bit machines were comparatively rare in the UK - we were all Sinclair, Acorn and Commodore - and on the basis parts don't come up too often I bit the bullet and bought it. Bit steep at £130 but, like I said, they are like gold dust over here.
I do like a story with a happy ending:
PXL_20250709_154730580.jpg
But if the FPGA replacement parts come out soon, maybe I can bring this donor board back from the dead too...
We're very close to these adapters be available to order, and I think it's more weeks away than months away. The testing phase is pretty advanced and shows that so far, these adapters work perfectly. On the other hand, I don't want to rush anything -- we've been waiting for IOU/MMU substitutes for 30 years, what's a couple of weeks more? I don't want to face the nightmare of discovering a problem and having to figure out a way to upgrade the firmware of all adapters that has been sold.
Back in january, Ralle Palaveev offered me his help in designing the adapters. It’s been quite a ride: full of highs, dead ends, letdowns, and moments of absolute triumph. I'd like to write a post on how it all went, but I'm about as slow writer as you can get. I'll probably stick to a summary. But the gist of it is that we originally wanted to use the Lattice iCE40. We had lots of problems with it due to the low number of GPIOs, the lack of space on the board, and it's slow configuration speed. At some point, we decided to abandon this FPGA and use the MACHXO2 instead. That forced us to throw away our design and start anew. Then we had weird things happening while experimenting with the IC we planned to use for voltage level-shifting (the LSF0108). We had to use this IC when we used the iCE40 (there weren't enough GPIOs for direction signals). We didn't have this limitation with the MACHXO2, so we decided to re-design (again!) to use the 74LVC245.
The designs for the IOU/MMU substitutes are completely open-source and is located here:
IOU: https://github.com/frozen-signal/Apple_IIe_IOU_3V3
MMU: https://github.com/frozen-signal/Apple_IIe_MMU_3V3
And the firmware is here: https://github.com/frozen-signal/Apple_IIe_MMU_IOU
I personally won't sell these, and I won't make any profit or other form of compensation from them. I feel I owe so much to the Apple IIe that I view this as returning a favor. I know Ralle will start selling them soon, and that ReActiveMicro should sell them as well.
Good. Now a more complex task awaits you -- the MMU and IOU of the //c .
I have done more testing and so far everything looks good. I have run several //e diagnostic softwares, and played a bunch of games.
In post #2, 'transwarp2' wrote:
" Good. Now a more complex task awaits you -- the MMU and IOU of the //c . "
Uncle Bernie comments:
Apple IIc MMU version:
The IIc MMU is a trivial mod and can be done in 5 minutes. I can state this with confidence as I have my own MMU/IOU implementations based on older 5V CPLDs, see here:
https://www.applefritter.com/content/uncle-bernies-replica-2e-ww-prototype-apple-iie-replica
Recent work on the Replica 2e revolves around giving it a IIc mode. The 'IWMless' development was a major milestone to enable IIc mode. So by turning a hex switch it can replicate the behaviour of all Apple II that ever did exist, except for the IIgs, which I'm not interested in, as I don't own one.
Apple IIe IOU version:
The IIc IOU is a bit more tricky than the IIe MMU as it contains mouse functions. These boil down to capture of mouse movement / direction events, and a few flipflops can do this. The problem is that the actual hardware spec of the IOU mouse functions seem to not have been published (at least I could not find any such documents on the usual websites) and there is no transistor level schematic available like for the MMU. This means that the IOU mouse functions must be re-invented based on the known few bits and pieces of information published by Apple and on analyzing their mouse driver software. This may take a few months ... simply because of all the testing that needs to be done, due to lack of a useful hardware specification for the IOU. If we had an "official" spec, the IIc IOU substitute could be done in maybe 1-2 weeks.
Conclusion:
There is no doubt that MMU and IOU substitutes for the Apple IIc will be available soon. Except for the elusive mouse functions it's a trivial further step of development based on the already existing MMU and IOU substitutes for the Apple IIe.
If the 'IWMless' (currently under beta test) turns out to be a good substitute for the original IWM, we (the Apple II user community) finally will be able to repair and replicate all Apple II family computers (except for the IIgs).
- Uncle Bernie
Can a //e MMU be adapted for the //c with just a socket adapter of some sort? The pre-//c mouse was based around the 68705 microcontroller which firmware is known along with the card's apple2 ROM. I guess Apple managed to strip this down to an apple2 own ROM firmare along with much simpler hardware implemented in the IOU?
In post #11, 'transwarp2' wrote:
" Can a //e MMU be adapted for the //c with just a socket adapter of some sort ? "
" The pre-//c mouse was based around the 68705 microcontroller ... "
Uncle Bernie answers:
No, it's not possible to adapt the MMU from IIe to IIc by using a socket adapter. IIc MMU has more outputs. Compare IIe and IIc schematics from their hardware manuals. But the extra outputs of the IIc MMU are signals which already exist internally anyways. The IIe / IIc MMU was the same die, differentiation was by a bond option.
Mouse hardware actually is simple, each axis has two photo interruptors, and needs two flipflops per axis to store an event and the direction. So four flipflops will do the job. Apple IIc IOU adds some interrupt logic to generate an interrupt per X or Y axis move event. The position counters are done in software. This looks trivial to implement but the devil is in the details which are not documented in a useful specification grade form. So lots of experiments are needed to reverse engineer what Apple really did.
Microcontrollers in mice can look at the photointerruptors directly via a standard I/O ports and if this is done 1 - 2 thousand times per second no mouse specific hardware is needed to keep track of the mouse movements. It's all done by software within this MCU.
- Uncle Bernie
It sounds like it might be possible to use a //c MMU with an adapter in a //e, but not vice-versa, or at least a //c with a //e MMU would be lacking mouse functionality?
Other than repairing broken //c units, what would the demand be for MMU and IOU for a //c? It seems like, because of lack of expandability of the //c that these chips fail less often in //c than //e, although that perception may be partially because there were so many fewer //c ever made than //e (by several million units I believe). Is there a desire to build new //c motherboards like there is for the //e? It would possibly be possible to build whole new //c units now because I believe there is a repro case and keyboard available. And I've seen solutions to replace the internal power supply on a //c with something modern as well.
Anyway, these are exciting times for the Apple II retro community.
Some additional testing --
Cassette tape save and load works.
I tested with a real Disk ][ drive since frozen signal and Ralle don't have them to test with.
I also tested the following accellerator cards:
AE Transwarp
Titan Accellerator //e
Ian Kim A2 Turbo
I have an A2 Heaven FASTChip //e which I will also test when I get a chance.
And I am now using an A2VGA with a VGA -> HDMI adapter for video in slot 1.
I've been asked to test printing. I have a bunch of different parallel and serial cards but I think the only old school printer I have anymore that might work is an HP LaserJet 2P which is not the ideal printer for use with an Apple II. But I think I can hook it up with a parallel card and Centronics cable and at least verify that text printing works. I've got little doubt it will.
For serial I think I can just hook a cable to an RS-232 cable on a Linux box or something and if it talks over a Super Serial card or one of the others I have then I think it should work for printing serial.
Any other ideas for things that should be tested?
You must use the color composite video output of the computer, otherwise the whole video circuitry of the chipset remains in the dark and untested.
My estimation is there is sufficient original A2E hardware left to suffice all apple2 fans for decades to come, and no new motherboard production is needed unless for "fancy" or not so rational reasons. That includes maintenance. That vintage hardare is good to be preserved from scrappers. Yes, the prices gradually inflate, like of everything else, but they are still a fraction of what these computers sold for originally. My technical curiosity alone is driving my interest in the MMU and IOU contemporary emulators. A friend of mine commented today that a single chip used in each of the latest MMU/IOU emulators would suffice to emulate a whole apple //e, including its CPU.
Please forgive me for going off-topic a moment, but it's worth addressing an off-topic error in the sentence above because it affects compatibility: the Super Expander card is a derivative of the Titan Neptune RAM card. It's misleading to characterize it as "a clone of RAMworks card" because the Super Expander came first...and because Applied Engineering intentionally designed their card to achieve only one-way-compatibility with Neptune cards.
Neptune-family RAM cards used a port at $C071 to select AUX-slot memory banks:
RAMWorks-family RAM cards used a port at $C073 to select AUX-slot memory banks, duplicated at $C071 for backward-compatibility with Neptune cards:
This distinction matters because some software is only compatible with the second group. For instance, later editions of AppleWorks automatically recognize RAMWorks-style memory cards, but not Neptune-style memory cards...unless you run a patch like PlusWorks. (There's also some juicy gossip about public attacks between these companies, but that would be going way-too-far-off-topic.)
Very interesting S. Elliot. I've never noticed any incompatibility with this card and RAMWorks, but I don't use Appleworks, so possibly that is why. Maybe everything else I've tried is compatible. Possibly my card has been modified or is a different version. It could even be a clone of a clone as some of these no-name Taiwan cards are. One of the diagnostic softwares even detected and tested all the extra RAM in the card automagically. I think it was the MECC one, but I don't remember now, I ran every //e diagnostic I had handy.
Anyway, it works fine with the new MMU and IOU substitutes. But I guess for completeness's sake I probably should go pull the real AE Ramworks ][ out of one of my //e units and maybe one of the modern AUX RAM cards like the Garret's Workshop ones (the ones I usually get) or the one I have in one machine from A2 Heaven. I'm pretty confident that they will all work fine.
One testing update. I remembered something in time thankfully, and that is there have been reports of PCPI Applicards causing problems with //e units, specifically frying the MMU chip. I definitely do not want to do this so I will not be testing any of my PCPI Applicards. I will instead test an A2VGA card with the Z80 firmware in it that emulates an Applicard. That's known safe for //e. If I get a chance I will test the generic Microsoft Z80 Softcard clone and the ALS Z80 card that I have as well.
I also remembered I have a clone of the ALF 8088 card that can run CP/M 86 that I can test.
I thought of a few other cards I should test. I've got a couple of Apple "Slinky" RAM cards. Also I should test some Saturn 128 clones (vintage and modern) as well as a few Quickloader type cards I have.
I have a couple of PCPI cards, and sufficient number of vintage MMUs. I am ready to test this doubtful rumor. Unless it is a transient current during power cycles, especially from -12V, -5V, or 12V rails...Do you have more details to how/when exactly it is rumored to "fry MMU"? Had I had a contemporary MMU emulator buffered like the one at your disposal it would have been even safer and more informative to experiment.
I'd have to ask Petar on the FB forums, he was the one who reported it originally. Ian Kim who designed an Applicard clone (but faster, using some modern components) mentioned he had fixed the problem with his design. I could ask him about it but he is sometimes slow to respond and he is in South Korea. If you want to test, that's up to you. You may also be correct that the replacement MMU may be more tolerant due to most all the signals being buffered through 74LVC245. Right now I'm not willing to take the risk. When I heard about the potential issue I just decided that it was better to use them in clones like my Franklin ACE 1200. One of my AppliCards is Franklin labeled so that one, as well as my Franklin Videx clone and Franklin multi-I/O card are all in that machine. I have another ACE 1000 which needs some work, I will probably put my other Franklin 80 column card and another Applicard in that one.
I have tested the IOU / MMU substitutes with a printer and it works perfectly.
transwarp2 asked for a test with a "well populated RAMWorks vintage card, and possibly with more peripheral cards in the slots". So for my test I had: A Ramworks 3 (512M), a Grappler+ card (slot 1), a Mouse Interface card (slot 3), and a Disk II interface card (slot 6). I booted up in DazzleDraw, and printed some random drawings. The printer I used is a OkiMate 20 and it printed with no problem.
You can also add TJ Boldt's ROM-Drive v4.0 card to the list of tested cards.
Just tested the Booti card.
Additionally tested:
Franklin floppy controller
Thunderclock Plus
A2VGA mouse emulation