Defcon:Blog Keklkakl blog blag

7Dec/170

Scribbling ideas for a homebrew computer design

This is part two of a series, documenting my journey in making my own homebrew computer (previous post here). As the title suggests, it looks at my process of selecting a design. But first, as I am a computer history nerd, a little computer history ...

The world of computing as we know it wasn't in my opinion started by the big behemoths of the early computing age. Yes, they created the field of computing, and through steady capability increase combined with reduced sizes made the systems we have today possible. But it required the invention of the microprocessor to make the idea of personal computing a realistic idea. Before that, it seemed computers was something for big businesses, universities and research institutes. But with the creation of chips, originally designed for flight computers in jetfighters and for calculators at accountant desks, hobbyists started playing with the idea of creating a computer of their own! Early on, the homebrew computer systems was the way to get a computer in a private home. Early examples of commercial personal computers, like the Altair 8800 and Processor Technology Sol-20 were in reality business-backed homebrew systems. In fact, the first of these commercial systems were shipped as blank PCBs and bags of components. Even the famous Apple I computer is an example of this. It is this enabling of computers in the average Joe's hands that enabled the explosion of computing that has lead to the technology enabling we have today.

Sol Terminal Computer / Sol-20

Sol Terminal Computer / Sol-20

So, to design thoughts and ideas. I wanted to create a computer that fits in the era of homebrew. This means to me, a fairly low-end system, designed by an individual or a small group of people, using time-period components, to be built in the home. If my design is able to be produced as a kit, that fits right in with the "standard" of the day. System designs were prototyped in basements and cellars, to later be sold as kits for other people to brew at home, and modify and expand. It was natural for me to select an 8-bit platform as my target, after all the 8-bit "revolution" was at the core of homebrew. As mentioned, I wanted to use time-period components, but I also wanted to be able to create my system without having to resort to "New-old-stock" or cannibalizing of parts to get a hold of parts that are no longer manufactured. This put some hefty restrictions on my options, and also meant I had to allow myself to use a few bits of "modern" technology.

This brings me directly to the choice of a CPU for my system. I talked about how the 6502 was the first CPU that I got to know in-depth in my previous post. Unfortunately (or fortunately, take a pick), I early on decided that the 6502 would not be the CPU for my system. While the CPU is still available, in a CMOS-ified version with added instructions (W65C02S6TPG-14), it would require some supporting components that are no longer available (other than NOS) to make a full computer that I would be happy with. With that realization, I started looking at what other microprocessors were used in significant number of designs. Candidates seemed to be: RCA CDP1802, Motorola 6800, Intel 8088, Intel 8086 and Zilog Z80. Of those, the only one that has an active, still in production version that's not a derivation is the Z80. As a bonus for choosing that one, it comes in a bread- and perf-board friendly 40Pin DIP, and has significantly simpler interfacing than the other options, by having full address- and databuses, simple single-phase clock and a trivial voltage-supply requirement of simply 5Volt. The Z80 was also designed to be relatively compatible with the 8080, so a lot of existing software runs on both CPUs.

Annotated photo of Z80 die, by Ken Shirriff

Landing on the Z80 gave me additional things to explore. Being a retrocomputing-nerd, I have for a long time wanted a system that could run CP/M. Control Program for Microcomputers is a very significant part of Personal Computing History, and a great number of systems, both commercial and homebrew, either had CP/M ported, or were designed specifically for it. With the Altair and IMSAI computers kick-starting a form of standardization with the S100 bus, CP/M became more or less the standard operating system for general personal computers, and thus had a majority share of the system software marked. It was only beat by the multitudes of different ROM BASIC versions summed up. CP/M was designed for select 8-bit Intel 8080 development systems, but due to its design it was easily ported to compatible machines, and with the compatibility of the Z80, quite a lot of systems were designed with just that CPU. While exploring what it would take to let me design a CP/M friendly system, I discovered Grant Searle's brilliant set of designs. On taking in the content of his site, I was first impressed by the amount and quality of work mr Searle has done to make his systems available and understandable. Second, I was blown away by how simple a CP/M system could be. So my path was early on set; I would take inspiration from those designs, and get CP/M running!

With a path staked, my plan became to try implementing the "Fully functional Z80 CP/M machine using only 9 chips" from Grant Searle on a breadboard or perfboard before proceeding to attempt a design of my own, to make sure that my understanding of the complexities involved was sane. However, I allowed myself to start sketching ideas for what I wanted to accomplish with my own design while waiting for parts. The journey of trying to get the first system operational will be documented in separate articles, this one is about the sketching...

My homebrew hybrid prototype of Grant Searle and Spencer Owens's designs

One of my early design choices was between simplicity or expandability. I had looked at the designs in the Retrobrew Computers community, and generally thought they were trying to be somewhat more "modern" than what I was trying to achieve. I wanted something that was a bit simpler, but at the same time I thought that having the option of extending the system would be great. This led to quite a few nights reading up on various bus architectures from the homebrew era, thinking about using one of the "standard" options like S100[1][2] or STD80[1][2]. One big issue with using one of the full-featured old standard bus designs was that it would require a lot more complexity than I wanted. So I decided not to go down that route, and rather go for a more raw CPU signal extension bus.

