It is currently Tue Nov 21, 2017 2:56 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Thu Jul 24, 2014 4:21 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
The issue with $500 is that some NSFs do clear the RAM when you call their init routine.

First time I saw that was on the 5B driver from mmlshare.com, on this Gato/Gonzales music I just posted.

In my humble opinion, the NSF standard is just as bad as the whole INES problem with only 256 mapper slots ... A big mess. XD


Top
 Profile  
 
PostPosted: Thu Jul 24, 2014 6:34 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
tepples wrote:
If you put the display list at $6000, some playback engine will probably end up trashing it there too. You might need to make it configurable per NSF.

That is a good point, is there any ram that is un-molested by NSF play routines?
As l_oliveira noted there is a vast gray area as to what a NSF can do. Am I wrong in thinking the vast majority of NSF Play routines don't touch WRAM? I know WRAM addresses are part of the NSF definition but in practice how many Trackers/Composition tool's player code use it? Only a very small number of NSF I have tried had a issue with ram at $0500 let alone WRAM (none) but my sample size is very small and I haven't messed at all with game rips (which may be more probable to use WRAM).
But this brings up another point I've been wondering about. As this code switches between NSF, should I be clearing the low ram as I do in the reset routine? (haven't see any problem so far, but...) All my VARs and Sprites are in WRAM now, so clearing the lo ram is only a benefit to the loaded NSF. It's really not clear to me if the NSF handles the initialization of the ram it uses.
Then again the NSF format was never assumed to be running on a console, right?
Yogi


Top
 Profile  
 
PostPosted: Thu Jul 24, 2014 6:50 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
The code which tampers with the sprites buffer on the Gonzales song is like this:
Code:
 06:8080:20 93 80  JSR $8093
 06:8083:60          RTS
....
 06:8093:A9 00      LDA #$00
 06:8095:A2 00      LDX #$00
 06:8097:9D 00 00  STA $0000,X @ $0000 = #$03
 06:809A:9D 00 02  STA $0200,X @ $0200 = #$8E
 06:809D:9D 00 03  STA $0300,X @ $0300 = #$00
 06:80A0:9D 00 04  STA $0400,X @ $0400 = #$00
 06:80A3:9D 00 05  STA $0500,X @ $0500 = #$37
 06:80A6:9D 00 06  STA $0600,X @ $0600 = #$00
 06:80A9:9D 00 07  STA $0700,X @ $0700 = #$00
 06:80AC:E8          INX
 06:80AD:D0 E8      BNE $8097
 06:80AF:A9 00      LDA #$00


It's quite obviously an ram clear routine which also happens to be similar to the existing one on VegaPlay.
At least it leaves the stack alone ...
(hehehe)

To fix this I just changed the JSR routine at the init address ($8080) to call $80AF instead of $8093.

Still I don't understand why someone would put a ram clear routine on a NSF.

Clearing the RAM supposedly is meant to be done by the NFS player firmware.


Top
 Profile  
 
PostPosted: Fri Jul 25, 2014 6:04 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
Yogi, while your goal (at the moment) seems to be pack a lot of songs on a cartridge, I wanted mostly to get the "in driver" banking working so I could play the longer, bigger songs.

Yesterday I did a experiment with a banked N163 song which at the moment only work on emulators. I'll do more testing to try to figure out why it only work on emulators but apparently seems to be a issue with the driver itself because when I tried a non banked song which used the same driver it failed with the same exact behavior.

This MCK driver is interesting because it seems to only bank $A000-$BFFF and $C000-$DFFF which matches perfectly the required behavior for operating on the real hardware.

Even then, I had to do some changes on the banking code:

- Modify mapper init on VegaPlay to init mapper for low bank numbers as I started to put the NSF at the start of the ROM file.
- Modify the NSF native init code to not touch memory regions used by VegaPlay.
- Modify the NSF banking code to not touch registers it's not supposed to and modify the actual banking code to use one 8KB bank instead of two 4KB banks:

Code:
Original:
 00:816E:C9 0E      CMP #$0E
 00:8170:B0 0D      BCS $817F
 00:8172:8D FA 5F  STA $5FFA
 00:8175:18          CLC
 00:8176:69 01      ADC #$01
 00:8178:C9 0E      CMP #$0E
 00:817A:B0 03      BCS $817F
 00:817C:8D FB 5F  STA $5FFB
 00:817F:60           RTS

Edited:
 00:816E:C9 0E      CMP #$0E
 00:8170:B0 0D      BCS $817F
 00:8172:EA          NOP
 00:8173:EA          NOP
 00:8174:EA          NOP
 00:8175:EA          NOP
 00:8176:EA          NOP
 00:8177:EA          NOP
 00:8178:EA          NOP
 00:8179:EA          NOP
 00:817A:EA          NOP
 00:817B:6A          ROR           <- Rotate 1 bit right because we're banking with 8KB banks, so we have 1 address line less to deal with.
 00:817C:8D 00 E8  STA $E800 <- This write originally went to $5FFA. We discard $5FFB write completely hence the NOPs.
 00:817F:60           RTS



- Relocate the stuff which used to get mapped at $E000-$FFFF to the end of the ROM image and fix some data the NSF had on the vectors position to stay at $FFE8 instead ...

(this is a work in progress)


Attachments:
Dancing Mad.zip [21.83 KiB]
Downloaded 58 times
Top
 Profile  
 
PostPosted: Sat Jul 26, 2014 2:11 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
Hi Ya,
l_oliveira wrote:
Yogi, while your goal (at the moment) seems to be pack a lot of songs on a cartridge, I wanted mostly to get the "in driver" banking working so I could play the longer, bigger songs.


Your efforts are greatly appreciated; I have barely scratched the surface of the NSF format and am trying to learn more. This project (the VRC7 and SNROM) is my first with the NES and it was something I thought I could:
A. Learn NES/Famicom development
B. Build something that feeds my personal interest and the Chiptune crowd.
So Please I hope you don't think I'm not interested in your project, just the opposite! :)
Quote:
Yesterday I did a experiment with a banked N163 song which at the moment only work on emulators. I'll do more testing to try to figure out why it only work on emulators but apparently seems to be a issue with the driver itself because when I tried a non banked song which used the same driver it failed with the same exact behavior.

This MCK driver is interesting because it seems to only bank $A000-$BFFF and $C000-$DFFF which matches perfectly the required behavior for operating on the real hardware.

Even then, I had to do some changes on the banking code:

- Modify mapper init on VegaPlay to init mapper for low bank numbers as I started to put the NSF at the start of the ROM file.
- Modify the NSF native init code to not touch memory regions used by VegaPlay.
- Modify the NSF banking code to not touch registers it's not supposed to and modify the actual banking code to use one 8KB bank instead of two 4KB banks:

Code:
Original:
 00:816E:C9 0E      CMP #$0E
 00:8170:B0 0D      BCS $817F
 00:8172:8D FA 5F  STA $5FFA
 00:8175:18          CLC
 00:8176:69 01      ADC #$01
 00:8178:C9 0E      CMP #$0E
 00:817A:B0 03      BCS $817F
 00:817C:8D FB 5F  STA $5FFB
 00:817F:60           RTS

Edited:
 00:816E:C9 0E      CMP #$0E
 00:8170:B0 0D      BCS $817F
 00:8172:EA          NOP
 00:8173:EA          NOP
 00:8174:EA          NOP
 00:8175:EA          NOP
 00:8176:EA          NOP
 00:8177:EA          NOP
 00:8178:EA          NOP
 00:8179:EA          NOP
 00:817A:EA          NOP
 00:817B:6A          ROR           <- Rotate 1 bit right because we're banking with 8KB banks, so we have 1 address line less to deal with.
 00:817C:8D 00 E8  STA $E800 <- This write originally went to $5FFA. We discard $5FFB write completely hence the NOPs.
 00:817F:60           RTS



- Relocate the stuff which used to get mapped at $E000-$FFFF to the end of the ROM image and fix some data the NSF had on the vectors position to stay at $FFE8 instead ...

(this is a work in progress)

