images/poc_populated_th.jpeg: unable to load image due to errors.

POC V1: System Design

With all features settled, it was time to actually design and build the unit.  My first step was to use my basic memory map to work out RAM, ROM and I/O decoding.  As I noted on the previous page, the selection of RAM and ROM is achieved by the use of conventional logic gates, such as AND and OR.  I/O, on the other hand, is selected through the 74AC138 3-8 decoder, which is wired to the chip select inputs of the RTC and DUART.  In order to get all this straight, I first created a memory map table in which the important bits of each address range were tabulated.  Knowing which address line bits needed to be asserted at any given time would simplify working out the required glue logic.  The memory map table is as follows:

Unable to load image due to errors.


Note that I also expressed logic equations so I could relate the address bus bit patterns with what would actually happen in the circuit.  In the logic equations, the symbol & means logical AND, | means logical OR and ! represents logical NOT (inversion).  Also, note that one of the logic equations references a signal called WDLWDL is true when the MPU is writing data—that is, when the MPU's RWB output is low, WDL is high.  Hence ROM will not be selected if a write operation occurs to any address in the range $00E000-$00FFFF.  Also note that I/O decoding occurs in one page (256 byte) segments, as I previously described.  This obviously wastes some address space, but is not a concern.  Decoding to a smaller address range per I/O device would greatly increase the amount of glue logic needed, but would not accomplish anything of value in return.

With the above information I could then work out how the glue logic would be interconnected to produce the desired results:

images/sbc_v1_glue_logic.gif: unable to load image due to errors.


By way of explanation, the /EPCE signal (where the symbol / means active low), when true, selects the EPROM and /SRCE, when true, selects the SRAM.  Note that no more than two gate delays are between the address bus and any one of the devices.  It is understood that the amount of propagation delay that occurs in logic devices sets a hard limit on just how fast any system can run with reliability.  By minimizing the number of gates involved, as well as using the fast 74AC logic, I was able to devise a glue logic setup that could, on paper, handle a 20 MHz Ø2 clock, even though such a clock rate wasn't practical with the chosen I/O hardware.

Incidentally, there's a bug—an error of omission—in the I/O select logic, which I'll explain when I get to how the circuit performed during initial testing.

Following the development of the glue logic, I drew a complete schematic of the unit.  As I was using Express PCB's free-for-downloading software, I had a reasonably good electrical CAD program at my disposal.  This CAD program can export its netlists to the board layout program included in the software, a feature which aids in correctly "wiring up" things.  The schematic editor program isn't as powerful as a full commercial package, but it is more than adequate for hobby and light commercial work.  The editor can also work with multiple sheets in one file, a feature that is essential for any project with any kind of complexity.

Here's the schematic I devised for my first-generation POC.  Click on each image to enlarge it in a separate browser window:

images/sbc_v1_page01_th.gif: unable to load image due to errors.
Page 1: Memory Map

images/sbc_v1_page02_th.gif: unable to load image due to errors.
Page 2: MPU Interface
images/sbc_v1_page03_th.gif: unable to load image due to errors.
Page 3: RAM, ROM and I/O


Not shown is page five, which is the parts list.

As can be seen, it's not a complicated design—pretty basic, in fact.  However, it's enough to make a functional computer.

There are some design features worth noting:
One of the members of the 6502.org microprocessor forum had encountered an interesting problem involving an apparently slow-starting clock oscillator that wasn't stabilized by the time the /RESET circuit was released following initial power-on.  The result was that his system wouldn't boot at power-on, but would boot if the reset button was pressed after power was applied.  His description of the problem led me to investigate ways to prolong the initial /RESET release delay from the default 250 milliseconds.  What I did was add a series resistor to the DS1813's Vcc connection, along with a parallel capacitor.  The resulting R-C time-constant delayed the rise of Vcc to the DS1813 for about one second, thus increasing the total elapsed time before the release of /RESET.  This addition had no effect on the release time when /RESET was pulled low by a push button, since the capacitor would already be charged.  I also included a jumper in the circuit to bypass the resistor in the event testing showed that the extra delay wasn't needed (it wasn't in this design).
While bloviating about interrupts, I should mention that the physical interconnection of the interrupt circuitry is one of those design areas where a lack of understanding can lead to a lack of operation.  The MPU has a single, active low interrupt request (IRQ) input (IRQB), which must be shared by all devices that use interrupts, using a circuit configuration called wired-OR.  In my design, this circuit is designated /IRQ, which is pulled up to Vcc by a resistor that is part of resistor network RN1 (see schematic page 2 above), a pull-up resistor being a necessary feature of a wired-OR circuit.  When /IRQ is released by the interrupting device, distributed capacitance in the circuit, which was discharged to ground while /IRQ was held low, has to be recharged to Vcc through the pull-up resistor.  Hence this circuit has an R-C time constant, which means that a small but measurable amount of time is required for /IRQ to return to a high enough voltage to stop interrupting the MPU.  If that time is excessive, /IRQ may not completely clear before the ISR has returned control to the interrupted task, resulting in a "phantom" or spurious interrupt that can cause all sorts of weird problems that will defy solution.  Avoiding this sort of design problem is accomplished by careful board layout, proper component choices, and by clearing all interrupt sources as early as possible in the ISR.
Incidentally, SRAM is the preferred choice for homebrew computers.  The alternative, DRAM (dynamic RAM), requires that refresh circuitry be implemented, which adds a fair amount of complexity to the system.  Also, accessing DRAM is slower and more involved, characteristics that increase the likelihood of obscure timing problems.  SRAM is much more expensive than an equivalent amount of DRAM, but is much easier to use.
After scrutinizing the schematic many times looking for errors (and fixing them) I concluded I had a workable design.  The next step was to lay out a printed circuit board.

Previous Page   Home   Next Page

x86?  We don't got no x86.  We don't need no stinking x86!

Copyright ©1996–2017 by BCS Technology Limited.  All rights reserved.
Unauthorized copying or reproduction of website content is prohibited.