In the early days of home computers, there was a company called Apple. She had just made huge strides with the Apple II line of computers, but she needed innovation to stay on top of the fast-paced computer market. The company has already worked on the Lisa line, which was inspired by mini-computers and was intended for business users, which means it had an appropriate price, but for the average consumer it seemed too expensive. As an additional project, the Macintosh was developed, which was supposed to be the realization of the idea of ​​a new generation of computers for “people from the street” and cost about $ 500. The project was taken up by Steve Jobs, and under his leadership, the hardware became more advanced, the software received a GUI instead of a text interface, and the price soared to almost $ 2,500. Although the equipment obtained at this price was a little disappointing, for example, it lacked the graphics accelerators and sound capabilities of other machines, but the software justified the price. The first Macintosh was the Mac 128K, and its success prompted the creation of more advanced models of this compact Mac, in particular, the Macintosh 512K, Macintosh Plus and the Macintosh SE series.

Although the development of the Macintosh took place around 1984, long before I began to understand computers, I had some weakness for the compact Macintosh: the first computer my parents bought was the Macintosh Plus. Later it was supplemented with a 20 MB SCSI hard drive, and on this machine I wrote my first Basic programs. When I was still living in the Netherlands, I bought a broken SE / 30 machine and turned it into a Linux server, which was nevertheless capable of running Mac software. However, I left this car in the Netherlands, and here, in Shanghai, I no longer have the classic Apple hardware.

Although it’s obvious that I don’t need Mac Plus in everyday life anymore, I liked the idea of ​​having it on hand in case of nostalgia attacks. Perhaps I can get a small share of the Macintosh experience if I myself create a small copy of such a machine. If I already have some experience creating smaller versions of old hardware , then why not try applying this process to build the venerable Mac Plus?

Display

What should I use to build such a machine? At first I came up with the idea to take a Raspberry Pi or something similar, add a 2.5-inch LCD screen, an emulator like PCE or MiniVMac, print a case on a 3D printer and consider the work done. But I don’t think this idea will pay off: the machine for my taste will not only be too big, but the project itself is too simple. In the original Mac 128K, even when the end result turned out to be too low-power, the developers managed to do a couple of tricks to save money. Simple assembly of a replica of standard “iron” is contrary to the spirit of the original design. So I went to Taobao for more exotic ingredients!


I decided to start with the display. For its time, the Mac had a high-resolution screen, so it was very important to choose the right display. Usually, when it comes to choosing displays in the Chinese electronics market, the assortment is large. Unfortunately, the "large assortment" consists of either high-resolution screens, but also large sizes, or small screens of small resolution. Ideally, I needed a resolution of 512x342 pixels; this is the native resolution of Mac and on a similar display I can display everything without zooming. Unfortunately, there are no ready-made screens of such a resolution on the market; the closest analogue will be something like 640x480. For some reason, screens of this resolution are quite large: the smallest has a diagonal of 3.5 inches. So alas, if I want to make the Mac as small as possible,

Having decided that it’s quite possible to slightly reduce the resolution, I got an assortment of a fairly large set of displays. One of the first displays seen was x163qln01 - a 1.63-inch OLED screen made by AUO. It's a bit expensive (about $ 25 per screen), but it can often be found on Taobao, and the datasheet at least documents the contacts, sizes, and power requirements. It seems that this display was designed for some kind of smart watch brand on Android, and a little google, I even found some initiation sequences that can be used.

The only problem (except for the connector, the contacts of which are located at a distance of 0.5 mm from each other) was that the display does not use a parallel interface and not SPI, but the MIPI interface. I will have to deal with this later.

Having selected the display, you can go to the processor. I chose the ESP32-Wrover module. This module contains an ESP32 (a WiFi chip with two 32-bit CPUs operating at a frequency of 240 MHz and with approximately half a megabyte of RAM), 4 MiB flash memory and 4 MiB PSRAM. I suggested that the two CPU cores would be fast enough to emulate a Mac and that I could use 4 MiB of PSRAM as a Mac RAM. Although 4 MiB of flash memory is not very much, they should be enough for the emulator plus a small hard disk with system software and programs. I also benefit from the fact that I work at Espressif, so this equipment is quite familiar to me; In addition, I can just take a few modules from work, instead of buying them and waiting for delivery.

