You really shouldn’t operate chips outside their normal operating ranges… the maximum ratings are there to tell you what will damage it. Running chips outside their normal range can cause strange things (the operation isn’t guaranteed outside the operating ranges) and can shorten the life of the chip.

Two diodes could possibly work, though you’d need to characterize the diodes… some may be too slow, and with near zero current, your diode drop will likely be much less than the typical 0.7V (for example a 1N916 has a 0.7V forward drop at 5mA, but 0.275V at 1uA). That also obviously wouldn’t work for bidirectional pins like the data pins.

DogP

mic_ wrote:
No need for printf. VGM is a binary format, not a text format. And yeah, allocating even something like 128 or 256 MB for a buffer won’t be a problem for a computer bought in the last 7-8 years.

Binary or not, you still need to get the data to disk somehow. And yeah, you could make a huge memory buffer, but that’d definitely have to be a different build… I wouldn’t want to waste 256MB in the normal emulator build when very few people would be using this feature.

mic_ wrote:
And it doesn’t really matter if the emulator runs faster than real-time, if you keep track of the number of V810 cycles you’ve emulated you can determine how many audio samples you need to generate.

DogP wrote:
Reality Boy isn’t cycle accurate, you really can’t get an accurate delay value (you could count cycles, but that’ll be wrong, and you could use a real PC timer, but that’d be wrong because the emu would be running really slow).

And while sampling 44100 times per second would probably get you sufficient sampling that you wouldn’t notice the difference between actual register write time and the time that it’s sampled, there’s certain things you’d likely miss, like if the SSTOP register is written w/ a 1, then 0, that should stop all channels, but wouldn’t catch it unless you sampled right at that instant. Also, like you said, all the registers shouldn’t be written 44.1k times per second, so you’re wasting ~235 bytes every time it’s sampled that it doesn’t change. Even with a 256MB buffer, that’s only ~25 seconds. You’d be better off just logging when something changes if it typically happens less often than 44100 times per second (although there’s some overhead from logging the time difference rather than a fixed delay, as well as the main problem of no stable timebase to log against).

DogP

mic_ wrote:
Logging only the sound registers can’t possibly be that slow, unless the emu author totally messed up the code. The point of VGM is that you log at a fixed sample rate (44100 Hz). So the emu only needs to check 44100 times per second if any of the sound register values have changed, and output the new value along with the delay (in samples) since the previous write.

Logging a small amount of changes isn’t too bad (like background music), but logging where there’s lots of changes, like speech takes forever. It doesn’t really have anything to do with the emu author… it’s just using fprintf to log an 8MB file a few bytes at a time is REALLY slow. I guess it could be optimized to log to memory, and then stream it out at once, but this isn’t what it was made for anyway.

Logging register values only 44100 times per second won’t work (or won’t be completely accurate), because the outputs depend on previous states, as well as the fact that Reality Boy doesn’t run at the correct speed (though it’s kinda close). I’ve gotta believe that dumping the entire sound register set 44100 times per second would bog things down as well. There’s also no current mechanism for interrupting 44100 times per second.

DogP

I’ve thought about making sprites from scans and pics of unreleased games, so we have more graphics to use for homebrew, but it’d take a LOT of effort to make a full replacement game, even if the art is all available. Some of the Nintendo Power articles are probably good enough that we could get a pretty good description of what the game should have been if we wanted to recreate it though.

DogP

