Paul Charlton

Myarc Computers Inc. - 1985 to 1989

In my adventures with Fast-Term, I quickly hit the roadblock of low-level support for disk controllers was different across different manufacturers. I had used a novel formatting scheme for piracy prevention which relied on the TI Floppy disk controller, not realizing until I received customer feedback that the formatting was not compatible with other vendors such as CorComp or Myarc. I acquired floppy controllers manufactured by both Corcomp and Myarc before I pivoted away from piracy prevention and made Fast-Term one of the earliest open-source and "share-ware" applications.

The Myarc FDC quickly became my main storage device because it could store 360k per disk instead of the 90k per disk offered by Texas Instruments. The Myarc FDC also had bugs -- I disassembled its device driver rom, found and fixed the bugs and uploaded EEPROM images of those to the TIFORUM on Compuserve so that others could benefit from the bug fixes. After requests from various users I was also able to offer performance and capacity improvements to the Myarc FDC rom in the following ways. Capacity improvement resulted from being able to store more sectors per track on many drives from various vendors by increasing the sectors per track to 20 from 18 and decreasing the gap between the sectors -- an increase to roughly 400kB per disk. Increasing the capacity in this manner also increased the throughput because of fewer seeks for each sector read on average. I implemented further improvements in performance by changing the track numbering on the second side, first by numbering tracks 1-40 on the top side going inward, and tracks 41-80 on the bottom side going outward (the previous standard for double-sided was both the top and the bottom increased track numbers going inward.) My modification eliminated the full seek stroke on the drive between tracks 40 and 41. My second performance improvement was to renumber the tracks so that the odd tracks 1-79 were on the top side going inward, and that the even tracks 2-80 were on the bottom side, also going inward, in what is known as a track interleave, which reduced the number of mechanical seeks to read a full disk from 79 seeks to 39 seeks. Given that seeks were expensive, this literally saved tens of seconds in reading and entire disk. I made these changes available to the community in both source code and EEPROM binary format via TIFORUM online.

After the release of new Myarc FDC EEPROM images, I was introduced to the president of Myarc by a mutual friend who was also a part-time Sysop on the TIFORUM. The president of Myarc wanted permission to distribute my changes for the FDC with his shipping product, and he also wanted me to complete the device service routines for his new product, the MPES (mini-peripheral expansion system), which combined 32k CPU Ram, RS232, and the Myarc FDC into one circuit board in a small enclosure with a built-in power supply and two half-height floppy drive slots. In exchange, he offered me a Myarc Hard disk controller and a 10MB Rodime hard drive. I accepted and delivered the complete DSR for the MPES 2 weeks later. I also volunteered to be responsible for all updates on the HDC (hard drive controller) device drivers because I wanted to make my own improvements to the HDC firmware.

I went to visit the headquarters of Myarc in Basking Ridge, New Jersey -- as it turned out, the headquarters was in the basement of the president's home, near AT&T headquarters. In all of my visits to HQ, I only ever spent time in the foyer of the first floor or the basement. Along the wall of the stairs leading to the second floor of the house, was a stylistic painting of a view of the lake in Geneva Switzerland, with the caption "Genève", which is the French spelling of Geneva.

The president shared with me his plans for a new computer based on the TMS9995 and the new TMS9938 video controller. I came to learn that the TMS9938 was the result of a collaboration between Microsoft, Texas Instruments, and several Japanese game console companies, from an initiative they called MSX. The MSX computer architecture was based on a Z80 with the TMS9938, and as far as I know, the only console in the USA which made use of it was the Sega Master System, which did not provide compatibility with MSX cartridges. He had already prototyped a board with the 9938, the 9995, and some glue logic, but realized that he did not have the board real estate available in the required form factor to add ram and other necessary upgrades. I proposed that we design a custom ASCI which contained all of the "glue" logic for the components on the board, and that the ASIC also perform other functions like DRAM control, keyboard control (with an IBM compatible keyboard), virtual paged memory, and also provide logic for complete compatibility with the TI-99/4A including its complete memory layout and emulation for a type of memory that TI called "GRAM" or "GROM". For reference, the TI-99/4A had 4 separate categories of memory: 1) CPU addressable, 2) VDP addressable, 3) GRAM/GROM, and 4) device service routines. He located an ASIC vendor he could work with, which turned out to be Mitsubishi Electronics of America, negotiated terms with them, and the next week I flew to their sales office in Sunnyvale California to be trained on their proprietary EDA software.

