Hi,all...
So after a long way of applying Banshaku's Music driver to my game,i run into next compability problem:
On FCEUX it's working Perfectly,
On Nintendulator it's working Perfectly,
But on Nestopia it's crashing.
The error?
"CPU Jam!"
But rom as VRC6(with switching banks etc..)was Fully working with those 3 emulators,After applying music driver Nestopia started to complain...
Why game is working with nintendulator,but not with nesto-pia if both have a "most accurate emulation" state?
And By the way:
I decided to use CHR RAM instead of CHR ROM(Far more flexibity...)And nintendulator don't load any Grafics...(but,TEMPORARILY i used CHR ROM to verify if game is working...).
try RockNES and let me know.
Are you initializing all banks? Some emulators provide default bank selection like first 16k @ 8000, last 16k @ C000, others don't.
I'd just test it on real hardware if possible...
(QUESTION TIME!)
Where's some programs to make .bin files for CHR and PRG ROM's?
"CPU Jam!" usually happens when the CPU tries to execute part of the ROM that's not a program. So your program most likely is related to bankswitching. Maybe you are trying to execute code in a slot to which the correct PRG-ROM bank wasn't assigned.
That would explain some emulators running your program... these probably initialize the slots with the banks you expect, while other emulators don't. You should never count on the emulator/hardware to initialize anything for you, and you should select all the banks you want mapped yourself.
Impossible
My code:
Code:
.org $FFFA
.dw vector_nmi ;NMI adress.
.dw Reset ; address to execute on reset.
.dw 0 ;no RTI for now.
Here's reset code:
Code:
Reset:
LDA #$00
STA $0000, x
STA $0100, x
STA $0200, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0300, x
INX
BNE Reset
ldx #$00
lda #$00
sta $8000 ;load Bank number
sta current_bank
jmp Start
Ohh,almost forgot:
Bank0-$8000
Music Bank-$C000
Fixed bank-$E000
Start label is at start of bank 0.I think that bank switching routine is fine...
Making game compability with nestopia and nintenudlator is last thing before "Demo" relase.
Since you're using CHR-RAM, you will have to set the right banks for the CHR too. I got bitten with the MMC3 because the emulators were setting it the right way but not the actual hardware (all banks were set to 0 on the real thing).
My guess is that some PRG-ROM banks are not set properly but until I can see the code and test it, I cannot say much. But that would be the most probable cause like everyone is saying. If it's just that, it will be an easy fix at a later stage.
It seems you don't initialise the bank at $c000-$dffff by a write to $c000.
BTW it's fun how the VRC6 bankswitching works where you write to the first adress of a bank to select the PRG that is swapped here. I'm also pretty sure Konami games have banks numbers stored here in the ROM so a write at $8000 select which banks is swapped at $8000, and a read at $8000 returns the bank currently swapped. Kinda interesting.
@Denine: did you try with RockNES?
Banshaku wrote:
My guess is that some PRG-ROM banks are not set properly but until I can see the code and test it, I cannot say much.
I...I think it's ok to provide you source code...But I need to translate most importatnt comments to english,besides I think that PRG bank is 99% set propely...
Quote:
It seems you don't initialise the bank at $c000-$dffff by a write to $c000.
If you mean to insert this:
Code:
lda #$0
sta $C000 ;load Bank number
sta current_bank
In the Reset code(before bank0 switch..)
Then,unfortunelly,game is not working ona ANY emulator.
Quote:
@Denine: did you try with RockNES?
Yeah...Music is playing,but screen is...randomly changing pallete(!).
NesterrJ is acting the same way.
EDIT:
I was reading wiki,and run into this(For VRC6):
Quote:
PRG ROM size: Up to 256 KB
So i lowered numeber of banks from to 16,and....well it almost started working with nestopia-now nestopia is emulating it in same was a RockNES and NessterJ....
The "current_bank" variable is there to let us know which bank is mapped in, but you seem to have copied it from UNROM bankswitching examples. Now that you're using another mapper, which has 2 slots for banks, you need 2 "current_bank" variables, one for each slot.
I'm not sure if this is right:
Code:
Reset:
LDA #$00
STA $0000, x
STA $0100, x
STA $0200, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0300, x
INX
BNE Reset
ldx #$00
lda #$3
sta $C000 ;load Bank number
sta current_bankC
lda #$00
sta $8000 ;load Bank number
sta current_bank
jmp Start
Because it's not working.
What's more:
If I keep 32 banks :
Game works with CHR-RAM only in FCEUX,Is working partially with Nintendulator,and nestopia is not working.
Game works with CHR-ROM With FCEUX and nintendulator,but nestopia not working at all..
And I can freely change banks at will(even using only one variable(making second don't affect game)
If I change to 16 banks:
Only change is that netopia still is acting like RockNES...but music is playing in background...
So i really have no idea what's going on...
I can send to someone soruce to veryfication.If anyone is up to challange.
I want to relase Demo soon,because i have to pass a secondary school ceritficate...
As a general rule of thumb... you must write to ALL CHR/PRG regs at least once on startup to set them to a known state. Even if you're using CHR-RAM (CHR-RAM is often swappable just like CHR-ROM)
Basically... set
everything the mapper has to a known state.
Here's an example (assuming 024 and not 026)
Code:
; assuming you want the first bank swapped in at $8000
; and the 2nd last bank swapped in at $C000
lda #0
sta $8000
sta current_bank
lda #-2
sta $C000
sta current_bankC
; set CHR regs appropriately
; ie: set it so the first 8k of CHR is swapped in at $0000
ldx #0
stx $D000
inx
stx $D001
inx
stx $D002
inx
stx $D003
inx
stx $E000
inx
stx $E001
inx
stx $E002
inx
stx $E003
; virtical mirroring
lda #%0000
sta $B003
; disable IRQs
lda #0
sta $F001
; disable VRC6 audio
lda #0
sta $9002
sta $A002
sta $B002
; now your mapper is good to go
EDIT:
Also, yes, make sure this is in the fixed bank (last 8k, between $E000-FFFF)
Header:
Code:
.inesprg 16
.inesmap 24
.inesmir 1
.ineschr 0
Last bank code:
Code:
.bank 30
.org $C000
; The music data
songData1:
.incbin "./music/vrc6.bin"
songData2:
.incbin "./music/cisza.bin"
songData3:
.incbin "./music/prime.bin"
.bank 31
.org $E000
**Here's Music driver code**
Reset:
LDA #$00
STA $0000, x
STA $0100, x
STA $0200, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0300, x
INX
BNE Reset
ldx #$00
; bank 0 in $8000...
lda #0
sta $8000
sta current_bank
;Bank 15 in $C000...
lda #-2
sta $C000
sta current_bankC
; set CHR registers
ldx #0
stx $D000
inx
stx $D001
inx
stx $D002
inx
stx $D003
inx
stx $E000
inx
stx $E001
inx
stx $E002
inx
stx $E003
; virtical mirroring
lda #%0000
sta $B003
; disable IRQs
lda #0
sta $F001
; disable VRC6 audio(Don't affect Music driver...)
lda #0
sta $9002
sta $A002
sta $B002
jmp Start
musicDataTableLow: .byte LOW(songData1), LOW(songData2), LOW(songData3)
musicDataTableHigh: .byte HIGH(songData1), HIGH(songData2), HIGH(songData3)
.include "SYS/Rysowania.txt"
.org $FFFA
.dw vector_nmi ; no VBlank
.dw Reset ; address to execute on reset
.dw 0 ; no whatever
I tried to init chr regs earlier,but didn't worked...
Anyway here's my last bank,and header...
Is your NMI vector also in the fixed bank? I don't see any NMI disabling code before it starts clearing RAM. You might get a NMI, and it jumps out into la la land before the bank has been set.
You mean something like this?:
Code:
LDA #%10000000 ;Disable NMI
STA $2000
LDA #$00
STA $0000, x
STA $0100, x
STA $0200, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0300, x
INX
BNE Reset
ldx #$00
LDA #%00000000 ;enable NMI
STA $2000
Now Even Fceux started to act like RockNES and Nestopia.SO I guess it's a problem related to bank switching after all..
Oh,here's NMI code:
Code:
vector_nmi:
jsr ft_music_play
rti
Yep,it's all NMI code...Any suggestions?
Disable the NMI, do the bankswitching, then enable NMI when you're ready for it. You shouldn't even consider enabling NMI until the PPU has 'warmed up'.
Remember to always clear the VBL flag by reading PPUSTAT whenever you enable NMI, otherwise you might start the NMI code in the middle of vblank, instead of at the beginning. So if you are wondering where those kind of single frame wrong-scrolling bugs are coming from, that's where.
I don't really know what to do...I'm started to get sick of this problem,and my boundless stupidity about NMI,Vblank and others like this.
Here:
Some code from begining of ROM:
http://paste.org/pastebin/view/17032
And last banks:
http://paste.org/pastebin/view/17034
Maybe is skillful enough to correct this code?(And explain what's was wrong,Pelase!)
The NMI code is missing essential code to push and pop the various registers. Otherwise you'll trash the A, X and Y registers every time there's an interrupt.
Throw in these:
vector_nmi:
PHA
TXA
PHA
TYA
PHA
;rest of code here
PLA
TAY
PLA
TAX
PLA
RTI
The reset code needs to disable IRQs and NMI as the very first thing.
sei ;disable all 6502 interrupts
lda #0
sta PPUCTRL ;disable NMI (PPUCTRL is address $2000)
lda #$40
sta $4017 ;disable APU frame IRQ
You must do the bankswitching before you re-enable interrupts and NMI. Looks like you're not using IRQ interrupts, so you probably don't need to worry about those.
You're also missing the code to initialize the stack pointer
ldx #$ff
txs
edit: fixed a small mistake in the post
OK:Status update:
Prefectly working:FCEUltra,NNesterJ.
Arch nemesis(Invisible sprites while in NTSC mode):Nestopia.
No GFX loaded(?):Nintendulator
Other:VirtuaNES is giving strange error:"An indistict error ocurred"
I'm not sure if I aplied interrupts code correctly:
Code:
Reset:
sei ;disable all 6502 interrupts
lda #0
sta $2000
lda #$40
sta $4017 ;disable APU frame IRQ
LDA #$00
STA $0000, x
STA $0100, x
STA $0200, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0300, x
INX
BNE Reset
ldx #$ff
txs
ldx #$00
; bank 0 in $8000...
lda #0
sta $8000
sta current_bank
;Bank 15 in $C000...
lda #-2
sta $C000
sta current_bankC
; set CHR registers
ldx #0
stx $D000
inx
stx $D001
inx
stx $D002
inx
stx $D003
inx
stx $E000
inx
stx $E001
inx
stx $E002
inx
stx $E003
; virtical mirroring
lda #%0000
sta $B003
; disable IRQs
lda #0
sta $F001
; disable VRC6 audio(Don't affect Music driver...)
lda #0
sta $9002
sta $A002
sta $B002
jmp Start
I don't understand why in the world Nintendulator don't see any GFX...CHR-RAM is loaded...CHR Slots initalized...
So you are having graphical problems in Nestopia and Nintendulator, which are, AFAIK, the most accurate ones of the bunch. Maybe you are trying to update graphics while the PPU is rendering.
But it could still be a bankswitching issue... Since you are using CHR-RAM, that means you are copying the graphics from somewhere in PRG-ROM, so if you don't have the correct bank switched in you'll use incorrect graphics.
EDIT: Wait, you said the sprite issues with Nestopia are only there in NTSC mode? Then the problem can be that your NMI code is taking too long to update the video, and the updates are spilling into rendering time, which is a terrible thing. PAL has a (much) longer VBlank, so it's much harder for such problems to occur on PAL consoles. Can you describe how you are handling the NMI and video updates? Please don't tell me you are reading the controller and moving sprites (i.e. game logic) in the NMI routine before updating the graphics...
Quote:
Arch nemesis(Invisible sprites while in NTSC mode):Nestopia.
Sounds like you're spilling out of VBlank to me.
- You should compare the disassembled code output of two different emulators, in order to spot the first meaningful difference. Care to keep trying on RockNES?
Quote:
Can you describe how you are handling the NMI
Code:
vector_nmi:
PHA
TXA
PHA
TYA
PHA
jsr ft_music_play
PLA
TAY
PLA
TAX
PLA
RTI
Ummm...if I delete "jsr ft_music_play" then nestopia is emulating perfectly on NTSC...So I guess is related to too long NMI.
Quote:
and video updates?
I not sure what it is
Quote:
- You should compare the disassembled code output of two different emulators, in order to spot the first meaningful difference. Care to keep trying on RockNES?
For now RockNES,after loading ROM,is giving me a "Send error to microsoft message"
If you play music in the NMI handler, you need to do your graphics update in the NMI handler too, before you call ft_music_play.
I'm not sure how to do it...
Denine wrote:
Quote:
and video updates?
I not sure what it is
Anything that's PPU-related that is supposed to change what's seen on the screen is a video update. Where in your code do you perform a sprite DMA? Set the scroll? Those things have to be before the call to ft_music_play.
Denine wrote:
For now RockNES,after loading ROM,is giving me a "Send error to microsoft message"
- I'd like a copy of your nes binary to test here. Send me a private message.
- Plus, are you counting the number of executed CPU cycles up to the end of VBlank?
Quote:
Where in your code do you perform a sprite DMA?
Ohh..that thing...ok,I'll put it into NMI...
...
Yay,it's working on NTSC with nestopia
Now only Nintendulator and Rocknes left...
I absolutly have no idea why in the world grafics is not showing up...
Quote:
- Plus, are you counting the number of executed CPU cycles up to the end of VBlank?
No...why?And more important...HOW
Stick a breakpoint at the end of vblank, FCEUX will tell you what the scanline number and PPU tick is.
Denine wrote:
Why game is working with nintendulator,but not with nesto-pia if both have a "most accurate emulation" state?
Because neither are 100% perfect. In fact, perfection is practically impossible.
Given the massive complexity of emulators at this low a level, there's bound to be differences even between two very highly accurate emulators.
Denine wrote:
I absolutly have no idea why in the world grafics is not showing up...
Well, you are obviously handling this problem in a very chaotic way. You are just trying whatever we suggest without even understanding why. Add that to the fact that our suggestions are limited, because there are several critical parts of the code you are not showing, and I say it will be a miracle if this thing works correctly. Even if by some miracle it appears to run correctly, if you get that result by pure luck there will probably still be problems, just not so severe to the point of breaking everything.
Maybe you are holding some code back because you're preparing some kind of surprise or something, but if you expect to fix this the good way you'll have to show more code. We need to see some of your main loop, and anything related to PPU updates. Or else it will be like going to the doctor and not wanting to take your clothes off... the doctor might not be able to help you much!
tokumaru wrote:
You are just trying whatever we suggest without even understanding why.
Well,that is almost true,I try to understand how it work,and even looking in wiki about it,to understand better.But...yeah i don't really understand everything.
About the code...Yep it's decided...it may be a little too much,but...you can see almost whole code:(I cut off Main game loop,because even title screen is not showing up so showing main code won't help,right?)
http://paste.org/pastebin/view/17080
And sorry about making you angry
I'm not angry, just a bit frustrated with all the guessing that has been going on, from you (that a lot of times don't understand what you are doing) and from us (who don't have a broader view of the problem).
As a personal rule, I don't consider anything I make "done" until I understand perfectly how it works. If I'm just guessing and the thing happens to work by luck, I can't consider it a good program. Just like things sometimes don't work by accident, sometimes they work by accident too, and that's not good. Honestly, if I were you, I'd be working on something simpler that I'd be able to understand better.
I think you are jumping ahead of yourself... You didn't even master how to work with graphics and the NMI yet, and are already complicating stuff by using a mapper like the VRC6.
I'm looking at your code though. I'll let you know if I see anything weird.
- One hint: you setup a VRC6 mapper (24) with CHR-RAM. Supposedly, VRC6 uses CHR-ROM. I could trap writes to the CHR-RAM in RockNES; that's why it crashes.
Zepper wrote:
Supposedly, VRC6 uses CHR-ROM.
And supposedly, NROM uses CHR ROM, but every popular NES emulator treats mapper 0 with 0 bytes CHR ROM data as a board from which one has desoldered the CHR ROM chip and rewired it to take a 6264 SRAM.
tepples wrote:
And supposedly, NROM uses CHR ROM, but every popular NES emulator treats mapper 0 with 0 bytes CHR ROM data
- What's the point with my previous statement? Anyway, nope, AFAIK, every NES emulator checks the number of CHR ROM pages specified in the iNES header; if it's zero, the game uses CHR RAM... but not only for mapper 0, but every other mapper.
I agree with what Tokumaru said. Before you go forward in your project, you should go a step back and understand the part that you have difficulty with. If you don't, your project will never go forward smoothly.
By quick reading of the code, I see sometime you use the register directly, sometime you use the constant I made. This imply cut & paste code and make it not uniform. One of the line say in english that it set the NMI flag with #010000 but there is no %, which mean it's not a binary number. And the NMI flag is the 7th bit so it would not work too.
So my suggestion is:
- Remove music engine, go back with mapper 0 for the time being
- Clean up your code, make it uniform
- Understand every part you code
- Part you don't understand, ask questions
- Once code is clean-up and stable on all emulator, start VRC6 music
As for CHR-RAM inside VRC6, no cart supported it so it's not sure that it would work. It could but not tested.
Banshaku wrote:
As for CHR-RAM inside VRC6, no cart supported it so it's not sure that it would work. It could but not tested.
AFAIK, taking a real cart and replacing its CHR chip by an 8KB RAM chip is a simple modification that should work in any board, so I don't think this is something to be worried about (unless emulators specifically refuse to use this mapper with CHR-RAM, which they shouldn't).
tokumaru wrote:
Banshaku wrote:
As for CHR-RAM inside VRC6, no cart supported it so it's not sure that it would work. It could but not tested.
AFAIK, taking a real cart and replacing its CHR chip by an 8KB RAM chip is a simple modification that should work in any board, so I don't think this is something to be worried about (unless emulators specifically refuse to use this mapper with CHR-RAM, which they shouldn't).
- It's just non-standard, much like having mapper 3 with CHR RAM. But ok, I'll fix this potential bug. I have to thanks the guy.
Quote:
you setup a VRC6 mapper (24) with CHR-RAM. Supposedly, VRC6 uses CHR-ROM.
Well,was thinking that VRC6 can use either of them.I can remember someone saying that...
Quote:
So my suggestion is:
- Remove music engine, go back with mapper 0 for the time being
- Clean up your code, make it uniform
- Understand every part you code
- Part you don't understand, ask questions
- Once code is clean-up and stable on all emulator, start VRC6 music
Umm...getting back after all troubles?Hmm...but..ehh,maybe you're right..I have to think about it..at the other hand,maybe i would be much beter if I start making a all new game.And this time no copy pasting code...
[quote]
As for CHR-RAM inside VRC6, no cart supported it so it's not sure that it would work. It could but not tested.]/quote]
You can consider this as a miracle...(I mean..only 3 games is for VRC6,right?)My friend can write games to carts,and he have "Mouryou Senki Madara" game which is VRC6 game,I send already a DRD binary to him.
EDIT:
OK,he checked Dizzy Rainy Day...acording to what he said,it look like Grafics is still loaded from CHR ROM...After that he cleaned CHR ROM,tried play,and took a photo:
Yeah,game is loading grafics from CHR ROM,unfortunelly...But game is 100% working.
I have a VRC-6 dev cart and know about CHR-ROM only. But like Tokumaru said, if you would modify it and add RAM in the CHR-ROM socket, it should work. I never tried it thought.
If you don't want to go back to mapper 0, this is up to you but you should try to clean-up at least your code, part by part and figure out what you don't understand: you don't have to figure out the code of the sound driver, this is not your code and is already tested. And by code of the sound driver I mean only the part located in soundDrv since the rest is my code to use it and it you re-use some of it, you have to understand it. The bank switching and music code is such a little part of what will be happening in your current game that it won't think it would be such an issue to go back. You decide.
- If he's using CHR RAM, there's no reason to write into VRC6 CHR registers. That's why it crashes my emulator.
Zepper wrote:
- If he's using CHR RAM, there's no reason to write into VRC6 CHR registers.
Many mappers allow bankswitching of CHR RAM by design. These include MMC1, MMC3, and CPROM. A ROM-to-6264 rewire job on a board with a VRC6 would operate the same way.
For example, if you don't set the banks for CHR-RAM on an MMC3, all banks will be at 0. I proved it more than 1 year ago.
tepples wrote:
Zepper wrote:
- If he's using CHR RAM, there's no reason to write into VRC6 CHR registers.
Many mappers allow bankswitching of CHR RAM by design. These include MMC1, MMC3, and CPROM. A ROM-to-6264 rewire job on a board with a VRC6 would operate the same way.
Also Langrage Point on VRC7. 8K of swappable CHR-RAM.
- The only mapper that makes sense is Videomation (13) within 16k of CHR RAM. Bankswitching 8 banks of 1k looks meaningless. Personally, we would have more possibilities - like having 16k of CHR RAM for VRC6 and someone says "it works". Well, it works but it's out of defaults (released games).
Disch wrote:
Also Langrage Point on VRC7. 8K of swappable CHR-RAM.
- But this isn't unusual. It's a well known mapper. It's a known game/feature.
Zepper wrote:
- The only mapper that makes sense is Videomation (13). Bankswitching 8 banks of 1k looks meaningless.
Games still do it, even if it's meaningless. Most mappers that have CHR-RAM and CHR swapping capabilities (ie: VRC7, MMC3, etc, etc) have swappable CHR-RAM. You're better off making CHR-RAM swappable by default than not.
I can only think of 1 or 2 pirate mappers in which you actually need to ignore the CHR regs when there's CHR-RAM. All other commercial games write to CHR regs appropriately.
Disch wrote:
Games still do it, even if it's meaningless. Most mappers that have CHR-RAM and CHR swapping capabilities (ie: VRC7, MMC3, etc, etc) have swappable CHR-RAM. You're better off making CHR-RAM swappable by default than not.
- You forgot mapper 19 (Pinbot and a racing game, missing the title now) with *both* CHR RAM and ROM swappable.
Quote:
I can only think of 1 or 2 pirate mappers in which you actually need to ignore the CHR regs when there's CHR-RAM. All other commercial games write to CHR regs appropriately.
- I didn't trace his code, but probably he's doing the "default" mapper setup, with 0,1,2,3,4,5,6,7 CHR RAM pages at PPU $0000. The only real problem I had was with Space Shuttle (MMC1). Is only my emulator that's not ready for this "new" unusual situation, of taking VRC6 with CHR RAM? Seriously, does Nestopia/Nintendulator support such feature? Even if I do the required changes, it won't change the world after all. ^_^;;
Zepper wrote:
You forgot mapper 19 (Pinbot and a racing game, missing the title now) with *both* CHR RAM and ROM swappable.
By 19 you meant
119, right? And it wasn't a racing game; it was
High Speed, a pinball game. But given the name of that pinball, I see how you'd make that mistake.
I don't think any emulator author should block certain cartridge configurations just because they have never been used before. If the iNES header allows it, and the real console would take it, emulators should support it. You never know when some homebrewer will decide to do something unusual...
Still angry about the idiocy that led to mapper #3 having a Max CHR size in some emulators. Just because CNROM cartridges can't accept more doesn't mean that Mapper #3 should be restricted by CNROM limitations.
Dwedit wrote:
Still angry about the idiocy that led to mapper #3 having a Max CHR size in some emulators. Just because CNROM cartridges can't accept more doesn't mean that Mapper #3 should be restricted by CNROM limitations.
If you're talking about the limit of 4 CHR banks (32 KiB), I agree. But the 16 bank (128 KiB) limit is because of the security diode slots on D5-D4 of authentic boards.
tepples wrote:
Zepper wrote:
You forgot mapper 19 (Pinbot and a racing game, missing the title now) with *both* CHR RAM and ROM swappable.
By 19 you meant
119, right? And it wasn't a racing game; it was
High Speed, a pinball game. But given the name of that pinball, I see how you'd make that mistake.
- Yes, thank you. Anyway, I meant a racing themed pinball game.
- Regarding the unusual stuff, personally, I consider it a brand new subject on NES homebrew scene. Although, I'm not in the good mood for such thing, until the "big accurate ones" try to follow/support such line of "unusual or unreleased cartridge features".
Just to say that I am very disapointed by the accuracy of Nintendulator and Nestopia. Now that I have eventually imported an NTSC NES here, I was able to figure out that... pretty much ALL demoes I did with raster effects that worked fine in those "accurate" emulators haves glitches on the NES !
At first I trought their accuracy was doubtful only in PAL mode, but no it's doubtful too in NTSC mode. I even had one program that worked fine in all emus but it looked like it spill out of VBlank time on the real console.
So just to say there is still a LOT of room for improvement in accuracy, and that Nintendulator & Nestopia really aren't that accurate. Anyone is pretty much forced to test their demoes on a real PAL and NSTC NES to be sure they work as expected.
Bregalad wrote:
So just to say there is still a LOT of room for improvement in accuracy, and that Nintendulator & Nestopia really aren't that accurate. Anyone is pretty much forced to test their demoes on a real PAL and NSTC NES to be sure they work as expected.
- That's what I was trying to say all the time.
Can I have a word?
'
OK...So friend claimed that VRC6 is not using CHR RAM without a cart mod...
SO....again I decided to Change to CHR ROM.I had even a nice routine to load GFX into specifed PPU number,with specifed number of tiles to read.But...RockNES and nintendulator is not working with VRC6 CHR RAM-that's why i decided to change it.
Quote:
You decide.
I'll leave DRD for a while to start learning everything from zero,I already finished Nerdy nights tutorial.I'll find other to be sure I understand everything.Then,I'll try to clean,and understand every bit of my code.
But right now i have some questions:
1.I understand how to change CHR slots in VRC6.But...I'm using 10 banks of CHR ROM(It's 256kb).And I can't switch to the second half of CHR ROM.Normally I need to write #$03 to $D000 when I want to map 3rd 4kb piece of CHR ROM into 1st PPU slot.But this possibility end at #$4F.If Ill' try #$50 then slot goes gray.0x50th 4kb piece of CHR ROM is about half of file...Of course I don't think I'll need even 20 pieces,but I'm curious how to do it.I can't find info about this in wiki.
2.When my friend treid to play DRD witch CHR ROM,it seems that slots have been swapped....
After some changes in code..it appears it is true,but in reset code i have proper CHR Slots init,even Nintendulator don't complain.
3.How to detect Consloe Region?(On PAL music is seriously too slow,and no enoyable)
Oh,and By The Way:My friend,just for fun had replaced Fantastic Dizzy PRG chip with DRD.It's propably nothing new to you,but it was working.
Fantastic Dizzy is mapper 71(Camerica).And I was suprised that music was working...
Anyway..I going to look for another tutorial,and read wiki.
tokumaru wrote:
emulators should support it.
- They should, but the task is quite complex. There's CHR page masking (RAM or native ROM), plus the bankswitching hooks - to swap CHR RAM or CHR ROM. It's *much* different when such feature is already present in a mapper, like MMC1 (Space Shuttle) or mapper 119 that uses *both*. By just putting such support available for any mapper requires a major code rewrite. Is worth the effort? Nope, unless such unusual mapper setups would be common in NES homebrew - we had an accidental case only! Anyway, meh!
For state of banks at beginning, I don't think any emulators support the official one since there is not much information about it. Commercials games already set their banks properly so you don't have to worry about the initial state of the mapper. For homebrew, this is an issue. Like mentioned before, it bit me for MMC3 with CHR-RAM when it was working fine in the emulator but not on the real thing.
Zepper wrote:
- They should, but the task is quite complex.
I really fail to see what the complexity is. If you already support this mapper with CHR-ROM, you already have all the memory management working, wouldn't it be just a matter of allowing writes to that memory?
I've never written an emulator before, but if I did I would probably make the distinction between CHR-ROM and CHR-RAM by simply allowing or disallowing writes to PPU addresses $0000-$1FFF, redirecting writes according to what the mapper has made accessible in that range, exactly like it's done for reads.
Quote:
I really fail to see what the complexity is.
Same. It's as simple as you described... just point the memory to a different buffer, and set a flag to indicate it's writable.
Lots of mappers have swappable CHR-RAM
Lots of mappers have CHR-ROM + CHR-RAM
Emulators should be dynamic enough to handle the above situations.
Zepper, maybe you have used an architecture for your emulator that is not very dynamic. You say this would require a major code rewrite... Maybe fixing this single ROM is not worth the trouble, but making your emulator more dynamic and able to handle such changes more easily in the future might be. Don't you think?
For PocketNES, it was a big deal to work in bankable CHR-RAM or mappers with mixed CHR RAM and CHR ROM, mainly because of the way it uses the GBA hardware. But other emulators with software renderers should have a much easier time.
- Can we put CHR ROM in mapper 2, for example? Or even in mapper 7? What about the value written, how would it be handled? I'm curious.
When figuring out how your emulator should behave under some configuration, figure out how you would build that configuration on a circuit board and ask yourself how that board would react. CHR ROM in mappers that ordinarily use RAM
SHOULD be handled the same way as if I had desoldered the RAM chip and rewired a socket to take a mask ROM or an EPROM. It would ignore pattern table writes, and the ROM would be switchable the same way that the RAM is. For example, UNROM (#2) and AOROM (#7) would have a fixed 8 KiB bank just like NROM, and CPROM (#13) would have a fixed 4 KiB bank and a switchable 4 KiB bank.
(
What's a SHOULD?)
If you put CHR ROM in Mapper 2 or Mapper 7, it would just act like nonbankable NROM CHR that is read only. Of course, also with bankable PRG, and one screen mirroring (on mapper 7).
HI,So I'm back
I cleared my code,and learned some things.
But there's some things I don't understand:
Title Screen:
OK...after pressing A,turn PPU OFF:
Fine,Load palette,Name table..wait what?:
Turn PPU ON...
After that everything is normally,but always when I'll try to use this "trick" problem is always repeating...
I was reading about 2 name table PPU update possibilities...One is to use method mentioned earlier,second is about "buffering" what have to be draw,but i don't really understand it,unfortunelly.
Here's some code in case you need it:
Code:
lda #%00000000
sta $2000 ;Clean PPU
sta $2001
**Here's Palette loading code**
**Here's Name Table loading code**
LDA #$00
STA $2005
STA $2005
lda #%10001000 ;enable NMI,Sprites from VRAM1
sta $2000
lda #%00011000 ;Turn PPU ON and show sprites.
sta $2001
Whenever you disable NMI, then re-enable it, read from PPUSTAT so you don't end up calling your NMI code halfway through vblank. But I don't that that's whats going on here.
Whenever you turn the screen back on, wait for VBLANK first. I put the screen turning-on code inside NMI personally, but you don't have to do that.
Thanks,it worked!I noticed one thing-I don't have to read PPUSTAT before turning PPU OFF,If I do then there's 2 black screen frames.
I would have some more questions,My friend has played My game on real hardware,but it seems that sprites isn't displayed correctly.(They are blinking...)But any emulator can produce that effect.I mean,game is working fine evenon Nestopia and Nintendulator.
Maybe I'm wrong...but maybe i should place sprite updates into NMI?At the other hand,it doesn't work and it'll waste lot of Vblank...
writes to $4014 (and $2004, but there's little point in using $2004 directly) must be done in VBlank or when the PPU is off.
You can't update onscreen sprites during rendering.
The code to MAKE the data for the sprite table does not need to run during vblank. The code to COPY the data (write to 4014) does.
while not done:
- Read controllers.
- Run game rules.
- Based on the new positions of game tokens, prepare buffers to be copied to OAM and VRAM.
- Wait for vertical blank.
- Copy buffers to OAM and VRAM.
- Set the scroll position.
- Run sound code.
Pretty much every NES game loop looks like this, except that many games do steps 5-7 in the NMI handler. Dwedit is talking about the difference between steps 3 and 5.
So,if I assume correctly...in step 3 (NOT inside NMI) I prepare sprites to be written.
In step 5 (inside NMI) I gather that data and write it into OAM.
Hmm...not sure about it though...
I have sprites data in $600-$6FF in RAM.
OK,my NMI:
Code:
vector_nmi:
PHA
TXA
PHA
TYA
PHA ;backup registers
lda #$00 ;Set 00 for sprites-bytes counter(if there's 1
sta $7F2 ;sprite then counter is 0x04)
ldx #$00 ;Start loading sprites data from 600
jsr Rys.Sprity ;Drawing sprites function
jsr ft_music_play ;play music
PLA ;restore registers
TAY
PLA
TAX
PLA
RTI
And Sprites drawing function:
Code:
Rys.Sprity:
lda $600,x ; load Y value
sta $2004
lda $601,x
sta $2004 ; store tile number
lda $602,x ; Atrybuty
sta $2004
lda $603,x ; load X value
sta $2004
inx
inx
inx
inx
cpx $7F2 ;check number of sprites
bne Rys.Sprity_Petla
rts
You should write nothing to $2004 and write the sprite page (here #$06) to $4014 once instead. Reason for this is that it will be WAY to slow to update sprites like you're doing.
If you're worried about the later sprites being unused you don't want to display, you should put their Y coordinate (first byte) to 240 ($f0), so that they're unused. Not updating them is not going to hide them.
Ok,SO Game is working Perfectly on (almost )every emulator.
(game is not working on nesticle and UberNes)
On real hardware everything is working...almost.
To make Name tables smaller I used RLE compression.
Decompresing in game is working without problems.I left 1 map uncompressed.
Then I took a quick look how it's working with real hardware.
And...ehh-every name table that was supposed to be decompressed is filled with random PPU number.So screen sometimes is filled with 0x00 or 0x06 PPU pieces instead of normal name tables.
Of course uncompressed name table that I left is working fine...
Anyone have an Idea what's going on?
Important note:
Yes,I don't have to use compression,but I'm curious,why it's not working...maybe soething with Vblank?
Just in case...
Code:
CZYSC_PPU: Turns PPU OFF
lda #%00000000
sta $2000 ;Wyczyść PPU
sta $2001
A0
lda $2002
bpl A0
rts
PPU_ON: ;Turns PPU ON
A1
lda $2002
bpl A1
LDA #$00
STA $2005
STA $2005
lda #%10001000 ;enable NMI,Sprites from VRAM1
sta $2000
lda #%00011010 ;Turn PPU ON,show 8 left pixels of BG and show sprites.
sta $2001
rts
Yeah,I'm using jsr to turn PPU OFF and ON,between which I'm running RLE decompressing script.