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

Re: Preview of my modded VegaPlay

Post by yogi »

l_oliveira wrote: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.
OH COOL, I do have a couple YMs I got for this project. I Like the 555 auto reset, I hadn't addressed the reset properly.
Yogi
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

It's actually a lot simpler than what you thought:
Image
(this is enough to make the YM2413 work properly without any side effects)

And I have a feeling that the mapper is using internally a logic function which is equivalent to a 74LS138 to decode all the register addresses...

Here's a little table I wrote at the time I was trying to see the big picture of the VRC7 registers decoding:

Code: Select all

_____AAAAAAAAAAAAAAAA
_____1111110000000000
_____5432109876543210
______***______**____  <- * means "do care"
8000 *000000000000000
8010 *000000000010000
9000 *001000000000000
9010 *001000000010000
9030 *001000000110000
A000 *010000000000000
A010 *010000000010000
B000 *011000000000000
B010 *011000000010000
C000 *100000000000000
C010 *100000000010000
D000 *101000000000000
D010 *101000000010000
E000 *110000000000000
E010 *110000000010000
F000 *111000000000000
F010 *111000000010000
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Preview of my modded VegaPlay

Post by lidnariq »

yogi wrote:I knew it used the VRC7 mapper but does it have a functional FM core?
Sure does, but you'll have to rewire it pretty substantially to get it a clock source and a reasonable audio amplifier.
At ~$30 without an adapter, it does sound much better.
Waitamoment... the US release of TTA2 does not use the VRC7. You'll still need an adapter or a total rebuild of a cartridge.


Two 74'521s and a 74'20? Seems more complex than a few 74'138s...
Especially 'cuz we know the VRC7 is only paying attention to A12..A15, A5, and (A4 xor A3): not A6 or A7.

74'138: A14=0, A13=0, A12, A4, /ROMSEL=0, R/W=0. Decoding on A12 and A4 lets you capture all five PRG/audio registers. Still use the 74'20 for WRAM and to prevent bus conflicts. ... Need another inverter from somewhere... ... er, and what l_oliveira said.

edit: remove bad advice
Last edited by lidnariq on Sun Jul 20, 2014 1:55 pm, edited 1 time in total.
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

lidnariq wrote: Still use the 74'20 for WRAM and to prevent bus conflicts. ... er, what l_oliveira said.
In my case, the real VRC7 is there and it has control of the ROM chip enable strobe. It certainly put the ROM "to sleep" when R/W is low.

If you're going to implement banking, I'd suggest a couple of 74LS670s.

a 74LS138 and a 74LS139 could be used to generate strobes which could then be combined using ports of 74LS32s to select.

But then due to the complexity of this, a PAL/GAL chip would be a better alternative for the combinational logic.

Using common sense we end figuring out that this stuff would be best fit within an modest CPLD chip after all. ;)
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

l_oliveira wrote:It's actually a lot simpler than what you thought:
Image
(this is enough to make the YM2413 work properly without any side effects)

And I have a feeling that the mapper is using internally a logic function which is equivalent to a 74LS138 to decode all the register addresses...

Here's a little table I wrote at the time I was trying to see the big picture of the VRC7 registers decoding:

Code: Select all

