> In other words, I believe they set this bit [ed: ffe3 & 0x0020] before
> they even think about doing memory accesses of any sort.
Just checked. Indeed - this is set before any external memory of any sort is touched by the dsp56k.
> 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."
Confirmed. The loops are perfectly symmetric - the 'checking' loops just call a different jump to do memory reading instead of writing...
I'm guessing the behavior is reasonable, it just doesn't seem like MAME is set up to handle something like this. For now, I've implemented the bits at 0x001c as banking and have left the 0x0181 stuff as a hack. Whenever we get further with the driver, we'll probably have to fix things even more. Heh there still 4 bits in that output port which haven't been touched yet  .
Is this the type of thing that makes Konami such devious hardware designers?
Andrew
* Maybe one way to handle this is to have two seperate memory maps and switch between them based on bit 0002 and 0020? Gonna' look to see if that's possible...
|
Index 
Flat 
Re: Memory banking in Polygonet Commanders
Reply
.
