eramirem / virtualagc Goto Github PK

To allow a developer to use both linear pseudo addressing and banked
addressing it would be nice to have a debug function to convert address
values between the two formats.

To enhance the command line debugging experience the display command should
be supported. This will enable printing of registers and variables and will
allow for a configuration similar to the original proprietary debug
interface that printed the register values.

It would be nice to have the command line option --directory=DIR for yaAGC
to allow the sources to be located in a different place. This will allow
the original sources to be managed in a user specified way and still enable
debugging with the sources.

After this change, the yaCode contained directories can be packaged and
released separately from the binary build (e.g.
virtualagc-luminary-131-20090301.tar.bz2)

Currently the yaAGC does not work yet for the Eclipse development
environment. It would be nice to be able to edit and debug the AGC code in
Eclipse.

Although the --core switch is also used by gdb usually one would pass the
core (i.e. resume image just as the second argument) For that reason we
should stick with the --core to pass the agc ropes-images and use this as a
detection to determine that the agc is to be started in classic run mode
and not debug as is desired in gdb compatibility.

Add to the Code::Blocks syntax high lighting with the capability to color
the AEA instructions,etc.

Currently the code supports both the R. Burkey proprietary debuggin
capabilities and the GDB/MI capabilities. To improve readability and future
maintenance it would be nice to only support GDB/MI. In addition some code
can be re-factored so that main does not play such a big role in the
debugging part.

What steps will reproduce the problem?
1. Call the function:
int res = agc_engine_init(&state, "filethatdoesnotexist", NULL, 0);

2. res should be 1, according to:
http://www.ibiblio.org/apollo/developer.html#AGC_CPU-Engine_API