So, everything is almost ready to work - the OLED screen still needed components for power supply, so the number of components increased by a low voltage drop stabilizer (LDO) and other power supply chips. For the Mac, sound was also required, so I took a cheap accelerator chip and speaker, and got the standard FT232 module for power and debugging. All of these components are quite small and allow me to reduce the body of the device; the result should be a model slightly more than 1/6 of a real Mac.

Display control

Although I can’t complain about the resolution, size and brightness of the display, it turned out to be more difficult to display pixels on it. MIPI was not supported by ESP32 silicon, so I needed to find another way to communicate with it. MIPI DSI is a standard developed by the MIPI Alliance and is not open; since this is a hobby for me, I had to collect bits of information from leaked documents and testing existing devices. Fortunately, a year or two ago, Mike Harrison reverse-engineered the MIPI DSI interface used to control iPod displays ( 1 , 2 , 3 , 4 , 5 , website), and also found several copies of the specifications. It made my life a lot easier: at least it helps me figure out what to send to the display.

Although there is much more to the interface (and to find out about this, you should watch all the videos that I gave links to above), the physical MIPI layer is quite easy to explain. MIPI uses four wires: two data buses and two clock buses. It also has two signal transmission modes: Low Power (LP) mode and High Speed ​​(HS) mode.


In Low Power mode, wires are used separately to transmit control data structures, as well as to indicate that certain commands have a direct effect on the physical receiver on the other hand. The voltage drop in this mode is quite large compared to the high-speed mode: for a high signal, the voltage is approximately 1.2 V, and for a low signal it is approximately 0 V. Since the low power mode has more signal states, it performs functions such as sending the recipient of the order to switch to high-speed mode or exit it. In the graph above, the blue lines indicate data transmission in Low Power mode.

In High Speed ​​mode, two clock buses (CLKP / CLKN), as well as two data buses (DP / DN) work as differential buses: one bus is always opposite to the other. The receiver detects the differences between the two buses and, based on them, sets the transmitted value: 1 if above DP, and 0 if above DN. As the name implies, the High Speed ​​mode provides very fast data transfer with a clock frequency of up to 1.5 GHz. To achieve this without too much electromagnetic interference and power consumption, the standard uses the following trick: it uses very low voltages: the voltage on the pairs is on average 200 mV, with deviations of ± 100 mV per bus to indicate zeros and ones. In the graph above, the red bits are transmitted in high speed mode.

From the point of view of transferring the data itself in high speed mode, the interface can essentially be regarded as a rather strange and differential SPI interface: there is a clock signal and a data transmission channel, and at each clock cycle the data value is transmitted to the interface. The difference from SPI (except that the signals are differential) is that the data bit is transmitted only when the state of the CLK buses changes, and not only, for example, on the leading edge. Another difference is that the start of a transmission is not recognized when the signal on the / CS bus becomes low, but rather an in-band signal: each data transmission starts with one unique “magic word”, and the receiver determines this value to understand when the transmission begins.

To ensure this interface interacts with ESP32, I will have to perform a level shift. I wanted to power the ESP32 from a 3.0 V source so that all GPIOs also had 3.0 or 0 V. To adapt this to the signal levels of the MIPI interface, I chose the most low-cost solution: I just used resistor divider networks.

To calculate the resistor values, I created equations for the three output voltage states that interests me (1.1 V for high Low Power signal, 0.07 V for low High Speed ​​signal, 0.33 V for high High Speed ​​signal; the voltages were chosen as so that in most cases they remain within the specification) and the three input states that should generate them. I got the equations. It was theoretically possible to solve them manually, but in the end I abandoned them in WolframAlpha and got the required resistors.

           3v
