Unitron was one of the first companies to introduce an Apple II clone in the Brazilian computer market. It was more faithful to the original than most of its competitors and enjoyed considerable success. My first impression of the company wasn't very favorable, however, as a friend asked me if I could lend them a book on 6502 programming - he claimed nobody at Unitron knew anything about the subject! See a brief history of the reserved market policy for a background on the Brazilian market back then.
Two years later they did impress me - in their booth at the 1985 National Computer Fair they were showing off two Macintosh "clones". The machines were suspended over a small artificial lake (it was a rather large booth!) in order to keep the public at a distance. One machine was running some demo software while the other one was turned off and partially open so you could see the internal components, including the main board. I guessed that the open machine, which had a board that was obviously different from Apple's, wasn't working yet while the working computer was probably an original Mac and not a clone at all. Such marketing tricks were a popular way to test public reaction to a future product, but it did show they were committed to moving beyond the Apple II (most of their competitors were jumping ship to the IBM PC).
At the 1986 Computer Fair (the same one where the Merlin II was presented) they had hands-on demos of their Mac clone. About six or more were available and it was obvious to me that they had actually built them. Visually, they looked exactly like the original Macintosh except that the keyboards had black keys. I got a chance to talk to some of the Unitron people and learned that SEI (the government organ whose approval was needed to legally sell computers in Brazil) was refusing to let them import the 3.5 inch floppy disk drives and wanted them to adopt the old 5.25 inch disks that were manufactured locally. Rather than agreeing to this silly idea, Unitron promised to build their own drive factory. When you take into account that it was a small company (less than 100 employees) in a simple house in a poor neighborhood of Sao Paulo, this was terribly ambitious.
1987 was the year Apple decided to strike in earnest against the Mac clone. They got the U.S. congress to approve a resolution that would hike import taxes on Brazilian products (shoes and oranges specially) to absurd levels if SEI were to allow the sale of the Unitron product. They stirred the Brazilian press against the company so that the local public was bombarded with articles about how these "nasty pirates" were going to ruin the whole country in an effort to make a quick buck for themselves. Some articles claimed that they had used a government run lab (CTI in Campinas) to crack open Apple's chips to look at them under a microscope in order to copy them - "your tax money is being used to help commit a crime!".
Though I had absolutely no connection with Unitron (in fact, I was their competitor), I wasn't happy with this situation. While I felt that Apple had every right to defend itself against clones if they wanted to (though it seemed stupid to me - they weren't able to sell their computers here while the reserved market lasted and Unitron was very unlikely to ever export to any other country. Apple denied itself a chance to have an indirect presence in the Brazilian market until it could come in itself at the end of 1992. Now it is unlikely that its local market share will ever compare to its worldwide one. On the other hand, letting Unitron alone or even encouraging them might have been a dangerous precedent), the courts were the proper channel to do this. What the many articles failed to mention was that every computer being sold in Brazil was a clone of some foreign machine and none involved anywhere near the level of technological contribution that a Mac clone did. The Mac had two custom chips: the real time clock (don't ask me why) and the IWM (Integrated Wozniak Machine) floppy disk controller. It also had six programmable chips (PALs) which interacted in very complex ways. By contrast, the PC AT (286 to you young ones) had just two PALs, one was a trivial decoder and the other a very simple state machine, and it stumped the local cloners for over three years! So naturally I felt it was unfair for Unitron to be taking such heat while the makers of PCs, TRS-80s, Apple IIs and Sinclairs were shown in a favorable light.
I walked into Unitron's booth at the 1987 Computer Fair (it was almost gloomy compared to the festive environment of the previous year) and asked to speak to the person responsible for technical development. I was introduced to Alberto Diez and asked him what would it be worth to his company if I could speed up their clone beyond what Apple's new Mac SE could do. I said it wouldn't require any redesign at all as I would merely reprogram the PALs, and then they could show it to the press and prove that it was more than a simple clone. He said that his engineers had already looked into this idea and it was impossible - the Mac's design was already "as good as it gets". Even so, he gave me his phone number so we could talk about this further after the Fair was over.
I found the idea that the "Turbo Mac" was impossible very funny because, in a way, I had already done it! Though there were significant differences between the 128K Macintosh and Merlin I, Burrell Carver Smith and I faced many of the same technical challenges while designing our respective machines. The most relevant one for our story was the relative timings shown in this table:
Project | Apple II | Merlin I and 128K Macintosh |
Processor | 6502 | 68000 |
CPU Clock | 1 MHz | 8 MHz |
Memory Access | 1 clock
1000 nS |
4 clocks
500 nS |
Memory chips | 4116 | 4164 |
Memory access time | 300 nS | 150 nS |
Memory cycle time | 500 nS | 300 nS |
The great idea in the Apple II was that as the memory was twice as fast as the processor, it could be used to feed the video circuits as well (what now is known as Unified Memory Architecture, or UMA) with no performance degradation at all. Unfortunately, the 4164 wasn't quite twice as fast as the 68000 due to an excessively long RAS precharge time (that isn't really important, here). Now there were two ways to work around this problem: you could slow down the 68000 to 6 MHz (that was the initial idea for the Merlin I) so that the CPU was once again twice as fast as the memory or you could insert wait states so that the CPU would use more clocks to access memory. The latter solution was adopted in the original Mac, but the problem with it is that it is very hard to divide clocks by factors other than powers of two, so wait states were inserted to make memory access take up eight full clocks! This isn't as bad as it sound, however, for video data isn't needed during vertical or horizontal retraces and the CPU can access memory at full speed during those times.
Though the Merlin I was designed using the 4164 datasheets since they were the only ones I had at the time, the machine was actually built using the larger 41256 memory chips. When I finally got hold of the datasheets for these newer components, I learned that the cycle time of the 150 nS 41256 was only 250 nS since the RAS precharge was more reasonable than in the previous generation. The CPU clock was bumped back up to 8 MHz and everything worked perfectly.
About six months after the Macintosh was introduced, Apple announced two improvements: the external floppy disk and the 512K model (known as the "Fat Mac"). Though this new machine replaced 4164 chips with the 41256, its timing was not changed to take advantage of this. A year later the Mac Plus brought the use of SIMMs for memory expansion and a SCSI interface for external peripherals, but otherwise was still the same design. The next model, the Mac SE, replaced the PALs with a custom chip and represented the first revision to the machine's timing in four years. They used the memory's "page mode" to read the video buffer two words at a time, which reduced the average number of wait states that the 68000 suffered while accessing the RAM. Other than this complex change, the memory timing was unchanged from the original design even though the memory chips now used were the 120 nS 41256 (with a cycle time of only 230 nS). The Merlin I had proved that this was less than optimal.
The time right after the Computer Fair was a very busy one for me, but about one or two months after that I called Alberto to see if they still had any interest in the idea of a Turbo Mac.We set up a meeting at Unitron (this was followed by a series of others, always on Wednesday afternoons). My proposal to do the job via my company (Inova Technology) was quickly rejected, but they were willing to consider hiring me personally. I asked for one modified Mac clone as payment - it would be worth the selling price for me but would cost considerably less for them, and having the machine would be a way for me to prove that I had done it and it had actually worked. I asked for the machine's schematics and promised to return them and all materials that I generated without making any copies for myself. Even so, negotiations dragged on week after week as they were not convinced this wasn't a ploy to milk them for information so that I could do my own Mac clone.
I finally saw that they hadn't understood what I was proposing - I did not want them to give me their (actually Apple's) equations for the PALs so that I could suggest improvements, but was going to create my own version from scratch using only publicly available information (Volume III of the original "Inside Macintosh" series and the February 1984 issue of Byte magazine). The schematics were needed just so I could know what each PAL pin did so the resulting equations would be fully compatible with their existing boards (as I had promised). I pointed out that if I had any interest in the schematics themselves then I could easily take a multimeter and open up an original Mac (I had one at home, that I and my father had upgraded from 128K to 512K) and draw my own schematics in a couple of days. When they saw that I meant business and was not trying to extract information from them then they quickly wrote up a contract.
The terms of the contract said that my modifications should result in a 50% speed increase in a RAM intensive benchmark previously defined and would require no changes to the machine other than the reprogramming of the PALs. The work would be finished in a month. They would give me no information beyond the machine's schematics and I would turn over all project material to them before receiving payment.
The 50% figure was rather arbitrary. Alberto asked me how much of an improvement I expected and I had to admit that I had no idea. So I did some quick calculations: total video was 704 pixels by 370 lines of which only 512 pixels by 342 lines are active, so if the 68000 now runs twice as fast during the active period and at the same speed during the blanking intervals then the average speedup would be 68%. The number in the contract seemed to be on the safe side.
Though I received the schematics on a Wednesday, I put them away until I could work on them on Saturday afternoon (it was a very busy and frustrating time at Inova/Softec). The first step was to follow the schematics and to name all the input and output pins on the PALs. Then I wrote a quick sketch of the equations for the basic memory cycle (they were very close to what I had done on the Merlin II) and for the video counter and control waveforms. I took these to next Wednesday's meeting and Alberto was amazed. "You did all this in just a week? We took three months to get to this point!" he said. I didn't mention that this actually represented just three hours of work (he might think that they had overestimated the job and were over paying me) but said that it is much easier to create something new than to reverse engineer (copy) the same thing. And this is true - if I had worked with them looking at the original Mac's waveforms on logic analyzers we probably would have taken the same three months. Too bad Brazil's cowardly businessmen never learned this lesson.
I had been afraid that I might need the datasheets for the auxiliary chips in the Mac (I knew the 68000 by heart at that time) but that turned out not to be the case. I didn't need to know more about the Z8530 SCC or the SY6522 VIA than what was in the Inside Macintosh book. But the speed control for the floppy disk motor was integrated with the sound generator and depended on details of Apple's custom IWM (Integrated Wozniak Machine) chip, so I had no equations to show for the sixth PAL. I would need a lot more information to program that PAL and the result would probably be identical to the original Mac's (my changes shouldn't affect that part of the system), so Alberto agreed to check that part and make any patches that might be needed himself. I mentioned that the equations were straining the limit of what I could simulate entirely in my head (it was a very complex design), so he agreed to lend me a copy of a logic simulator for this job.
So there was great progress the next Saturday, but I got stumped by what the February 1984 Byte called "phase read". The Inside Macintosh was no help in finding out what this "high frequency timing adjust" was for and a loop reading from these positions seemed to produce no effect other than returning a regular bit pattern. Since now I was really busy with other projects I put this aside for the next few weeks.
Alberto called me and asked if I had given up on the idea. I said that two problems had cropped up. The calculations we had done would have implied that the Mac SE should be about 30% faster than the Mac Plus, but the latest issue of Byte had benchmarks showing only a 12% increase. So it was very unlikely we would obtain 50%. He said that I didn't need to worry about that. I also mentioned the "phase read" and said I would not be able to figure it out without his help. He asked me to come over so we could talk about it, so we resumed our Wednesday meetings even though the month established in the contract had already passed (they had been very busy as well, so the lack of meetings to close the project had been as much their fault as mine and they were willing to recognize that). At the meeting I described how I was unable to find any more details about this high frequency timing thing, so he showed me a sheet of graph paper with some pencil drawn waveforms on them. "Is that it?" I asked as I looked at one of the ugliest hacks I had ever seen. Alberto Diez confirmed it: the memory state machine could end up in one of several states when the machine was turned on. Since only one of the waveform phases was useful, it was the job of the boot up software to check this and fix it if it was wrong. My memory timing was entirely different, so none of this made any sense for it. I had finished the job several weeks earlier and didn't know it!
Our next meeting was in their lab. We typed in the equations and programmed their GALs (a more advanced type of PAL which is erasable and reprogrammable). When we turned on the modified Mac, nothing happened. We soon found out that the logic board wasn't getting any voltage from the power supply. They were sure it was working before, so they replaced the original PALs and the machine booted just fine. It turned out that the power supply was intimately connected to the high voltage, high frequency circuits of the monitor. There seemed to be something wrong the the video control waveforms in my equations. I reran a simulation and everything seemed in order. But then I noticed that the equations weren't exactly the same as the ones we had programmed - I had somehow given them an outdated version. That was quickly corrected and the machine booted with my modifications too! Unfortunately, it would sometimes work and sometimes would come up with the left and right halfs of the screen exchanged. We hooked up their logic analyzer (I had never actually used one before) and soon found a nasty glitch that was causing this. Just another small fix and we were done! I was amazed - with the tools we had at Softec this would have been a two week job (at least).
Alberto soon called to say the benchmark had shown a 35% speed up (as we had suspected) and that they had modified some 15 machines and half of them were having problems with sound (but were otherwise working). It wasn't hard to spot the problem - there wasn't enough set up time for the sound latch. I told him that he could choose between two fixes: I could rewrite the equations to solve this but they would become rather obscure and critical or he could invert a clock signal on the board. He preferred the latter option and found out that the signal just happened to pass between two unused pins in an inverter chip! How lucky can you get? So there ended up being a patch to the logic board after all, but it was a pretty small one.
In the next week's meeting I delivered all the material and reports I had written as well as their schematics and they gave me the Turbo Mac serial number T-70029. I was pleased to see it had beige keys like a "normal" Mac instead of the ugly black ones. Alberto said they were having lots of problems getting the mouse to work right, so they had tested a number of them and given me the best one. As the months passed in early 1988 and I didn't read anything about the Turbo Mac in the press I called them to ask what happened. Alberto said that the executives were pleased with how the project turned out, but since the press seemed to have forgotten about them it was best to keep it that way for as long as possible. The last time I heard from Alberto was some time later when he called me to say that he and a few others were frustrated with the end of the Mac project at Unitron (besides the Turbo Mac they had developed a Mac Plus clone with a separate monitor, their own Finder and systems software and their own version of the Mac ROMs, though they were still in the early debugging phase for the latter) and they wanted to build an expansion board for the PC that would convert it into a Mac. Since I knew much more about the PC than they did, they asked if I could help. In the end, this didn't work out.
At the 1992 National Computer Fair Apple had a booth for the first time. The reserved market policy was going to end in a few months and they would be able to sell machines in Brazil. I mentioned to one of the staff manning the booth that my Turbo Mac was probably faster than the Mac Classic that they were showing. He said that was impossible as they had been improving each successive model and that my machine was merely a modified old Fat Mac. The ROM firmware had indeed been greatly enhanced, but the hardware was the same as an SE. So I wrote a simple RAM-only benchmark in Smalltalk-80 and took the floppy disk to the Fair the next day. There was a different person standing by the Mac Classic and I asked him if I could run an application from a floppy I had, warning it he would have to reboot the machine afterwards (Smalltalk-80 didn't know how to talk to the ADB keyboard and mouse on the Classic, so there was no way to exit the program). He said it was ok, so I tried it and the benchmark indicated that it had run 23% faster on the Turbo Mac than on the Classic.