gnupic@linuxhacker.org

> 
> The .cod file has this information encoded in it. But you'd still have
> this problem if the memory you wish to view is modified by your program
> but not specified in your assembly file (e.g. suppose you want to use the
> whole upper half of the program memory to store data acquired from some
> measurement. You wouldn't necessarily define this area in your code.)
> 
> >
> > My first thought was to select memory in the object browser and have
> > a menu item to add it?
> 
> I think that would be the way. Essentially have a tab that allows the
> object browser select which mode to view the object code: either as
> disassembled source or as a 2D spreadsheet.
> 
> Some of the features:
> 
> 1) Highlight the active instruction (the one that the PC points too).
> 2) Show locations that have changed since the hex code was loaded in a
> different background color the original code (like a light gray instead of
> white).
> 3) Right click to bring up a menu that allows:
>    a) Set execution break point on the select location(s)
>    b) Set read break points
>    c) Set write break points
> 4) Allow the user to edit the program memory within either the sheet or
> the edit field at the top of the sheet (like the one that is in the
> register viewer)
> 5) As an alternative to entering raw opcodes also allow mnemonics to be
> entered.
> 6) Show the equivalent ascii in a column to the right of the program
> memory (like in the register window). Perhaps allow the ascii column to be
> decoded in one of two ways:
>   - show the ascii equivalent for just the lower 8 bits (this
>     would be useful for decoding retlw encoded strings)
>   - show the ascii equivalent of the two 7-bit numbers that
>     result when the 14-bit number is split in half. On the 18cxxx
>     family, we could make this two 8-bit numbers. It doesn't make
>     a whole lot of sense to do this on the 12-bit cores since the
>     program memory is not readable.
> 7) ???
> 
> Scott
> 


If you can go this far without to much trouble, perhaps it is becoming a
small step for gpsim to accept .asm files. i know there's more to
compiling than converting mnemonics to opcodes, but if you can do that..
well maybe there's a gpsim.0.19 w/ assembler.

as for the idea of entering instructions into program memory, sounds
very good.

Matt