On and off over the past few weeks I've been sketching out on paper what I think would be a workable NES tracker. I just wanted to get some opinion on whether people think it would be a worthwhile endeavour?
I'm quite excited about the idea but the one big "fly in the ointment" at the moment is the issue of being able to save your song.
I've worked out a reasonable memory map using the 8Kb SRAM to store a complete song but that presents problems. How do you save your song with a file name? How do you save multiple work-in-progress versions of the song?
I was thinking I could somehow utilise the save game feature of PowerPak but, to be brutally honest, I've never actually managed to get it to work (with a game ROM) despite reading the instructions several times
Of course, it would work fairly easily using Nestopia (or your emulator of choice, providing it supports SRAM saving) but it would be cool to run it on actual hardware.
Sounds good. People have made tools that run in the NES itself before. I think Celius made a level editor or something, and if I'm not mistaken Memblers did something too.
To make things easier, you could make a PC application to extract the relevant data out of the SRAM file. If you want to handle file names and such on the NES side, you can create your own pseudo file system, so that the names of the files, as well as their sizes, would be stored somewhere in the SRAM file, and then your PC application would extract the files out of your made up file system.
Well, if the main target is the Powerpak, maybe you should consider writing files to the CF card? This way the 8KB SRAM (or 32KB even) would be used for keepings the tune(s) in memory while tracking, and for saving files you'd use the CF card. Emulator users on the other hand could just use multiple save states. Or Lua scripting if you prefer FCEU.
That said, I've never been a big fan of this "wouldn't it be cooler to have the development environment actually running on a NES". I simply believe the least akward way of creating code and content for a console, which was never meant for creating new things on, is to use the most modern computer available to you. But never the less I look forward to trying out your results! :)
Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me. If the tracker is made to play files with a cool viewer and not to edit them then it's another story.
Bregalad wrote:
Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me. If the tracker is made to play files with a cool viewer and not to edit them then it's another story.
Mr Cup-Is-Half-Empty....
I've always wrote NES music in a text file so I know what you mean. However, a native tracker offers some advantages such as live tweaking of sounds which could be useful both in a compositional use and a "live" use - give you the ability to "mix" a song in real time. Kind of like LSDJ....but on NES.
(Though I don't actually know much about LSDJ so I could be talking rubbish
)
Bregalad wrote:
Making a tracker work with the NES controller doesn't sound more exiting to place .db statements in notepad to me.
Do .db statements in Notepad:
- allow starting playback at any point?
- allow easy visualization of envelopes?
- guarantee that your music bytecode is consistent?
- allow viewing the relationships in time of commands across multiple channels?
- run on the target platform, for composing in a handheld-based emulator while on the bus? (One can assemble a .nsf from source on a netbook but not realistically anything smaller.)
A tracker does.
Quote:
If the tracker is made to play files with a cool viewer and not to edit them then it's another story.
The sort of "cool viewer" I'd appreciate would involve something like D-Pad Hero or DDR GB.
I'm working on mocking up the screen layout and will try to explain the approach/controls when that is done.
@Tepples: some interesting points there, some that I had overlooked or that won't work with the approach I've taken with the design. I've not gone for a traditional tracker where each pattern has the same number of steps for each voice but more based on a track->sequence format. I was inspired mostly by Ninja Tracker (C64) as it has a simple one-screen layout. I'll explain once I've got the screen mocked up.
Although I'm guilty of being one of the people who'd likely prefer a mouse and keyboard set-up, I've heard many others wish for an LSDJ equivalent NES tracker. People will be interested, there is no doubt about that!
I also have an idea that I think would be pretty awesome for a live play mode. It'd be a nice bonus that would set it apart from other trackers, and would be something that I'd certainly make use of. I'll shoot you an e-mail.
I guess I have the same opinion as Banamos. I would prefer a better tracker compatible in many OS than a tracker inside the platform itself since the inputs and screen estate are limited. With the current state of nes emulation, the needs to do it on the actual console directly become less an issue. I'm sure that even with the latest console, we don't make the music directly on it.
But this is just my personal opinion. It will still be interesting to see the final result for the technical aspect of it.
My opinion is identical to that of Bananmos and Banshaku, for what it's worth.
I'm not starting a line of code until I've resolved several issues.
The main one being just how someone would actually use the thing, especially in respect of being able to load/save their work. If I can't find a workable solution to that one, I don't think it's worth doing. I probably need to take a look at LSDJ and see how that's used (unless someone here can give us a brief overview of how loading/saving aspect is done, or indeed if it does at all?)
The other one is coming up with a clever data system for the note patterns. You have so little RAM to work with (in SRAM) that I see this as the biggest technical challenge.
As for the joypad input, I think I've worked out quite a good system for most of the editing but there are a few instances that I've yet to figure out.
The easy bit is the actual audio player so I'm not thinking about that yet.
As for using on *actual* hardware, I'm not suggesting that that would be the only use/reason for a NES tracker. Actually I was thinking more along the lines of being able to use it within an emulator. Seeing as there are so many good NES emulators, it might even be as platform agnostic as writing a Windows/Mac tracker that emulates NES audio. What about running it on, say, the iPhone NES emulator? Composing NES tunes in your pocket?
neilbaldwin wrote:
That link supposed to go somewhere meaningful?
thefox wrote:
neilbaldwin wrote:
That link supposed to go somewhere meaningful?
I thought I'd put the screen up there in the hope of promoting some discussion.
I was going to type up some design ideas but it was 1.00am and I was tired and also spotted a few holes in my paper scribbles so I went to bed instead.
neilbaldwin wrote:
The main one being just how someone would actually use the thing, especially in respect of being able to load/save their work. If I can't find a workable solution to that one, I don't think it's worth doing. I probably need to take a look at LSDJ and see how that's used (unless someone here can give us a brief overview of how loading/saving aspect is done, or indeed if it does at all?)
I'm not 100% what you want to know here. If you mean how people save their work they've made on the actual game boy, there are game boy flash carts available with tools to extract the .sav file. (Much like how a .sav file would be put on a compact flash card with the powerpak). Or... they just use an emulator and get that save. So if you distribute an SRAM enabled rom, there's no issue there, as the powerpak or any emulator would accomplish the same thing.
If you mean how the program's save interface works, it allows you to save multiple files in the one SRAM file. At the bottom of the interface it tells you how many "blocks" you've used of the SRAM. The songs are shown in a list, with the number of blocks used by the song. When you save you're allowed to enter an 8 character filename to distinguish the files from one another. As well, it keeps track of how many times a file has been saved, and that number is displayed on the left of the file name, so if you have two versions of the same file you know which one was saved the most times. (which would usually be the most recent one) You can also delete and load files from this menu. Also, the file you're currently working on is stored uncompressed in 32kb, so you can turn the power off without saving and your song should still be there. (Wouldn't recommend that though, unless you're in a big hurry)
If you mean how the program compresses its save data, I can't be of much help : (
But rather than me ranting about the program, you REALLY should check out LSDJ yourself! The full (and save enabled) rom is only 2 USD, and the demo version (missing some features, and can't save) is free, so there's no reason not to check it out, especially since you want to make another native tracker using the exact same button layout. Or even if you don't want to mess with the rom, read the documentation pdf available on the site to see how it's laid out.
LSDJ has a great interface designed for an even smaller screen than NES has available to it, and the controls allow for much faster tracking than you'd think. I like it even better than some PC trackers. Even if you don't want to copy it completely, LSDJ has probably solved a lot of the problems you'll run into, especially those related to input/screen economy. The much smaller SRAM space NES has becomes a problem though, but with a similar compression scheme to LSDJ I think you could fit at least three small songs in 8k.
Kasumi wrote:
The much smaller SRAM space NES has becomes a problem though
On both the Game Boy and the NES, PRG RAM is an 8 KiB memory area, but Game Boy mappers are more likely to support bankswitching this. The only boards I know of with more than 8 KiB of PRG RAM are
SXROM and
EWROM. (SOROM and ETROM back up only half of their 16 KiB PRG RAM.) Neither of these is common: SXROM is Japan-only, and EWROM was used for one game: Romance of the 3 Kingdoms 2. More importantly, I'm not sure how widely supported they are in emulators and copiers originating from 72-pin territories. If it doesn't work on PowerPak and PocketNES, there really isn't much of an advantage of an NES-native app; one might as well use an app for a netbook that compiles NSF to play through Blargg's Game_Music_Emu.
Thanks Tepples, Kasumi - some interesting and useful information.
I have to say I'm a little less optimistic. It's a real shame - I think the 8K RAM is the Achilles Heel of the whole concept. Dividing up the RAM for the necessary data tables, it doesn't leave you much room to play with in terms of storing music data. And because the normal RAM is so small there doesn't seem much scope for using that as a work area then compressing the data to SRAM for saving.
My original though was to utilise the entire SRAM for one song. On PowerPak, could this be workable? Would it be easy to manage several different save files?
Progress Update
First off I totally redesigned the layout and have come up with what seems (through consulting a few tracker users) an acceptable layout and a (make-the-best-of-limited-resources) SRAM memory map.
I figured one of the most important aspects of how the editor will feel is to have a quick as possible screen data refreshing. I've coded a scalable refresh system for each "panel" of information - you specify how many lines and how many lines-per frame need updating. What this means is that you can make sure you specify a as-fast-as-possible refresh speed for the editing "panel" you are currently in and any other panels that don't currently have focus can be instructed to refresh at a slower speed. It works really well so far.
However, to get the maximum possible speed, I'm doing absolute read/writes from buffers to screen i.e.
lda buffer
sta $2007
lda buffer+1
sta $2007
lda buffer+2
sta $2007
and so on. Thus all my "screen writes" go to the buffers and the buffers are instructed when/how much to throw at the screen per frame.
While this is fast, the downside is that it's taking up a massive amount of code space (there's a total of over 600 lda/sta pairs to handle the various buffers).
Just wondering if anyone has any clever ideas for a fast-but-ROM-space-efficient DMA methods?
I might end up optimising the speed downwards once the editor is fully working but I can't tell yet how it's going to pan out.
neilbaldwin wrote:
Just wondering if anyone has any clever ideas for a fast-but-ROM-space-efficient DMA methods?
I wrote about the trick I use for fast Name Table updates in
this post. With careful manipulation of the index register you can have an unrolled transfer loop just as fast as the one you currently have but more versatile because the source address is not so hardcoded, it can be manipulated to some extent.
The current implementation of this technique that I'm using has only 32 pairs of LDA STA (instead of the 128 like in the sample code) because that's the longest a contiguous NT update will be, so it doesn't take much ROM. That limits me to copying up to 32 bytes at a time from anywhere in a buffer of 128 bytes.
I don't know what exactly you are updating (Name Tables? Pattern Tables?) and how the data is divided, so I can't give more specific suggestions, but with some indexing and by breaking your long runs of LDA STA into smaller ones (partially unrolled loops) it should be possible to reduce ROM use without much loss of speed.
tokumaru wrote:
neilbaldwin wrote:
Just wondering if anyone has any clever ideas for a fast-but-ROM-space-efficient DMA methods?
I wrote about the trick I use for fast Name Table updates in
this post. With careful manipulation of the index register you can have an unrolled transfer loop just as fast as the one you currently have but more versatile because the source address is not so hardcoded, it can be manipulated to some extent.
The current implementation of this technique that I'm using has only 32 pairs of LDA STA (instead of the 128 like in the sample code) because that's the longest a contiguous NT update will be, so it doesn't take much ROM. That limits me to copying up to 32 bytes at a time from anywhere in a buffer of 128 bytes.
I don't know what exactly you are updating (Name Tables? Pattern Tables?) and how the data is divided, so I can't give more specific suggestions, but with some indexing and by breaking your long runs of LDA STA into smaller ones (partially unrolled loops) it should be possible to reduce ROM use without much loss of speed.
It's all NT transfers. I have 5 areas of the screen (22 x 6, 27 x 12, 5 x 6, 5 x 6, 5 x 6, 5 x 14) that need updating so I have a set of LDA/STA sequences for each area. I've split them into lines so, for example, the first area has 6 subroutines that writes 22 characters from the buffer to the screen. If I want to update one line of the area I can. If I need to update the whole area I call each of the six subroutines in turn.
Ironically it's the 27 x 12 one that needs updating the fastest
Yeah, that's a lot of stuff to update. The 27 x 12 area alone is already too much to do in a single (NTSC) VBlank, even with the fastest unrolled code possible.
If you don't need to update the screen every frame (which is probably the case, since you're showing information for humans to read and they just can't read stuff that changes as fast as 60Hz), a full Name Table can comfortably be written in 4 VBlanks, so you could take your time and draw all the new info to the hidden Name Table and display it when it's ready, so screen updates would happen at 15Hz, maybe this is enough for your purposes.
What exactly is the 27 x 12 area? If by any chance it's a window with scrolling stuff (I read something like this about your tracker), instead of doing software scrolling you could do hardware scrolling by drawing the scrolling text/numbers to the alternate NT and use a split screen effect to display any portion of it that you wish. This way you'd only have to update a single line at a time, much like games that scroll (they only draw the new tiles that enter the screen, the parts that were already visible are just shifted by hardware scrolling).
EDIT: BTW, in this thread I saw that you were having problems with memory constraints. I don't know if you have solved that or not, but I figured I'd suggest this anyway: If there are free tiles at the sprite or background side of the pattern tables, you could use CHR-RAM (if you aren't already), group all the unused space together and use it as an extra block of memory. Of course this memory is much more difficult to use than regular RAM or WRAM (since you can only access it through $2006/7 and while not rendering), but it's still usable if you're short on memory. I'm sure there is some data that doesn't need constant access that could be stored there.
tokumaru wrote:
Yeah, that's a lot of stuff to update. The 27 x 12 area alone is already too much to do in a single (NTSC) VBlank, even with the fastest unrolled code possible.
If you don't need to update the screen every frame (which is probably the case, since you're showing information for humans to read and they just can't read stuff that changes as fast as 60Hz), a full Name Table can comfortably be written in 4 VBlanks, so you could take your time and draw all the new info to the hidden Name Table and display it when it's ready, so screen updates would happen at 15Hz, maybe this is enough for your purposes.
What exactly is the 27 x 12 area? If by any chance it's a window with scrolling stuff (I read something like this about your tracker), instead of doing software scrolling you could do hardware scrolling by drawing the scrolling text/numbers to the alternate NT and use a split screen effect to display any portion of it that you wish. This way you'd only have to update a single line at a time, much like games that scroll (they only draw the new tiles that enter the screen, the parts that were already visible are just shifted by hardware scrolling).
EDIT: BTW, in this thread I saw that you were having problems with memory constraints. I don't know if you have solved that or not, but I figured I'd suggest this anyway: If there are free tiles at the sprite or background side of the pattern tables, you could use CHR-RAM (if you aren't already), group all the unused space together and use it as an extra block of memory. Of course this memory is much more difficult to use than regular RAM or WRAM (since you can only access it through $2006/7 and while not rendering), but it's still usable if you're short on memory. I'm sure there is some data that doesn't need constant access that could be stored there.
Yeah, far too much
As I said in the previous post, I have a dynamic drawing system so I can tell the drawing routine to only DMA 1 line per-frame or as many as there is time in the VBLANK to process. That's not really the problem. Thanks for all the information and suggestions though, it's really appreciated.
The big 27 x 12 area is the note data editing window. Yes, essentially I'm software scrolling it (or will be once it's written). It's a window onto data that can be a maximum of 48 lines deep (48 steps in a sequence of note data). The "12" in the dimensions is because I'm only showing 12 lines at any time. I don't really get how hardware scrolling could help me there. I know how hardware scrolling works (in principle) but surely the problem is similar - I'd still have to be able to shift 11 x 27 lines of text up or down somehow once I've scrolled the other screen 8 pixels?
That CHAR-RAM idea is nice, didn't think of that
neilbaldwin wrote:
The big 27 x 12 area is the note data editing window. Yes, essentially I'm software scrolling it (or will be once it's written). It's a window onto data that can be a maximum of 48 lines deep (48 steps in a sequence of note data). The "12" in the dimensions is because I'm only showing 12 lines at any time. I don't really get how hardware scrolling could help me there.
Excuse my crappy drawing, but look a this:
Here are the 2 Name Tables. The first one has the basic screen layout you want your interface to have, and the second one contains nothing but the list of note data. To display the list in the red area of the first NT, you'll have to use a sprite hit, IRQ, whatever to detect the start of the red area. At that point you modify $2005/$2006 to point to the first line of the note list you want to display. After 96 scanlines (12 lines of data) you change the scroll back to the first NT.
You have to use vertical mirroring, so that the list wraps around, and then you'll only need to draw a single row at the bottom or the top of the list as new information needs to be displayed (no need to update the whole 12 lines, hadware scrolling will take care of displacing the other 11), exactly like any game that scrolls vertically.
Of course the process of switching from one NT to the other varies a little depending on where you want the red box to be. It's easier if it's at the very top or the very bottom of the screen, because then you'll need to switch Name Tables only once during the frame, but if you have the means to count 96 scanlines (IRQs or timed code, for example) it isn't much harder to have it by the middle.
another advantage of this is that you can even smooth scroll the list if you want to, so that it looks more pleasing.
Maybe I'm misunderstanding but it seems that would work as long as you had no more than 30 lines to display (i.e. the whole of the 2nd NT).
If you need to scroll 64 lines, surely there is still some manual shifting of the data to do?
In other news: after reading your other thread I changed the two largest unrolled loops to be only half-unrolled. Works like a charm
Yes, you will run out of lines eventually, but rather than shift all data manually you can adjust to the fact that the nametable will wrap around from line 29 to line 0 again, and write your lines there. Essentially, you'll need to treat the second nametable as a kind of circular buffer for pattern lines.
Of course, this makes updating a little more akward and means you cannot keep your entire PPU version in the pattern all at once, only a portion of it, but it'll still save you PPU updates with the tradeoff of more complicated code for the nametable updates.
In case something wasn't clear, here are two animations that might help.
Scrolling:
The red square is the new scroll point you have to set during rendering. The red box shows what part of the second NT gets displayed during rendering, as seen in the animation at the left.
Updating (when necessary):
Here you can see how wrapping works. As long as you have NT mirroring set to vertical, setting the scroll to after line 18 will cause line 00 to be automatically displayed after line 29. So all you have to do is rewrite line 00 with new information. As long as you rewrite the lines before they are displayed, it will look like a continuous list. Lines that need rewriting are highlighted in red in the animation.
As you can see, you only need to rewrite 1 line at a time. Sure it adds some complexity (not much, really), but IMO it's better than reducing the frame rate or shoving too much stuff in the NMI. As a plus, like I said before, you get the chance to use smooth scrolling, which looks much better IMO.
Bananmos wrote:
this makes updating a little more akward
The updating is actually pretty simple. If instead of having special checks to update only when it wraps, it's much simpler start only with lines 00-11 drawn (leave anything on lines 12-29, as they won't be displayed initially anyway), and
always draw a new line just below the red box (or above, if you scroll up) when scrolling happens. It's a pretty strightforward process.
What is a bit awkward, IMO, is having to switch from one NT to the other and then back, but it's perfectly possible and if done right it will look perfect, no user will be able to tell what's happening.
Actually, I'm not 100% sure that smooth scrolling is such a good idea in this case... it'll sure look nicer, but it might also be a little deceiving since the lines in a tracker layout visualize how each line is a discrete entity, whose effect takes place the instant you switch to it, and having things go smoother might make this less obvious. Then again, this may be a non-issue that won't give any bother after all. Only way to know is to compare and see for yourself :)
tokumaru wrote:
a full Name Table can comfortably be written in 4 VBlanks, so you could take your time and draw all the new info to the hidden Name Table and display it when it's ready, so screen updates would happen at 15Hz, maybe this is enough for your purposes.
Unless you're tracking at 150 BPM (tempo $96) with 32nd note resolution (speed 3).
Quote:
What exactly is the 27 x 12 area? If by any chance it's a window with scrolling stuff (I read something like this about your tracker), instead of doing software scrolling you could do hardware scrolling by drawing the scrolling text/numbers to the alternate NT and use a split screen effect to display any portion of it that you wish.
What's the best way to do more than one split (one at the top of the region, one at the bottom) on a mapper without a scanline or CPU cycle counter and without wasting over one-third of the CPU time? Or what mapper with such a counter is replicable?
Quote:
you could use CHR-RAM (if you aren't already), group all the unused space together and use it as an extra block of memory. Of course this memory is much more difficult to use than regular RAM or WRAM (since you can only access it through $2006/7 and while not rendering)
Given that someone's already having trouble fitting things into 2300 cycles, I'm not sure how helpful that would be.
I know this is kinda going against the grain here, but there is one advantage to having the patterns not scroll at all - you can edit it while it's playing. Though this could come off as looking kind of cheap, to anyone who doesn't care about that feature.
tepples wrote:
Unless you're tracking at 150 BPM (tempo $96) with 32nd note resolution (speed 3).
I know that reducing the frame rate isn't the best solution.
Quote:
What's the best way to do more than one split (one at the top of the region, one at the bottom) on a mapper without a scanline or CPU cycle counter and without wasting over one-third of the CPU time?
I can't think of anything. You either use IRQs or waste time (waiting for a sprite 0 hit). But depending on how he arranges the interface the scrolling window might be at the top or at the bottom, and then only one split will be necessary.
Considering the type of program he's making, wasting a chunk of time that big might not be such a problem, as it shouldn't be as CPU-intensive as games. If it's in edit mode, it will only do anything upon user input, and even with some of the time missing the response should still feel real-time enough. In playing mode, I doubt a music playback engine, as complex as it may be, will need more than 50% of the CPU time.
Quote:
Given that someone's already having trouble fitting things into 2300 cycles, I'm not sure how helpful that would be.
By using hardware scrolling he gains a lot of cycles. Also, I said this could be done for data that isn't accessed often, as in not every VBlank. For a game I can think of a few kinds of data I would store there (game status information that is only accessed between levels, checkpoint information, maybe even level maps, depending on their format), but for a tracker I'm not sure, maybe he can think of something.
Tepples, are you against the idea of using hardware scrolling? 'Cause it seems you showed up just to bash my ideas. I suggested what I did because it's simply impossible to update 400+ bytes of NT data in a single frame (unless a considerable amount of the screen was cut for extra blanking time, but that's not so trivial either).
tokumaru wrote:
You either use IRQs or waste time (waiting for a sprite 0 hit).
Waiting for a sprite 0 hit isn't any more of a waste of time than waiting for vertical blank because you don't have to maintain a
constant cycle count up to that point, just keep that part of the frame under a
maximum cycle count. It's finding something to do while waiting exactly 96*341/3 = 10,912 cycles that's a problem.
Quote:
But depending on how he arranges the interface the scrolling window might be at the top or at the bottom, and then only one split will be necessary.
Different TVs have different overscan amounts, especially at the top and bottom.
Quote:
Tepples, are you against the idea of using hardware scrolling?
No, I'm just confused about the best way to implement it. I
want hardware scroll to work. It's just that I investigated this a few years ago when I
tried to implement an e-book reader with a proportional font on the NES. I ended up needing 1. a more accurate emulator than was available on the DVD player in question, and 2. two split points to change from pattern table 0 to 1 to 0 or from pattern table 1 to 0 to 1 when the player scrolled the text. Around that time, I thought of a long-shot method that involved waiting for sprite 0 at the top split and then abusing DMC IRQ as a crude timer to do something useful while waiting for the bottom split. But then, I had no writable cart to test it on. Now I do, and I want to prove myself.
Quote:
'Cause it seems you showed up just to bash my ideas.
Perhaps I'm just the Adi Shamir to your Ron Rivest, blowing holes in your arguments to encourage all of us to
make them stronger. Rivest would propose a cipher, and Shamir would find the hole in it.
tepples wrote:
Waiting for a sprite 0 hit isn't any more of a waste of time than waiting for vertical blank because you don't have to maintain a constant cycle count up to that point, just keep that part of the frame under a maximum cycle count. It's finding something to do while waiting exactly 96*341/3 = 10,912 cycles that's a problem.
Yeah, I got that, I just got confused when I mentioned sprite 0, I wanted to say "waiting 96 scanlines", sorry. The hit is used to detect the first split point.
Quote:
Different TVs have different overscan amounts, especially at the top and bottom.
Sure, but a tracker sure will use a lot of the screen area.
Something will have to be close (in a way that he considers safe) to the edges of the screen, even if it's not the scrolling window. And if
something has to be there, why not the scrolling window, to make the split operation simpler?
Quote:
No, I'm just confused about the best way to implement it.
Yeah, so am I. I'm not too fond of the idea of wasting a lot of cycles either.
Quote:
Perhaps I'm just the Adi Shamir to your Ron Rivest
Everyone's Ron Rivest I guess, you're always looking for problems and alternatives! =) It's true, you are the very definition of the devil's advocate! XD But I guess you are right, in the end that should help us reach a better solution.
@Memblers : currently I'm only thinking about scrolling the window as you edit as opposed to the scrolling following the play head.
@tokumaru & tepples : plenty of food for thought gentlemen, great stuff.
@tokumaru : I absolutely love your animated diagram. Makes perfect sense now
I'm not far off getting to the stage where I'm able to edit the data at which point I'll be able to have a play around with the scrolling method a bit more.
Update time again
OK, so now I'm making progress with the editor side and have pretty much got the Song Editor window working and partly got the Pattern Editor working (you can scroll around it at least).
I wanted to try a new thing and have video screen-grabbed me navigating around in Nestopia.
http://dutycyclegenerator.com/#NTRQ-Video-1
Another video update;
http://dutycyclegenerator.com/#NTRQ-Video-3
The editor is pretty advanced now
looks great, really looking forward to hearing it scream :)
It does look good. I don't know much about music or trackers, so I'm not really sure what everything is, but it certainly looks promising.
One thing worries me though: there are absolutely no margins in that interface. This will probably limit the usability of this tool on real hardware, because TVs tend to cut the edges of the frame. I don't know if this has changed with LCD and plasma TVs, but not being able to use it on hardware kinda kills the point in having a native tool.
tokumaru wrote:
It does look good. I don't know much about music or trackers, so I'm not really sure what everything is, but it certainly looks promising.
One thing worries me though: there are absolutely no margins in that interface. This will probably limit the usability of this tool on real hardware, because TVs tend to cut the edges of the frame. I don't know if this has changed with LCD and plasma TVs, but not being able to use it on hardware kinda kills the point in having a native tool.
I have a top and bottom margin of 8 pixels (losing the top and bottom line of the screen). I turned on the "NTSC stuff" in Nestopia and it cropped a pixel or two off the right-hand side but you could still see the numbers. Ignore the very top numbers - they are just debug sprites.
Weirdly, on my TV (NTSC NES->AV amp->60Hz plasma), it's the top two lines (of characters) that are cut off and not the top and bottom.
Is there a definitive guide for this stuff?
neilbaldwin wrote:
Ignore the very top numbers - they are just debug sprites.
Ah I see. I've seen some TVs hiding a good deal of the right side of the picture, but I believe the tracker should be usable on most TVs then.
Quote:
Weirdly, on my TV (NTSC NES->AV amp->60Hz plasma), it's the top two lines (of characters) that are cut off and not the top and bottom.
I had 2 CRTs hat did the same thing.
Quote:
Is there a definitive guide for this stuff?
No, each TV behaves differently, it seems. IIRC, CRT TVs could even be calibrated (by a technician, not a regular user) so that the image was more centered. I don't know if plasma/LCD has something like that.
My guideline: If you can see it in PocketNES's scaled mode, you can see it on a TV.
tepples wrote:
My guideline: If you can see it in PocketNES's scaled mode, you can see it on a TV.
Nice
I just tried this but using VisualBoyAdvance to run the PocketNES ROM. Vertically it's fine as you're only missing the top line of text but horizontally I'm losing the left-most and right-most column.
The top third of the interface (Song Info, Song Editor) is OK as I can move both of these panels in towards the centre.
The biggest problem is the Instrument/Table Editor. I need to rethink that bit as it uses the whole 32 char width of the screen.
The latest version of the editor runs really quite cool in PocketNES.
However, some of the features require you to hold B+A then press another button but I couldn't seem to make it work (works on the NES). Can anyone that runs this on actual hardware (I'm going to get myself set up) confirm that you can actually do this and it's just a limitation (for some reason) of VisualBoyAdvance?
neilbaldwin wrote:
However, some of the features require you to hold B+A then press another button but I couldn't seem to make it work (works on the NES). Can anyone that runs this on actual hardware (I'm going to get myself set up) confirm that you can actually do this and it's just a limitation (for some reason) of VisualBoyAdvance?
Not to worry: I reconfigured the keys in VBA and it works fine now.
Had a quick go at a different layout.
Means;
- I've lost one line of the Pattern Editor
- The Song Info abbreviations are slightly more obscure. SNG=Current song number, TMP=Current song tempo, PLN=(global) Pattern length and PNS=maximum number of patters (changes dynamically as you change the global pattern length, hence being darker as you can't edit the number directly). Make sense?
- I've had to lose my 6th "Aux" byte from the instruments but as I'd yet to think of a use for it I guess it's no great loss
+ Slightly less to draw per frame
+ Will display OK on PocketNES and, I guess, most NTSC TVs
You might spot that there's a blank line between the Song Editor and Pattern Editor but this will be put to use for some simple key-press hints at a later stage so I want to keep that.
neilbaldwin wrote:
PNS=maximum number of patters (changes dynamically as you change the global pattern length, hence being darker as you can't edit the number directly).
So it doesn't stand for
PiNgaS? I wonder if there's another abbreviation that's less, ummm, suggestive.
I looked at several of those videos and I'm still none the wiser.
Say "P-N-S" aloud. I was trying to point out where pre-teen and teenage boys using your tracker might giggle, but point it out obliquely (hence politely).
tepples wrote:
Say "P-N-S" aloud. I was trying to point out where pre-teen and teenage boys using your tracker might giggle, but point it out obliquely (hence politely).
Ha ha, I totally didn't see that
PTS then?
Another video update;
http://dutycyclegenerator.com/#NTRQ-Video-4
I think I'm done with most of the editing features now so next stage (after Christmas) is the audio coding.
If anyone is genuinely interested I'll make the ROM available to play with. Would love some feedback from that too.
Neil
I wish I had any idea what any of this meant
Latest video update, this with with audio;
http://dutycyclegenerator.com/#NTRQ-Video-5
i'm speechless.. don't really know what to say besides... wow, me likes
Yeah, that's pretty impressive.. might try my hand at making a couple of songs with it.
Yeah, since sound doesn't work with my computer, I'm gonna have to whip up a native tracker of some sort to put on my brand new powerpak that I just ordered (yes!). Unfortunately I wasn't able to hear the audio on the video, but it looks pretty impressive. The one I make will probably be more of a hex editor compared to this
!
RushJet1 wrote:
Yeah, that's pretty impressive.. might try my hand at making a couple of songs with it.
Cool
Celius wrote:
Yeah, since sound doesn't work with my computer, I'm gonna have to whip up a native tracker of some sort to put on my brand new powerpak that I just ordered (yes!). Unfortunately I wasn't able to hear the audio on the video, but it looks pretty impressive. The one I make will probably be more of a hex editor compared to this
!
Oh, there's plenty of HEX editing involved
I actually thought about adding a "raw" editing mode on a separate "screen" but to be honest you can pretty much get at every byte of the song data through the various editor panes as it is
That is completely amazing and I can't wait to play with it.
Of course I am going to have to learn a lot about the different types of effects - I can do some rudimentary stuff with Famitracker but not much besides adjusting duty, pitch and timing on instruments and plinking out a melody.
It will be very nice to be able to hear how it sounds on hardware as I'm editing it.
I assume it's compatible with Nijuu so we can use the songs we make?
Have you considered built in DPCM such as a basic drum set? Obviously it would be very complicated to let people use their own DPCM but a preset drum kit could cover a broad range of music.
Will you be releasing the source?
neilbaldwin wrote:
Oh, there's plenty of HEX editing involved
I actually thought about adding a "raw" editing mode on a separate "screen" but to be honest you can pretty much get at every byte of the song data through the various editor panes as it is
Yeah, I think for me it would be easier to just have a hex editor than to make a whole complex native tracker. But it might be fun though to go the extra mile. I like the idea of editing music not being tedious. But I'd even be happy if I could have notepad open and hear every change in my .db statements in real time. So I think I'll actually make the hex editor more of a text editor. It will display everything in .db statements and meaningful names assigned to hex values rather than just the hex values themselves. For example, instead of seeing ".db $B0, $24", I would see ".db SetReferenceNote, Octave4.Bb". Then I could actually have a program on my computer that takes the music data saved in the .SAV file on the PowerPak, and have it turn it back into .db statements inside of a text file I can include in my project. Probably sounds crazy, but I'm actually quite comfortable with the idea. Sometimes .db statements are easier to work with than just raw data.
UncleSporky wrote:
That is completely amazing and I can't wait to play with it.
Of course I am going to have to learn a lot about the different types of effects - I can do some rudimentary stuff with Famitracker but not much besides adjusting duty, pitch and timing on instruments and plinking out a melody.
It will be very nice to be able to hear how it sounds on hardware as I'm editing it.
I assume it's compatible with Nijuu so we can use the songs we make?
Have you considered built in DPCM such as a basic drum set? Obviously it would be very complicated to let people use their own DPCM but a preset drum kit could cover a broad range of music.
Will you be releasing the source?
I can't wait to have a proper play with it either!
It's very, very easy to use so don't worry too much.
It's not compatible with Nijuu, no. I approached the two things in a very different way. However, I have a feeling that NTRQ will end up being better than Nijuu - easier to use and almost equal in audio terms.
Yes, it's my intention to put in a built in DPCM set but also give you the ability to build your own (it's not as complicated as you might think). DPCM is fairly new to me though so I'm experimenting at the moment.
Source code? Most likely, yes. I need to look at the GPL licence and will probably release it under those terms.
Maybe I'm missing something, but I can't seem to find a link to your work anywhere, and it seems super exciting! Publish that stuff more man!...
And how would you compare this to famitracker?
Cheers!
- Very cool
Keep up the good work!
fireseed wrote:
Maybe I'm missing something, but I can't seem to find a link to your work anywhere, and it seems super exciting! Publish that stuff more man!...
And how would you compare this to famitracker?
Cheers!
You mean music he has made, or just publicizing this program around gaming blogs? Because his music is all available at the same site he's been linking.
I think it's pretty clear how it compared to Famitracker, UI-wise. Obviously editing is a lot slower without a mouse and keyboard, and it's tough to fit all the same kind of information on the screen at once. I suppose we know less about the scope of instrument-creation options and such.
NTRQ V1.0 released today.
http://ntrq.net
Yay! Thanks for actually releasing something on April Fools. I was so wary, I downloaded and even made sure it ran before posting thanks for putting it out.
Thanks for putting it out!
I would think that an April 1st release should have a certain Rick Astley song preloaded.
Looks great! I haven't had time to read through the manual yet, but that looks really nice too.
Awesome. Unfortunately (as you said in the readme) its not working on my PAL NES - the interface seems to work but there's no sound. I guess I have to go emu for now. Will there be PAL support in a feature release? :)
dXtr wrote:
Awesome. Unfortunately (as you said in the readme) its not working on my PAL NES - the interface seems to work but there's no sound. I guess I have to go emu for now. Will there be PAL support in a feature release?
How odd!
I did a test by setting the relevant flag in the iNES header of the ROM to force it to be PAL and it worked OK in Nestopia (though the pitch and speed was obviously "wrong").
Does anyone know why there might be no audio output running NTSC NTRQ on a PAL NES?
weird indeed. just to make sure it's nothing wrong with my connection to the TV I will try some other stuff too. will post back in a minute.
hm seems to be something else wrong, tried bubble bobble and no sound
sorry about that.. but still any plans for a PAL "corrected" release later? ^_^
edit: apparently there was something wrong with the TV settings for the NES channel.. I wonder how that happened :S
dXtr wrote:
hm seems to be something else wrong, tried bubble bobble and no sound
sorry about that.. but still any plans for a PAL "corrected" release later? ^_^
Phew, I went into a mild panic there for a moment
PAL version? Yes, definitely.
sweet. now to dig through the manual :)
Maybe run a cycle counter routine to tell whether it's running on NTSC or PAL (or even Dendy).
Dwedit wrote:
Maybe run a cycle counter routine to tell whether it's running on NTSC or PAL (or even Dendy).
Sounds intriguing - is there example code of this technique available?
The total number of clock cycles per frame on various systems:
29780 NTSC
33247 PAL
35464 Dendy
Run this code for a frame. Look at the value of counter afterwards. I'll assume all variables are in the zeropage, and the last beq does not cross pages.
Code:
clc
loop:
lda counter+0 ;3
adc #1 ;2
sta counter+0 ;3
lda counter+1 ;3
adc #0 ;2
sta counter+1 ;3
lda giveup ;3
beq loop ;3
Total cycles per iteration: 22
So afterwards, you look at the value of counter.
up to 1354: NTSC
up to 1512: PAL
up to 1612: Dendy (has NTSC-like sound pitch, and PAL-like 50 FPS)
Michel did this in Years Behind. The source is linked in this post:
http://nesdev.com/bbs/viewtopic.php?p=50455#50455
You'll have to ask him if you want to use it though.
EDIT: There should be a law against posting at the same time as me.
neilbaldwin wrote:
Sounds intriguing - is there example code of this technique available?
The simplest way I know of to detect NTSC vs PAL is having your NMI wait, say, 22 scanlines (NTSC Vblank has 20 scanlines, PAL has way more) as soon as it fires, and then check $2002. If the Vblank flag is set, it's a PAL console.
How long is Dendy's VBlank? Well, I don't think it's possible to detect a third system with this technique anyway, since the VBlank flag is cleared when you read it.
tokumaru wrote:
the VBlank flag is cleared when you read it
The vblank signaling in the NES PPU has a race condition bug. If you try to read vblank status out of PPUSTATUS ($2002), you'll miss even more vblanks than you would with an NMI handler. I think that's why Dwedit used 'giveup' instead of PPUSTATUS in his code sample.
Now as I understand it, timings are like this:
Famicom, PlayChoice, NTSC NES, Brazil NES: 262 lines per frame, vblank NMI fires at 241, 3 dots per CPU cycle
PAL NES: 312 lines per frame, vblank NMI fires at 241, 3.2 dots per CPU cycle
Dendy: 312 lines per frame(?), vblank NMI fires at 291, 3 dots per CPU cycle
The Dendy NMI fires later so as to be more compatible with cycle-timed NMI handlers (e.g. Balloon Fight and Battletoads) and cycle counting mappers (e.g. VRC series).
tepples wrote:
The vblank signaling in the NES PPU has a race condition bug.
And what does that have to do with the method I posted? The NMI fires, you wait a little more than 20 scanlines, read the PPU status and the VBlank flag will tell you if the system is PAL or NTSC (according to what you said about the Dendy, it would be detected as NTSC, which is nice). As far as I can tell, the racing condition doesn't affect anything in this case.
Are there emulators with a "Dendy mode"? I thought that the game I'm working on would fail on a Dendy, but if it's indeed like you described it will run just fine.
I was confused when I read about your method.
But if you want to measure a lot of frame timings to calibrate your engine, that's what a copyright notice screen is for.[1] You get at least 120 chances to measure frame timing while it is displayed. Besides, you can find the end of vertical blanking by waiting for the sprite 0 flag to turn off.
[1] That and decompressing the title screen tiles.
tepples wrote:
But if you want to measure a lot of frame timings to calibrate your engine, that's what a copyright notice screen is for.
Why would anyone want that? I check it every frame just because my VBlank code is timed anyway, and it's cool to have the program adapt to the other system on the fly, without resetting.
Quote:
Besides, you can find the end of vertical blanking by waiting for the sprite 0 flag to turn off.
Yeah, but the goal is not to find out how long the vertical blank is, the goal is to check the VBlank flag past the known duration of the NTSC vertical blank so that you get the answer (is the console NTSC or PAL) from a simple flag, without having to use a counter and check its value afterward. I find it simpler, but it will not detect a Dendy.
Bregalad wrote:
What is a dendy ?
Russia's unlicensed version of the Famicom. Apparently it has some unique hardware differences.
tokumaru wrote:
Why would anyone want that? I check it every frame just because my VBlank code is timed anyway, and it's cool to have the program adapt to the other system on the fly, without resetting.
Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o
BMF54123 wrote:
Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o
You're right that it isn't possible on the NES, but it is on the Super NES. Apparently there's some sort of "50/60 switch".
In fact it could be possible if you soldered 2 PPUs one on the top of the other and connect all their output pins to a multiplexer. (I don't know what you'd do with the video out pins tough).
But there would be issues with frequencies, as the main crystal freq isn't the same for PAL and NTSC so that's much inapplicable.
BMF54123 wrote:
Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o
My game just supports this because in my case there is absolutely no extra cost in doing so, and it's cool to see a timing-sensitive program not breaking on emulators when the region is changed.
Quote:
What's a Dendy?
Quote:
Russia's unlicensed version of the Famicom. Apparently it has some unique hardware differences.
Generally speaking, it's the Asian PAL-Famiclones based on the
6527P/6538 chips (Dendy, Microgenius, Pegasus, etc.)
Oscilloscope tests HERE:
http://nesdev.com/bbs/viewtopic.php?t=5070
Vblank, NMI, scanlines, PPU etc.
Can someone fix nestopia's "dendy-mode" according these tests?
tokumaru wrote:
BMF54123 wrote:
Why would anyone change regions in the middle of a game? That's not even possible on the original hardware... O_o
My game just supports this because in my case there is absolutely no extra cost in doing so, and it's cool to see a timing-sensitive program not breaking on emulators when the region is changed.
-
Fine, it's a nice exercise. By the way, it requires a lot of extra code to adjust the things, quite unusual for the NES at least. Anyway, the usual way is to write software for NTSC and for PAL systems.
I don't expect to adjust everything on the fly like I do with the bar that hides scrolling glitches. I could probably have the music adapt itself on the fly as well, but the physics and such would be kinda hard to do. I'm not sure I will change any of the physics for PAL though, because the rounding errors could end up making the game play too differently from the NTSC version... But it would be very nice to have everything in a single ROM.
Famitracker is a NES tracker designed specifically for NES music. It also has the Japanese expansion chips.
Doommaster1994 wrote:
Famitracker is a NES tracker designed specifically for NES music. It also has the Japanese expansion chips.
You're perhaps missing the point of the word "native" as applied to NTRQ.
Doommaster1994 wrote:
Famitracker is a NES tracker designed specifically for NES music. It also has the Japanese expansion chips.
Yes, but Famitracker doesn't run on the NES, you need a PC to use it. This thread is about
native applications, those that run on the NES.
Some NES programmers don't like or don't know how to write programs that run on a PC, so they might decide to code their tools for the NES itself. Some people made level editors like that, for example.
tokumaru wrote:
Doommaster1994 wrote:
Famitracker is a NES tracker designed specifically for NES music. It also has the Japanese expansion chips.
Yes, but Famitracker doesn't run on the NES, you need a PC to use it. This thread is about
native applications, those that run on the NES.
Some NES programmers don't like or don't know how to write programs that run on a PC, so they might decide to code their tools for the NES itself. Some people made level editors like that, for example.
And some can do both but liked the challenge of doing it on the NES...