Sometime during the previous process, we decided to do some branding, to come up with a formal name for the product, which up to that point was the Myarc 9640. The 9640 was an abbreviated form of 99-640, with the "99" paying homage to the TMS9900, the TMS9938, and the TI-99/4A, but shortened to simply "9" for flow of pronunciation. The "640" represented the total ram on the main computer board - which was 512kB for the CPU and 128kB for the Yamaha TMS9938. We adopted the "Genève" from the wall painting, dropped the accent mark and the name "Geneve 9640" was born. I was there when it was named.

The Mitsubishi EDA software was fairly clunky, running from a text-mode DOS prompt on an IBM PC. It covered the basics -- there was a library containing all of the gate logic Mitsubishi was making available, a manual net-list editor that let you connect gate logic cells to each other or to i/o pins on the ASIC, a sub-system for creating and running test vectors against the netlist, and another subsystem to ensure that the test vectors running against the netlist conformed with all of Mitsubishi's timing criteria. Their test tool also performed analysis of the netlist to locate any traces which connected to too many downstream device inputs. On return to my apartment near RPI, I acquired the necessary PC and set forth implementing the netlists to correspond to the design in my head. 2 weeks later I had a working netlist and set of test vectors that validated all of my logic and validated mitsubishi's fan-out and timing requirements. The ASIC design was approximately 4000 gate equivalents. Two months later, the moment of truth came when we received the first batch of 20 asics, and were able to plug it into the board we had laid out and etched in the meantime. To our disappointment, the first tape-out device did not work as planned -- it was having issues with the IBM keyboard controller emulation, and with the DRAM refresh circuitry. What I had to do to diagnose the issues was write custom boot roms which isolated the specific features, cut traces on the board and solder on test leads which I hooked to an oscilloscope to observe the behaviors. The keyboard logic was easy to isolate and prove out. The DRAM refresh timing was more elusive, since for the most part, the DRAM stayed refreshed by ordinary memory access. What I proved is that the timing database provided by Mitsubishi in their EDA tool was wrong, and that if it had been correct, the ASIC would have worked. I drove to their new regional office in North Carolina, where Mitsubishi had established a new design center in Research Triangle Park, and shared my findings with their two local engineers, and then was invited to a conference call with their team in Japan. They apologized and agreed to do another run for us without charge. They also allowed us to revise the netlist, at which point I added a couple more bells and whistles to improve performance of the TI-99/4A emulation capability, and I redid the logic for both the keyboard controller and the DRAM controller to be more resilient against potential timing errors in the EDA database. 2 weeks later we got the new ASIC batch and were able to completely bring up the computer. I had already written a boot rom, and a set of software drivers to bring up the TI-99/4A emulation mode as the first booted application. It was a thing of beauty, and we showed it at some larger user group meetings from Boston to Chicago. Once the original board was shown to be working, we quickly hand-assembled 10 others to distribute to key developers who were contributing to the original ecosystem. I had already developed the TI-99/4A compatibility module, and a boot rom which could launch the TI compatible mode or drop from that into a separate program loaded from disk into RAM. We farmed out several applications to those developers, and I directed two other developers in writing: 1) a graphics library to showcase the 9938 features, 2) a math package at the level of a modern TI calculator including implementations of SIN/COS and other intrinsics, while I retained personal responsibility for the command line (similar to DOS or CP/M) and the overall architecture of the operating system including device drivers, virtual memory management, and a preemptive process manager that allowed multiple processes to share the same pool of resources managed by the OS. Unimaginatively, we called this MDOS for "Myarc Disk Operating System".

