How Sega built the Genesis

In late 2014, publisher Read-Only Memory released Mega Drive/Genesis: Collected Works, a history book covering the hardware, games and legacy of Sega's 16-Bit system. Featuring console diagrams and translated design documents, it serves as part art book, part history lesson and part interview collection. And you can read one of those interviews below. Read-Only Memory has provided Polygon with an excerpt — an interview with product designer Masami Ishikawa on how the hardware came about.

16-BIT

Only one Sega product designer saw the Mega Drive through from initial plans to final execution. Joining Sega in 1979, initially to work in the amusement machine division, Masami Ishikawa then became leader of the company's home console R&D division. His early projects included SG-1000 console variants the Othello Multivision — a hardware clone that represented an early attempt to create a global standard for computer games — and the Game Pack — an add-on module that slotted into a Pioneer television system. The SG-1000 II followed, before Ishikawa took on the role of design team leader for the Mark III and the Master System, the technical building blocks of which underpinned the subsequent creation of the Mega Drive. Remaining at Sega, Ishikawa headed up the development of the TeraDrive — the combined PC/Mega Drive unit manufactured by IBM — and then returned to his roots, working at the forefront of arcade hardware innovation at the company.

All images in this story come from Read-Only Memory's Mega Drive/Genesis: Collected Works.

How did you get involved with the design of the Mega Drive?

Masami Ishikawa: I was the team leader working on the design of the Mark III, the predecessor to the Mega Drive. It had a similar underlying concept to the Mark III so the project was a natural progression for me.

What were your priorities with the Mega Drive architecture?

MI: We wanted the Mega Drive to have the basic performance of the preceding system boards — the System I, System II and System 16 — and we wanted to preserve compatibility with the Mark III. In fact, even SG-1000 II titles were playable on the Mega Drive. The top priority was the Mark III compatibility — in order to retain gamers who owned older systems — while at the same time maximising the graphic performance. The crux was how to optimise the efficiency of the memory access cycle with the graphic memory. We also separated the CPU into a graphic component and sound component to lessen the stress on the game program. The Mark III compatibility meant that it also had a Zilog Z80 CPU. When the Mega Drive was in Mark III mode, it was mainly running on the Z80, but when it was in Mega Drive mode, the Z80 was used only for sound.

How did you decide on the Motorola 68000 as the primary CPU?

MI: Arcade consoles were already using 16-bit systems, but cost considerations meant that the decision to use an 8-bit or 16-bit CPU was made quite late in the design process. I think the final decision was made by the manager at the time, Sato-san, who later became president of the company. By using the 68000 we could take advantage of the programming resources already available for arcade use, plus the hardware — bus components — and software — for coding — were relatively simple to get to grips with.


What were the major strengths of the hardware in terms of graphics?

MI: I think its strength was in having multiple displays. We were able to have two scrolling windows — with both vertical and horizontal line scrolling — and the sprite size could be changed to fill the whole display. It could also display the background screen behind the scrolling window and could change the color of each line. The number of available colors was limited compared to comparable arcade systems, but it could create shadows that matched each character's shape and was also capable of semi-transparency. The biggest hurdle was the size of the chip. We wanted to include enlarging and minimizing capabilities as well as sprite-spinning functionality, but the circuit design was becoming too large to fit on one chip, which would have lowered the production yield rate and hiked up costs, so we had to remove it from the spec. The number of available colors was also limited by the size of the circuit structure.

Did you ever experiment with different CPU or graphics processing chips?

MI: No, it was more about choosing between 8-bit and 16-bit. We were planning to use a customised, in-house-designed graphic processor from the beginning. The 68000 had all the qualities we were looking for, and there were no other comparable chips on the market.

What was the idea behind using two sound chips (the Yamaha YM2612 and the TI SN76489) in tandem?

MI: We already used the Yamaha FM sound chip for arcade games, while the TI sound generator was employed to retain SG-1000 and Mark III compatibility.

How long did the design process for the console take?

MI: The project started in mid-1986 and lasted approximately one and a half years. I was the only person in charge of the project, but an additional four people became involved during the debugging process, after which I think we had one full-time assistant.

What was the most challenging part of the production process?

MI: Two elements in particular were very challenging. The first was choosing the optimal memory access cycle spec. 
Sato-san handed me a data sheet for Texas Instruments’ newly released dynamic RAM spec, called Dual-Port Memory, and asked me to somehow find a way to adopt this memory within the Mega Drive. I had a tough time tackling the data sheet of memory — which no one had ever used before — so I decided upon the specs first and then just jotted down any observations or ideas I had. I would spend days just contemplating it. The second challenge was to understand the circuit designs — which had also never been implemented anywhere before, even in arcade development. The complex circuit designs were FIFO memory, read/write of one line buffer method for drawing, and interlace display. They were explained to us by our senior colleagues. Finally, I also had to fully understand TV broadcasting standards in order to figure out the interlaced video display.

