MAMEWorld Forums - Programming - Memory banking in Polygonet Commanders

'Ello.

I'm attempting to finally remove a hack in the Polygonet Commanders driver that lets the dsp56k pass the memory tests. The first 3 memory tests are easy, but the fourth one seems to test some memory banking hardware which is a little bit confusing to me. I was wondering if anyone had any suggestions.

A description of the behavior is as follows :

There are two main sections to memtest 4. In the first section a bunch of RAM is written, in the second it's read back and checked. The reading is done exactly the same way as the writing (same bits are twiddled, etc). Since the reading expects the same bits, I'll leave that out of the description.

Each section has two loops. During each of these loops, the bits of a generic port of the dsp56k (addr ffe3) are twiddled in a manner consistent with what I believe to be memory banking. There seems to be a trick in here though.

Here's a rundown of what happens :

MEMTEST 4 (the writes to memory)
--------------------------------------------------
* First, ffe3 is set to 0020
* The first loop:


for (i = 0; i < 8; i++)

{

    write test data to the range 0x8000-0xbfff

    add 4 to ffe3

}

Because of the "add 4," ffe3's bits 001c are changed for each iteration of the loop. In other words (I think), 001c are the bits controlling a memory banking device, and it changes them each time around. Implementing this like a memory bank in MAME works quite well - it checks properly when verified in section 2.

The trick is in the second loop.

* First, bit 0002 of ffe3 is set (bits 001c of ffe3 are left as 111).
* The second loop :


for (i = 0; i < 2; i++)

{

    for (j = 0; j < 2; j++)

    {

        write from 6000 to 6fff 

        write from 7000 to 7fff 



        for (k = 0; k < 2; k++)

        {

            write from 8000 to ffbf 

            flip bit 0001 of ffe3 ;

        }



        flip bit 0100 of ffe3 ;

    }



    flip bit 0080 of ffe3 ;

}

Nothing too crazy, there seem to be 3 more bits (0181) in ffe3 that control another banking device (strange that 6000-6fff and 7000-7fff aren't written when bit 0001 is twiddled, but oh well). But there's one problem : that inner loop writes at 0x8000!

0x8000 was part of the first loop's test... So either the memory from 8000 to bfff is switched based on both banking devices (a total of 6 bits of banking), or something else is going on...

I think that "something else" has to do with bits 0020 and 0002 of ffe3. Seems like 0020 is initially switched on before the first loop, then 8000-bfff change based on the first banking bits (001c). Then, before the second loop, bit 0002 is switched on and 8000-ffbf change based on the next banking bits (0181). If so, is it possible (hardware wise) that 0002 can override the banking device used in the first loop and route all memory to another physical location?

And if so, how would I best implement this in MAME? It doesn't seem particularly straightforward.

Also, I left out one other sticky point. Memory from c000 to dfff is shared between the dsp56k and the 68020. This is verified to be the case when ffe3 is 0020. Since loop 2 writes from over this region (8000-ffff), I wonder what happens to the shared memory at c000? I'm thinking if 0002 is set in ffe3, c000-dfff is not the shared memory (thus encouraging the theory that bit 0002 switches physical banks altogether), but the game doesn't get far enough to really give me any proof of this.

So yeah, thanks for reading and thanks for you comments in advance! There's a good chance I'm thinking about this all wrong too, so please don't let my description lead you too far astray

.

Andrew

Edited by drewcifer (05/10/06 05:02 AM)