DogP wrote:
The duration of the note is until you stop it, unless you use fading.
Regarding waveform RAM… on real hardware you don’t need to initialize the waveform to get sound (I’m not sure if it’s a random waveform or a default one), but in the emulator you probably do. It’s obviously a good idea to do it anyway.
DogP
My guess would be that on real hardware, the waveform RAM is filled with garbage when the system gets powered on, but in an emulator, the memory that gets allocated for waveform RAM might get initialized to zero depending on the implementation.
Anyway, thanks a bunch for the code samples DanB! (Especially the frequency tables… I really didn’t want to try to figure those out. 😀 )
Also, I looked at DanB’s instrument waveform definitions and was thinking about how difficult it would be to make new ones, when it occurred to me that many waveforms were already produced for commercial VB games! Not only that, but the mednafen debugger makes them incredibly easy to get at. To dump a waveform:
1. Load up the game that has the instrument you want in mednafen.
2. Once the music that uses the instrument begins, hit Alt+D to start the debugger
3. Press Alt+3 to bring up the memory editor
4. Now, by pressing < and >, you can switch between main memory, and the five VSU waveform banks. The cool thing is, the debugger even graphically displays the waveform that is loaded into the currently selected bank! (Another cool thing you can use the debugger for is editing these waveforms in real time – just press Insert to enter/exit edit mode.)
5. Once you find the waveform that you want a copy of, press D to bring up the dump dialog, then type
0000 001F wave.bin
to dump the entire waveform to a file called wave.bin.
This will give you a dump of the waveform memory segment that you selected, which is cool, but not really useful for coding purposes. If you want to change the raw binary into a usable format (a C header), I whipped up a python script which will do that for you. It’s attached to this post, and the syntax for it is
./bintoheader.py [hex dump filename] [header name without .h]
It probably has a few flaws, but it gets the job done more quickly than manually transcribing hex codes. Hope this helps someone out!
I do have one question about the VSU registers: What does setting the interval do? I tried changing the lower 4 bits of SxINT, but it didn’t seem to affect the sound.
VirtualChris wrote:
That’s what I want to do: Make music. I played with the wav converter, but it seems like the game freezes while playing the file (you can’t press a buton or anything.)
It’s a good learning experience to try and understand what other people’s code is doing. I think you mentioned that C isn’t your first programming language VirtualChris, so a couple of good coding exercises would be: Can you see why the game “freezes” while the sound is playing? Can you make it so that the currently playing sound stops when a button is pressed?
Unfortunately, we don’t have any good utilities right now for converting something like a midi file to a format the VB can play. (At least not any released ones… *cough*DanB*cough ;-)) DogP’s wav player really isn’t a practical way to play music during the game. The practical way to play music during the game is to use the VB’s built-in tone playing capabilities along with something like a timer interrupt, so that the speed of the game doesn’t affect the pitch of the sound, and the sound doesn’t freeze the game.
Unfortunately, no, it’s a lot harder than just calling up built-in sounds. I’ve never done it, but from looking at the programming manuals, my understanding is that the VSU (Virtual Sound Unit) has a number of registers which can be programmed with a very short “sound effect”. (The “sound effect” is actually a wave pattern which defines an “instrument” of sorts.) It also has other registers which tell the VSU if the sound should be played, how fast it should be played (the frequency, or pitch of the sound), how loud it should be played, etc. This is mostly for making music though… To actually play sound effects, there are a few different techniques. One is to use the standard “instruments” (channels 1-4 of the VSU) to play beep boop sounds, use the sweep channel (channel 5 of the VSU) to make “boing” jumping noises, or use the noise generator (channel 6) to make explosion noises. However, DogP also wrote a demo/utility for converting wav files into a format that could (with some supporting code) be played on the VB. I just tried it, and in mednafen the default code seems to be playing the sound files too fast, (in fact, exactly 10x too fast!) but I just got it to work by changing the the definition of SR_DIV on line 126 of wavonvb.c to 3750000 instead of 375000. Beware though, that including wav files in your game will significantly increase the size of the ROM image. That demo with just the four sound files requires an 8Mbit cartridge! Hope this helps!
I mentioned before the contest ended that I’m working on a Gradius clone. Right now is a very hectic time for me, as it’s the last few weeks in the semester (and I’m a CS major, so I’m pretty burnt out on programming :-P) but I’ll probably pick up work again over the break.
Wow, these are some really long posts… 😯 Guess I’ll just throw my 2 cents into the parts I found interesting.
Audio:
I think the code is out there, it just needs to be released. We need something that can convert from a format that’s easy to compose in, to something that’s easy to import into your project, such that it can be updated with timer calls. (Like… DanB’s midi converter? I know you said you would release the source 2 years ago when it debuted, DanB. It has to come out sooner or later. ;-)) I think music would work best with a timer interrupt call so that the music is completely unaffected by slowdown. You could use a frame interrupt to handle graphics. Which brings me to…
Graphics:
I’ve never used Grit, how does it work? It looked to me like a “dumb” tool that would just convert an image into something that can be used in VRAM. I’d like something that gives you full control over VRAM tiles. The problem with VIDE is that it’s really clunky when it comes to Chars. You can’t even move them around once you’ve placed them. If you look at the Mandelbrot explorer source folder, you can see that I was actually using the GIMP to lay out tiles, and then just using VIDE as a go-between. Another thing (sorry, I’m on a rant) is that VIDE “links” BGMaps to CharSets, and limits BGMaps to the Chars in that set, when a BGMap tile actually has access to all the tiles in Char RAM. I’d like to write a utility if I get the time.
Objects:
I actually prefer objects over BGMaps because of their versatility, but they are a bit of a pain to manage. If you want to “generalize” object management, you have to come up with some way of allocating objects, and then keeping track of them. This should be easy, but might have some nasty overhead. I have my own more hackish solutions to this problem…
Random Numbers:
I actually wrote my own random.h based on c’s standard rand. As far as seeding, I figure a predefined static seed is good enough, especially if the game’s progress depends on user input.
As a parting note, I would prefer it if whatever gets added to the pool is not tied down to an IDE. Personally, I develop in Vim and terminal, so having to use an IDE would be frustrating for me.
Cool! How much work was it to port your code to Basic? That wouldn’t have been my first choice, I would imagine it would have been easier to port it to DOS while staying in C. You might also consider writing it in Java. That way your code would be both cross-platform and web enabled.
Eh, I’ve always wanted a FlashBoy, but to be honest I probably wouldn’t use it that much. Virtual Boy development is just one of many hobbies I have, so I’ve never wanted to invest that much in it. Also, my desire to work on hobbies goes in phases, so I’m probably burned out on VB for the moment. (But I’ll probably pick up work on my Gradius clone again in a few weeks, once finals are over with and I have a few minutes to breathe.) Another one of my bigger hobbies is electronics so I’ve always just figured that I’d build myself a RAM cart if I ever got a decent way to etch PCBs. (I’m also considering building myself a CNC PCB mill one of these days. :-P)
KR155E wrote:
The idea of using the last 3 digits for the country where it was made is a nice one, but couldn’t that be a bit confusing? Nobody would understand what’s meant who didn’t read this read or some explanation somewhere.
I don’t think it’s confusing at all. When I see “USA” or “JPN” or even “DEU” on something, I’d probably assume that it was a country code. Additionally, it’s not really necessary for the end-user to know what the serial number means. Personally, I think HBR or PD are just as cryptic as a country code. If we were going to choose a worldwide country code, my vote is for “INT”.
Allen wrote:
Subtotal: US $13.02
Shipping & handling: US $10.70
Total: US $23.72
Not bad since the Visor alone is work that much….
Man, I remember that I got my first unit for $20 shipped, and it still had all the pieces intact (foam visor, battery pack, unbroken stand) and came with 2 games. My “broken” unit was $5 shipped, and then I think I picked up the controller for $10 with an AC adapter. Prices sure have spiked recently…
Great! I don’t care that it’s not in the zip file. Here’s the updated version, my crt0 should be fixed, but my main also calls vbSetColTable() just in case. As an added bonus, I actually set the header info this time. The publisher ID “SP” is now taken. 😀 (I’ll update the dev wiki.)
Someone should try running it on hardware and let me know if that resolves the issue.
SegNin wrote:
Well, thanks to dasi, I’m now down to 7 roms missing:
1) GoSub v2009-07-31 by Chris Read (PD)
2) Nester’s Funky Bowling (U) [b3]
3) Reality Boy Demo 3 by David Tucker (PD)
4) Red Alarm (U) [b1]
5) This Demo Owes ALOT to RunnerPack HelloWorld SpriteExam 1 (PD)
6) Wario Gonna Win Demo (PD)
7) Wavs (PD)
Umm… neither Red Alarm nor Nester’s Funky Bowling are public domain. Their copyrights are held by by T&E Soft and Nintendo respectively.
SegNin wrote:
And dasi, I know that not all homebrew projects are public domain–Dicing Knight for WonderSwan Color comes to mind as an example. But these roms (except for the 2 bad dumps) are demos that were released on the Internet by their authors, thus they’re public domain.
It’s already been said by several others, but I’ll say it too: You have to be careful there. Just because someone shoves their project onto the internet with source means the project is “public domain”. Sometimes the intent is to release it free and clear, but in most cases the copyright still belongs to the person who wrote it. It’s only legally public domain if the author forfeits copyright on it, and that’s hard to do sometimes. It’s best to ask the author of the software before you decide that because you got it for free, it must be public domain.
Very cool idea! Glad you found something that worked for you, it looks like a pretty permanent solution that’s also easily reversible. I’d be afraid to do that because of alignment issues, but then again I’ve hardly ever heard of people having problems with that.
It’s really an annoying problem to fix, even though there are many possible solutions. I wish Nintendo had just used better glue to begin with…
By the way, how much did you pick up the unit for?
EDIT:
Vaughanabe13 wrote:
So what were your results then. Did it fix it?
He just forgot a period:
So I made a clamp to hold the FFC in place. After I had it work with out line in the display.
I agree, even though I haven’t put serial numbers on any of my projects. “Public Domain” is not a country (plus it makes the serial number asymmetrical. ;-)) All kidding aside, the meaning of public domain varies from place to place, and in some countries, there is no real way to release something into the public domain. Whoever writes the software holds copyright (regardless of if they declare it public domain) and copying of that software may be considered copyright infringement. The best course of action to take if you want to guarantee availability of your software to everyone is to release it under any one of the many free software licenses. As far as the serial number goes, I think it makes more sense to use the last 3 digits for their intended purpose anyway.
It would be nice if I could release a fixed version, since this bug didn’t appear until it was tested on real hardware after the contest was over. (If I could have tested it on real hardware I would have… Maybe I’ll be able to afford a FlashBoy one of these days.) I don’t believe there was anything in the rules about posting an update after the deadline, but I’d want to be sure that I wasn’t going to be stepping on anyone’s toes before I did it. I promise I won’t add any new features. 😛
I hope I haven’t lost too many votes because of this… >:(
Hmm… Looking back at my source code, I realize that I forgot to call vbSetColTable(), could that be causing it? I’ve always forgotten to call that because it’s never affected how my code ran in an emulator, but I wonder if that would cause vertical lines and shaking on real hardware. As a double check, I just ran it on Reality Boy and it runs perfectly there too… I would attach a version with that function call in, but I don’t think it would be fair to do that until after the voting deadline has passed. But wazzal, if you have the toolchain built, feel free to add that line to mandelbrot.c right after vbDisplayOn() and let me know if that fixes it.