3. BUT: res is equal 0 (value is overwritten in agc_engine_init.c:210  (see 
also line 193 for ROM-file-load assignment)

What version of the product are you using? On what operating system?
Last change in header: 03/30/09 RSB Added the Downlink variable to the core 
dumps.

yaAGC-dev-20100220.tar.bz2
(same as subversion rev 609)

Also found in:
https://code.google.com/p/virtualagc/source/browse/trunk/yaAGC/agc_engine_init.c

Use label name instead of file name for the function name. This means that
when creating the "stack" frame that the name of the frame is not the file
name is is currently the case.

So instead of:

#0 0x1234 filename () ...

you will get

#0 0x1234 LABEL ()...

This will provide better insight into the code.

When running yaAGC in debug mode and giving it debugging commands from the
command line, if you backspace over the command (say, to correct typing
errors) it allows you to backspace over the prompt as well, so that the
prompt disappears.  This happened for me using the svn source from
20090404, on Ubuntu 8.04 64-bit.

Add a Wiki to instruct users on hoe to use the Code::Blocks IDE for
development and debugging to step through code and how to examine data.

What steps will reproduce the problem?

1. Start VirtualAGC.app (prebuilt binary) on Mac OS X Lion
2. Attempt to run any simulation
3. Applications will start (e.g. yaDSKY2, yaAGC, yaTelemetry), however, nothing 
actually connects to yaAGC

What is the expected output? What do you see instead?

I expect that the DSKY will initialize to P00 and to see telemetry data.  The 
DSKY remains blank, no verb/noun commands are recognized, and no telemetry is 
received.  I performed an 'lsof' on yaAGC and port 19797 does not appear to be 
open.  I turned off the Mac OS firewall with no change in results.  I also 
attempted to start the application as root (sudo open VirtualAGC.app), same 
results.  I disabled IPv6 just in case that was a potential cause, no change.

What version of the product are you using? On what operating system?

ActiveTCL 8.5, prebuilt VirtualAGC binary from the Virtual AGC Download page, 
Mac OS X 10.7 Lion.

Please provide any additional information below.

I'm not sure why the application will not open (or is not allowed to open) 
these ports.  They are above 1024 so there shouldn't be an issue.

Allow people to experiment on Windows with the AGC without setting up a
full MingGW development environment; create an install package for Windows.

http://code.google.com/p/virtualagc/source/browse/trunk/Luminary099/LUNAR_LANDIN
G_GUIDANCE_EQUATIONS.s?r=258#1243

says "USING NETON'S METHOD"

That looked wrong, but code of this era is notable for specialized
shortcuts, so I looked for the source images - based on the comments, image
822:
http://www.ibiblio.org/apollo/ScansForConversion/Luminary099/0822.jpg

says "USING NEWTON'S METHOD" (line R1064.)

Since the AGC emulator supports running 10 interrupts it can while
preapting the main thread of execution show the interrupt execution as a
separate thread. It would also be nice to signify which interrupt execution
is running using symbolic names for example in the info part of the thread
data to show if it is the timer4 , keyboard1 interrupt etc. The thread id's
can match the internal interrupt id.  

Add the disassemble command and its alias disas. Support the default no arg
support, the single argument and the range dump support.

Example:

(agc) disas                                  
Dump of assembler code from 0x25f9 to 0x2602:
0x25f9 <STARTSUB+2>:    CA      4672         
0x25fa <STARTSUB+3>:    TS      0026         
0x25fb <STARTSUB+4>:    AD      7715         
0x25fc <STARTSUB+5>:    TS      0027         
0x25fd <STARTSUB+6>:    AD      7716         
0x25fe <STARTSUB+7>:    TS      0030         
0x25ff <STARTSB2+0>:    CA      3163         
0x2600 <STARTSB2+1>:    EXTEND               
0x2601 <STARTSB2+2>:    WAND    011          
End of assembler dump.                       

Experimenting with AGC API I've bumped into a strange phenomenon. Running the 
agc_engine() step by step, and printing the registers before calling the 
function, I got the following result:
PendDelay:0 A:0 L:0 Z: 4000 BB:0
PendDelay:0 A:0 L:0 Z: 4001 BB:0
PendDelay:1 A:0 L:0 Z: 4001 BB:0
PendDelay:0 A:0 L:0 Z: 4001 BB:0
PendDelay:0 A:12063 L:0 Z: 4002 BB:0
PendDelay:1 A:12063 L:0 Z: 4002 BB:0
PendDelay:0 A:12063 L:0 Z: 4002 BB:0
PendDelay:0 A:0 L:0 Z: 4003 BB:12003
PendDelay:0 A:0 L:0 Z: 2563 BB:12003

The ROM image was Artemis072, so the instructions are the following:

INHINT                                         
CAF      GOBB                                  
XCH      BBANK 
TCF      GOPROG
...

The INHINT and TCF consumes 1 machine cycle correctly, but the XCH and CAF 
consumes 3 machine cycles which contradicts to the language manual. It says 
that both of these two instructions needs 2 MCT to finish. I changed line 
agc_engince.c:1891   
    State->PendDelay = i; 
to
    State->PendDelay = i-1;
with the intention to decrease the machine cycle by 1 for every multi-MCT 
instuctions. This modification doesn't have any bad effect on the scheduled 
processes, I checked V16N36 and it worked correctly.

Enable confirmation support to get confirmation requests for example when
exiting while debugging or when run is used again while already in a run
state. 

Since the gdb commands where and bt and backtrace are already supported you
may as well add the info stack alias to the same implementation.

1. Start Virtual AGC in debug mode:
yaAGC --core=Colossus249.bin --cfg=CM.ini --debug
2. Try to examine register A with command "x A". The yaAGC immediately quits 
with segmentation fault. "x 0" or "x L" or "x 1" also result in segfault.

I've built my yaAGC from source yaAGC-dev-20100220.tar.bz2, op.system is 
Debian/Lenny

Seem to me the reason for this behaviour is an unhandled nullification of a 
string variable at agc_gdbmi.c:1709  
   if ((s = strstr(s,"/")))
which ends up in a segmentation fault at agc_gdbmi.c:1716, where the variable 
"s" is referred.

To replace the classic sym-dump function add the gdb commands:
info variables
info functions

and additionally info constants to be able to replace the sym-dump command.
Each of these new commands shall support the REGEXP based filtering to
reduce the output result.

The equivalent of the classic "files" command in gdb is the "info sources"
command. Normally the gdb command does not support pattern matching like
"files" does however since the feature exists in the classic interface the
info sources should be extended with this same capability; This means that
a command like: "info sources time" will return all the sources for which
symbols are read that have "time" in their file name.

This task is intended to initiate the merge of the new elements added by Ron
(20090415) into the SVN build to get a common source tree.

Update the SVN sources with the changes made by RSB and released on 
20090331. Since this source tree started with the 20070422 release the 
differences of these two releases shall be used to update yaAGC and yaAGS. 
Ron will take care of yaDSKY and the other GUI code with his new wxWidget 
implementation.

I made this issue of type defect because the new 2009 release has some bug 
fixes.

(Re)introduce the display of the next source line to be executed when 
stepping through code (just like gdb) when not using --fullname. The current 
implementation shows the actual assembly without labels even. So in the 
default mode it feels a little you are debugging without symbols but you are 
not it is just the display of the inner stack frame is awkward and not gdb 
style.

What steps will reproduce the problem?

1. Download file VirtualAGC-setup.exe
2. Run VirtualAGC-setup.exe


What is the expected output? What do you see instead?
Please find attached image.

What version of the product are you using? On what operating system?
The latest, I'm hope. Operation system: Windows Vista

Please provide any additional information below.

Add support for gdb command line options will allow for better integration 
with 3rd party debug GUI's.

launching the emulator could take a binary directly as the default input 
instead of using the --core option in the current version.

It should be possible to launch the tool like:

yaAGC Colossu249.bin

to start debugging. And use an option like --nodebug to launch just the 
simulation without debugging.

Hello, I'm zxMarce, and I have a problem I think you may help me overcome.
I installed VirtualAGC version 20100220 under GNU Ubuntu Linux 12.04.1 in my 
home folder. I made two installs on two different machines, one is a physical 
laptop (2GB RAM), the other is a VirtualBox virtual machine (768MB RAM).

Both GUIs fail with the same symptoms: No matter the modules/modes chosen, when 
the Run button is clicked, the selected support modules (DSKY, Status, 
Telemetry, etc) start up and appear for 3-5 seconds and then everything shuts 
down and I get the main Virtual AGC screen back to select other emulation 
parameters.

When resorting to the terminal, it seems yaAGC has a problem. In order to see 
if the Luminary binaries are to be blamed I tried running with both binaries 
supplied (099 and 131) and even a fake, non-existing version 999 (not even the 
directory for Luminary 999 exists in my environment).

I get the following "Floating point exception (core dumped)", on all three 
Luminary versions I tried (virtual machine tests shown, physical laptop throws 
the same exceptions):

user@vmachine:~/VirtualAGC/Resources$ ../bin/yaAGC 
--core="source/Luminary131/Luminary131.bin" --port=19797 --cfg=LM.ini
Apollo Guidance Computer simulation, ver. 20100220, built Feb 20 2010 11:03:52
Copyright (C) 2003-2009 Ronald S. Burkey, Onno Hommes.
yaAGC is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Refer to http://www.ibiblio.org/apollo/index.html for additional information.
Floating point exception (core dumped)

user@vmachine:~/VirtualAGC/Resources$ ../bin/yaAGC 
--core="source/Luminary099/Luminary099.bin" --port=19797 --cfg=LM.ini
Apollo Guidance Computer simulation, ver. 20100220, built Feb 20 2010 11:03:52
Copyright (C) 2003-2009 Ronald S. Burkey, Onno Hommes.
yaAGC is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Refer to http://www.ibiblio.org/apollo/index.html for additional information.
Floating point exception (core dumped)

user@vmachine:~/VirtualAGC/Resources$ ../bin/yaAGC 
--core="source/Luminary999/Luminary999.bin" --port=19797 --cfg=LM.ini
Apollo Guidance Computer simulation, ver. 20100220, built Feb 20 2010 11:03:52
Copyright (C) 2003-2009 Ronald S. Burkey, Onno Hommes.
yaAGC is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Refer to http://www.ibiblio.org/apollo/index.html for additional information.
Floating point exception (core dumped)

The command line for yaAGC was shamelessly "borrowed" from the 'simulate' 
script in 'VirtualAGC/Resources'.
If you need anything else besides the above supplied data, please don't 
hesitate to ask me. I think this is a great program.

TIA,
zxMarce.

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?