PsionOrganiser ROM Disassembly

[amenjet]

Does anyone know of a disassembled ROM listing? Having this would be interesting and probably very useful. I'm just wondering if the original source files were ever released, or could be.
If not then maybe I'll start the work. Which ROM would be the best?

Andrew

[amenjet]

OK, I have started this work by adding (slightly unfinished and so limited) support for the 6303 processor to the NSA's Ghidra reverse engineering tool. Yes, that's the National Security Agency in the US, if you weren't aware of this tool. It has been open sourced and is a really powerful tool. It takes a bit of learning but has some very nice features. One of which is the specification of the processor architectures that it supports in a special language. to add support for a new processor you specify the architecture in that language, drop it in to the Ghidra directory structure and run the tool. You then have all the powerful features of the tool, but can now disassemble your processor.

Disassembly
==========

Ghidra is a powerful disassembler. You can annotate the code and adjust variables etc., just as you would expect. The output should assemble on an assembler (I haven't tried my Tcl macro assembler yet, but will sometime).

Decompilation
=============

One of the very very powerful features of Ghidra is that it can provide a decompilation of your code. So, instead of outputting assembly language like a disassember does, it provides a C code version of the code. This is very powerful. For example, here's some disassembled Psion data from the ROM:

Code: Select all

 LAB_d84b                                        XREF[1]:     800f  
            d84b 4f              CLRA
            d84c 97 16           STA        <0x16
            d84e 4a              DECA
            d84f 97 8c           STA        <0x8c
            d851 c6 12           LDB        #0x12
            d853 ce 23 f1        LDX        #0x23f1
            d856 7e 87 b8        JMP        DAT_87b8

and here's the decompiled version, in C:

Code: Select all

/* WARNING: Control flow encountered bad instruction data */

void UndefinedFunction_d84b(void)

{
  byte in_DP;
  
  *(undefined *)((ushort)in_DP * 0x100 + 0x16) = 0;
  *(undefined *)((ushort)in_DP * 0x100 + 0x8c) = 0xff;
                    /* WARNING: Bad instruction - Truncating control flow here */
  halt_baddata();
}

As you can see it has encountered an error and failed to decompile part of the code. But it has successfully decompiled the first few instructions. I'm not sure why there is an error here, I've left it in the example to make it clear that this is all quite new and I may have made mistakes in the 6303 support with regards to the decompilation aspect. Hopefully this can all get fixed, as it opens up the possibility of decompiling the organiser ROMs, then recompiling the resulting C code using the Pico compiler (targeting ARM and the RP Pico). That code could then run on the recreation of the organiser and should result in Organiser functionality running at native Pico speed (125MHz). That should give you a pretty fast organiser.

Here's another example:

Code: Select all

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             undefined FUN_cfe2()
             undefined         A:1            <RETURN>
                             FUN_cfe2                                        XREF[1]:     cfca(c)  
            cfe2 96 64           LDA        <0x64
            cfe4 27 08           BEQ        LAB_cfee
                             LAB_cfe6                                        XREF[1]:     cfec(j)  
            cfe6 e6 00           LDB        0x0,X
            cfe8 cb 03           ADDB       #0x3
            cfea 3a              ABX
            cfeb 4a              DECA
            cfec 26 f8           BNE        LAB_cfe6
                             LAB_cfee                                        XREF[2]:     cfe4(j), cff1(j)  
            cfee 39              RTS

and the decompiled C code:

Code: Select all

void FUN_cfe2(void)

{
  char cVar1;
  byte in_DP;
  
  for (cVar1 = *(char *)((ushort)in_DP * 0x100 + 100); cVar1 != '\0'; cVar1 = cVar1 + -1) {
  }
  return;
}

You can see that this decompilation is much more impressive. To get these disasemblies and decompilations was a few clicks of the mouse...

As well as very possibly being able to retarget the Organiser ROM code to an ARM processor, having a decompilation is a great help to code comprehension as you can see in the second example.

============================================
Here's my repository with the 6303 support and the ROM project:

https://github.com/blackjetrock/ghidra-6303

Feel free to work on this...

Andrew

[Lostgallifreyan]

That's likely to be very useful, but I think the end target notion won't work as an ideal end.

The big thing about the Psion Organiser II is ruthless efficiency with electrical energy, combined with just how much it can do with so little. This is why it ended up on battleships and aircraft carriers and up the Amazon and in other places where heavier and more powerful systems were less useful.

There are probably many ARM CPU's, so I don't know which you have in mind as eventual basis for production of hardware, so my first thought was of OPL and Psion machine code running on a quad-core 64-bit 1.4 GHz Raspberry Pi 4B board. My mind boggled for several minutes before I thought through the implications. It's an awesome thought, but it would be very counterproductive, beyond maybe getting some big-time high profile awareness that the old system even exists.

Making the system portable on as many emulators as possible might be a better outcome, but that too won't be an end game.

The thing that I think would make by far the greatest distance is to aim for a device that is as easy to use, as light in weight, at least as durable, and without taking a MILLIWATT more power if at all possible, to see just how fast and far current CPU's can take it with the best variant of the original operating system. What the world really NEEDS right now is an astounding display of how much can be done with an extreme reduction in energy used. Something so effective it might even make the likes of NASA sit up and take notice.

Other than that I'd not want to change a thing, except to add at least one extra storage slot (not least because the ROM must always be reachable for services and OPL support code), and a backlit LCD that uses the existing 4-wire addressing method, and maybe a DIV instruction for whatever CPU gets used. :) If there is one already, I missed it when I looked recently.

[Lostgallifreyan]

Ghidra's C output might be very useful, but does it have some basic optimisation, i.e. does it avoid obvious UN-optimisations?

The example I have in mind is that with C, using a while(); loop is very efficient, but in Lua a for() loop is faster than while(), and do{}while() is also faster. ASM is fastest using a do-while loop plus a one-off shortcircuit jump for cases where the term 'whiled' is already 0 or false.

It's possible to re-jig loops afterwards, but tedious, so if a decompiler can do these things it might be much more useful than if it can't. I also suspect that decompiler might output some very odd C code when challenged with some manually optimised machine code, or code that is optimised to get around specific CPU instruction limitations. I wonder what it would make of the four bitshifts in my BYTES proc...

[amenjet]

The optimisation would be done by the compiler that compiled the C. the model Ghidra uses is quite interesting, the assembly instructions are converted to an internal language and that is then fed into the rest of the tools. So the decompiler doesn't look at machine code or assembly, but its own internal language. Semantically it will just copy what is there in the C code, a compiler will optimise as it sees fit.

Andrew

[Lostgallifreyan]

That could get odd, an extra layer might solve one thing at the expense of several other and more specific things. That could make for hard work. Optimisation definitely cuts both ways, it's happening as part of an exchange and like any exchange there can be overheads and losses. It's still nice to have a second opinion though, and if it does that consistently it could help. If it can spot a better structuring of code's flow as it goes, and put it in the output, it really WOULD be helpful, but likely only to help thought, because if it's not aware of the specifics of the Organiser CPU, the C code might never be easily modified for porting back to it as ASM. A C compiler than could, might still have trouble with generic C code if that's what Gidra will do, though it might still be better than badly written C. :)

[MartinP]

There's a C compiler for the 6303 here: https://github.com/EtchedPixels/CC6303
Looks like a work in progress, but maybe there are others? Would be interesting to compile, then decompile and compare to see what's lost & gained.
Martin P

[amenjet]

That could be interesting. I'd hope nothing is lost or gained, though!

Andrew

[Lostgallifreyan]

I prefer to modularise chunks of ASM rather than rely on a tool for more complex assemblies, that way I can be freer in how to structure it. (Not that I'd turn my nose up at a tool that automated the fixup adjustments.)

While there are no packages of ready-to-go tools there, the separate files might be very helpful. One example I liked (I went looking for it) is the code for division:
https://github.com/EtchedPixels/CC6303/ ... 3/divide.s

Code: Select all

div16x16:
    ; TODO - should be we spot div by 0 and trap out ?
    std @tmp1       ; divisor
    ldaa #16        ; bit count
    staa @tmp       ; counter
    clra
    clrb
loop:
    xgdx
    asld            ; shift X left one bit at a time (dividend)
    xgdx
    rolb
    rola
    inx
    subd @tmp1      ; divisor
    bcc skip
    addd @tmp1
    dex
skip:
    dec tmp
    bne loop
    rts

It also needs an early return for divide by 1 and division where numerator equals divisor.

This method is what Watcom does for 32-bit division in 16-bit code when both values use the HIWORD bits. I came up with a method of my own that is similar and depends on detecting the carry flag to prevent unwanted iterations. There's no reason not to use this iteration method every time, given that the CPU appears to have no DIV even for 8-bit registers.

[amenjet]

I prefer to modularise chunks of ASM rather than rely on a tool for more complex assemblies, that way I can be freer in how to structure it. (Not that I'd turn my nose up at a tool that automated the fixup adjustments.)

The macro assembler here:

https://github.com/blackjetrock/psion-org2-assembler

generates a fixup table for Psion code.

Andrew