While examining what I would need to put on such an expansion interface, I became aware of Spencer Owen's RC2014. His first version of the RC2014 was basically Grant Searle's simple Z80 BASIC system, split into multiple cards, one for each major component, connected to each other on a simple 40-pin perfboard-friendly bus-approach. I really liked the concept, but saw a few challenges in it. It used single-row 2.54mm spaced header pins, and omitted a few signals that I knew would be needed later. From experience, I felt that using double-row connectors would lead to more solid mechanical properties, as well as making the bus mechanically smaller. Spencer's bus does not "fit" on a 100mm wide PCB, a real issue as prices for PCBs (and EDA/CAD if not using KiCAD or EasyEDA) has a definite crossing point at exactly 100mm... A double-row physical layout would also very easily translate into a card-edge implementation if one would like a truly retro feel... There will be a (possibly short) article about the result, with pinout and concept released to the public domain. I call my idea/approach the Z50Bus.

With a bus inspired by RC2014, it would also be possible to take advantage of the many cool designs that Scott M Baker has made. Take a look at http://www.smbaker.com/category/electronics-projects/, he has some really sleek additions and extensions based on the fairly simple RC2014. After seeing what smbaker has been able to do, I was sure that I wanted a simple, yet complete CPU bus, and that way be able to reduce the amount of "onboard" features.

Originally, I really really wanted to have a graphics system as a direct part of my design. Quite a lot of time was spent thinking about using memory-mapped or register/io-space based with their pros and cons, debating using a prefab Video Display Processor like the VIC, VDP or Yamaha V-series, and researching indexed video, colour-register based approaches and planar graphics. After seeing FAP, the FPGA Assisted Processor, I came to the conclusion that using an FPGA would be very similar to the time-period correct ULA, PLA and CPLD approaches that were actually used on Home Computers of the 1979-1985 period, just faster and reconfigurable. Going that route should allow a core hardware design to implement many different graphics subsystems, allowing experimentation.

However, I have chosen to not implement the actual graphics system initially! Most homebrew computers of the early microprocessor age didn't actually have graphics capabilities. Most didn't even support a keyboard. Generally the approach in the early days of homebrew computing was to use a teletype terminal, or a video display terminal. So I decided, if a set of serial ports was enough to get the homebrew computing started, a set of serial ports would be enough to get my system started as well! After all, I had already included an expansion interface, so adding graphics and keyboard I/O later on would simply be just that; an expansion. However, to be able to use memory-mapped video later, I would have to design my memory-map and RAM-interfacing with that in mind. The memory map, and the reasoning behind it is topic for a separate article.

Similar to the decision design for graphics as an expansion, I decided that storage media like floppy disk support is to be an expansion. I intend to create a floppy disk interface, for an actual floppy drive and/or a Lotharek HXC. Also on the roadmap is trying to go real retro, with a cassette interface. But I changed my mind about one form of storage connection. Even if IDE appeared on the market late in the 80's, it is too embarrassingly trivial to implement the 8bit microcomputer compatible mode of IDE. With a sane I/O interface like the Z80 has, all that is required to get working 8-bit mode IDE is a simple address selector, and two OR-gates and a few resistors. Plop a Compact Flash card adapter onto that, and you have an interface to solid state storage "for free". The fact that Grant Searle's CP/M computer uses that exact approach meant that is was an obvious choice for me to include it.

Hand-drawn early version of the system design

So, my basic design was centered around a Z80 CPU, with a memory map that would work with CP/M and a future graphics expansion, and serial ports for console and communication. To make it possible to have reconfigurable serial port speeds, and also general purpose timer triggered events I figured I needed to include some form of timer controller as an on-board peripheral. It would also be nice if interfacing with the "outside world" was easy, so adding one or more configurable parallel I/O ports made sense. The more I looked at that spec, the more obvious it became that I was more or less describing the standard Zilog "stack" (minus the DMAC): Z80 CPU as the processor, Z80 SIO for serial ports, Z80 CTC for the timer/counters and the Z80 PIO for two parallel ports. From this, it became natural to also design the system to take full advantage of the somewhat special, but cool Z80 Interrupt Mode 2.

IM2 is designed with a very powerful daisy-chain form of interrupt priority and arbitration. In IM2, devices are daisy-chained using their Interrupt Enable In (IEI) and Interrupt Enable Out (IEO) pins, with priority being resolved by their order in the chain. Additionally, interrupt handling is vectored, with the CPU providing upper 8 bits and the interrupting device providing the lower 8 bits of the relevant Interrupt Service Routine to be executed. The whole IM2 system looked very nice to me, so it is a central design element. It introduces challenges when trying to use non-Zilog peripherals unfortunately, but Luke Maurits has given me some ideas to solve that later from his LM-512 Homebrew computer.

