Mithris' Interview

 

Hooka: How long have you had a gp32?

 

Mithris: I think I got my GP32 early 2002.

 

Hooka: What caught your interest in the gp32?

 

Mithris: The GP32 seemed really powerful but still pretty simple to program, and I wanted to find a new fun platform to make demos for. I were never interested in emulators at all, my plan was to make some demos for it, and try to get some scene movement going.

 

Hooka: What dev environment do you use?

 

Mithris: About my dev environment, well I'm running linux ofcourse (gentoo), so I have to use GCC. I'm still using 3.2.2 because I'm too lazy to build 3.4. The IDE I'm using is Visual SlickEdit (www.slickedit.com) which probably is the best code editor ever. And ontop of that I use some small scripts and proggies I have slapped together to make the dev cycle faster.

 

Hooka: What prompted you to make gdb for the gp32?

 

Mithris: Well, the GDB-stub. I got the idea for that when i purchased the Xport for GBA, i thought that a GDB-stub could probably be very useful for GP32 aswell, and easier to implement since the applicaion does not reside in ROM. But at the time ppl also tried to get JTAG debugging going, but it turned out to be too slow for any useful debugging. (atleast without a very expensive JTAG-probe).

So I figured I could implement a GDB-stub for the GP32 instead.

 

Hooka: Could you explain what the gdb is for? (maybe part of above question, I dunno)

 

Mithris: GDB (Gnu DeBugger or smth) is something very useful. It's kind of hard to explain if you don't have any experience of debugging at all. But something like this, you start your program on the GP32, and it runs for a while, and then crashes. Instead of just resetting you can connect GDB to your GP32 and find out exactly on which C/C++ line the program crashed, you can look at the variables and see which values they were holding at the time of the crash. And after a crash, it's not much else you can do. In the latest version of the stub (only UART) you can stop the program anytime just by connecting GDB (via UART). You can examine where the program stopped and more interresting, add breakpoints. A breakpoint is a line somewhere in the program where you want it to stop when it's reached. After setting one or more breakpoints you can let the program continue executing, until it reaches a breakpoint or you press CTRL-C. At a breakpoint you can ofcourse examine the values of variables, change the value of them and add or remove breakpoints. You can also step the program, let it execute line by line or assembler instruction by assembler instruction. Or just continue executing until the program stops again. Thats a short probably bad explanation of how to use a debugger, but hopefully you get the point.

 

Hooka: What do the profiler and map parser do?

 

Mithris: Well, it's really really simple actually, the "profiler" is just a small lib that sets up a timer interrupt to trigger a couple of houndred times a sec. The timer interrupt finds out where in the code the program counter were before the interrupt occured and stores in an array. The map parser can then use that array to match those values with functions, so in the end, it can tell you pretty accurate in which function the program counter was most of the time. And when you know that, it's pretty easy to know what to optimize.

 

The program counter is a pointer to the assembler instruction currently is executed.

 

Hooka: GPRally looks really nice when do you expect a release(don't have to answer if you don't want to)?

 

Mithris: A release..well probably never, atleast not a complete game. I might release some previews now and then but making a complete game is something completely different. In the end, I might release my exporting tools and some plugins for creating levels or smth.

Hooka: What is the progress on GPRally?

 

Mithris: Slow progress as always, the switch from the semi-voxel engine to the poly based engine took some time but it was also much fun to work with collision detection with polymeshes etc.

Right now i'm working on some plugins for a certain modeller to make it easier to add custom attributes for objects etc.

 

Hooka: What other projects do you have planned or just cooking up in the back of your mind?

 

Mithris: Other projects, well, not that many really, I've been working a little on a threading lib for the GP32. It's pretty much done, just haven't bothered releasing anything. And some uart tools, dunno if i ever finish them. And then the USB Host stuff, got some code running, it doesn't work however, and ppl knowing more about USB stuff are working on it now.

 

Hooka: How do you feel about Mr. Spiv incorporated your gdb-stub into his multifirmware?

 

Mithris: That is great, i have been writing a special version of the stub just for that, spiv and i have been discussing it for a while, so hopefully mfw3 will have the gdb-stub built in, and we'll also release some crt0.s to do proper initialization of it. However, i have not decided if it should be a dual stub (USB and UART), since that would require some more work.

 

If you want to check out Mithris' Webpage it's right here

 

Thanks for your time, I'd just like to say even though it's unfinished, I really like your rally engine, especially how when you drive off the edge your vehicle actually barrel rolls until it crashes it's neat to see an advanced looking 3d rally game on gp32, here's hoping you finish it soon!

 

TJ Hooka

 

*Interview finished 04/03/04*