Preview of my modded VegaPlay

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Preview of my modded VegaPlay

Post by yogi » Fri Jun 06, 2014 6:24 pm

So here is a project that I've been working on.
It's a SNROM version of VegaPlay. With a 256KB flash you can load 7 non-banking NSFs <32K (you lose the vector table and trampoline bytes from each 32K 'slot'. One 32K 'slot' is used for reset code and CHR data that's banked out after reset.).
The runtime is loaded into WRAM during reset, leaving the PRG space for NSFs. The testing I've done so far: works with FamiTracker NSFs but can have strange behavior with other NSF Players. I use Nestopia so can't speak for other EMUs.
I've tried to simplify the loading and compiling process, you don't need to strip the header from the NSFs and there is a User Configure file to do all the editing in, so the main ASM file can be left alone.
Just drop all your NSFs into the build folder, edit User Configure with the NSF titles and load addresses and run the compile bat. It will spit out a .NES and/or a .PRG ready to flash.
With a compiler switch you can use the normal playback timing based on the NMI or use Sync pulses on controller 2 (this is based on FamiSlayer v6.66 by Heavyw8bit). I'm working on a cheap (16F628 based) Midi Clock to NES Sync24 converter. Testing a proto board, so both the HW and the NES rom could change as things progress.
These preview ROMs are NSFs from the FamiMiniCompo10, the User Configure.asm has the title info. NSF 1, 3 and 4 have strange behavior, plays for a short time then triggers a bankswitch. Still testing :)
The Pad1 controls:
Up/Down - song # (all these are single song NSFs so trying to run a song other than the first will crash it)
Left/Right - cycle thru the 7 NSFs
Start Button - Start/Stop playback

UPDATE 7/20/2014:
Added a preview rom with a fixed Read routines. No more strange behavior, at least from the NES :)

https://www.dropbox.com/sh/g6osy6uozook ... -yjh_7WJUa
Yogi
Last edited by yogi on Sun Jul 20, 2014 8:18 pm, edited 2 times in total.

User avatar
Kreese
Posts: 65
Joined: Sat Sep 22, 2007 3:42 pm

Re: Preview of my modded VegaPlay

Post by Kreese » Thu Jun 12, 2014 4:58 pm

This sounds promising. The limitation of songs in Vegaplay has been a problem for me.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi » Thu Jun 12, 2014 5:57 pm

Kreese wrote:This sounds promising. The limitation of songs in Vegaplay has been a problem for me.
Same here, it was my motivation. I hope it will be useful, if people would like a 512K build it's not too much of an issue. The main thing I wanted was a 'no fuss' tool to put music on real hardware.
I haven't changed the UI very much so there is lots of room there for improvement, but OTH I'm considering turning the PPU off during playback for the best sync timing. I'm finishing up a HW Midi Clock to Sync24 interface and after some testing will know how much NMI calls affect the playback.
Yogi

User avatar
l_oliveira
Posts: 404
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira » Mon Jul 14, 2014 5:29 am

Just to let you know, Vegaplay code for pad reading has that problem with DPCM DMA transfers causing false positives to button presses.
For obvious reasons this is actually a SERIOUS problem considering that DPCM will be used extensively within the music playback code.

To fix it I had to change this:

Code: Select all

ControllerTest:

        LDA NewButtons
	STA OldButtons

        LDX #$00
	LDA #$01		; strobe joypad
	STA $4016
	LDA #$00
	STA $4016
ConLoop:
	LDA $4016		; check the state of each button
	LSR
	ROR NewButtons
        INX
        CPX #$08
        bne ConLoop
into this:

Code: Select all

ControllerTest:

        LDA NewButtons
	STA OldButtons

	LDA #$01		; strobe joypad
	STA $4016
	LDA #$00
	STA $4016

	lda #$80
	sta NewButtons
ConLoop:
		LDA $4016
		AND #$03
		CMP #$01
		ROR NewButtons
		BCC ConLoop
