It is currently Mon Nov 20, 2017 6:48 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 73 posts ]  Go to page 1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Jun 06, 2014 6:24 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
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.

Top
 Profile  
 
PostPosted: Thu Jun 12, 2014 4:58 pm 
Offline
User avatar

Joined: Sat Sep 22, 2007 3:42 pm
Posts: 65
This sounds promising. The limitation of songs in Vegaplay has been a problem for me.


Top
 Profile  
 
PostPosted: Thu Jun 12, 2014 5:57 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 5:29 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
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:
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:
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 10:28 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 10:33 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10114
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 10:55 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 10:56 am 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
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:
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:
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.

Quote:
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 10:58 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 11:06 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Last edited by thefox on Tue Jul 22, 2014 8:45 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 11:07 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
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.)

_________________
.


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 11:13 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
Are you guys interested on testing this ? If so I can share the sources and the test roms I am working with.


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 11:19 am 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 2:58 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
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


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 4:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19234
Location: NE Indiana, USA (NTSC)
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.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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