advertisement

Print

Powering Up Your Home-Brewed Computer
Pages: 1, 2

Construct Your Computer

Do the construction a step at a time and check everything as you go. Start with soldering in the power connector, "power" LED, resistor, and protection diode. Check that these are operational and also that you have power on every pad on the board where you expect power to be. Check the ground pads and signal pads to make sure that there is not power where you expect no power to be. Solder the reset circuitry for the processor and confirm that it is operational -- observe the reset line with an oscilloscope. Does the reset signal line go active when you press the reset button? Solder in the power-decoupling capacitors for the chips. Add in the processor's oscillator and decoupling capacitors. For a prototype system, the use of sockets to hold the chips is a good idea. If there is a problem and you need to remove a chip, it is a simple matter of popping it out of its socket. This is much easier than having to desolder a multi-pinned chip.



When you are sure that the processor socket has power and ground connections, plug the processor into its socket and power it up. Check the processor's clock and confirm that it is oscillating.

If the processor has external buses, check these for activity. With no ROM (or flash) plugged in, the processor will be executing garbage from nonexistent memory. (It is, in effect, crashing, but you should still be able to see that it is trying to do something.) With processors that support externally-generated wait states (such as 68000s), the wait state input on the processor may be tied active (with a piece of wire between two pins of the wait-state generator's socket, for example) such that the processor is in a permanent wait state. When exiting reset, the processor will therefore be locked in its first access -- the fetching of the reset vector from ROM. This allows you to check whether the addresses and control signals coming from the processor are appropriate and also reaching all devices as they should. Confirm this on all appropriate pins. Don't assume that just because a signal is present at one end of a trace that it is present at all points along the trace. Check everywhere with an oscilloscope probe.

If your system uses programmable logic, program the chip with appropriate equations and plug this chip into your system. Use an oscilloscope to confirm that it is generating the signals you expect. Use the "permanent wait state" technique described previously to verify that the PAL is generating a chip select to the ROM as the processor comes out of reset.

In assembly language, write a program that does nothing but loop back on itself. This program should be as simple as possible. An example of such a program in pseudo-assembly language is shown below.

    org ROM     ; start code at ROM

loop    BRA loop    ; just a simple program that
            ; loops back on itself.
            ; this is used to check the
            ; ROM chip select and output enable
            ;

    org VECTORS ; vector table

    fdb ROM     ; allocate all vectors equal
    fdb ROM     ; to RESET for the time being
    fdb ROM     ;
    fdb ROM     ;
    fdb ROM     ;
    fdb ROM     ;
    fdb ROM     ;
    fdb ROM     ; this is the REAL RESET vector
            ; this points to start of code

Burn this program into a ROM and plug the ROM into your system.

If your system is working correctly, the processor will be running this program from ROM. This means that there will be a chip select to the ROM. There should be no other chip selects being generated by your address decode logic. There should be an output enable (read enable) going active at the same time as the ROM's chip select (as the processor fetches each instruction in turn). There should be no write-enable active, since your program isn't storing anything to memory.

Consider the addresses in memory at which your program lies. The activity on the address bus should reflect the processor running through this address range. The state of the address bits should correspond to these addresses and no others. Check each of these aspects of your system in turn. For example, if the following program lies at address 0xC000 in ROM:

loop    BRA loop

You should see the processor reading from address 0xC000 as it fetches the BRA (branch) instruction, then from 0xC001 as it fetches the offset. The processor will then branch back to 0xC000 and begin the loop again. Therefore, the only activity seen by this processor is a read from 0xC000, followed by a read from 0xC001, followed by a read from 0xC000, and so on. Thus, if the processor is executing this program correctly, when the processor is performing a read cycle (when the read strobe is active), the address bits should correspond to 0xC000/1. If the address bus looks random, then you have a problem that needs to be solved.

Once you have confirmed that the processor is executing code from ROM, add the components that compose the serial interface (if you've included it in your system). Confirm that the serial interface chip's oscillator is working by looking at the crystal inputs with an oscilloscope.

Write a program that initializes the serial port and then continuously outputs a single character to a terminal. Don't try to be too adventurous. If it doesn't work and you need to debug, you will appreciate a really simple program without lots of complexity and unknowns.

Once the serial interface is operational, plug in your RAM and write a program to confirm that it is functioning correctly. For example, read a character from a terminal (via the serial interface), store this to the RAM, read it back from the RAM, then print it back to the terminal. If the character printed back is the same as the one that was typed, this shows that the processor was successfully able to write to, and read back from, the RAM. Once this is done, you have a basic operational computer system, and you can move on to debugging the rest of your peripherals.

Prior to doing this, replace your simple diagnostic software with something more useful, such as a simple monitor program or a bootloader. This will allow you to more easily change the code on your computer and allow you to debug any other hardware in the system that remains to be tested. The time spent porting Forth to your system (and it's not that hard) is well worth the effort for the debugging capabilities it affords.

And after that, well there's always Linux to be ported ....

John Catsoulis is an electronics engineer, programmer and physicist who specializes in advanced computer architectures.


O'Reilly & Associates will soon release (November 2002) Designing Embedded Hardware .

Return to the O'Reilly Network.