It is currently Wed Dec 13, 2017 12:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Thu Nov 14, 2013 2:44 am 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
Ok so, I'm trying to make a multi song NES cart and I came across vegaplay and thought my prayers were answered. All up until I got about 3 songs into my writing (compiling some tests every step of the way as usual) I noticed that hitting the button for next song it will only go to track 2. Furthermore, if I hit up to go backwards one song, it will glitch out and play garbage. I've attached some test .nsf, .nes, and .asm files to show you what I mean. The nsf labeled 'orig' has the nsf header intact. Something important to note here is that I'm using MML to code my songs and I'm using the TextMate Multi-Song MML Bundle to compile the nsf.

I would really appreciate any help you can give me. I'm really running out of options when attempting to fit a album on a cart, cause I attempted famitracker but I can't figure out how to optimize file size as much as I can with MML. It comes nowhere close to as small as my mml versions. Being able to loop individual channels with |: \ :| can give me so much more memory.

Thank you for your time.


Attachments:
File comment: All the files I'm using.
Vegaplay issues.zip [9.91 KiB]
Downloaded 90 times
Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 6:51 am 
Offline

Joined: Thu Apr 14, 2011 9:27 pm
Posts: 85
Your problem is that your music engine is trying to use the same RAM that Vegaplay is using to store sprites and track numbers and so they're messing with each other's memory. You need to either change the memory locations your music engine uses, or edit vegaplay.asm to use $200 instead of $700 for the start of the sprite buffer.


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 1:44 pm 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
Where in the asm do you see $700? I had messed with lines 210 and 217 once before and I changed them to $200 because the help doc said to change it from the default $500 in case I was getting glitchy sprites, which I am, but I'm not concerned with the sprites. All I want is the music to play properly. And it had no effect anyway. I even tryed removing everything related to sprites, which got rid of the glitchy graphics but the music was still broken in the same way.

I'm kind of a beginner so I don't know how to change where the song numbers live or how to change the memory location of my music engine. Which is easier? Could you tell me the basics of how to do both the option you offered?


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 2:48 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6513
Location: Seattle
The relevant problem you're having is that the NSF is clearing all of memory for you, so it's a miracle the code works at all. Try replacing the bytes in your NSF from 0x0093 through 0x00A9 with the byte 0xEA.

As far as I can tell, your NSF is using random chunks all over the entirety of the NES's 2k of RAM. There's no large contiguous chunk of memory large enough to hold sprites, let alone predict where's safe for vegaplay to store its private variables. So "it's not you, it's them", not that helps you.

It tentatively looks like the bottom 16 bytes of memory ($00 through $0F) might be unused by your NSF, to use this you'll need to replace all the places in vegaplay.asm where anything else is used. This is both your $c1/$c2/$c3/$c4/$c5 but also vegaplay's use of $10 and $11 in DrawScreen, and you'll have to trash the sprites code (as you probably already knew)

By the way, the NES only has 2k of RAM, there's no point in the sta $0800,x or sta $0900,x instructions; they're entirely redundant to the earlier sta $00,x and sta $0100,x instructions.


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 3:01 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
Damn, Lidnariq beat me to it! :lol: I wonder if it's even worth it to try to use the stack $0100-$01FF (which isn't cleared) for the program's RAM. (Obviously no sprites, though!)

Let's say you want to change songs. The program depends on the previous song being in RAM. Except... the second you press the button to change the song, that RAM is cleared. That's why you could only get to track 2. Add one to current song. Play second track. But at the start of the second track, current song is made the first track again. Press down. Add one to current song... etc.


Edit: HAH! That totally works (The stack thing). Attached is a file that will work for you. As a bonus, I made it easier to change the number of songs. How complicated do you want your cart to be? Many of us could write a thing that could work in just the unused stack bytes (heh), as long as you're not going for epic presentation.


Attachments:
vegaplay.asm [6.45 KiB]
Downloaded 76 times