mic_ wrote:
I was thinking more along the lines of having something like VGM files (http://www.smspower.org/music/uploads/Help/vgmspec150.txt) with values to write to the VSU and delays, and the input plugin would allow listening to these files directly in winamp.

Ah… yeah, something could be done like that, though there’s currently no good way to get the values out. In Red Dragon (and probably Reality Boy) you can log accesses to a memory location, but it slows the emulator down to a crawl when there’s a lot of sound activity going on (because it’s logging to the hard drive). And because of that, and that Reality Boy isn’t cycle accurate, you really can’t get an accurate delay value (you could count cycles, but that’ll be wrong, and you could use a real PC timer, but that’d be wrong because the emu would be running really slow).

The real purpose of this was to help development, but yeah, I’ll post the source this weekend and you guys are free to do whatever you want with it. Let me know if you find any problems so I can fix them before posting. I’ve got a short list of things to compare on hardware that I’d like to make sure are correct, which I’ll probably do tonight (but that requires changing my VB side sound tester, which I hope will be easy to make the needed mods).

DogP

If you have mirrored images overlaid, it means that the display select line isn’t working correctly. Basically, both displays use the same wires except one to select whether the left or right screen is drawn at a time, and if the display is constantly being selected, you’ll get both screens drawn on one display (and mirrored because they’re drawn in opposite directions).

DogP

Could you guys elaborate on the Winamp plugin thing? I personally rarely use Winamp, but I don’t see how this generator as a plugin would be useful.

How do you plan on configuring the registers? Are you just wanting Winamp to play whatever is generated from a manually configured file rather than having to double click the wav file? Or maybe the plugin would look like a strange graphic equalizer and you could configure there? I have no experience w/ Winamp plugins, so I really doubt I’ll do it, but if anyone would like to, I’d be glad to help make it happen.

DogP

I couldn’t find a diagram in 3 seconds of searching, so I spent 3 seconds drawing one (as you can tell) 😉 . Basically, the resistor limits the current, the diode conducts when the voltage goes above 3.3V+(diode drop), which makes the input at the chip ~3.6V max when using a diode w/ a low forward voltage drop. The resistor value doesn’t matter too much… 1k to 10k should be good. The ESD diodes internally (if present) act the same as the diode in this circuit, so you may be able to get away with just using series resistors to limit the current.

You could also use a 3.3V zener connected to ground, but my experience w/ them is that they’re very slow and the voltage overshoots.

If you’ve go to do an entire bus, it may be kinda messy to do this though… you should look up other solutions, like a bus switch or other IC meant for translating a large number of lines.

DogP

Attachments:

1. 

   shunt.jpg
   

Yeah, I know the outputs will be High-Z when disabled, but even at High-Z the maximum voltage levels on a pin has to be followed. If the chip is disabled but the CPU is talking to SRAM, WRAM, or anything else on the bus, the address and data lines will be experiencing 5V levels. This may be a problem if the chip isn’t 5V tolerant.

My point is just that it’s a 5V bus… you can’t assume that the data lines are only outputs from the ROM and inputs to the CPU, like for example if you were connecting a 3.3V<->5V SPI, where you’d only need to protect the 5V output(s) (Tx, when the 3.3V is the master).

DogP

3.3V should be fine… the CPU specifies 2.2V when running at 5V, and I don’t think any of the other devices on the VB would talk to the ROM, so they shouldn’t matter. Of course you have to be aware that it’s a common bus, so even though the VB may not write the data pins, there will still be other communications on the bus, so there will be 5V signals (so just make sure the data lines are 5V tolerant).

I wouldn’t do a resistor divider for shifting levels though… if there’s ESD diodes internally, a series resistor will (usually) work, otherwise, I’d use series resistors w/ low voltage drop diodes to shunt to Vcc. You could also build in something like: http://www.sparkfun.com/commerce/product_info.php?products_id=8745 , though that’s probably overkill (and I don’t know the performance of it, though I do have a few of them).

Edit: Just saw your edit and reply… that’s for CMOS logic chips (the 74*Cxxx stuff)… typically devices made using the CMOS process have different levels than that (I commonly see 0.5*Vcc to 0.65*Vcc). They seem to be specified like that rather than a specific voltage, because it’s dependent on the Vcc voltage rather than a certain threshold (and CMOS chips are usually pretty tolerant about operating voltages). It seems that the V810 was made to have TTL compatible inputs though, since the threshold is 2.2V @ 5V and 2V @ 3.3V.

DogP

Here’s a quick mockup of the GUI that I was thinking of. Basically, it’d allow a high-level selection of parameters, allowing various options depending on those selected. Of course I didn’t disable controls as appropriate, but basically you could select one of the 5 main options, then options for that, and any unavailable options would be disabled. The frequency would of course have to be converted from Hz to the nearest available option, and I think those hover tips would be useful for telling specifics, like Envelope Volume is a channel master volume or initial envelope value.

Then when you’re done, select “output settings” to set the settings and go to the next line. The forward and back buttons at the bottom allow you to scroll through the file, though I guess there should be an insert/delete line option.

There’s a few things that I forgot, like a preview wav button, and selecting where the files go (and optional code output), but hopefully you get the idea.

DogP

Attachments:

1. 

   screenshot.jpg
   

Agreed… they made way too many of something that nobody wants… might as well make something good out of them. They obviously overestimated what was needed, so if they would have estimated correctly, we wouldn’t have these extras and we’d be scrounging for cart parts.

It’s even possible that they got a good deal to make more carts, because Nintendo made too many connectors and cart plastics (the stuff that we want), so at the time they could at least make a few bucks back on their investment. But in the end at least the raw materials were made available rather than being tossed… but IMO there’s nothing special about any of these carts, which would just sit in boxes (unsold) rather than being put to use.

DogP

Yeah, GUIs in C++ aren’t too bad, but I just want something that I can put very little effort into making… but if you want to make it, that’s even less effort than doing it in VB 😉 . Maybe I’ll mock up what I think the GUI should be like and post it here for comments and ideas. I probably haven’t used VB in about 10 years anyway, so who knows what I’d remember 😛 .

DogP

I just checked a connector (male) w/ the calipers… it’s about 0.014″, or 0.35mm.

DogP

Thanks for the comments… the GUI that I’m talking about would be for configuring the registers, rather than editing the input text file. You could move sliders around to make waveforms (or select predefined ones), use dropdowns to select registers and hit checkboxes to select their meanings (instead of just putting in the raw values). Then of course a preview button, which would run it through the process and play the wav file. The ability to step back and forth through the commands would be nice.

DogP

Heh, I guess it’s kinda convenient that this discussion came up… if you look in the dev section, I just posted a VSU emulator, which, if I understand what you’re talking about, could be used for playing back a native VB sound format.

I’m not exactly sure how to extract the audio from the VB ROM, though it’s likely that most BGM would be contiguous, and logging writes to the sound regs in an emulator may take us to the right spot.

DogP

Same here.

DogP

I think there’s been some problems w/ the site in the last day, so that’s probably the reason for the post funniness.

But if you’re thinking of trying a 7 chip cart, IMO, the best way would be to physically stack the chips and hand-wire the pin(s) that are different (since basically all pins are connected together except the /CS). It’d look ugly (and that way would be ugly), but so would the routing on a board with 7 chips all connected to the same lines. I guess you could also mount some chips upsidedown on the bottom of the board and use vias to connect the two sides.

DogP

I’m pretty sure it’s a switching regulator, as the voltage drops, the input current goes up, so as the batteries get weak the VB starts drawing more current, putting an even heavier load on the dying batteries. The VB can run at less than 6.8V… you really need to measure under load.

Though yes… if everything is running at 3.3V, it should draw less current (especially if the switcher is modified to output 3.3V rather than running 5V through a 3.3V linear regulator).

DogP

Yeah, that ugly thing right there is (was) my dumper, and I put jumpers on it to allow the SRAM to be dumped as well. And the adapters aren’t too expensive on ebay… neither are the sockets if you can solder the adapter yourself. I bought some 56 pin ones a while back for next to nothing.

DogP