_____AAAAAAAAAAAAAAAA
_____1111110000000000
_____5432109876543210
______***______**____  <- * means "do care"
8000 *000000000000000
8010 *000000000010000
9000 *001000000000000
9010 *001000000010000
9030 *001000000110000
A000 *010000000000000
A010 *010000000010000
B000 *011000000000000
B010 *011000000010000
C000 *100000000000000
C010 *100000000010000
D000 *101000000000000
D010 *101000000010000
E000 *110000000000000
E010 *110000000010000
F000 *111000000000000
F010 *111000000010000
Ok, so /Y1= /ROMSEL & A4 & /A12 & /A13 & A14
ADR b100x xxxx xxx1 xxxx, wouldn't this mirror at $8010 as well as $9010. Thinking about this, I guess for my design with a bank reg @ $8000 and the YM regs @ $9010 and $9030, 2- '138s would handle it, but would have to move A4 to /G2A or B for the $8000 address decoder. Isn't M2 relevant here or is it a factor of the /ROMSEL, so it's accounted for?
And Yes A5:A7 are not needed but I had the extra pins on the '521s (not a good reason to add the wires, I know).
Lidnariq wrote:74'138: A14=0, A13=0, A12, A4, M2=1, R/W=0. Decoding on A12 and A4 lets you capture all five PRG/audio registers.
Shouldn't A14=1 for $8xxx or $9xxx and in both cases A12 should be 0? b100x for both $8 or $9. What am I missing, will have a look at the '138 truth table.
Yogi
EDIT- just figured it out The correct adr bit pattern bx001 xxxx xxx1 xxxx true for $9010 if we include /ROMSEL for Bit 15. And bx000 xxxx xxx0 xxxx & /ROMSEL is true for $8000.
Doh!
Last edited by yogi on Fri Jul 18, 2014 9:29 pm, edited 1 time in total.
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

There's absolutely no mirroring in the way you mention.

Because the 74LS138 considers A14,A13 and A12 on it's logic, the YM2413 will be mirrored at the whole 9000-9FFF range.
But then the FM synth inside the VRC7 mirrors in the exact same way.

For 8000 we have A15=1 A14=0 A13=0 A12=0 and for 9000 we have A15=1 A14=0 A13=0 A12=1, hence me connecting the YM2413 to Y1.
A4 is connected to non inverted G enable of the 74LS138 to prevent the YM2413 from appearing at 9000.

M2 is the actual source of CPU chip select signals on this system. /ROMSEL already brings M2 encoded in itself as it's just M2 when A15=1. You already know that since you exploit that to generate a chip select for WRAM.

Edit:
yogi wrote: What am I missing, will have a look at the '138 truth table.
What you are missing is that the binary number being input on the three inputs correspond exactly to which output will be active:

321 <- inputs
000=Y0
001=Y1
010=Y2
011=Y3
100=Y4
101=Y5
110=Y6
111=Y7

(Y will be 0 only when /G1=0 /G2=0 and G1=1)

What is actually output depends on the status of the three G pins. Two are inverted and both need to be connected to gnd and the non inverted enable must be connected to +5v to make the selected output active.
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

l_oliveira wrote:There's absolutely no mirroring in the way you mention.

Because the 74LS138 considers A14,A13 and A12 on it's logic, the YM2413 will be mirrored at the whole 9000-9FFF range.
But then the FM synth inside the VRC7 mirrors in the exact same way.

For 8000 we have A15=1 A14=0 A13=0 A12=0 and for 9000 we have A15=1 A14=0 A13=0 A12=1, hence me connecting the YM2413 to Y1.
A4 is connected to non inverted G enable of the 74LS138 to prevent the YM2413 from appearing at 9000.

M2 is the actual source of CPU chip select signals on this system. /ROMSEL already brings M2 encoded in itself as it's just M2 when A15=1. You already know that since you exploit that to generate a chip select for WRAM.

Edit:
yogi wrote: What am I missing, will have a look at the '138 truth table.
What you are missing is that the binary number being input on the three inputs correspond exactly to which output will be active:

321 <- inputs
000=Y0
001=Y1
010=Y2
011=Y3
100=Y4
101=Y5
110=Y6
111=Y7

(Y will be 0 only when /G1=0 /G2=0 and G1=1)

What is actually output depends on the status of the three G pins. Two are inverted and both need to be connected to gnd and the non inverted enable must be connected to +5v to make the selected output active.
I just worked out what I was missing. Looking at the '138s inputs A, B & C with A12, A13 & A14 ADR - $x001, but what I was SEEING was ADR bit15, 14 and 13 - $100x. In truth /ROMSEL active accounts for ADR Bit 15, so Bits 14:12 completes the MSNibble of the address. Hence the state of A12 determines if the nibble is $8 or $9. Got it.
/Y1 = /G2 & A & /B & /C & G1 = /ROMSEL & A12 & /A13 & /A14 & A4
Got to take a brake,
Yogi
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