It took me a couple of months to design and write the 50,000 lines of assembler which created the full operating environment, which I did concurrently with my 21 academic credit course load and writing of developer tools described in separate stories -- I averaged around 1500 lines of non-comment functional assembler code per day during that process.

We also attended a small trade show in Germany to show off the new computer and answer questions from enthusiasts who had come to attend from all over Europe. It was my first trip outside of the USA and I had to order an expedited passport. We flew to Brussels Belgium from Newark NJ, on a 747 operated by "People Express". During our landing in Brussels, the fog was so thick I had difficulty seeing the painted lines on the runway -- a bit disconcerting. The first night, we stayed in a "historic" Brussels hotel, where the sleeping arrangement was literally a board about 18 inches width with a pillow and blanket. From there, we took a train to Cologne Germany where we stayed a few nights. I was in Cologne for nearly two days before I realized the extent of their underground shopping arcades, dance establishments, and bars. The actual trade show was in Bonn, an hour away by car. I spent most of my time in Cologne coding demos that performed graphing with the new math routines and graphics libraries. On our return trip, via train then flying back to America from Brussels, I got to observe that El Al, the Israeli airline, actually had military style escort from the gate to the tarmac on the active runway -- 2 jeep style vehicles with large guns mounted on top. On the trip back, we made an emergency landing in Iceland, where we were on the ground for a couple of hours -- we were told that there had been a medical emergency, and the diversion to Iceland was the quickest way to get the person to a hospital. Even later in the flight, when we were less than 1 hour from Newark, we were joined by American F18 fighter jets, who flew directly off of the wingtips of the 747 for about 10-15 minutes until I could see the Manhattan skyline on the horizon. I never did learn why those military jets flew in formation with our 747 passenger plane -- they departed as we gained clear sight of New York city.

Somewhere along the journey of writing the 50,000 lines of source code for MDOS, I also wrote a full set of tools to assist me -- a macro Assembler for TMS9900, a linker, an object code librarian, a full-featured MAKE utility and later a "C" compiler. I also wrote end user documentation for all of those and developer documentation for the MDOS apis. They were bootstrapped initially using the assembler language tooling from the TI-99/4A compatibility environment, but ultimately they all ran as native, preemptible, command line applications on MDOS.

Shortly after MDOS was released to the public and the Geneve computer started shipping, I turned my attention to a new controller that I needed for my own use, and that Myarc's president agreed to mass produce for his customer base. It was a new combination HDC and FDC (the HFDC) on one peripheral card and was able to manage multiple hard drives and floppy drives concurrently. For the initial design, I placed all glue logic and other functionality into a new ASIC design. This time, the ASIC was bid out to California Devices who had a sales office near Boston Massachusetts. I spent 6 days at their office, learning their proprietary EDA tool, entering my design, entering my test vectors, and validating the design using their test suite. This second ASIC of mine was also about 4000 gate equivalents. They offered me a job at a really good pay rate after seeing my work -- they had imagined that I would be working a month of more for a design of that size. The ASIC worked on the first tape out, and the HFDC was born.

HDC "purchase"
FDC bugs
FDC performance improvements
HDC bugs
HDC performance improvements
HDC features, larger drives
Geneve 9640 Design
Paged virtual memory
TI-99/4A emulation
First Asic - MELA 3micron
MDOS
Software support for virtual memory
Software support for TI-99/4A emulation
New HFDC
Second ASIC - California Devices - Boston Sales Office
Cologne Germany
Germany Trade Show
People Express
TMS 9900
TMS 9901
TMS 9902
TMS 9918
TMS 9938
GRAM
GROM
VDP

UCSD P-system IML - Infocom machine language port Infocom games