tepples wrote:
Now that's a problem. The $C000 banks should be 01 to match the Python output:
Code:
mode $0c, outer bank $00
$8000 banks: 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01
$C000 banks: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
I must have got things mixed up when coping from the screen to post because my output does match the python output there.
I made the change to the script for 512KB, sorry for missing this point in the discussion earlier... Here was the swaperoo I did:
Code:
outer_bank = (outer_bank << 1) & 0x1F #512KB
#2MB outer_bank = outer_bank << 1
So the first two outputs match fine now, along with previous issues I've voiced. But here's what I'm seeing wrong elsewhere: (I'll try not to let my binary dyslexia shine through again...)
EDIT2: Unless you feel like reading what problems I had and how exactly I found/fixed them, save yourself the read and skip down to my EDITs...
My 'mode $28, outer bank $3f' output matches 'mode $28, outer bank $3c' when the script says they should differ.
So for 'mode $28, outer bank $3f' I see:
Code:
$8000 banks: 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18 18
$C000 banks: 18 19 1a 1b 1c 1d 1e 1f 18 19 1a 1b 1c 1d 1e 1f
instead of what the python script says:
mode $28, outer bank $3f
$8000 banks: 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e
$C000 banks: 18 19 1a 1b 1c 1d 1e 1f 18 19 1a 1b 1c 1d 1e 1f
Additionally the next output is wrong, for mode $2c, outer bank $00 I get:
Code:
$8000 banks: 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
$C000 banks: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07
expecting based on script:
mode $2c, outer bank $00
$8000 banks: 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
$C000 banks: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
The next one is correct though:
Code:
mode $2c, outer bank $03
$8000 banks: 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
$C000 banks: 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07 07
Quote:
Did you try $18, $28, or $38?
Now that I think I'm starting to grasp what is going on here exactly they appear correct.
I think it's all coming together for me now... But when I look back at the differences above I don't understand why the script should be giving me this:
Code:
mode $28, outer bank $3f
$8000 banks: 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e
$C000 banks: 18 19 1a 1b 1c 1d 1e 1f 18 19 1a 1b 1c 1d 1e 1f
lower mode nibble is 8 -> UNROM #180 with lower bank fixed to the 'first' bank right? So wouldn't that mean all $8000 banks should be 18???
Same here:
Code:
mode $2c, outer bank $00
$8000 banks: 00 01 02 03 04 05 06 07 00 01 02 03 04 05 06 07
$C000 banks: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
UNROM #2 with upper bank fixed to last bank, so shouldn't $C000 banks be 07???
My cart is behaving in the manner I'd personally expect ($8000->18 and $C000->07 from above). So either I messed up the script, there's and issue with the script, or my understanding of how the mapper is supposed to work is wrong. If I'm understanding the mapper behavior wrong then it should be an easy fix because it appears to be operating how I'd expect, I just need to fix my lack of understanding and the problem will present its self...
EDIT: So it looks like cpow and I had/have some similar confusion looking back at the previous discussion:
Quote:
With the outer bank set to $2A, the 16K banks used by 32K mode are $54 and $55, and the top half of this is $55. More commonly for a ROM of his size, the outer bank would be set to $2F, which produces the expected UOROM-alike last bank in the fixed slot.
I think I'm getting it now...
It kinda stems back to some previous private discussions we had Tepples. I think you've got it set up so that the fixed bank is the current bank, not necessarily the last or the first. My implementation assumes it's the last/first bank that it gets fixed to. Is it beneficial to fix to the current bank vice the last/first? As I remember it consumes more logic to fix the current bank. But for this mapper implementation we've got some logic to spare, so I can change it to fix to the current bank assuming that's what we want. So would this then allow for two smaller possibly non-power of 2 sized games to fit into one larger 'UNROM slot' then?
EDIT 2: I coded it up for the fixed to current outer_bank behavior and fixed up everything. Didn't cost any extra logic or anything either. Everything matches the output of the script now
I also updated the wiki code. So everything should be good there now and fairly 'final'. Guess I was right about finding my misunderstanding of the behavior and revealing the problem.
Aside from the 32KB CHR RAM issues Tepples should be able to continue testing/development with NESICIDE. The 32KB CHR RAM isn't really planed to be made use of for the 'action15 bundle feat. Streemerz' right? Additionally thefox should be able to take my verilog and dump it into mapper #28 of power pak mappers to allow for additional testing. The one thing to keep in mind when he does that though is default/startup values my code doesn't actually cover that, it's a setting in the fitting properties of Xilinx webpack. Although I don't know how necessary all that is until the ROM is more finalized and we can be more sure that their won't be alterations of the mapper. Now that we've got this test up and running in an emu and hardware we should have most details ironed out in order to proceed with what we currently have.