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?

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.

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'.

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

For Eraseable and Fixed Memory use the x/1hx approach where: Eraseable Memory is : 0x0000 to 0x07ff Fixed Memory is : 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?

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.)

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?

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

That seems more useful to me.

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.