Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!snorkelwacker!bu-cs!encore!pinocchio.encore.com
From: devoz@pinocchio.encore.com (Joe DeVincentis,EFD TR 75S TR 4S TL 1S TL,2622,7568004)
Newsgroups: comp.sys.m88k
Subject: Re: M88K simulator from Motorola
Message-ID: <10352@encore.Encore.COM>
Date: 14 Nov 89 14:09:53 GMT
References: <5321@orca.WV.TEK.COM>
Sender: news@Encore.COM
Distribution: usa
Lines: 59

From article <5321@orca.WV.TEK.COM>, by andrew@frip.WV.TEK.COM (Andrew Klossner):
> We used Moto's 88k simulator for awhile, but ended up abandoning it and
> writing our own so as to get good execution speed.  It runs 88k code at
> about 0.2 MIPS on a 20MHz 68020-based system.
>   -=- Andrew Klossner   (uunet!tektronix!frip.WV.TEK!andrew)    [UUCP]

We run the simulator on a system that has 6 "8.5" mip NS32532 chips.  I
haven't found the speed to be a big issue.  It also doesn't require a
68020.  It does like big endian though :-(.

I particularly like the preset capability, which is essentially running
simulator commands from a file at startup.  I have multiple CPUS to control,
and they play certain roles based on CSR values at startup.  With this
simulator, I can run a single CPU through the code, modify registers, memory,
the IP, and test the actual code without conditional compilation...  all
from a "command" file!

Here is a sample of the command file

[lots of memory mapping statements deleted]
md ip; di		; display 4 instructions from the current ip
br init_checksum_label	; set a break point
g			; go
md ip; di		; display 4 instrucs at breakpoint
br uart_test		; set another break
sym stack_setup		; show address of symbol "stack_setup"
rm ip stack_setup .	; modify the IP to this address
md ip; di		; display 4 more instrucs, (I like to see whats happ)
g			; go
rm ip ram_address_test . ; get up to the current test code
md ip; di		; show instrucs
br ram_address_ok	; set break on completion
br data_address_failure	; or failure
g			; go

So, you see from this example, that I can control the flow of the code
to test what I want with very little effort, NO recompilation, and I
don't have to sit through a couple of minutes of memory scan tests,
or rom checksum tests, (things we do in our startup of the diags)....

With the code developed for multiple CPUS, I bring the board up to certain
points, then force values into registers which makes it look like the other
CPUS are actually doing what they should be, testing multiple CPU software
before we have the multiple CPUS around.

Neat stuff.  Makes my job more fun too.  Moto would have to make some
changes to their simulator to let everyone do this.  The rm (register modify)
command, and I assume the memory modify command , read input from the stdin,
so I had to hack code in to check the number of arguments for the current
command.  If there are a complete set of args, I use the args as opposed to
reading stdin.

Anyway, said more than I want to.  I am working on a list of things that
I had to do (other than what we did for endian changes, as thats another
story), to make the simulator more useful for the Moto simulator
person(s).

Joe DeVincentis
devoz@whateverthemailheadersays.com