_________________
https://kasumi.itch.io/indivisible
Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 3:24 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5892
Location: Canada
An even more stealth way to use the stack is to push bytes on the bottom of the stack to reserve space at reset (or simply TXS a value lower than $FF). The lets you use some space, say $1F0-1FF, and the chances of it interfering are extremely improbable. The Powerpak NSF player does this, since some rare NSFs still use the low area of $100 for things, but none depend on the reset state of the stack (this would be forbidden by the NSF spec anyway).


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 3:37 pm 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
Wow, thanks that worked well. Kasumi, your asm made the song selection work alot better cause looping back to song one is now functioning. and lidnariq, your idea made the curser show up in the right places as well as allowed the third track to join the party. Though I might have fibbed when I said I didn't care about the sprites. The background is a must, but having the curser sprite would still be very nice. I'm working on a background image that I want to be displayed. But as far as what I'm trying to accomplish is I want to use up as much as the 30k as possible with song data. I want to fit a decent amount of music on the cart. Will the method of fixing the code be different depending on how full my music data gets? if so I guess I'll have to wait till I finish writing the album to come ask you wizards for help. If not I would greatly appreciate a modified asm I could work from.


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 3:46 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6513
Location: Seattle
Right now your NSF uses short arrays in RAM spaced all over it every 64 or 128 bytes, all the way from $0200 up to $07FF. It's hard to be sure what exactly that MML replay engine is doing, and whether they'll actually use all that space (in which case, no sprites for you) or are just pretending to be a gas (and expanding to fill all available space; in this case you could move things around to make space).

You should probably talk to the developer and ask what's going on, and if they might be willing to make a version that leaves 256 contiguous bytes for you somewhere.


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 3:54 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5892
Location: Canada
The PPMCK MML NSF engine clears RAM itself during init, which is annoying because the NSF player is required to do this ahead of time.

So, modifying the asm for you means modifying the PPMCK MML assembly for your NSF, not VegaPlay.

If PPMCK MML works by assembling the NSF with an assembler, then you should be able to make the changes to its source conveniently to prevent the problem in the future. There should be some code near the beginning of the assembly file that looks like this:

sta $200, x
sta $300, x
sta $400, x
sta $500, x
sta $600, x
sta $700, x
inx

Just comment it out, or whatever you need to do to get rid of it.