to stop the input from glitching on the FAMICOM. Original code work perfectly fine on a NES (as you already know).

My project is play VRC6 songs on real hardware. I still need to tackle banking. Great job at banking here, considering that MMC1 banking is harder to deal with than VRC6!

I'll be using this for "classic" (2A03 only) NSFs! :D

P.S.:Thanks to blargg for the very smart bit of code which does the controller read using "ring buffer" idea with the carry bit.

The issue at hand:
viewtopic.php?t=4116
The solution used here is leeched from this:
viewtopic.php?t=4124

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Preview of my modded VegaPlay

Post by thefox » Mon Jul 14, 2014 10:28 am

l_oliveira wrote: into this:
I don't see how this fixes anything. To avoid problems due to the DPCM glitch, you need to read the controller multiple times. Also the problem is not Famicom specific, it also occurs on CPU revisions used in NTSC NESes.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
tokumaru
Posts: 11764
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Preview of my modded VegaPlay

Post by tokumaru » Mon Jul 14, 2014 10:33 am

thefox wrote:I don't see how this fixes anything.
Indeed. I fail to see how switching from counting with the X register to waiting for a flag bit will help at all. If the controller gets clocked, the bits read after this will be wrong with either kind of loop.

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Preview of my modded VegaPlay

Post by tepples » Mon Jul 14, 2014 10:55 am

Perhaps the multiple reads settle faster if three of them can be done in one DMC fetch period (432 cycles). Not needing to bookkeep with X makes this more likely.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi » Mon Jul 14, 2014 10:56 am

l_oliveira wrote:Just to let you know, Vegaplay code for pad reading has that problem with DPCM DMA transfers causing false positives to button presses.
For obvious reasons this is actually a SERIOUS problem considering that DPCM will be used extensively within the music playback code.

To fix it I had to change this:

Code: Select all

ControllerTest:

        LDA NewButtons
	STA OldButtons

        LDX #$00
	LDA #$01		; strobe joypad
	STA $4016
	LDA #$00
	STA $4016
ConLoop:
	LDA $4016		; check the state of each button
	LSR
	ROR NewButtons
        INX
        CPX #$08
        bne ConLoop
into this:

Code: Select all

ControllerTest:

        LDA NewButtons
	STA OldButtons

	LDA #$01		; strobe joypad
	STA $4016
	LDA #$00
	STA $4016

	lda #$80
	sta NewButtons
ConLoop:
		LDA $4016
		AND #$03
		CMP #$01
		ROR NewButtons
		BCC ConLoop
to stop the input from glitching on the FAMICOM. Original code work perfectly fine on a NES (as you already know).
Thanks much for this 'heads up'. Does sound like the glitches I have observed; a random advance to the next NSF ( = to a 'Right' button press on controller 1). The odd thing, in my case, is I have the glitches testing on Nestopia (haven't tested on real HW yet) and the the same NSFs have the glitch when played via the NMI or via the 'SlayerSync' variable timing, which so far amounts to me banging controller 2's trigger button to advance the Frame plays at a very slow rate.
The Frame at which the glitch occurs ( through different for each of the troubled roms) seems to be fixed, regardless of the timing; so leads me to conclude the the trigger is associated with a particular Frame's actions. A false controller read due to a DPCM could account for the behavior but I doubt that Nestopia emulates the hardware this closely.
My project is play VRC6 songs on real hardware. I still need to tackle banking. Great job at banking here, considering that MMC1 banking is harder to deal with than VRC6!

I'll be using this for "classic" (2A03 only) NSFs! :D

P.S.:Thanks to blargg for the very smart bit of code which does the controller read using "ring buffer" idea with the carry bit.

The issue at hand:
viewtopic.php?t=4116
The solution used here is leeched from this:
viewtopic.php?t=4124
The first iterations of this project was focused on VRC7 playback and banking, but I changed direction due to the access to La Grange Point vers SNROM based NES carts :) I do have a working rom with VRC7 banking (limited testing on Nestopia only).
yogi

