EPOC Projects

Abstract

Everything you always wanted to ask about Matt's EPOC projects but were afraid to ask....
or
How To Get Side-Tracked

1 Introduction
2 Enter hForth
- 2.1 Mixed Language Programming for EPOC
- 2.2 GDB Remote Debug Stub
  - 2.2.1 Peeking Up EPOC's Skirt

1 Introduction

SIBO is dead; long live EPOC. I've finally started developing for EPOC, and have a major project, and lots of hurdles to overcome. This is a situation I found myself in when starting developing for SIBO: I hadn't got any development tools, since they were expensive at the time, and I was but a poor, penniless student. Things have changed somewhat: the basic EPOC C++ toolkit is freely downloadable, and I'm not a student any more. (Saying this, I have no "development budget" for these projects, so if it costs, it's not an option.)

So for SIBO, I decided to retarget an existing C compiler, thus giving me a development environment. This almost worked, but rewriting Psion's SIBO libraries was far too much work. So, i bought the SIBO C SDK, and started writing code. Lots of code. Some of it even worked, which was nice. However, time marched on, which it seems to do when you're busy hacking. The SIBO platform became less important, as Psion released the Series 5, and branched into Symbian.

It was around this time that I upgraded my computer, and "re-install the SIBO C SDK" slipped further and further down my list of things to do. I did it eventually, but never picked up the SIBO manuals again.

The projects that are still potentially active for SIBO are my port of hForth, an email client, and my work on plptools - the Psion Link Protocol implementation for UNIX/Linux, developed by Philip Proudman, Fritz Elfert et al.

Of these, plptools looks like the best chance of being kept alive - because there are lots of people using it, and development is on Linux, which is an excellent development environment. Writing code for SIBO in the MS-DOS environment is really, really horrible, when you're used to a proper system.

I obtained a second-hand, damaged Series 5 for testing my SIBO integration work for plptools. I can't use it as my main PDA since the screen is 1/4 damaged, but it has sparked my interest in EPOC at last.

I joined EPOC World, and downloaded the SDK. I installed Visual C++, and then realised that this was NT, and no, Microsoft's latest system is still no match for Linux. I downloaded several familiar tools for NT: bash, vim, etc., just so I could have some semblance of useability.

I just needed a project to work on.... there's a steep learning curve with EPOC, what could I do to circumvent that? ;-)

2 Enter hForth

hForth is an ANS-compliant implementation of the Forth programming language, and is ideal for programming PDAs with. Unfortunately, it is written in assembler, and there's no ARM-based debugging tools available with the C++ SDK. You normally write your applications in C++, build them for WINS, run them and debug them in the emulator, and then recompile for MARM.

So this presented two problems:

How could I debug my ARM code?
How does one program in assembler for EPOC?

The hForth for EPOC page is here.

2.1 Mixed Language Programming for EPOC

This was probably the easy problem to solve. Several experiments later, and we now have Mixed Language Programming for EPOC.

2.2 GDB Remote Debug Stub

All England Knows There's No Native Debugger... or is there? Poking about with ESHELL indicates that there might be, but Symbian are keeping schtumm about it.

Not deterred, I investigated, and discovered that GDB (the GNU debugger) had a remote debug facility. Reading the source of GDB (Ahhh, how refreshing.. how Heineken) indicated that it wouldn't be difficult to build a remote debug stub for EPOC... or would it?

Ben Williamson posted the source to an ARM stub on the linux-7110 list around the time I was having these thoughts, and with a little work, I had the necessary RS232 code working properly.

Then came the difficult bit: patching the exception vector table. Where was the exception handler? How could I, as a user space process, patch it? Where do the vectors point to?

Before I digress any further, the debug stub page is here.

2.2.1 Peeking Up EPOC's Skirt

I'd need to get very intimate with EPOC's exception handling before I attempted to change things so that exceptions transferred to the stub code. I needed to look through EPOC's memory, and disassemble things.

ArLo, the loader program for the Linux-7110 project came to the rescue - it has a logical device driver that allows client programs to examine physical memory (and boot a Linux kernel, but that's not important right now).

Its memory dumping facilities are a little basic, so I decided to extend it. You can find my results on the disasm page.

Great. Now I can look through parts of EPOC's memory, and disassemble away.... or can I?

Virtual address 0 (the start of the exception vector table) corresponds to physical location 2000. Lo and behold, there are the exception vectors. So, disassemble the routine found there.... except that you can't.

I *think*, but can't say for sure, that there's some clever MMU stuff going on here so that a user-space program can't see the OS.

I'll have to look at how system calls are made, to work out how to get any further. There's some stuff in the EPOC SDK header files that looks interesting w.r.t. debugging, and the MMU, but there's no documentation... or is there?

There is, but you have to be a member of EPOC World's Premium Developer programme, and that costs Ł250.