G -R1 - + R3
G -R2 - + - + ---->
           R4
           GND
R4 * (1.9 / R1 + 1.9 / R3) = 1.1, 
(1 / (1 / R4 + 1 / R1 + 1 / R2)) * (2.93 / R3) = 0.07, 
(1 / (1 / R4 + 1 / R1)) * 2.67 * (1 / R3 + 1 / R2) = 0.33, 
R2 = 1000
R1 = 280, R2 = 1K, R3 = 3K6, R4 = 150

At this point, I realized that you can also cheat a little: since in high-speed mode the buses are differential, the display will only look at the difference between the two buses to determine the transmitted data. This means that I can save GPIO by keeping a fixed voltage on one of the buses and applying a high or low signal to the other. To do this, I needed a second type of resistor network:

           3v
           R3
G -R1 - + - + ---->
           R4
           GND
R4 * (1.9 / R1 + 1.9 / R3) = 1.1,
(1 / (1 / R4 + 1 / R1)) * (2.8 / R3) = 0.2,
R4 = 150
R1 = 320, R3 = 1500, R4 = 150

Another task was to create a clock circuit. Normal SPI transmits a bit on the leading edge of the clock bus. (Or at the trailing edge, depending on the configuration.) MIPI transmits a bit at both the leading and trailing edges of the clock signal. Although the SPI module of the ESP32 equipment cannot generate such signals by itself, we can convert one to another using a simple D-trigger, whose inverted output is connected to the input. Each clock pulse at the input will change the output level, as we require.

Circuit diagram

Having dealt with the display equipment, we ended the most difficult part. Now all we have to do is add the rest. Let's start with the power source. It's quite simple: I feed the entire 5V circuit from a USB-to-serial converter, which can also be used as a debugging / programming interface. This voltage is taken to generate the +4.6 V, -3.4 V and 1.8 V required by the OLED screen, as well as 3.0 V to power the ESP32. Voltages of +4.6 V and -3.4 V are generated by the TPS65631 chip, and the reference circuit for this is shown in the datasheet of the OLED display. Other voltages are generated by a pair of simple LDOs.


The Macintosh also had sound. By modern standards, its quality is not very high (22 kHz, 8 bits), but the sounds of its programs are now legendary, so in my project I could not refuse them. ESP32 has a built-in 8-bit DAC, which is used to create analog sound waves generated by the emulator. Then they are fed to the NS8002, which is a 2-watt AB-class sound amplifier mounted in the small SOIC8 format. It is cheap, requires very few supporting components, and creates more than enough sound to draw attention to the tiny Mac.


One of the aspects that made the Macintosh so revolutionary was that it was one of the first commercial computers with a mouse. The Macintosh team thought out the mouse so carefully that almost the entire OS is based on mouse-controlled UI elements, and unlike, for example, the IBM PC, the entire Macintosh could be controlled by a mouse. Obviously, my tiny Mac also needed this important peripheral device. I still remember the ball mice sold with the first Macintosh, but I was not very pleased with the need to clean the rollers too often from dirt; it is for this reason that these mechanical devices were completely replaced by optical mice. The advantage of this is that the details for these newfangled optical mice are quite easy to find: for example, it didn’t take me much time,

Another convenient aspect is that the optical mouse sensor is a rather deeply integrated device: it requires only a few external components to work, and this is reflected in the diagram. Added several capacitors to stabilize the voltage, a MOS transistor (copied directly from the datasheet) to turn on the laser diode and other standard details. The mouse sensor transmits data through a four-wire SPI signal, and I used one of these wires to send the mouse button signal: when I click on the button, the MISO contact is pulled down quite a bit. The value of this pull-up resistor is not enough for the mouse to stop transmitting data, but enough to overcome the pull-up resistor, which normally pulls the bus up, so when the sensor creates three states in the MISO bus,