(I haven't looked directly at PPMCK MML source, I just have dealt with it in disassembly before.)


Top
 Profile  
 
PostPosted: Thu Nov 14, 2013 4:08 pm 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
To do what rainwarrior suggests, look for sounddrv.h in the MML package. (provided whatever I downloaded is actually what you mentioned)

Code:
   .memclear
      sta   $0000,x
      sta   $0200,x
      sta   $0300,x
      sta   $0400,x
      sta   $0500,x
      sta   $0600,x
      sta   $0700,x
      inx
      bne   .memclear


to
Code:
;   .memclear
;      sta   $0000,x
;      sta   $0200,x
;      sta   $0300,x
;      sta   $0400,x
;      sta   $0500,x
;      sta   $0600,x
;      sta   $0700,x
;      inx
;      bne   .memclear


Also, the screen won't cause any problems, just take out the semicolon before JSR DrawScreen on line 131. Instead of sprites, the background could be updated for a cursor, but that requires a bit more work. Also, if you want more than 10 songs (or as many will fit on the screen if you change it), that also becomes more work.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Nov 15, 2013 12:54 am 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
Nice. I found the sounddrv.h inside the MML Bundle, and changed it as you mentioned. It has the same result as when I padded the bytes 0x0093 through 0x00A9 in my nsf with 0xEA. I'm guessing that might be two way to skin the same cat? either way this is good progress. So now I'm unclear on whether you gentleman think that a curser will be doable or not. Well I guess technically I have a curser right now but it comes with glitchy tiles across the screen. Is there a reasonable coarse of action to get it working as intended? And also if that redrawing the screen idea is possible, will that eat more of my precious memory just for a curser?


Top
 Profile  
 
PostPosted: Fri Nov 15, 2013 1:33 am 
Offline
User avatar

Joined: Wed Apr 02, 2008 2:09 pm
Posts: 1046
Quote:
Nice. I found the sounddrv.h inside the MML Bundle, and changed it as you mentioned. It has the same result as when I padded the bytes 0x0093 through 0x00A9 in my nsf with 0xEA. I'm guessing that might be two way to skin the same cat?

Right. 0xEA makes the CPU do nothing for that instruction. So by replacing those bytes with 0xEA, the CPU is doing nothing instead of zeroing the RAM.

Removing the instructions from sounddrv.h just keeps them from being put in the NSF in the first place.

Quote:
So now I'm unclear on whether you gentleman think that a curser will be doable or not.

It's absolutely doable. A cursor on the background wouldn't use much memory. (Like... a byte or two because we need to keep track of where it is/was to draw/erase it.) Edit: Or... wait, if you mean ROM, it'll use some, but not a lot. Maybe less than 100 bytes?

The issue with sprites is the best way to draw them to the screen needs 256 contiguous bytes of RAM.

That said, someone still has to write you a thing. Which I guess I can do, but it obviously depends on the layout of your background being final which you said you were working on changing. Get that sorted, keep the distance between the songs the same and we'll probably be good.

Edit: Ah, two more things that may go without saying: 1. Leave actual ROOM for where you want the cursor. 2: Design the screen such that the same tile can be used to hide the cursor in all places you'd want it drawn. Maybe 2 isn't required, but it makes things easy.

_________________
https://kasumi.itch.io/indivisible


Top
 Profile  
 
PostPosted: Fri Nov 15, 2013 1:46 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6513
Location: Seattle
... Actually, do you want to use only one single sprite? Because I have got a goofy solution for you, then.

1- Leave 256 bytes of all FFs somewhere in your ROM, aligned to some multiple of 256 bytes.
2- In your UpdateSprites routine, write the upper byte of that address to $4014 (where it right now says LDA #$05, STA $4014 replace the #$05 appropriately)
3- Afterwards, write the following values in order to $2004: Y, tile number, attributes (e.g. color), X


Unrelatedly, there's some place in the PPMCK where it uses addresses $10 and $11, as does vegaplay. You should probably change one or the other.


Top
 Profile  
 
PostPosted: Fri Nov 15, 2013 1:58 am 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
If you are referring the the graphic track names when you say keep the same distance between songs then I'm ok with how that is working. I found that
Code:
Line:
        .db $37,$47,$57,$67,$77,$87,$97,$A7,$B7,$C7

are the locations of the curser on screen.
and that
Code:
sprites:
           ;vert tile attr horiz
        .db $37, $2D, $00, $17  ; sprite

is the initial place that sprite is drawn. $37 is the screen location, $2D is the Tile used from bank 2 of the .chr and $17 is a horizontal shift.


What I'm concerned with fixing in terms of 'getting the curser working' is removing all the glitchyness from the screen. It seems to move in time with the music and scroll through every tile in bank 2 of the .chr. Attached is the current state of the .nes


Attachments:
File comment: current .nes
vegaplay.nes [40.02 KiB]
Downloaded 76 times
Top
 Profile  
 
PostPosted: Fri Nov 15, 2013 2:02 am 
Offline

Joined: Fri Mar 08, 2013 12:19 am
Posts: 43
lidnariq wrote:
... Actually, do you want to use only one single sprite? Because I have got a goofy solution for you, then.

1- Leave 256 bytes of all FFs somewhere in your ROM, aligned to some multiple of 256 bytes.
2- In your UpdateSprites routine, write the upper byte of that address to $4014 (where it right now says LDA #$05, STA $4014 replace the #$05 appropriately)
3- Afterwards, write the following values in order to $2004: Y, tile number, attributes (e.g. color), X


Unrelatedly, there's some place in the PPMCK where it uses addresses $10 and $11, as does vegaplay. You should probably change one or the other.



I indeed only need one sprite for the curser. I'm up for anything that works. and what line in the vegaplay.asm are refering for those addresses? and how do you know that PPMCK uses them too? are they in one of the .h or asm files inside the MML Bundle?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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