How much did other home consoles of the era influence you?

MI: There was a rumor that Nintendo was going to release the Super Famicom, so towards the end of the design process my manager asked me to consider doubling the graphic memory capacity to dramatically improve the console's performance. I had to redesign the way timing worked — the memory access 
cycle — and minimize the additional 
circuit size and number of IC pins needed. I managed to increase the graphic memory capacity, but it resulted in only a very incremental performance improvement, for example, increasing the number of display characters. This was when I hit a brick wall. I learned the painful lesson that designers need to imagine all the eventualities that may appear later in a process, and so must design in a way that makes it easy to change the design later.


How did developers create games for the Mega Drive? Did Sega supply development kits or frameworks?

MI: As far as I know, they were using ZAX Z80 emulators to develop game programs. It was nothing like modern day software development environments, which are equipped with libraries and SDKs. I recall that programmers were studying the source codes of the test program 
I made for debugging in order to develop each function. This is because the CS programmers did not yet have experience with the 68000 — up until this point they had been working with the Z80 alone.

How closely did you work with the arcade development teams?

MI: The development teams were organized under the leadership of the manager, Sato-san. The AM/CS departments were then divided into smaller divisions, such as the technical division, which I would go to for advice. Plus, all of the divisions were on the same floor.

Did games developers and designers have any input into how the hardware was designed?

MI: The process was not like it is today — we did not ask software developers for opinions. We simply had a one-way meeting when we finished drafting the specs. Since the Saturn, however, the software development environment was improved, taking into account third-party opinions. From that point, the development methods, organizational structure and staffing systems were changed.

Which games do you feel used the Mega Drive hardware most successfully?

MI: Sonic The Hedgehog 2 is the best. The two-player mode used an interlaced display function — which is the TV broadcasting standard — to display both players' windows in one screen, doubling the vertical resolution. On the whole, game displays at the time, both arcade and home console, were using non-interlaced video. I did make the video display method available when I developed the Mega Drive, but because it requires double capacity for characters, I never thought it would be used.


Were you involved in the development of system updates, like the Mega Drive 2?

MI: No. After the Mega Drive, I moved over to the System 32 development team to work on arcade machines, so I wash't involved in any home console development between the Mega Drive and the Saturn. The Mega Drive 2 — developed by the CS team along with the Mega-CD and Super 32X — did not have any basic performance changes. It was mainly about redesigning the case and cutting down the cost of the unit.

Despite not working on the Mega-CD were you aware of the design process? Was the hardware complex to implement?

MI: I was told by someone who worked in the Mega-CD production department that because there were no plans to release a CD-ROM add-on when we were designing the body of the Mega Drive, it was really difficult to design the connection between the two units. It seemed, however, that Sato-san was obsessed with the idea of a CD peripheral. The solution involved attaching a metal plate adaptor to the base of the Mega Drive and then sliding it onto the CD unit. Four holes and connectors held them together — it was not screwed on to hold it in position. Another obstacle was that the Mega Drive's side extension connector slot had a carbon resistant coating to prevent rust on the copper connectors of the board, but this actually made electric resistance very high and lowered connection signal levels, which resulted in weaker noise-resistance.

Did you have any knowledge of the development of the 32X?

MI: Again, I was told by someone who worked in that production department that at the time there were many rumors about Sega's competitors working on consoles like the PlayStation and N64. As a result, the company pursued 32-bit development. Also, because sales of the Genesis were going well, Sega needed to release something for the U.S. market while proceeding to work on the Saturn. Sega of America had also announced the 32X at the Consumer Electronics Show, so it was developed and released very quickly — it apparently took only nine months to build a prototype.

Looking back, is there anything you would have done differently with the design of the Mega Drive?

MI: Due to delayed decision-making on the CPU, I wasn’t able to embrace a flexible design philosophy on the CPU interface and graphic memory expansion. I wish 
I could have implemented a solution that was adaptable enough to accommodate variations.

What did you think of the subsequent Sega consoles?

MI: When developing the Saturn and the Dreamcast, the software and hardware teams worked together — everything from the design specification to the development environment was revolutionized. Even though I was working for AM at the time, I really wanted those consoles to become big hits.

Images: Read-Only Memory