circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 


Published March 2000

EMBED THIS PC

Lessons from the TrenchesPART 3: Emulator to the App Test
by George Martin

StartThe ProgramReal ModeGetting An App Up and RunningSources and PDF

THE PROGRAM

This is where Paradigm’s C++ tools come in. The software package, PDREMOTE, is a stand-alone product that can be used with several software development packages. Paradigm also has its own integrated development environment, which appears to be licensed from Borland and, as you know from my last column, I highly recommend Turbo C 3.0.

From the Paradigm integrated environment, you can create several types of applications, including a remote startup application. Feel free to download a copy of a typical PDREMOTE startup source file for an SC400. This startup source file gets the CPU under control, configures the hardware, and transfers control to the PDREMOTE software.

Paradigm has done a good job of separating all you need to know about the PDREMOTE software from what you need to alter. It’s easy to bring up a nonstandard system—which, as you know, includes just about everything.

If you download the source file, you’ll notice a SC400RegInit table, which loads the configuration registers into the SC400. I copied this table from the Paradigm software that runs on the AMD demo boards, which saved me a lot of time.

Just after the table, I placed the startup label, which is where the CPU reset vector is set to point. You’ll notice several "This loops forever" comments. In the first one, the jmp mm9 instruction completely bypasses the loop. But, if that instruction is commented out, the CPU continuously performs the out dx,al and in al,dx instruction pair.

When I comment out the jmp mm9 instruction, I can look at my hardware and see the I/O write and read instruction activity. Also, I see the decode for the specific I/O address loaded into the DX register. With the loop enabled, if the CPU starts running, it will get stuck in the loop, and I can observe the activity with a scope.

When you’re bringing up a new piece of hardware, techniques such as these are invaluable. They help you figure out if the CPU is running, and you can observe the power supplies and clock signals. If you get to the loop and remain stuck, you know the reset vector and BIOS EPROM instruction fetches are working.

With that first loop disabled, the registers are loaded, and the RTC oscillator is enabled. Next, a wait is inserted to let all the SC400 hardware catch up with what you’ve just done. The waiting period probably needs to be adjusted for your specific application.

PDREMOTE software is initialized and ends with a call to PROGmain, which is the actual PDREMOTE software. The PDREM software, at this point, should be running. Now, you should have an emulator and debugger for your application software.

The Paradigm design environment was used to create this PDREMOTE application. Depending on your specific design, you can locate the PDREMOTE at a location such as F000:0000. I’ll explain this notation later for those of you who are not familiar with the segmented architecture.

The compiler-linker then creates a loadable module. That module is loaded using the LoadIce utility from Grammar Engine. The LoadIce utility clears the emulator memory, loads and verifies the program, resets the CPU, and starts running. The EPROM emulator can be powered separately or from your CPU circuitry. I typically load the emulator with the CPU power off. Then after LoadIce is complete, I power up the CPU.

PREVIOUSNEXT


Circuit Cellar provides up-to-date information for engineers. Visit www.circuitcellar.com for more information and additional articles.
For subscription information, call (860) 875-2199, subscribe@circuitcellar.com or subscribe online. ©Circuit Cellar, the Magazine for Computer Applications. Posted with permission.