Another hint for expanded customization is the presence of at least two new processor instructions 0x00AB and 0x0nE3 (n=register-no.), which are not documented.

0x00AB and 0x0nE3 are new indeed, but not customized. Since the Prizm processor revealed, that it is a member of the SH-4A family, I had a closer look at the 7780 manual.
0x00AB is SYNCO (new with the 7780)
0x0nE3 is ICBI @Rn (new with the 7780)

BTW.: the SH-4A members are specified to run between 160 MHz and 600 MHz, depending on the processor type.
The SH-4 members are specified to run up to 240 MHz.
The SH-3 members are specified to run up to 200 MHz.
(http://www.renesas.eu/products/mpumcu/superh/superh_landing.jsp)

...The DMAC-address for this operation is 0xFE008020 (channel 0). The address of DMAOR is 0xFE008060...Every single register-address involved in accessing the display does not occur in the 7705- or 7720-lists...

I just noticed that the DMAC-address of the Prizm belongs to the 7730. I would not be surprised, if it turnes out, that parts of the Cyberdyne Systems Model 101 Series 800 have been used, too.

miniSDK (version 1.04).
New with version 1.04: SDK equipped with a GUI, to configure the projects more conveniently. The documentation of which resides in the included HTMLHELP-file (fx_calculators_SuperH_based.chm; search for "SDK, getting started"); two new functions in INSIGHT to demonstrate the speed difference between direct draw and VRAM-DMAC.

EDIT:
Attachment removed.
New version: http://ourl.ca/9205/201161

...what is great about the SH3 is that the keyboard is memory mapped. How that works is that there are 10 bytes representing the state of the keyboard starting at 0xA44B0000...

The 0xA44B0000 register set is not a standard feature of the SH3-group. If you program another SH3-based machine, you won't find the set. It is a special feature of the Prizm. The Prizm MPU is a 7705/7720/XXXX hybrid (the OS identifies the MPU as 7305, which is CASIO customized, t. i. a lot of registers are not documented).

http://ourl.ca/8207/178228

I totally like the display routine!

So? Then if you like it crowded, try this...

@DJ_O: it is C, not assembler!

static unsigned int lastrandom=0x12345678;
unsigned short random( int seed = 0 ){
    if (seed) lastrandom=seed;
    lastrandom = ( 0x41C64E6D*lastrandom ) + 0x3039;
    return ( lastrandom >> 16 );
}

#define NSHAPES 100

//
int MoveOne( TBdispFillArea a[], TShapeProps sp[], int idx ){
int vy1, vy2, j, k;
int xoverlap, yoverlap, overlap;
int xd, yd;
a[idx].x1 += sp[idx].dx;
if ( a[idx].x1 >= 384 - sp[idx].wx){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
sp[idx].dx = -1;  // cold wall
return 0;
}
if ( a[idx].x1 <= 1){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
sp[idx].dx = 3; // hot wall
return 0;
}
for (j=0;j<NSHAPES;j++){
overlap = 0;
if ( j != idx ){
xd = a[idx].x1 - a[j].x1;
yd = a[idx].y1 - a[j].y1;
if ( xd * xd + yd * yd < 100 ) overlap = 1;
if ( overlap ) break;
}
}
if ( overlap ){
sp[idx].dx = -sp[idx].dx;
a[idx].x1 += sp[idx].dx;
k = sp[idx].dx;
sp[idx].dx = sp[j].dx;
sp[j].dx = -k;
return 0;
}

a[idx].y1 += sp[idx].dy;
if ( a[idx].y1 >= 216 - sp[idx].wy){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
return 0;
}
if ( a[idx].y1 <= 1){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
return 0;
}
for (j=0;j<NSHAPES;j++){
overlap = 0;
if ( j != idx ){
xd = a[idx].x1 - a[j].x1;
yd = a[idx].y1 - a[j].y1;
if ( xd * xd + yd * yd < 100 ) overlap = 1;
if ( overlap ) break;
}
}
if ( overlap ){
sp[idx].dy = -sp[idx].dy;
a[idx].y1 += sp[idx].dy;
k = sp[idx].dy;
sp[idx].dy = sp[j].dy;
sp[j].dy = -k;
return 0;
}

k = 0;
if (sp[idx].dy<0) k -= sp[idx].dy; else k += sp[idx].dy;
if (sp[idx].dx<0) k -= sp[idx].dx; else k += sp[idx].dx;
switch (k){
case 2 : sp[idx].color = 0x001F ; break;
case 3 : sp[idx].color = 0x03FF ; break;
case 4 : sp[idx].color = 0x07E0 ; break;
case 5 : sp[idx].color = 0xFFC0 ; break;
case 6 : sp[idx].color = 0xF800 ; break;
}

a[idx].mode = 0;
Bdisp_AreaClr( &sp[idx].saved, 1, -1 );
a[idx].mode = 1;

a[idx].x2 = a[idx].x1 + sp[idx].wx;
a[idx].y2 = a[idx].y1 + sp[idx].wy;
Bdisp_AreaClr( &a[idx], 1, sp[idx].color );
memcpy( &sp[idx].saved, &a[idx], sizeof( TBdispFillArea ) );

/*
vy1 = a[idx].y1 - sp[idx].wy / 2;
vy2 = a[idx].y2 + sp[idx].wy / 2;
if ( vy1 < 0 ) vy1 = 0;
if ( vy2 > 215 ) vy2 = 215;
Bdisp_PutDisp_DD_stripe( vy1, vy2 );
*/
return 1;

}

#define V 1

void F7_Handler(){
TBdispFillArea ar[NSHAPES];
TShapeProps mp[NSHAPES];
int ticks, i, iwork;
ticks = RTC_GetTicks();
random( ticks );
while (!RTC_Elapsed_ms( ticks, 100 ));

for ( i=0;i<NSHAPES;i++){
ar[i]. mode = 1;
memset( &mp[i], 0, sizeof( TShapeProps ) );
mp[i].wx = 10;
mp[i].wy = 10;
ar[i].x1 = 11 * ((i >> 2)+1);
mp[i].color = random();
ar[i].y1 = 10 + 11 * ( i & 0x3 );

iwork = random();
iwork = ( 3 * iwork ) / 0x10000 + 1;
if ( random() & 0x8000 ) iwork = -iwork;
mp[i].dx = iwork;
iwork = random();
iwork = ( 3 * iwork ) / 0x10000 + 1;
if ( random() & 0x8000 ) iwork = -iwork;
mp[i].dy = iwork;

ar[i].x2 = ar[i].x1 + mp[i].wx;
ar[i].y2 = ar[i].y1 + mp[i].wy;
}
while ( !(*(unsigned short*)0xA44B0000) ){
for (i=0;i<NSHAPES;i++){
MoveOne( ar, mp, i );
}
   Bdisp_PutDisp_DD();
}
}

Attachment removed. Actual version included here:
http://ourl.ca/9205/218371

How do you think the cache works with it, though?

I think the cache has to be flushed before DMA (direct memory access) occurs. Perhaps it is done automatically by the DMA request or by setting/toggling certain bits of the registers involved. As these registers are undocumented, this is not easy to verify (at least for me).

EDIT: I forgot to mention. VRAM usually is accessed using base address 0xA8000000, which lies within area P2, a non-cacheable memory range. Caching could be a problem, if you access VRAM using base-address 0x88000000.

Direct display access

syscall 0x026B (void Bdisp_SetPoint_DD( int x, int y, unsigned short color )) writes a point directly to the display.

BTW: syscall 0x025F Bdisp_PutDisp_DD() transfers the data from VRAM to display-RAM via DMA. The DMAC-address for this operation is 0xFE008020 (channel 0). The address of DMAOR is 0xFE008060. The DMAC functions seem to be similar, if not identical compared to those of the 7705's DMAC (0xA4000020) or the 7720's DMAC (0xA4010020). The base address of the displaydriver is 0xB4000000, which does not mean, that this address can be simply used to write directly to the display! The special (undocumented) processor instruction 0x00AB seems to be kind of ping, after something has been written to a DD-related register, perhaps to sync the MPU/DD-interaction. The correspnding DMA-source register (DMARSx) is difficult to identify. At least 0xA4050130 and 0xA405013C are involved.
Every single register-address involved in accessing the display does not occur in the 7705- or 7720-lists.

I recommend to use links to where the miniSDK has been uploaded the first time. It is only a few days old and it will be changed frequently. Especially the syscall-library and insight will be subject to changes. Distributing copies will possibly hamper the revision management.