User avatar
l_oliveira
Posts: 404
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira » Mon Jul 14, 2014 10:58 am

tokumaru wrote:
thefox wrote:I don't see how this fixes anything.
Indeed. I fail to see how switching from counting with the X register to waiting for a flag bit will help at all. If the controller gets clocked, the bits read after this will be wrong with either kind of loop.
If you guys had a Famicom you could test it. I wish I had means to explain what is going on.
I simply don't have enough engineering background to even get close to understand this behavior.


Original code randomly jumps down on the track list during music playback.
Jumping stopped completely when I changed the code. And of course as you see there's no multiple reads involved.

Edit:

Videos of it running on a real Famicom: (controller code already changed)
https://www.youtube.com/watch?v=PxXf0KBTvnI
https://www.youtube.com/watch?v=Pgu7l_XpE1A

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Preview of my modded VegaPlay

Post by thefox » Mon Jul 14, 2014 11:06 am

yogi wrote:A false controller read due to a DPCM could account for the behavior but I doubt that Nestopia emulates the hardware this closely.
Nestopia does emulate this glitch behavior.

l_oliveira: The fact that it works with the modified code is probably just luck. If you want a robust approach, read the controller multiple times. People often say to read multiple times until you get matching reads, but it may be theoretically possible that two consecutive reads get corrupted. In the thread you linked there's a routine by blargg that always reads the controller 4 times and should never fail (IIRC it can guarantee this because of the timing of the routine).

EDIT: I realized (thanks to rainwarrior at #nesdev) that it shouldn't be possible for two consecutive reads to get corrupted if the reading routine is sufficiently fast enough. From a quick look at blargg's code it seems like it reads 4 times only because there's a chance that the button state may change inbetween the reads. But I didn't look further into it.
Last edited by thefox on Tue Jul 22, 2014 8:45 am, edited 2 times in total.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

zzo38
Posts: 1070
Joined: Mon Feb 07, 2011 12:46 pm

Re: Preview of my modded VegaPlay

Post by zzo38 » Mon Jul 14, 2014 11:07 am

Another way to avoid this problem with DPCM may be to disallow any functions while music is playing except to push the "A" button to stop it, and then you can push the direction buttons and START button to play the next music. (I believe the "A" button can be read without DPCM interference.)
[url=gopher://zzo38computer.org/].[/url]

User avatar
l_oliveira
Posts: 404
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira » Mon Jul 14, 2014 11:13 am

Are you guys interested on testing this ? If so I can share the sources and the test roms I am working with.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi » Mon Jul 14, 2014 11:19 am

thefox wrote:
yogi wrote:A false controller read due to a DPCM could account for the behavior but I doubt that Nestopia emulates the hardware this closely.
Nestopia does emulate this glitch behavior.
Wow, did not realize. This sheds a new light on things. Will have to investigate this more; had assumed it was due to different trackers frame play code.
yogi

User avatar
l_oliveira
Posts: 404
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira » Mon Jul 14, 2014 2:58 pm

I tested the ROM which glitches on the Famicom in Nestopia 1.40 and there isn't a single sign of the glitch anywhere.
It's as if it was being run in a NES. Works fine on my NES.

I don't understand what is going on here, at all ... lol

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Preview of my modded VegaPlay

Post by tepples » Mon Jul 14, 2014 4:41 pm

It might be a timing difference ultimately resulting from a difference in PPU/CPU alignment between the Famicom and NES. Anything that affects PPU/CPU alignment is likely to affect 6502/APU alignment within the CPU because normally, the program running on the 6502 waits for the PPU to warm up before doing anything. I know the PPU reset line isn't connected one way on the front-loading NES and the other way on the Famicom and top-loading NES.

Post Reply