Finally, you need to connect the OLED screen. We have already completed all the difficult work of calculating the values ​​of all resistors, so the circuit should more or less speak for itself. The added chip is a D-flip-flop, and it is used to halve the clock speed: as mentioned above, the MIPI standard requires a new bit every time the polarity of the clock signal is inverted, while the ESP32 transmits a new bit only on the front or back front.


Having drawn a schematic diagram, I went on to create a circuit board design. The display I selected was to be mounted on the board that controls it, and the connector should be on the back of this circuit board. Although this would not have left much space for other components, I still wanted to place all the other components on the other side.


It’s great to have good vision and a hot air gun: this allowed me to use the 0603 components and place everything on the board’s limited space. It would be especially difficult to connect the display connector and the OLED QFN power chip with a conventional soldering iron.


I realized that the mouse sensor and its components will take up too much space on the board, so I decided to solder all the components to the sensor itself. Thanks to this, everything can be placed in the mouse.

Software

Obviously, the software is a rather important element of this assembly: you must emulate the entire Macintosh. However, the Macintosh is not such a complicated machine. In fact, it consists of a 68000 microcontroller, a Zilog Z8530 serial transfer controller that controls the serial port, 6522 VIA for internal I / O and for providing an interface with a keyboard, as well as several programmable logic arrays (PAL) containing logic for the display and sound. It also has an Integrated Woz Machine chip that provides an interface with a floppy drive. This is a pretty complicated chip; however, I do not plan to emulate a floppy disk, so it will be enough to emulate IWM, constantly returning that there is no disk in the drive. Instead, I plan to fully emulate the NCR 5380 SCSI chip connected to the emulated SCSI hard drive,

Moreover, the system will have very few programs with direct access to equipment: Mac programmers were told from the very beginning to use OS-level hardware abstraction layers to maintain compatibility with future versions of Mac equipment. In general, this means that if I manage to emulate hardware to such an extent that the OS boots up and is happy with everything, then most programs will work without any problems.

So I decided that you could try writing an emulator from scratch. More precisely, not quite from scratch; 68000 is a rather complicated beast and I did not want to reinvent the wheel. Instead, I searched the Internet and found that in MAMEThere is a convenient and fast CK-based 68K emulator called Musashi, which is quite suitable for my requirements. It will be necessary to conjure a bit to transfer opcodes instead of RAM to flash memory, but for the rest, almost nothing is needed to port to ESP32.

However, I did not plan to develop the entire project on ESP32: since the chip has support for OpenOCD, which provides fairly wide debugging capabilities, the “downloaded-tested-fixed-loaded” cycle will be too monotonous. Therefore, I decided to first develop everything on my Linux machine, not forgetting the limitations of ESP32. So I got to work using datasheet for different chips, Linux-68K informationfor the machine, as well as information from the Inside Macintosh series that can be found on the Internet. When I couldn't figure out what to do next, I could look under the hood of other open source emulators . Armed with all this, choosing gcc as the compiler and libsdl as the library for working with graphics, I got to work. In short, then after a while I will get a simple, but generally functioning MacPlus emulator: mouse, video, SCSI hard drive and sound work:




Since my hardware was not ready yet, I decided to port my emulator to the devboard ESP-Wrover-Kit. I still had several such boards on hand, and in addition to the Wrover module, which I will use anyway, they have a convenient 320x240 display that can be used to check the operation of the video.


After setting up, the Mac emulator made pretty good money on this board; in fact, it is usually quite close to the 7.8 MHz that the Mac Plus runs on. (7.8 MHz will be slightly faster than Mac Plus; since in this machine part of the memory cycles the frame buffer and sound system eat up, the frequency can be reduced by 35%.)

Obviously, the emulator on devboard is a good step forward, but in the end, everything should work on the screen that I bought, and not on the devboard screen. And one more thing: the devkit screen has a 320x240 screen and cuts off the solid part of the Mac screen. The display that I will use has a size of 320x320, and therefore it is larger only vertically: how can I manage to display a 512x342 Mac screen on it?

