ASM Programming with HP50g

[3298]

Oh, dear ... Windows only? You see, I've become a happy Linux-only person a few years ago, sooo... well, I won't tell you to switch, but things that I find natural, like working out of a terminal, compiling software on my own, viewing man-pages, etc., might be foreign concepts to you. Conversely, I'm not quite up to date on Windows stuff. I'll do my best to tell you how you can get started regardless.

Full disclosure: I've made some contributions to x49gp, so I may be a bit biased. However, as far as I can tell it would be the best tool available for your explorations - based on a quick search, this "ARMu" you mentioned seems to be a generic ARM tool without 50g-specific pieces like display and keyboard, so it would probably only get you so far. By all means, try it anyway - though since I don't know anything about it, I wouldn't be able to help you much with that tool. With x49gp, on the other hand, I have enough knowledge to troubleshoot and probably fix issues if any come up.

I suspect you are a little scared by the prospect of switching your entire operating system (who wouldn't be!), but that's not actually necessary. (I did try to make x49gp run on Windows once, but I was only able to confirm that it doesn't even compile in MinGW, and in Cygwin it compiles fine but crashes on startup somewhere deep inside the QEmu code that does the actual ARM emulation for x49gp. I just gave up after that.) Let's get you a virtual Linux environment inside your Windows instead. WSL2 supposedly has a beta with experimental support for graphical applications, but a full VM is probably your best bet right now. You'll need software to host the VM (Microsoft Virtual PC, Oracle VirtualBox, ... whatever floats your boat), and a Linux distro. I tend to recommend Ubuntu for newcomers: stable and well-supported by software devs, very user-friendly, and because it is so popular, there are plenty of answered questions out there in case of trouble. The exact steps to set this all up depend on your choices - but if you are experienced enough with a computer to try dealing with ASM, you should be able to find your way through.

Once you have your Linux desktop up and running, you'll want to open a terminal. Several of the following steps can be done with graphical applications too, but how these applications work can be very different, and a handful of steps require the terminal anyway, so let's keep it simple and do everything in it.
First, you'll need to install a few pieces of software so you can compile x49gp. Many Linux distros already have them installed, but there are some which don't, so let's just make sure they are there. The command to install a package on Ubuntu is 'sudo apt-get install name-of-the-software', and the programs we need are: git, make, gcc. The "sudo" at the start of the line means "do this with system administrator privileges", and it will accordingly ask you to type the system administrator password - that's perfectly normal, it should be the password of the user you set up during installation of the Linux distro.

Then, let's get x49gp and compile it. Right now, Claudio's repository on GitHub is the one with all the bells and whistles, so issue the command "git clone https://github.com/claudiobsd/x49gp/", then change into the directory created by that operation with "cd x49gp", and finally tell the computer to compile it all with "make". It'll take a moment ... and then you have a fully operational copy of x49gp at your fingertips. You can either just run it from that directory, or you can install it system-wide with "sudo make install". If you choose the latter, you'll be able to refer to it as "x49gp" from anywhere; if you choose the former, you'll always have to specify the path to it (even if it's the same directory you're already in). Be careful - in Linux the path separator is a forward slash, not a backward slash as in Windows (though I think Windows can now deal with forward slashes too), so the command to run it from the current directory would be "./x49gp". I recommend installing it - that also gives you a shortcut in your application menu, and a man-page which you'll be able to view with "man x49gp" (written by yours truly, by the way). Reading that might be a good idea, actually, because then you'll better understand the debug options you'll use in a moment. It also gives some information about where x49gp's persistent data ends up, which may be useful to you - it includes binary images of RAM and flash memory, for instance.

The parameter to launch x49gp in debug mode is "-d", which makes the full command "x49gp -d". However, it'll appear to get stuck, because it's waiting for a connection from the debugger. Also, once the debugger is hooked up to it and tells x49gp to execute an instruction, it'll continue wherever it was stopped during its last run. That won't be a problem the first time because it'll prompt you to select a firmware and then boot up from 0, but on subsequent runs you would be ... probably somewhere inside the Saturn emulator embedded in the stock firmware. You can force it to reboot by adding the "-r" parameter to the command line, though.

With x49gp waiting for a connection, let's run the debugger in a second terminal. Oh wait, it's not installed yet. Well, that's easy to fix, "sudo apt-get install binutils-arm-none-eabi". Once installed, run "arm-none-eabi-gdb". Normally you would pass the name of a program as parameter, and the debugger would read debug info from it, but for this case we don't have access to such luxury.
GDB will offer its own command prompt, allowing you to control what happens with program execution. The first command we need here is "target remote :1234". You can also insert "localhost" before the colon, but that's implicit. What this causes GDB to do is to connect to TCP port 1234 (which is x49gp's default debugging port) and route all program-controlling requests through that connection. And yes, this is real TCP - x49gp and GDB could run on different computers, though that's usually not so useful. There might be a case for using this mechanism to run GDB outside your Linux VM, but getting the ARM version of it for Windows is probably more trouble than it's worth. You might be tempted to do so if you could then hook it up to Eclipse ... but like any IDE that one is made for debugging a program whose source is loaded in it, not for poking around unknown code. Let's not bother with that then.

Okay, you now have x49gp paused at the start of its boot sequence, and GDB connected to it. Now you can start investigating whatever you want. The most useful commands for that would be:
- "stepi" executes a single instruction. There is a variant without the "i" at the end, but that tries to run a whole line of source code ... which needs the debug info we don't have. Like many commands, this one has an abbreviation: "si".
- "nexti" is similar, but if the instruction is a subroutine call, it'll step over it, i.e. run until the subroutine finishes. Abbreviated as "ni", and it also has a useless-to-us whole-line-of-source variant without the "i" at the end.
- "info registers" shows you all the processor registers. Can be abbreviated as "i r".
- "print expression" calculates an expression and shows the result. The syntax for the expression is very C-like with typecasting, pointer arithmetic etc. For instance, you could write "print *((int *) $r0)" to have the register r0 interpreted as a pointer to integers, and have GDB tell you the value of the integer it points to. You'll also notice that the result is given back with "$number = " in front of it - that's a hint that you can reference these results with the corresponding number and a dollar sign in front of it in subsequent expressions. The "print" command can also be abbreviated as "p".
- "disassemble start, end" disassembles a portion of code between two addresses. Abbreviate as "disas".
- "break address" sets a breakpoint. Abbreviate as "b".
- "continue" runs until it hits a breakpoint. Abbreviate as "c". If you don't have a breakpoint, it'll just keep running, which in our case means you'll soon end up inside the Saturn emulator. Hitting Ctrl-C while it's running will also interrupt execution, but you likely can't do that fast enough to correct mistakes.
- When you're done, "quit" will terminate GDB. x49gp will automatically run on its own after that, but if you queue up a Ctrl-C in its terminal before exiting GDB, it's going to terminate too. Otherwise, x49gp can be closed from the menu which appears on a right-click on the emulated display, but x49gp's simplistic single-threaded design keeps the UI from responding to the right-click while it's waiting on GDB commands.
For the rest, I'll just refer to the "help" command, which tells you what's up.

There you go, from zero to ASM debugging with x49gp. Feel free to keep asking questions, there are enough knowledgeable people around here to help you out.