As part of my process of building my "learning computers", in the forms of Grant Searle's CP/M computer and Spencer Owen's RC2014, I figured that following an approach close to those made sense. Using 74LS138 for address decoding of on-board peripherals was a safe and natural approach. To enable a memory map for CP/M plus expansion for graphics, I decided to add a "write-only configuration register" by including a 74LS273, placed at the IO address that Grant's monitor ROM uses to enable/disable onboard ROM. I decided that I did not want the complexity of catering for a large memory space, onboard memory was set to 64kbyte onboard RAM, 16k onboard ROM, with a bit of banking for a max configuration of 176k ( 16k*8+48k) RAM and 64k (16k*4) ROM in an expanded system using memory banking via the configuration register. This configuration would allow use of CP/M, expansion with graphics and storage later, but it restricts the system to not be compatible with Fuzix by Alan Cox et al.

To close off a by now rather lengthy post, a summary of design conclusions is in place

  • Z80 CPU
  • Zilog SIO/2 serial port controller with dual serial ports
  • Zilog CTC for four channels of Counter/Timer, 2 of them dedicated to the SIO/2
  • Zilog PIO for two Parallel ports
  • Expandable system through Z50Bus
  • Memory map designed to allow for graphics expansion
  • CP/M compatibility
  • ROM part of memory from address $0000 disable-able (needed for CP/M and more)
  • For fun, a dedicated ROM Cartridge connector
  • Z80 Interrupt Mode 2 in the core
  • Compatibility with software from Grant Searle (for easy system bring-up)

The last point in the list turned out to be very useful, as it allowed me to tackle a bunch of problems I encountered, without having to also write my own system ROM monitor. It also let me simply load up CP/M onto a CF card and start playing Zork!

6Dec/170

Nostaliga: Emma II and the desire to make a computer

This article starts a series, documenting my journey in making my own homebrew computer.

Back in ye olde times of 1994 I attended vocational secondary school as a student of electronics, and during that time, I was introduced to the wonderful lady Emma II. Emma was a "trainer" system based on the MOS Technologies 6502 CPU, in many ways related to the somewhat more commonly known KIM demonstration and development system. This sparked a love for quirky 8-bit computer systems that's still with me today.

MOS 6502 CPU, image CC BY-SA Dirk Oppelt / Wikipedia

http://retro.hansotten.nl/6502-sbc/emma-by-l-j-technical-systems/
http://www.anf.nildram.co.uk/beebcontrol/arms/atlas/emma.html

Using Emma's (fairly flakey) hexadecimal keyboard, we were set to program the 6502 using opcodes and raw data bytes. To solve the task, we had to design our programs using flow charts drawn on paper, and then translate the flowcharts to pseudo-code. With an idea of what the programming should look like, we sat down studying the manuals for the 6502 CPU internal structure, how it operated, and what it's view of memory and the world looked like. Next the manual for the Emma II was examined in detail, to learn how what we now knew about the CPU was used to implement a full single board computer.[1][2][3][4]

The 6502 trainer Emma II by LJ Electronics. CC BY-NC-SA Hans Otten (http://retro.hansotten.nl)

Armed with oodles of new information, our next task was to transform our flow-charts and pseudo-code into something Emma could understand. And that meant hand-translating our concept, first into Assembly mnemonics, and next to "hand-compile" our ASM-code into 6502 opcodes. The joy when our "traffic light simulator" finally worked! The frustration when our "lift controller" never worked... The satisfaction of coding up a lottery-number-picker of our own design, and having it work on the second try! Details such as zero-page, indirect and immediate addressing and the importance of understand addressing modes are still (if somewhat ratteling) stuck in my head 🙂 And I will easily claim that the experience of having to opcode-program a computer system has given a solid foundation for my later work and understanding in the field of information tech.

Even if we (naturally) were using more modern and advanced computer systems for our day-to-day tasks, and the Internet was about to explode (actually, my 2nd-year project in spring of 1995 was internet-enabling the school), the raw nature of the 8-bit computers fascinated me, and the simplicity of such a system had me thinking "This is something I can design and build from".

Alas, I had to leave Emma at school. But a short time later, I came in possession of two 6502 CPU chips, an 8086, a weird thing named 80186, and also an even weirder named thing called a Zilog Z80. These parts rattled about in my parts bin, and my head for many long years. My hope, and intention, was to build a computer from at least one of these. A fairly simple 8 bit system, with RAM, ROM and some form of communication on a higher level than the sponge-like flaky keys of Emma was the whole "design".

I am happy and proud to tell that I have now completed that task! In a series of articles, I will tell about the 2-year journey that lead to a fully functioning 8-bit computer, not at all built on the 6502 🙂

26Sep/101

Microcontroller concepts

Microcontroller concepts

Tiny computers surround your life. In your coffee maker, remote control, vacuum cleaner, telephone, and clock radio. Unlike your personal computer, where a central processor has a huge amount of processing power, these tiny computers are special purpose devices that have relative low performance requirements. These tiny computers are, in general, microcontrollers.

Microcontrollers are getting more and more available to the general hobby-hacker through the advent of devices like the BasicStamp and the Arduino.

Continue reading ...

Filed under: Electronics Tagged as: 1 Comment