|
PART
3: Emulator to the App Test
by George
Martin
Start
• The Program • Real
Mode • Getting An App
Up and Running • Sources
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.
PREVIOUS
NEXT
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. |