So thinking along these same lines
138 ADR decoder 2.png
138 ADR decoder 2.png (4.43 KiB) Viewed 4803 times
Came up with this
Yogi
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

So wahoo \o/ fixed the Read routines.

Code: Select all

Controller1Test:  ; Check Controller 1 till we get matching reads in a row
               LDA NewButtons		; Get last pass button state
	       STA OldButtons		; Save to OldButtons

Chk_Loop1:   ; Read Controller till we get two consecutive matching reads
		LDA NewButtons
		STA LastPass            ; save copy of last state
		JSR Check_Joy1        ; Read Pad 1
		LDA NewButtons       ; Button State returned
		CMP LastPass           ; same as last?
	        BNE Chk_Loop1        ; loop if reads don't match. 
(sorry about the weird formatting above, can't get the forum to cooperate)
The Chk_Loop1 will run a min of 2x but not sure what the max would be during heavy DMAs.
Added a preview ROM into the dropbox on on the first post.
Yogi
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

I've been testing blargg's "DPCM resistant" controller read code and it doesn't help at all with this problem.

If your solution works for the controller issue, it still creates a problem, which is holding up the processor during NMI processing....
Fortunately that problem is of easy solution:

Because the controller read routine and related processing doesn't rely on anything that *MUST* be done during NMI we can move it away from the NMI processing and insert it on the main loop (which is just a jump instruction which jumps on itself) and then we don't waste processor cycles during the NMI processing. To mod it to work that way we would just need to move the "ControllerTest" code to the "InfLoop" routine and remove the JSR instruction which originally called it.

Funny enough, when I did that, the bug manifested itself on FCEUX. Probably means that FCEUX is coded in a way that the the bug simulation code won't trigger if the processor core is doing interrupt processing...

Oh well...

Test case file added (includes asm listing) with controller stuff moved to main loop. Uses blargg's code for controller read. Music change instruction was removed so the music driver don't crash while "the cursor is dancing" ...
Attachments
Vegaplay_testcase.zip
Vegaplay ROM for VRC6 (32KB only are used, no banking)
(13.67 KiB) Downloaded 174 times
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Preview of my modded VegaPlay

Post by thefox »

l_oliveira wrote:I've been testing blargg's "DPCM resistant" controller read code and it doesn't help at all with this problem.
You're not using the code properly. The DPCM glitch resistant button state byte is returned in A, it's not in tmp1.

EDIT: I didn't notice the listing file in the package so the variable name is not tmp1 in this case, obviously.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

VegaPlay testcase 2 here. Original controller code was put on main loop.

Again, listing included.

Edit: Test case 3 included
Attachments
vegaplay_testcase3.zip
(13.77 KiB) Downloaded 168 times
vegaplay_testcase2.zip
(13.42 KiB) Downloaded 166 times
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

l_oliveira wrote:I've been testing blargg's "DPCM resistant" controller read code and it doesn't help at all with this problem.

If your solution works for the controller issue, it still creates a problem, which is holding up the processor during NMI processing....
Fortunately that problem is of easy solution:

Because the controller read routine and related processing doesn't rely on anything that *MUST* be done during NMI we can move it away from the NMI processing and insert it on the main loop (which is just a jump instruction which jumps on itself) and then we don't waste processor cycles during the NMI processing. To mod it to work that way we would just need to move the "ControllerTest" code to the "InfLoop" routine and remove the JSR instruction which originally called it.

Funny enough, when I did that, the bug manifested itself on FCEUX. Probably means that FCEUX is coded in a way that the the bug simulation code won't trigger if the processor core is doing interrupt processing...

Oh well...

Test case file added (includes asm listing) with controller stuff moved to main loop. Uses blargg's code for controller read. Music change instruction was removed so the music driver don't crash while "the cursor is dancing" ...
I watched your 1st test rom, thanks. That sprite behavior doesn't seem like the DMA bug to me; more of a case of the sprit data or pointer getting over written. It doesn't affect the NSF playback so its not changing the 'SongNumber' VAR that is passed to the InitMusic routine. Just saw that you commented out "JSR InitMusic" at the end of EndDrawChk:
Should recheck your ControllerTest:
NewButton3 is the first Read; stack holds the second Read; NewBotton2 is the third Read; 'A' then holds the fourth read but you overwrite it from the stack with the second Read.
A> CMP second Read to first Read, and exit to JoyEnd if Equal.
B> If not Equal, CMP second Read to NewButtons (which seems like it's undefined) and exit to JoyEnd if Equal.
C>If not Equal get the third Read (which may or may not match the first two Reads) and drop into JoyEnd and RTS.
Thinking you wanted a four Read test routine, but it is only testing the first two reads and assuming the third Read will be good if the first two fail. The undefined NewButtons is part(all) of the problem. That may solve your sprite/NewSong problem but you will need to restructure to get the four Read testing working, I think. I would also avoid the stack it may be a problem also if other code is using it in the NMI; or Not.

The configuration I'm using with the MMC1 code, has the bulk of the logic in the main loop. It's based on the VegaPlay fork called FamiSlayer v6.66
http://www.heavyw8bit.com/famislayer.php
The NMI routine I use only does a few tests to either call the NSF Frame Play code or let the Main loop do the Frame Play. The choice is based on a Assembler definition 'Sync'. It will never changed at runtime, so could be rewritten with IFDEFs to eliminate the Sync check.

Code: Select all

NMI:	   	;Extern NMI = NSFroutine + $021F
			; Save regs to stk
	PHA
	TXA
	PHA
	TYA
	PHA
    JSR UpdateSprites	
	LDA StartMode		; Mode CHK: 1=PLAYING OR  0=STOPPED
    BEQ NMIexit			; IF STOPPED, We're done
	LDA #Sync			; Test Sync option
	CMP #$01
	BEQ NMIexit			; If Sync = 0, NSFplay via NMI
	JSR RamPlay			; go sub to NSF Play vector
NMIexit:	; Restore regs from stk
	PLA
	TAY
	PLA
	TAX
	PLA
			; Fall into IRQ for RTI

IRQ:		;Extern IRQ = NSFroutine + $023A
    RTI
Though I had tried another Controller Read routine that had a fixed structure- 'read twice; CMP both; and do again if no match' , it had issues but could have been the surrounding code. Also tried not using the 'RIGHT' button at all, this solved the DMA issue but complicated the UI layout. But it did demonstrate to me that the the DMA bug seems to only affect Bit7. Anyone know for sure?
With the controller read loop I posted, in most cases it will execute twice, but I don't know the max pass count with DMA interference.
It plays all the NSF that had failed before, without the 'false trigger' bug, but I did notice a slight tempo slow down that occurred after 2-5 mins of play time on a file (testing on Nestopia). I'm not convinced of the reason; could have been caused by a Windows' background tasks or some other code issue. Needs more testing but not sure there is a tempo fix, in my case, for NSFs that heavily use the DPCM channel aside from just not using the 'RIGHT' button.
Yogi
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: Preview of my modded VegaPlay

Post by l_oliveira »

After very useful insights from thefox at #NESDEV IRC I got this to work properly.

This time I included the asm file so yogi, give this controller read code a try on your sources for MMC1...
Attachments
vegaplay_testcase4.zip
(16.58 KiB) Downloaded 169 times
yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: Preview of my modded VegaPlay

Post by yogi »

Thanks man, I'll look it over but my code is working with the new controller Read code I posted.
Yogi
Post Reply