Yeah, this one has been done plenty of times, but I’ll throw in the most important reason IMO… someone’s word. The person who lends the carts to be dumped will typically let someone borrow them only if they agree to just keep the dump for themselves and not release it. If people go ahead and release it because “it’s the public’s right to play the games”, then the people who own the rare stuff will never lend it out and there will be no preservation of rare stuff, and nobody but the people with the deep wallets will get to play it. It’s just a matter of playing by the rules, and IMO trust is one of the most important qualities… especially in a small community like the VB.
Why collectors don’t want the stuff released? Clearly it’s related to status, which is related to value. Since the games aren’t available to be downloaded, they hold sort of a superior status among VB games. It’s like a Lexus… they’re not that great, they’re just a Toyota… but the status that goes along with it makes it great (to people that “drink the Kool-Aid”). What if they started putting Lexus logos on all new Toyotas? Would a Lexus be great? I would lose a lot of respect for Lexus once I saw my friend driving his $12,000 Lexus Echo.
I remember the first time I played the 4 rare games at a friend’s house… I was blown away. Not because they were that great, but because they were 4 brand new games to me. This was MUCH more impressive than when I finally got Space Squash or Insmouse in their own dedicated cartridges. I had already played both of those in the emulator, and burned EPROMs of them and played them in my EPROM cart. I had no real reason to buy them except for completeness of my collection, so when I found them for cheap enough (~$75 each) I went ahead and bought them. If I hadn’t already been able to play them whenever I wanted, I would have definitely paid more since I wouldn’t have been able to wait for the right deal, and demand would have been higher.
But, in the end, money talks. If someone’s willing to spend several thousand $$$, then devalue their own carts by releasing the ROMs, that’s totally up to that person. Nobody can make you not release the ROMs. But don’t expect any more than one or two thanks, and the whole thing will be forgotten in a day or two… people on the internet just want things that they can’t have because they can’t have them.
I laugh when people talk about their “ROM collections”… how they have very different version of every game out there. I think… wow, that must have been tough to download the 80,000 NES/SNES ROM pack from bit torrent (good luck finding the game you want). It’s not just that the majority of people can’t afford the games, it’s that people want everything for free. Try selling the ROM for a fair price that people can afford. Very few people will buy it. Put it up for a free download and everyone will download it (and it’ll get played once in the emulator and forgotten). Look at $10 shareware… nobody buys it, but they’ll gladly go find the crack so they’re using the full version rather than an evaluation version. It’s just the whole “free” mentality. And don’t get me started on leeches profiting from other people. The day the ROMs hit the internet people will be trying to sell Flashboys pre-loaded with Virtual Bowling on ebay and stuff.
Heh, sorry… I think my post got a little bit long-winded and trailed off on a few tangents… but I’m sure the answer you’re looking for is in there somewhere 😉 .
That sounds like a display problem to me (likely the cable, but possibly just a bad display). A game connector or bad ROM would almost certainly not cause a problem like that, since there’s just a single ROM that holds both graphics and code, and since the game runs fine, and looks fine on one eye, I’d say the system is reading the ROM just fine. The display doesn’t always have horizontal lines, that’s just the most common effect due to the way the data is sent to the display.
Also, if you’re running on batteries, replace them… or running from an AC adapter is of course better. But yeah, you should get sound after hitting start enough times to get into the game, and if you don’t, I’d worry about that before the displays (the lines are a much more common problem than a completely dead display, and both displays being dead of course would be even less likely… but possible).
You guys realize this post is from 2007, and the user hasn’t posted anything since then, right? I think we can be pretty certain that this whole story was made up.
One way you could do it is to keep track of where you want to be opaque black, then after the frame is rendered by the VPU, go into the framebuffers and set those pixels to be black. Not exactly a nice way to do it, but wouldn’t take too much effort or processing time if you always knew that one small chunk needed to be solid black (like filling in the black of your main character).
No offense to DanB, but I’d recommend against doing the bypass method. I’ve used 30 awg wrapping wire for MANY things, and unless you’re really careful when you’re stripping, you’re very likely to knick the edge of the wires, which will break after a couple small movements or shakes. Of course it’s also a difficult and tedious procedure, so a novice would likely cause more problems than fixing anything. Wrapping wire is also not very flexible since it’s a solid core wire (rather than stranded), so it’ll break at any bends after being moved several times (like adjusting the IPD)… of course the hot glue that he used should relieve the stress at the bends. DanB’s looked good, and I’m sure he took his time and was very careful, but he’s also experienced at soldering, but for someone less skilled, it’d likely turn into a huge mess.
I personally REALLY like my new method using Sodium Hydroxide to dissolve the coating, and then solder the original cable to the PCB. This works well because the cable itself is perfectly fine, but the connection between the cable and the display PCB has failed. By soldering this connection, there should be no worry of the connection ever coming undone. The display is also still removable from the system after this method. This method isn’t easy, since the pins are still very small, and of course I realize that not everyone has access to, or wants to use nasty chemicals like that, but if you’re really careful, you can also remove the coating manually with a very sharp knife. It’s very nice compared to other methods too, since the cable stays attached the whole time, so there’s no need to worry about connecting the wires to the wrong place, or trying to line up a new cable. The last cable I did using this method took me approximately 20 minutes from putting in the oven to finishing soldering the wires, and I’ll bet the next one I do takes even less time.
Heh, it’s actually pretty easy… the last one I did in about 20 minutes, although I had everything ready, so there wasn’t much to it. There’s not really solder underneath, although the tips of the cable do bend up a little bit most of the time, so some solder does get underneath at the edges. The solder over the edge should be sufficient though, since it’s still held in place by the adhesive, and with solder covering the pins on that many pins, the cable is definitely more sturdy, even if the adhesive was to someday completely lose it’s stickyness.
That’s the correct way to access it… when I get home from work I’ll check if I see the same bug. I assume it does it with commercial games that use the SRAM also?
Actually, that is pretty rare. The Birthday Paradox talks about multiple people comparing their birthdays with multiple other people. This is comparing one person’s birthday with that of Gunpei’s… and even comparing all of the forum members’ birthdays with Gunpei’s, the odds are pretty low (well… not sure how many members are here, so counting the regulars at least 😛 ). It’s hard to say the exact odds since some birthdays are more common than others (aka 9 months after winter 😉 ).
Right… I think game animation should be based on display/game “frames” (after you’re done processing that frame, you should wait until the next frame before starting the next), but general purpose waits shouldn’t be based on game frames, because you only have a resolution of 1/50th of a second. Even if you know you want to wait 1/50th of a second, if you just started a new frame, then it’s really gonna be up to 1/25th of a second if you want for a full frame, or down to no wait if you only wait for the next frame. Of course this gets better the longer you wait (you’re always within +/- 1/50th of a second), but like I said, it depends on your purpose of the wait.
If you know you want to wait for the next frame (which really isn’t a delay, it’s more of a synchronization) then you should use the dispaly flags (one of the vbWaitFrame() functions did this). If you know that you want the CPU to stop execution for 37ms (for whatever reason), then the CPU should run independent of anything else and just waste cycles for that period. Another problem of using the display flags is that the display must be enabled. If you haven’t set up the display and wait for the flags, it’ll just be stuck in an infinite loop.
And yeah, typically you won’t need microsecond accuracy, but with an unsigned int argument, that’ll get you from 1us to almost 1hr 12min (which I’m pretty sure NOBODY will need 😉 ). One thing I use a lot of short delays for is for interfacing with other hardware. I don’t care what’s on the display (or if it’s even enabled), but I know I want COMCNT to pulse high for 10ms, or during initialization I have to wait 400us before I can access something, or things to that effect.
So yeah… I think vbWaitFrame() should be deprecated (since it’s been used so much in the past and rarely consistently), and we should have a new function waitDispFrame() or something which waits display frames (argument of 0 waits until the end of the current frame to sync the game to the display), and then another function usPause() which would wait based on a set time delay.
I’m not sure what else the JP AC adapter works with… it may be the Super Famicom (like how the US one is the same as the SNES). Japan uses a similar power plug and voltage as the US, so is it possible that you were using a JP AC adapter?
The timer is nice, but it’s a bad idea for delays. Timers are especially good for running in the background while you’re doing other stuff, then you can know how long something has been going. For a wait loop, you want it to block execution until a specific amount of time has gone by. There’s no reason to use a timer when you can count clock cycles and have the CPU run in a loop for that long (plus it’s more precise and accurate). If the standard library mandates that to use a wait you must have the timer enabled and running, then we lose the ability to have control over a really useful piece of the hardware.
About the optimizer causing an infinite loop, you need to change VIP_REGS to be volatile. The old gccVB didn’t optimize that, but the new one does.
I agree that we should have a standardized library, although I’ve been wishing this for a long time, and unfortunately it may be too late for me. I’ve done WAY too many programs with my personal libgccvb.h, and I’m not particularly interested in changing all my current projects over to a new system, and definitely have no desire in updating any of my old code to work with new libs.
One suggestion though would be to have #ifndef FUNCTIONNAME #define FUNCTIONNAME #endif around every function. This way we could have our own customized libraries #included before this one (with #define FUNCTIONNAME), and they’d override the default libraries. This would be useful for using asm optimized functions, or special requirements for that specific application, or just for laziness of porting from the old libgccvb.h that the app was originally compiled with.
I also agree about printing functions, but I don’t think there should be a printf() function. I think there should be sprintf(), which can be passed to the display function. The VB does not have a terminal output, and shouldn’t be treated like you would running a PC console app. If you have it print to a string, then you can decide what to do with the string, either by writing it to the display using vbPrint() or something similar, or to the link port, or just to memory (like saving high scores).
I also think the ASCII table should be modified from the current 256 char one to just the standard 7 bit 128 char one (with one of the non-printable characters being the blank char so you can have transparent – space isn’t transparent when you have the text “highlighted”). We don’t have unlimited resources, and there’s really no reason to have extended ASCII (or if you really need it, add it in your own specialized lib). I guess the unprintable characters could also be replaced with special extended chars that people may use if anyone thinks that they’d actually be useful.
Another one I hate is the vbWaitFrame() function. This has had MANY different versions, and they all suck :-P. To me, waiting a frame would be a display or game frame. This has almost always been just a delay of arbitrary length, with the exception of a few versions that actually wait a full frame. The problem with waiting an unknown length is that it changes from version to version, and the waits are all messed up… and the problem with waiting a full frame is that it doesn’t give you an exact amount of time that it waits, and it’s also too long for most simple waits (main game loops should be based on this, not short pauses). IMO, we should have an asm function with the proper number of clock cycles counted to get near exact (minus small overhead in/out of the function) to a specified amount of time. Then call the function something like usPause() for microsecond pause (which will always stay at 1us regardless of anything). With an unsigned integer passed to it, we could wait anywhere from 1us to over an hour. I think I even wrote a function like this in asm a long time ago.
I disagree about using precompiled libraries. I like to make modifications to libraries, and especially on the VB, many of these libraries are not optimal, and based on old information (they work well enough, but using new info, they could be made better). I think the headers should be freely available for anyone to modify, and especially to view as a reference… although people should realize that it’s preferred to keep the libraries standard, which is why I think we should use #ifndefs in the standard libraries, and encourage people to make copies in their own headers. That’s another problem with standard libraries is that many of these functions are in their infancy, and you can’t continue to make these things backwards compatible forever when they should have been done some other way.
Anyway, I haven’t seen jorgeche’s libs, but I know Parasyte had logically broken them down into several .h files a while ago, so it may be worth checking those out too.
Cool… it’s good to hear that you guys are getting them working again, and making your own methods. The way that I’ve been doing mine lately is using a spring clamp (like: http://www.toolstation.com/images/library/stock/webbig/14106.jpg ), and a transistor heatsink (like: http://www.hamtronics.com/images/P1002092.jpg ). I take the rubber ends off the clamp, stick the heatsink against the display cable, then clamp it to the display with the clamp. Then I stick that in the oven.
The clamped heatsink gives equal pressure against the cable, along with heating evenly and absorbing more heat (because the air is hot and the device is cool, so it does the opposite of the cooling effect when the air is cool than the device is making the heat).
Another technique that may work, but I’ve never tried is using an iron. With that, you could heat and press on the cable by hand, which would give you a little bit more of a “feel” of what you’re doing.