Quite interesting; which disassembler do you use? I've tried FCEUltra but it's timing is not setup right or this XP box just doesn't like it; it runs very badly and stutters horribly. Looking for a stand alone disassembler.
I implemented the ControllerTest code you posted with mixed results. It runs fine and I think is faster on average, than the original routine I had; but the troubled NSFs have the same errors as when using the original code. So I'm thinking there is a subtle bug somewhere else. Or it is due to the frequency I read the controllers in the Main Loop and the timing of the DMA activity. In which case I will have to live with it and use the workaround of not reading the 'Right' button, which is not the worst thing (it speeds up the Main Loop). At the very least, the good news is I have a definite cycle count for each pass of the routine.
Also changed the handling of the Sprite ram, to allow easy reassignment of it's ram location. WRAM should be the safest place; if the NSF clears WRAM, it will destroy the runtime code as well, so this software will not support it anyway. But it's flexible enough if I needed to use system ram at some point or in another project.
I just ordered one of INL's Sunsoft 5B carts so next on the agenda is to try out your 5B code! Looking forward to it,
Yogi


Top
 Profile  
 
PostPosted: Sat Jul 26, 2014 2:24 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19237
Location: NE Indiana, USA (NTSC)
yogi wrote:
Looking for a stand alone disassembler.

I used da65 (from the makers of cc65) to recover my DPCM Split demo after a laptop died and all I had was the .nes binary.


Top
 Profile  
 
PostPosted: Sat Jul 26, 2014 2:46 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
tepples wrote:
yogi wrote:
Looking for a stand alone disassembler.

I used da65 (from the makers of cc65) to recover my DPCM Split demo after a laptop died and all I had was the .nes binary.

OK will give that a try, Thanks.


Top
 Profile  
 
PostPosted: Sat Jul 26, 2014 3:19 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6447
Location: UK (temporarily)
I have been astoundingly pleased with bisqwit's clever-disasm (part of nescom). ... but his site seems to be down at the moment.


Top
 Profile  
 
PostPosted: Sat Jul 26, 2014 3:30 pm 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 153
Location: freemland (NTSC-U)
The nescom part of site seems to be work for me... The git server looks like it's down, though.


Top
 Profile  
 
PostPosted: Sun Jul 27, 2014 6:40 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
l_oliveira wrote:
I'll do more testing to try to figure out why it only work on emulators but apparently seems to be a issue with the driver itself because when I tried a non banked song which used the same driver it failed with the same exact behavior.


I spent the WHOLE WEEKEND tinkering with this and in the end THERE WERE NOTHING WRONG WITH THE CODE.

-_______-;


The problem was fuxxoring crappy unreliable flash memories.

Several types of flash memory seem to be unreliable when used in a configuration where the /OE pin is to be tied to GND.
Even "high quality" Intel chips gave me this headache.
I suppose I'll stick to Atmel flash chips when working with 6502 based stuff ... :P

Once I burnt "Dancing Mad" on a Atmel flash chip the thing booted properly and played the song.

edit: Disassembler ? I'm loading the NSF file on FCEUX and debugging it there (debugger with conditional watchpoints and breakpoints, hexa editor/viewer and instruction logging, not to mention a very decent real time disassembler). The point of doing it this way is that you can watch things happening in real time. Also helps with learning the processor.


Top
 Profile  
 
PostPosted: Thu Aug 14, 2014 8:44 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
Just letting you know I didn't give up yet on this yet ... Just hella busy with other things ...

This is a very large banked song for you to listen to.

The VRC7 rocks, man !


Attachments:
File comment: VRC7
vegaplay.nes [136.02 KiB]
Downloaded 62 times
Top
 Profile  
 
PostPosted: Thu Aug 14, 2014 11:02 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6447
Location: UK (temporarily)
Crashes after I change the track number twice ?


Top
 Profile  
 
PostPosted: Thu Aug 14, 2014 12:55 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
lidnariq wrote:
Crashes after I change the track number twice ?


There's only one song on that .nes file. Famitracker driver still tries to find "song 2" even if there's none, hence the crash...


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 73 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group