It is currently Thu Oct 19, 2017 8:31 pm

All times are UTC - 7 hours





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

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
Did anyone ever make a test ROM for demonstrating the DPCM problem?

I've run stuff before that I thought should have been subject to the problem on both my Famicom and NES, but so far I've never seen a spurious right-press. Is this a thing that doesn't happen on some Famicom or NES revisions?


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 5:05 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Did anyone ever make a test ROM for demonstrating the DPCM problem?

I made Eighty, which requires an NES Four Score and demonstrates the preferred DPCM glitch detection method for that device. But it won't run on the original RF Famicom because the NES Four Score works only with NES (front- and top-loading) and AV Famicom. Should I make another test ROM for DPCM glitching without the Four Score?


Top
 Profile  
 
PostPosted: Mon Jul 14, 2014 6:11 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 920
tepples wrote:
But it won't run on the original RF Famicom because the NES Four Score works only with NES (front- and top-loading) and AV Famicom. Should I make another test ROM for DPCM glitching without the Four Score?
Yes, not only for that reason, but also in case you have NES without Four Score, or to test it with emulators not emulator Four Score.

_________________
.


Top
 Profile  
 
PostPosted: Tue Jul 15, 2014 1:04 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
I can confirm that the glitches are due to DPCM samples. I added a folder to the Dropbox on the first post, which has a .NES rom and the User Configure.asm (Disclaimer: none of the songs used are my work, all have been DLed from FT Fourm). To test, I edited a FTM file and exported the song with two versions, one with DPCM (NSF #3 & #6) and the other (NSF #4 & #7) without. As soon as the Samples start playing it triggers a bankswitch (triggers a false 'Right' button).
SO... it's good that I know what the problem is; now just got to work out a better controller read routine.
Thanks for all the input, this helped alot!
Yogi

PS the first two NSF in the ROM are a test of FT's engine speed custom setting. One at 60Hz and the other at 30Hz playback.


Top
 Profile  
 
PostPosted: Tue Jul 15, 2014 2:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
What I do is read the controllers twice, and if they don't match, use the previous frame's data. A tested example is in pads.s in this project template.


Top
 Profile  
 
PostPosted: Tue Jul 15, 2014 3:15 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
tepples wrote:
What I do is read the controllers twice, and if they don't match, use the previous frame's data. A tested example is in pads.s in this project template.

Thanks tepples! I'll follow your example. Such a weird thing!
Yogi


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 9:14 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 394
Location: Brasilia, Brazil
Man let's work together so we don't need to do all the work twice ! :D


VRCVI:
http://www.youtube.com/watch?v=PxXf0KBTvnI
http://www.youtube.com/watch?v=Pgu7l_XpE1A
The VRCVI hardware is just a Madara cart with holes and sockets for eproms/eeproms. It was modified to use INES 24 registers layout.

VRCVII:
http://www.youtube.com/watch?v=yZNW1MwnLRQ

Hardware picture:
Image

I need to work with the banking stuff still and this part is where we should join up to define a standard way of doing it.


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 9:52 am 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
l_oliveira wrote:
Man let's work together so we don't need to do all the work twice ! :D


VRCVI:
http://www.youtube.com/watch?v=PxXf0KBTvnI
http://www.youtube.com/watch?v=Pgu7l_XpE1A
The VRCVI hardware is just a Madara cart with holes and sockets for eproms/eeproms. It was modified to use INES 24 registers layout.

VRCVII:
http://www.youtube.com/watch?v=yZNW1MwnLRQ

Hardware picture:
Image

I need to work with the banking stuff still and this part is where we should join up to define a standard way of doing it.


WOW, Cool vids! nice work!! Yes we can work out a early ALPHA release for testing :) would love to see/hear it on HW!!
My rom isn't ready for general release but does work on Nestopia. As built, it assumes 128KB Eprom, but can be expanded without too much work. Let me know your Eprom target size.
The kernel and NMI code resides in the last 8K bank, so max NSF size is 24K, starting at $8000.
The docs are 'lacking' and out of date, but the code is commented (excessively). If you have the time to read through the code, should be able to get the gist.
I'll clean it a bit and do a 'quick start' guide (not too different from VegaPlay) and zip it up. 'Own risk' and all that :)
Yogi


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 10:23 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 394
Location: Brasilia, Brazil
My current idea is put the driver code *too* at the fixed page (we can have two different source codes as it won't be too much of a hassle) and we use the songs as .asm includes.

Would be something like this:

VRC6:
0x8000-0xBFFF -> Song data banking
0xC000-0xDFFF -> DPCM data banking
0xE000 -> Song driver and VegaPlay

VRC7:
0x8000-0x9FFF -> Song data banking
0xA000-0xBFFF -> Song data banking
0xC000-0xDFFF -> DPCM data banking
0xE000 -> Song driver and VegaPlay

My current target size is 256KB/256KB. VRC6 supports only 256KB for PRG but VRC7 supports 512KB.

VRC6 has CHR mapper capabilities comparable to that of MMC5 (MMC5 has a lot more features though) but the PRG banking is quite lame/meh.
VRC7 has decent PRG mapper capabilities but it gimps CHR (it can't do rom nametables, for example).

In our case, original VRC7 carts use CHR RAM but I am using CHR ROM for sake of saving space on PRG ROM. My cart has WRAM so it can be used for code storage. CHR ROM can be used as "offline" data storage which could in turn be copied to WRAM for execution.


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 2:35 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
l_oliveira wrote:
My current idea is put the driver code *too* at the fixed page (we can have two different source codes as it won't be too much of a hassle) and we use the songs as .asm includes.


That is how I handled it. The CHR data, Reset and a part of the NMI code are in two 8K banks (we lose 16K for these). During the NMI the bulk of the controller read and logic code is banked back in. When we are ready to play the next frame, we jump to the NMI code in the fixed bank and the current NSF banks are restored and we JSR to the play address and then exits the NMI.
Banking of NSFs is done with 3 - 8K banks at a time, each of these 24K blocks contain an NSF. So with a 128K rom this allows 4 NSFs, 3 at 24K and the last at 31K max. This is all based on a 128K device, with a 256K you could have 7.
My Fixed bank code is less than 200 bytes at the top of mem, so the last NSF can overlap onto the lower part of this fixed bank.

With the MMC1 that I have been working on, all of the runtime code is in WRAM and during normal play, NSF banking is done with 32K blocks. During a reset, the MMC switches to 16K banking, that makes the Reset code visible in the top 16K bank.

Quote:
Would be something like this:

VRC6:
0x8000-0xBFFF -> Song data banking
0xC000-0xDFFF -> DPCM data banking
0xE000 -> Song driver and VegaPlay

VRC7:
0x8000-0x9FFF -> Song data banking
0xA000-0xBFFF -> Song data banking
0xC000-0xDFFF -> DPCM data banking
0xE000 -> Song driver and VegaPlay


Your approach does give you tight control over the placement of song data and would work well for album production. How difficult is the preparation process for the song data? Hand editing of the raw data? If it can be automated with a script that would help users.
I wanted to maintain the VegaPlay NSF structure; many users of VegaPlay are more interested is making music and less knowledgeable about NES kernels. It has it's downside, wasteful of the space and dependent on the Export routine's default memory usage, but for a musician it's far less complicated.

Quote:
My current target size is 256KB/256KB. VRC6 supports only 256KB for PRG but VRC7 supports 512KB.

VRC6 has CHR mapper capabilities comparable to that of MMC5 (MMC5 has a lot more features though) but the PRG banking is quite lame/meh.
VRC7 has decent PRG mapper capabilities but it gimps CHR (it can't do rom nametables, for example).

In our case, original VRC7 carts use CHR RAM but I am using CHR ROM for sake of saving space on PRG ROM. My cart has WRAM so it can be used for code storage. CHR ROM can be used as "offline" data storage which could in turn be copied to WRAM for execution.


I debated CHR ram vs rom, but giving up the space for the CHR seemed the best trade off. With VegaPlay the background is static so it is a bit of a waste with RAM, but I only have to worry about the PRG when flashing.
Yogi
EDIT: I have added a test VRC7 .PRG and .NES to the dropbox in the first post


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 3:32 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 394
Location: Brasilia, Brazil
My hardware has a socket for CHR ROM but it has a CHR RAM (32Kb banked) piggy backed on the solder side of the board.

A pair of switches toggle A18 on/off (when off it puts the pin 31 at +5v which is ideal for 256 or 128Kb flash chips) and CHR ROM/CHR RAM mode.
The cart can run Lagrange Point as it if A18 is enabled and CHR is set to RAM mode.

Also the limit here is 512KB.

I'll need some time to study the code you sent me and decide what I'll do with my own code which is just a small patch on the original code. Atm most of the work I spent was spent on the hardware side of the thing.

Edit: Do you have means to assembly hardware stuff at your side ?
It might be possible to make some simple circuit that add a standard YM2413 to the NES and on that case you don't really need a VRC7 to play own compositions. ;)


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 4:23 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
l_oliveira wrote:
My hardware has a socket for CHR ROM but it has a CHR RAM (32Kb banked) piggy backed on the solder side of the board.

A pair of switches toggle A18 on/off (when off it puts the pin 31 at +5v which is ideal for 256 or 128Kb flash chips) and CHR ROM/CHR RAM mode.
The cart can run Lagrange Point as it if A18 is enabled and CHR is set to RAM mode.

Also the limit here is 512KB.

Very good, nice dev cart. You are using a VRC 7, how did you come by it? I was thinking of getting a LGP famicom cart but didn't want to layout the cash for it and a Fami-to-NES adaptor ATM.
AS far as the ROM size goes, at the time I was working on the code just picked 128K out of the blue, the way the rom is layed out not much effort to increase the size.

Quote:
I'll need some time to study the code you sent me and decide what I'll do with my own code which is just a small patch on the original code. Atm most of the work I spent was spent on the hardware side of the thing.

Edit: Do you have means to assembly hardware stuff at your side ?
It might be possible to make some simple circuit that add a standard YM2413 to the NES and on that case you don't really need a VRC7 to play own compositions. ;)

Hum, funny you should ask, been working on a modified VRC7 hack with a YM2413. The idea is to implement the two VRC7 sound addresses and just the first banking register address at $8000. All banking would be in 24K blocks. It would be compatible with VRC7 NSFs and the VegaPlay code I have; just no 8K banking. I got it mostly prototyped but not tested yet. Kind of went on the back burner till I get the MMC project done.
Yogi


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 4:55 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6285
Location: Seattle
yogi wrote:
I was thinking of getting a LGP famicom cart but didn't want to lay out the cash for it and a Fami-to-NES adaptor ATM.
If you're already up for rework, Tiny Toon Adventures 2 is a little bit cheaper on ebay. (Looks like ~$28 instead of ~$35)
Quote:
All banking would be in 24K blocks.
How would 24K blocks work? Specify an offset as a multiple of 8 KiB? Multiply by 3? 32 KiB where the top 8 KiB is concealed?


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 5:29 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 394
Location: Brasilia, Brazil
I commented about the YM2413, because the small chip in the middle of the board happens to be a YM2413 which is connected to 0x9010/0x9030 and receives the same writes as the VRC7 FM core. It's operating properly and produces music without distortion or wrong sounding notes. (save the rom patches being different)

The 74LS138 is there to provide decoding for the YM2413 enable. It does leech it's clock from the VRC7 crystal oscillator.

The 555 timer IC is there as a "missing pulse detector", which monitors the phy2 signal. That provides a proper power on reset for the YM2413 and when phy2 stops changing states, YM2413 reset is held high, stopping the sound completely.

So the connection of YM2413 to the NES/Famicom is a non issue atm.


Top
 Profile  
 
PostPosted: Fri Jul 18, 2014 6:13 pm 
Offline

Joined: Sun Nov 17, 2013 8:14 pm
Posts: 133
Location: Bowie, Maryland
lidnariq wrote:
yogi wrote:
I was thinking of getting a LGP famicom cart but didn't want to lay out the cash for it and a Fami-to-NES adaptor ATM.
If you're already up for rework, Tiny Toon Adventures 2 is a little bit cheaper on ebay. (Looks like ~$28 instead of ~$35)

I knew it used the VRC7 mapper but does it have a functional FM core? I remember seeing some discussion and guesses on if it can do expo sound but didn't think anyone had done it. It does seems likely that they would use the same chip but...
At ~$30 without an adapter, it does sound much better.

Quote:
Quote:
All banking would be in 24K blocks.
How would 24K blocks work? Specify an offset as a multiple of 8 KiB? Multiply by 3? 32 KiB where the top 8 KiB is concealed?


You're right, 32K banks (been awhile since I reviewed the sch) With the bulk of the kernel in WRAM and some bytes in each bank lost to the reset vectors and bankswitch trampoline. One bank loses the space for the CHR data and Reset code. We still end up with 7 30-31K banks and one 18-20K on a 256K device.
Attachment:
VRC Lite V0.1.png
VRC Lite V0.1.png [ 21.09 KiB | Viewed 1543 times ]

IC3 Bank Reg decoder- /W & PHI & 1000xxxxx000xxxx
IC2 YM decoder- /W & PHI & 1001xxxx00x1xxxx
Yogi


Last edited by yogi on Fri Jul 18, 2014 6:39 pm, edited 1 time in total.

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  Next

All times are UTC - 7 hours


Who is online

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