MEM11 Update

Guy Sotomayor ggs at shiresoft.com
Mon Jul 20 16:04:01 CDT 2015


As I mentioned previously, I took some time off from working on the 
MEM11 for the past several months.
I had some time over the past few days, so I spent it working on the 
simulator.

Right now all of the J1 instructions seem to simulate properly. 
Everything related to the basic simulator
also seems to be functional.  I still have work to do to write code for 
the simulated I/O (it's all stubbed
out at the moment).  The way that I'm implementing the I/O, is that it's 
pretty modular.  All of the
fundamental code structures are there, I just have to write the 
"handlers" for the particular I/O devices.

I wrote the majority of the J1 simulator to be H/W agnostic (as far as 
the I/O is concerned), the I/O
at this point will match what I expect to be in the actual MEM11 H/W.

Here's what the simulator currently supports:
   - All command functionality is present and functional.  These are the 
way that one interacts with
     the simulator.  The commands include things like:
        - loading files into J1 memory or FRAM
        - dumping memory locations from J1 memory or FRAM
        - modifying memory locations in J1 memory or FRAM
        - setting, listing and clearing breakpoints
        - starting execution
        - single stepping execution
        - dumping the data & return stacks
        - starting and stopping instruction tracing
    - All of the J1 instructions now seem to execute correctly (lots of 
typo's and other subtle bugs)
    - Exceptions work now.  This allows the J1 program to do something 
"silly" and the simulator
       won't crash (had enough of that already while I was debugging the 
simulator!).
       It'll report what the J1 program did that was "silly" (ie 
unaligned memory accesses, etc).
    - It also contains a reasonable "help" system.

I've written an instruction test program that tests out all of the J1 
instructions and it is "self checking".
That is, it will throw an exception (unaligned address) if the result of 
the instruction test isn't what
was expected.  To determine what failed, I look at the address where the 
exception occurred and
reference the test program listing to determine which test failed. I 
verified that it is indeed operating
correctly by hand checking via the instruction trace file that it was 
doing the "right things".

I had originally started debugging by single stepping through the 
program but after the test program
grew to over a few dozen instructions, it became too tedious for me to 
ensure that I was accurately
verifying the instruction execution.  This is where the instruction 
trace file became invaluable.

The next thing to do is to work on the simulated I/O.  Once I'm 
confident that all of that is working
then I can go about debugging all of the code I've already written for 
the MEM11 itself.  The simulator
should give me a pretty good environment for debugging, especially when 
compared to the actual HW.

Oh, and of course everything (simulator, MEM11 firmware and tools for 
the  build environment) are all
written in forth.  ;-)

TTFN - Guy


More information about the cctech mailing list