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

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:

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 developmentB. 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:

- 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

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 ...

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.

Who is online

Users browsing this forum: No registered users and 2 guests

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