Quick note:
I released the simulator sources with cgplayer (at http://martin.poupe.org/casio/cgplayer/index.html )

That's really cool; do you have a list of all syscalls that are implemented?  Will there be a linux port?

Look in the header for the syscall list.
Currently I debug in Visual Studio, it is much comfortable than in gdb. I tried Eclipse, but it seems Eclipse is not compatible with me :-)
So currently I do not plan to port it to Linux, but is should be easy.

I thought CGDOOM over clocked it for you... If not, I'm still playing the game slower than I should be

No CGDoom doesn't overclock anything.

Hello,
I slightly improved cgdoom.
Updated controls:
arrows - movement
[menu] - exit
[exit] - map on/off
[optn] - pause
[vars] - (hack) switch between smooth and fast movement
[F1]~[F6]+[Shift] - select weapon 1 ~ 7
[Exe] - use (open door, use switch)
[ 0 ] - step left
[.] - step right
[->] - idclip
[^] - iddqd + idkfa
[alpha] - fire
[F<->D] - show free memory in the pool
[ + ] - larger screen
[-] - smaller screen

New features:
- use directly flash memory when possible (saved ~ 150 KB in the first room of the attached wad).
   This doesn't work for areas which are in 2 different areas (file fragmentation). So less fragments -> better.
- show only each second frame (smooth mode) or each fourth frame (fast mode), switch by [vars]
   It seems playable when in smooth mode and overclocked to 87 MHz (94 MHz doesn't work for me)
- other wad files may work (I tried full wad from Doom I and Doom II on simulator - worked; another wads (Heretic, Hexen and TNT do NOT work).
   If you want to use it, try it in simulator first.
- support for composite textures was limited to 8KB to save RAM. It seems 8 KB is enough for switches (they use composite textures). Larger composite textures are cripled - see an image.



Notes for simulator:
- simulator is much faster than calculator, because your PC is much faster. Run it on as slow PC as possible :-)
- on first run it creates flash.bin file to simulate flash for direct access. Can be safely removed later (will recreate).
- Important: delete flash.bin if you change doom.wad file !


Todo:
- multiple keys at a time (currently I use GetKeyPRGM)
- do not use VRAM (do we have some demo code talking directly with LCD registers for MiniSDK ?) Use VRAM as RAM.
- Find each usable byte of RAM (do we have any detailed map of memory ?) and use it.
Currently I use (except globals & stack):system stack, heap,save VRAM buffer

System ERROR
ADDRESS (R)
TARGET = A1524CCD
PC        = 00305BA0

I did some deeper research and it seems it is write exception. The (R) probably means real address.
I updated my Prizm simulator to map simulated flash into the read only memory (by MapViewOfFile(hMap,FILE_MAP_READ,...);
so it throwed an exception on write. I fixed a small bug so then it worked in the simulator, but not in real HW. And I found the source:

typedef struct
{
  const short       width; // bounding box size
  const short height;
  const short leftoffset; // pixels to the left of origin
  const short topoffset; // pixels below the origin
  const int columnofs[8]; // only [width] used
  // the [0] is &columnofs[width]
} patch_t;

// posts are runs of non masked source pixels
typedef struct
{
    byte topdelta; // -1 is the last post in a column
    byte length; // length data bytes follows
} post_t;

// column_t is a list of 0 or more post_t, (byte)-1 terminated
typedef post_t column_t;

//RANGECHECK undefined

#define SHORT(x) LTOH16(x) //swap bytes in word (on Prizm)
#define LONG(x) LTOH32(x) //swap bytes in dword (on Prizm)
#define SCREEN_COUNT 2
#define ASSERT(x)
#define SCREENWIDTH 320 //DOOM screen width

void V_DrawPatchX(int x,int y,int scrn,const patch_t* patch)
{
  int  count;
  int  col;
  const column_t* column;
  byte* desttop;
  byte* dest;
  const byte* source;
  int  w;

  y -= SHORT(patch->topoffset);
  x -= SHORT(patch->leftoffset);
#ifdef RANGECHECK
  if (x<0 ||x+SHORT(patch->width) >SCREENWIDTH || y<0 || y+SHORT(patch->height)>SCREENHEIGHT  || (unsigned)scrn>4)
  {
    //printf("Patch at %d,%d exceeds LFB\n", x,y );
    // No I_Error abort - what is up with TNT.WAD?
    //printf("V_DrawPatch: bad patch (ignored)\n");
    return;
  }
#endif

  if (!scrn)
    V_MarkRect (x, y, SHORT(patch->width), SHORT(patch->height));

  col = 0;
  ASSERT(SCREEN_COUNT > scrn);
  desttop = screens[scrn]+y*SCREENWIDTH+x;

  w = SHORT(patch->width);
  for ( ; col<w ; x++, col++, desttop++)
  {
    column = (const column_t *)((const byte *)patch + LONG(patch->columnofs[col]));
    // step through the posts in a column
    while (column->topdelta != 0xff )
    {
      source = (const byte *)column + 3;
      dest = desttop + column->topdelta*SCREENWIDTH;
      count = column->length;

      while (count--)
      {
        *dest = *source;
        source++;
        dest += SCREENWIDTH;
      }
      column = (const column_t *)(  (const byte *)column + column->length + 4 );
    }
  }   
}

extern int giMaxPatchInFlash;
void V_DrawPatch(int x,int y,int scrn,const patch_t* patch)
{
#ifdef WORK_WITH_COPY
  if(PTR_TO_FLASH(patch))
  {
    memcpy(VRAM,patch,giMaxPatchInFlash);
    patch = (const patch_t*)VRAM;
  }
#endif
  V_DrawPatchX(x,y,scrn,patch);
}
The function V_DrawPatchX() is used to draw any entity to the screen buffer (simplest thing is a letter of message "Picked weapon", (called for each letter)). On windows it works (patch points to HW protected readonly memory), on Prizm it throws an access exception. If I copy the buffer to RAM (by wrapper) , then it works (on Prizm). So it seems the compiler generates some writes to read only pointer.

I guess the CX really is faster than the Prizm in raw speed. That's too bad, but this is a great achievement anyway Can't wait to try this out!

I think the majority of the slowness of CGDoom is not slower  CPU in Prizm, but low RAM. Doom (in general) uses big RAM buffer to load pieces of WAD and it tries to keep them here as cache. So if HW has enough RAM, it loads everything in the beginning and then it works with RAM only. CGDoom is not able to keep everything in RAM so it loads parts of WAD for each frame.
Imagine Windows 2000 on PC with 16 MB RAM (I have seen it once and it was worse than CGDoom :-) )

Is it possible that you accidentally wrote to flash? I imagine that would generate a system error.

Yes, of course. In reality I do not know exactly, what is happening inside the code :-)
But I think problem is in reading (there is "ADDRESS (R)", I hope this means read error and I would get "ADDRESS (W)" on write error.)