Accurate is a general term. Most emulators are alot more accurate than the used to be for the NES. This is thanks to more detailed information becoming available. The author of puNES could tell you some things about how it emulates. In the past, emulator programmers had to guess, assume, and just try things out to get games working. Some information was available but it was incomplete and sometimes not entirely correct. But now we know most of the important details to emulate it with a high degree of accuracy.Vectrex2809 wrote:
I used FCEUX and NEStopia. I'm gonna give Nintendulator a go, thanks for the advice. I also heard about puNes being accurate, is that the case?
It's important to note that most software isn't going to require extremely accurate emulation. Only a small percentage of games are programmed in a way that requires precise simulation.
Including your game that ends up inadvertently depending on an emulator bug. Emulators for developers need to be a lot more accurate to be useful for testing things that push the NES harder. For game logic and simple graphics updates, FCEUX plus testing on an NES about once a day is fine. But if you're trying raster effects or pushing a lot of data to the PPU each frame, you might want to be able to test without having to go to the NES (which lacks a step debugger and RAM viewer) every single time.MottZilla wrote:Only a small percentage of games are programmed in a way that requires precise simulation.
On this Thanksgiving day, I'm thankful that we're not stuck with NESticle anymore.
0-15 means the maximum number of banks 16 x 16kb - 256KB PRG. Is it not clear whether by loading a value greater than 15 the code will automatically switch banks 16-31?Then to switch PRG ROM banks, load the bank number (0-15) into A and call this subroutine:
You must write the MSbit into the register at $A000: (nesdevwiki)
Can anyone explain this to me:
"The 256 KB PRG bank selection applies to all the PRG area, including the supposedly "fixed" bank."
I guess that if I set the second 256KB of banks, the last bank will also be replaced with a new one? So I need to make a copy of a fixed bank?
LDA #%00000000 ;banks 0-15 (15fixed)
LDA #%00001000 ;banks 16-31 (31 fixed - copy)
If you have different banks, you have to keep track of everything with bankswitching, just like how you keep track of what is swapped in the swappable bank. You can also have part of the fixed bank being an exact copy, and part of it being different. I think that's what Dragon Warrior III and IV does, if I'm not mistaken.
Or you could just use 32k bankswitching and have 16 banks of 32k.
For example. So if I have a code in the last SUROM fixed bank 31:
Code: Select all
SomeCode: ;code in fixed bank 31 LDA #%00001000 ;select PRG slot 2 STA $A000 ;(***) LDA #$20 ;switch to bank 20 (example) STA MMC1_BankNumber JSR MMC1_PRGBankWrite JSR SomeCodeInBank20 LDA #%00000000 ;select PRG Slot 1 STA $A000 LDA #$00 ;back to bank 00 STA MMC1_BankNumber JSR MMC1_PRGBankWrite RTS
Sory, for stupid questions, but I'm stubborn and I often find it difficult to understand many things: /
Because with SUROM there's only two useful values, you may wish to have functions like:
Code: Select all
SUROM_select_high_256k: ldx #1 stx $A000 stx $A000 stx $A000 stx $A000 stx $A000 rts SUROM_select_low_256k: ldx #0 stx $A000 stx $A000 stx $A000 stx $A000 stx $A000 rts
Code: Select all
SUROM_unified_bankswitch: sta $E000 lsr sta $E000 lsr sta $E000 lsr sta $E000 ldx PRG_RAM_DISABLED stx $E000 stx $A000 ; these writes must still happen despite having no other effect stx $A000 stx $A000 stx $A000 lsr sta $A000 rts
Personally I've never used much PRG bankswitching other than just testing (my only large project so far uses 32kb PRG), so I can't comment on what good practices are. However I'd go for two approaches if I were to make a large MMC1 games:
- Approach A: Just say "screw it", and make bank 15 and bank 31 (the fixed banks) exact twins of eachother. You can now freely swap banks 0-14 and 16-30 in the first slot without worrying about anything. This is definitely what you should be doing if you're used to UNROM-style bankswitching. You "loose" 16k because one bank is duplicated
- Approach B : Use 32kb bankswitching so that the problem does not even appears. You use 16 banks of 32kb. You need to make your own "fixed bank" trampoline code replicated in each of the 16 banks, where the bare minimum for IRQ, NMI and RESET handling should be done as well as bankswitching code. This should take about 1k, so you effectively "loose" 15k.
- Approach C : I don't recommend this, but you go crazy and fully use the bankswitching sheme: You have two sets of 16 banks, and 2 fixed banks, and you make full usage of this. For example if you're making an RPG, you can have one set of banks dedicated to battle and overworld, and the other set of banks dedicated to towns and dungeons and script. It sounds like it wouldn't be that practical to use, but at least you don't loose anything because nothing is duplicated.
Use all of the first 256K for CHR and map storage, with CHR and map decompression in the first fixed bank. This frees up all of the second fixed bank for your game logic.