MEM11 Update

[Guy Sotomayor]

Made a lot of progress today.

I just wrote a "hello world" program and got it working so the UART 
output shows up on the simulator.
Took a bit more work as there were a couple of subtle bugs lurking in 
paths I hadn't fully exercised
previously (it's the nature of things).  It was more complicated by the 
fact that this is the first time that
the "timekeeping" code has been executed (when a character is sent over 
the simulated UART, a timer
is set in the simulator that determines when to clear the transmit busy 
flag).  That code had a few issues
but it's all working well now.

The way that the timekeeping code works is that time advances only as 
each instruction is executed.
Therefor, you don't have to worry about time dependent code behaving 
poorly when instruction execution
has halted (such as hitting a breakpoint).

I also updated the code that generates the assembler listing so that the 
ALU instructions are fully
decoded.  Makes it much easier to figure out what's going on when I'm 
debugging the J1 code.  The simple
forth programs I was using prior to the "hello world" program didn't 
present too much of a problem but
as the programs are becoming more complex, having a "reasonable" listing 
makes a world of difference.

I also added the capability to "break" into a running program by 
entering a ^D on the keyboard.  Not
sure if I'll keep it as ^D or not but for now it allows me to interrupt 
the execution of the J1 program.
It's useful when the code is looping and not hitting any of the set 
breakpoints.  ;-)

I have a few more things to try out with the UART (like character input) 
before I move on to testing out
the simulated FRAM.

TTFN - Guy

On 7/20/15 2:04 PM, Guy Sotomayor wrote:
> 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