There is only one way to put 512x342 pixels on a 320x320 screen, and that is scaling. In fact, we take an image, compress it, making it smaller, and then display. However, scaling can be done in a bunch of different ways, and considering that the black-and-white image generated by the OS assumes that each pixel creates a clearly defined point of light on the screen, that is, there are many ways to ruin everything. I need to lose as few pixels as possible. That is, you need to increase the resolution of the OLED screen.

But how to do that? It is unlikely that you can open the OLED screen and put a few more pixels inside. However, this is not necessary; the resolution of the OLED display is already three times that stated. The reason is that this screen is color: each virtual “pixel” has red, green and blue subpixels. Furthermore, in this particular screen, the subpixels are lined with a triangle. Here is a close-up screenshot with three pixels turned on:


As you can see, pixels are triangular sets of three subpixels; depending on the column, the triangles point down or up. In essence, this means that the sub-pixel resolution of the screen is 480 x 640 pixels. Although this is still not completely enough to display 512x342 pixels, the difference is so small that with the right choice of small scaling, the display will be as readable as possible for a 1.63-inch screen displaying a GUI designed for a 9-inch screen:

Housing

So now I have a display and software that emulates the Macintosh Plus quite well, plus a microcontroller on which it can be run. What is missing? Obviously, enclosures for all this!

I decided to print it on a Formlabs 1+ SLA 3D printer from my work. To do this, I first need a model. I wanted to create it from scratch. Obviously, it’s better to have a real Macintosh Plus on hand. In fact, I have it, but we are separated by half a continent ... Fortunately, I managed to find an almost equally good solution: some kind person indicated the dimensions of the original Mac 128K (whose body is almost the same as that of Plus) in the iFixit wiki .

I still create all my 3D models in OpenScad, and after tormenting and cursing, I managed to make all the curves look as they should. I got a beautiful Mac model on a 1: 6 scale.


I also created the mouse from images with iFixit, but since a sufficiently large sensor of the optical mouse should fit in it, it cannot be scaled to 1/6 of a real mouse. The scale is closer to 2/5, so the mouse looks large compared to the tiny Mac, but it is much more convenient for unscaled human fingers.


So all that remains is to print the models. I exported the construct to various STL files and printed them on Formlabs 1+. The end result was good enough; I only regret that I did not add latches to both parts of the design. This problem was solved with a drop of superglue.

Result

So, I had all the components and could only assemble them. The PCB connectors in the front of the chassis are secured with several clips. The usb-to-serial converter, used as a boot mechanism and power supply, is connected to the rear and also holds on several terminals. I forgot to do something for mounting inside the speaker, but I managed to fix it in the case with super glue. The mouse is connected by a set of thin wires. (Yes, they are somewhat inconsistent with the color scheme ... as soon as I find a more beautiful multicore cable, I will fix it.)


When you develop everything on a computer, you realize the true scale of the product only when the project is fully materialized, for example, when you receive printed circuit boards from the factory or after printing on the 3D printer of the case design that you have been working on for weeks. Of course, I knew that everything would be six times smaller than the original Mac, but only after putting everything together and seeing the car live, I realized what that means. The Mac really turned out to be tiny!



And even despite the small size and lack of a keyboard, it is able to run most of the programs that Mac is famous for. Here is a demo. The first 20 seconds, a memory check is performed, and I know from experience that such a long check is not a bug: the original Mac Plus took the same time to load, even after the upgrade.


So what's good about this Mac Plus? Although I enjoyed creating it, I must admit that without a keyboard it cannot be used to its full potential. In addition, he does not have the means of communication: I planned to implement AppleTalk via WiFi, but I did not succeed because of the oddities that I could not emulate in the original Mac's serial bus controller chip itself. Nevertheless, having the completed project in this state, I can finally fulfill my old dream and put it on the Mac table with the toasters from the screensaver After Dark flying around the screen:


As usual, this project is open-source, the design of the circuit board and case, as well as the firmware, are posted on Github . Everything is licensed under a Beer-Ware license, so you can do almost anything you want with it. If you ever use something in your projects, you can write about it to me.