User forums > Embedded development

Virtual AGC (Apollo Guidance Computer) debugging in C::B

(1/3) > >>

ohommes:
 All,

I have been working for sometime to extend the Virtual AGC to support a full GDB/MI interface (replacing a proprietary one). Now that most of the command-line interface for gdb is working for the AGC emulator I thought I'd send a notice to this forum letting you know you can now visually debug the original Code Colossus249 (Apollo Command Module) and Lumiary131 (Apollo Lunar Module) under Code:Blocks control and launch the external simulators from it. Active Interrupts will show as different active threads in C::B.

If interested visit http://virtualagc.googlecode.com and checkout the Wiki pages and in particular Visual debugging it has a small screen shot showing C::B debugging Colossus249 in an interrupt service routine. To work with the AGC and DSKY you need some extensive knowledge but I also provide some links to reference the original site where it all started which currently most of the background to get you off the ground. A working snapshot of the svn code base is needed to fully debug the original code. The download area only has a binary version of the emulator but doesn't have the original sources bundled with it.

Recently there was a post at slashdot discussion the oldest code still running. I guess the MIT Apollo program code maybe a candidate here since it is code from the mid 60's. Anyway if you are intrested  in Embedded development and enjoy playing and hacking around with the software of humans greatest adventure then checkout the site above. I have both Linux and Windows version of Code::Blocks 8.02 working with the AGC. It is really exciting to see 60's software in a 2008 IDE.

I wrote a document see yaScripts/CodeBlocks in the source tree explain how to integrate the YUL assembler and add the AGC syntax highlighting. So not only does C::B support C++ development it also supports AGC development using the YUL assembler.

Enjoy,


Onno Hommes

ohommes:
As part of the 40th anniversary of the Apollo 11 flight we changed our extension from ".s" to ".agc" and ".aea" to allow for proper syntax-highlighting on the googlecode servers. Immediately the sources became of category other and one can no longer single step through the assembler code.

Tried the following:
Updated the File extension handler to open the .agc and .aea with the Code blocks editor and updated the ASM Sources category for the project to also recognize *.agc and *.aea. However no matter what I do the files remain grayed out and the single step refuses to show the source location while stepping through the code in debug mode yet all windows update except for the editor window. SO the registers nicely change with every step so does the call stack correctly. However it seems unless the file has a .s extension you cannot single step. This is horrible since we are promoting this as our primary debugger for the virtual agc environment. Any thoughts on how to get the new extensions to not be grayed out and allow for single stepping? Every thing else including syntax highlighting and opening in the editor after updating the file extension handler section works. This all worked fine with the .s extension. HELP!!!!

stahta01:
Not an gdb guru; but it seems to be an gdb issue and not directly an Code::Blocks issue.

try finding where to can do the following.
set language asm
set extension-language .ext language

See web page
https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gdb/show.html

Tim S.

ohommes:
Just to give you more input. It is not the gdb, I am sure of this because the same debugger session works fine in KDbg or Emacs. The actual fullname frames as set with the --fullname flag are produced properly. What is striking to me is that eventhough I registered my new extension with the ASM Sources my source still remain grayed out in the project browser as if they are still considered other source files. registering a .s file shows a nice non-grayed filename in the project browser. So before even starting the debugger Code::Blocks behaves differently just based on the extension even if the extension is properly registered with: Syntax Highlighting, File Categories and File Extension Handler. To me this seems like Code::Blocks only "paints" the default extensions file names black and the non-standard always grayed-out and consequently refuses to use the editor for the single step update just because the extension is different. I am sure you can try this yourself with 8.02; Just register a file with extension .agc and one with .s and observe how the .s shows as a black font (I think indicating this is source) and the .agc as grayed-out (indicating "unknown what this is").

I guess I need to dive into the Code:Blocks project manager first to determine why the file appears grayed out even when the extension is registered with the types and categories setting.

Anyone else have any thoughts?

ohommes:
I think the issue is related to the hard coded types of CB. See associations.cpp. In this C++ file there is a array symbol knownTypes containing file extensions with their respective  description and icons. I believe this is used to determining the color and icon of the filename in the ProjectManager as well as the relation between the editor for debugging. I'll patch a binary to see if this assumption is correct.

Navigation

[0] Message Index

[#] Next page