Confusion over address spaces in yaAGC command-line debugger.

[GoogleCodeExporter]

Here are several related issues having to do with command-line debugging
and the different address spaces of the AGC CPU.  I'm not sure if they're
bugs so much as confusing points.

1.  It's not obvious how to select which address space is being used in
(for example) an 'x' command.  The help system does not describe how to
select different address spaces, as far as I can tell.

2.  The output of the 'x' command shows different data when I use addresses
which (in my mind) *may* be in different address spaces, but the addresses
it prints are always the same.

3.  Is there some way to use addresses as opposed to symbols with the
'print' command?

Original issue reported on code.google.com by rburkey2...@gmail.com on 5 Apr 2009 at 3:04

[GoogleCodeExporter]

For 1,2: I only have implemented the hex output for the w,h,b output formats.
Examples:
x/1bx 0x0 will print 1 byte for the data at address 0x0,
x/1hx 0x0 will print a word for the data at address 0x0,
x/1wx 0x0 will print a dword for the data at address 0x0

x/2hx 0x0 will print 2 words for the data at adress 0x0

I still need to implement the decimal and octal output format but will do this 
asap. 
Also the x command is a bit unstable. If you try x with no /FMT it will bail 
ungracefully (i.e. crash). I'll fix this asap also for most of the command you 
can 
look at the gdb manual as well because all the help details I still need to 
write.

For print you are correct I only have the symbol based support. I'll fix the 
address 
printing (for now use the more cumbersome x command). I'll have the print 
update 
asap and checked in next weekend.

Original comment by ohommes@gmail.com on 7 Apr 2009 at 9:09

• Changed state: Started
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Sorry, I guess I wasn't explicit enough.  The problem is not the output 
formats. 
Rather, it's the difference between erasable memory vs. fixed memory vs. i/o
channels.  I don't understand how to select addresses from these different 
spaces,
and I don't see how to tell the difference in the output from 'x'.

Original comment by rburkey2...@gmail.com on 7 Apr 2009 at 11:04

[GoogleCodeExporter]

I used the following approach to access these three memory regions:

For Eraseable and Fixed Memory use the x/1hx <address> approach where:
Eraseable Memory is <address>: 0x0000 to 0x07ff
Fixed Memory is <address>: 0x800 to 0x9fff

For details at the debug (agc) prompt type: info target
or look at http://code.google.com/p/virtualagc/wiki/LinearAddressing to see the 
summary of AGC to pseudo address mapping as explained in AGC4 Memo #9 1965 page 
5.

For I/O channels use: info channels
Yes it dumps the whole channel array but I was planning to limit it to the 
range 
that was used in Apollo. What do you think of this approach for the I/O 
channels?

Original comment by ohommes@gmail.com on 7 Apr 2009 at 3:02

[GoogleCodeExporter]

My point was that the 'help' command doesn't say any of this, so anyone trying 
to use
the debugger without having hit upon the "Linear Addressing" document won't 
know what
to do.  The 'help' command should either explain this, or else call out the 
document.

However, as far as the specific addressing scheme you mention is concerned, it 
does
not correspond to anything used in the assembly-language code, so it would be 
very
difficult for someone to relate these addresses to the addresses in actual 
assembly
listings.  Perhaps there should be a conversion command that allows you to 
convert
back and forth between these different types of addressing --- i.e., to enter a
number like 13,4000 as used in assembly language and to get back your linear 
address
or vice-versa.

As far as "info channels" is concerned, I have no particular problem with it.  
But
unless there is a uniform scheme for addressing all memory spaces (i/o channels
included) then the contents of the i/o channels cannot be modified at debugging 
time,
so there's no way (for example) to experiment with the outcome of placing 
different
values in the channels.  Nor would there be a way to set watchpoints on changes 
to
the i/o channels.  (The "classic" debugging mode didn't allow this either, as I 
found
out to my disappointment when I tried to use it yesterday to capture ACA input 
to the
CPU.  But very the fact that I tried to use it indicates that it's a needed 
feature.)

Original comment by rburkey2...@gmail.com on 7 Apr 2009 at 3:54

[GoogleCodeExporter]

What I can do is to allow in console mode to also have the original addressing 
capability available for anything that uses an address. For example the x, 
print and 
set all can use addresses so for the GUI debuggers they won't use this 
addressing 
technique but for console mode we can reintroduce the E01,1400

Examples:
x/1hx E01,1400
print E01,1400
set E01,1400=010

What do you think?

Original comment by ohommes@gmail.com on 7 Apr 2009 at 4:27

[GoogleCodeExporter]

To be correct you have to dereference the address for print or set commands so:
print *E01,1400
set *E01,1400=010

Original comment by ohommes@gmail.com on 7 Apr 2009 at 4:31

[GoogleCodeExporter]

That seems more useful to me.

Original comment by rburkey2...@gmail.com on 7 Apr 2009 at 4:46

[GoogleCodeExporter]

Build r104  has the capability to use addresses for print instead of just 
symbols.
All addresses can now be expressed in decimal, octal, hex or AGC banked format.

Example:
print *108
print *0x6c
print MPAC
print *0154
print *E0,0154

These commands above will all print the same result. Also try the x/1hx *0x6c 
and set
*E01,0154=5 followed by a print for verification.
The address mechanism works for both fixed as well as erase-able memory. I 
still want
to do some investigation what is normally done when debugging ports on a target 
that
aren't memory mapped (e.g. on Intel) and see what is used their to write values.

Still to be done is the detailed help for these commands before I close this 
issue. I
probably open a new issue just to deal with the I/O port value setting.

Original comment by ohommes@gmail.com on 13 Apr 2009 at 2:31