MAMEWorld Forums - Programming - Re: Memory banking in Polygonet Commanders

Thanks for the response Arbee! And thanks for reading all that junk

> A few things aren't clear here.

Understood - I can totally see where I didn't explain things well enough. I'll clarify as best I can...

> For the first test, ffe3 is always 0x0020 | (whatever), right?

Correct. Actually, ffe3 requires one more fact to explain the full story.

When the proc first fires up, ffe3 is set to 0x0020 at around, eh, the 5th instruction, and it's left on for the rest of the execution. In other words, I believe they set this bit before they even think about doing memory accesses of any sort (I'll double check to make sure they don't touch external memory before that, but I'm 99.9% positive this is the case).

When the first loop of memtest 4 starts, a "mov 0020, ffe3" is executed just to make sure ffe3 is exactly how they want it, but since it was set that way in the CPU's init routine and noone else touched it, the instruction has "no effect"...

> And is 0x0020 set for the second test?

Correct again, sorry this wasn't clear at all. Just to be complete, a full list of the ffe3 values from my error.log are as follows :

(that "mov" instruction i described above)
DSP56K WRITING (0020) TO ffe3 (PC=00000154)

(the first loop)
DSP56K WRITING (0024) TO ffe3 (PC=0000021d)
DSP56K WRITING (0028) TO ffe3 (PC=0000021d)
DSP56K WRITING (002c) TO ffe3 (PC=0000021d)
DSP56K WRITING (0030) TO ffe3 (PC=0000021d)
DSP56K WRITING (0034) TO ffe3 (PC=0000021d)
DSP56K WRITING (0038) TO ffe3 (PC=0000021d)
DSP56K WRITING (003c) TO ffe3 (PC=0000021d)

(setting bit 0002 to prepare for the second loop)
DSP56K WRITING (003e) TO ffe3 (PC=00000159)

(the second, nested, loop)
DSP56K WRITING (003f) TO ffe3 (PC=00000167)
DSP56K WRITING (013e) TO ffe3 (PC=00000169)
DSP56K WRITING (013f) TO ffe3 (PC=00000167)
DSP56K WRITING (00be) TO ffe3 (PC=0000016b)
DSP56K WRITING (00bf) TO ffe3 (PC=00000167)
DSP56K WRITING (01be) TO ffe3 (PC=00000169)
DSP56K WRITING (01bf) TO ffe3 (PC=00000167)

> Also, what does the code look like that tries to verify these results?

I'll double-check when i get home tonight, but I believe the loop which does the checking is exactly the same as the loop which does the writing. Instead of a "jump to write subroutine" call though, there's a "jump to read-and-verify subroutine."

It may be too early to really get into this though, since each segment of memory is simply loaded with values that start with fff0 and decrease as the memory addr increases. When the memory is then checked, a register simply gets loaded with fff0, memory is read, values are compared, stuff is decremented, repeat. Dumb memory check i guess - just making sure the physical device is okay (?)...

Is that what you wanted to know? I'll respond if the mem read-and-verify loop is not the same later today or tomorrow...

> The banking in the second test definitely looks to me like double buffers
> for the display list (or possibly 2 lists double-buffered: one from 6000-6fff,
> the other from 7000-7fff given that there are 2 pairs of polygon chips on the PCB).

Brilliant! Seriously, good idea - that's why it's so nice having someone else look at it - bigger picture thinking...

Andrew