Although I haven’t seen a small VB display like the one you’re selling one ebay for a while, IMO you’ve listed it WAY too high… last time I’ve seen them, they were selling for ~$150-$300, probably on the low end of that without the inserts.
Red Alarm demos aren’t very rare… the last few I’ve seen have sold for $50-$100, and that’s about the same for a working Wario Land demo… no idea what a non-working one would sell for (assuming you mean Wario Land, and not Mario World). If you do mean Mario World, yeah… post some pics… I’d be interested in seeing it, although if it doesn’t work, that’s sorta a problem :-/. Of course I may still be interested.
You should drag/drop the ROM onto the padder icon in the folder… not a window with the padder running. You can also do “padvb ” at a command prompt, which is why drag/dropping on the icon works (windows concatenates the file name of the file you’re dropping to a command line of the executable).
Emulating the timing of the registers is a mess… I wanted to fix that problem too, but since I didn’t write the original code, it made absolutely no sense to me. I’m hoping David will have a chance to rewrite that code. Red Alarm is kinda playable as it is… 3D Tetris is worse, but almost playable… Golf is unplayable because it doesn’t freeze the screen like it should. That’s the same problem that causes 3D Battlesnake not to work (and probably Etch A Sketch, and other homebrew direct screen drawing apps that disable the framebuffer refresh).
Cool… I’ll have to try that… I already made the changes in the cp_io.h, along with a few other simple things… and yeah, I just recently upgraded the Platform SDK to get the Winsock stuff working for the link port emulation. Rather than converting the VC7 project, I just modified my original VC6 project from the older RB version and rearranged the file structure.
I’ll have to rebuild Allegro and see if that solves the problem… that looks like the most likely culprit.
Yeah, I’ve considered getting the free Visual Studio 2005 (or even the full version that I am licensed for from work)… but personally, I think .Net sucks. For almost all the apps I write, what should be 50k (compiled w/ gcc) is usually about 100k w/ VC6, and 300+k w/ .Net. I just dislike the extra bloat, and I really hate .Net framework, and some of the other crap that many programs compiled w/ .Net require.
I guess it’s just VC6 is what I’ve been using forever, I’m comfortable w/ it, and it doesn’t have those extra annoyances that the newer VS’s have… I’ve never had anything that I wasn’t able to do w/ VC6… although I do very little GUI work, which I’m sure .Net greatly simplified.
That’s good to know about linking Allegro statically… that’s probably the dll problem that I’m seeing. I think I’m using Allegro 4.22 as well, but I’ll check that too.
BTW, I uploaded the fixed link games: http://home.comcast.net/~virtual.boy/projectvb/tech/programming.html … I don’t remember if I ever tested them on hardware though… but I’m pretty sure they work. Tron (3D Battlesnake) doesn’t work correctly in the emu because the freeze of direct framebuffer drawing doesn’t work correctly, so it’s just moving dots rather than leaving lines (makes it pretty tough to have a collision). TicTacToe should work, and should be a good example to write your own link code from.
If we could get the direct screen drawing working properly, I think we’d have 100% emulation (not 100% perfect, but all games would play with reasonable accuracy).
Yeah, you’ll need to start two instances of the emu, and use a command line argument for the ip. I don’t remember the exact syntax, but it’s something like “-network host” to host a game, and “-network ” to join a game. You’d use “localhost” or “127.0.0.1” to connect to your own system. If you look at the usage from the command line (by just running reality_boy with no arguments), it’ll tell you the correct syntax. RunnerPack also updated the frontend to allow all the new options to be selected from the frontend, although I don’t think his changes made it into this release (maybe he can post it seperately).
IIRC the current TTT and 3DBS don’t work on it though, because I made a stupid mistake in the code, which surprisingly works on real hardware (could actually cause bus contention). I’ll post the new versions w/ the new source when I get home tonight.
On a side note… I haven’t been able to compile this last merge of the code… I get lots of errors, so I’ll have to dig into it some more. I’m still using Visual C++ 6 though. The last versions where you had used .Net hadn’t been a problem, but for some reason, something in this version gives me warnings such as inconsistent dll linkage, and then an error of unresolved external symbol set_window_title. There were a few other changes you made that were incompatible (like long long int, which VC6 doesn’t recognize), but those are simple changes. I really haven’t spent more than about 30 mins trying to get this compiled, so it may be something simple that I forgot to change.
BTW, as far as sound emulation goes… it’s not perfect, but it’s pretty good in most cases, with no support for modulation, and I believe sweep is incorrect, and I think some of the noise channels don’t work (I think it’s a problem with something I set up in Allegro). Link port emulation is not really playable over the internet (too laggy), but it works well for development on the same computer connecting to localhost (or for turn-based over the internet). My link code for 3D Battlesnake and TicTacToe on my site is flawed… I’ve made the changes on my local computer, but I haven’t uploaded it yet… once I upload it, you guys can use that code as an example to experiment w/ the link port.
I think the rest of the changes are listed in the history.txt file… of them, notable are the fixes of some affine stuff (which fixes the graphical problems RB had w/ MK’s VB Racing, along w/ various minor problems seen in other games). Also, I added cache profiling in the debug version (reality_boyD.exe), which you can press ‘\’ to display cache stats, and ‘/’ to clear them.
The interesting thing with that is seeing how almost every VB game just turns on the cache and leaves it… which is horribly inefficient. Teleroboxer is the only game that I noticed to actually enable/disable it, but during the game it’s disabled almost the entire time (once again, inefficient). To supplement my post in the dev section about cache usage… if you check my Mario Kart game w/ this, you’ll see a very high cache hit ratio, along with a high percentage of instructions cached… this is good use of the cache. That’s the real reason I added this… so when you’re developing a game, you can optimize your cache usage.
Oh, and I fixed the Save RAM bug that KR155E pointed out.
I haven’t done any DS development, nor have I really compared the two systems side by side to see what kind of optimizations that could be done… but IMO it’d be pretty close to hopeless without the perfect emulator (ie not a port of an existing emu). The ARM9 is a 32bit RISC running at 66MHz, the v810 is a 32bit RISC running at 20MHz. Even if you could find comparable ARM9 instructions to completely replace the v810 instructions for the CPU core, you only have about 3x the clock speed to handle all the overhead of the rest of the CPU core, fetching from ROM, RAM, display, etc.
IIRC, David Tucker said that 80% of the time in the current RB is spent in the CPU core, so that’s where most of the optimization would need to be done, and luckily that’s probably the best place since most v810 instructions probably have an identical ARM instruction (except probably the bitstring functions, which aren’t used much). But you still can’t execute these instructions natively, so there’s still overhead of translating the native v810 to the ARM instruction.
So yeah… my opinion is that you probably could get the emu running on the DS, but getting it running at any more than a couple FPS, or especially at a playable speed would be EXTREMELY difficult. As RunnerPack said, even on a reasonably fast desktop PC, the emu still doesn’t run perfectly. Of course RISC emulation on a CISC CPU in a multitasking environment isn’t ideal, but comparing a multitasking CISC @ 2.4GHz to a dedicated RISC @ 66MHz, there should be more than enough difference to suggest the P4 would perform better than the ARM9.
Heh, I’ve got a case of those… there was originally 48 (8 of those boxes), but I’ve used some of them. The entire case used to pop up on ebay every now and then, and usually sold for ~$30.
That is pretty cool… although I believe it’s supposed to be non-crossed. That reminds me of my desire to connect 2 gameboy cameras to the VB (although other cameras would probably work better since we have 4 colors rather than just 2).
My Mario Kart game is currently waiting the the queue… I got annoyed by some bugs and the lack of certain features in Reality Boy when working on Mario Kart, so I decided to take a few weeks to fix up RB. I’ll get back to Mario Kart once I get everything on RB working how I want it.
AFAIK there’s no patch… the only real problems that it has is that it crashes every now and then on the real cart in real hardware, although when I burned it to my flash cart I got past level 100 without it crashing. I don’t know for sure what causes it, but the only thing I can think of is that they set the wait states to 1, but the ROM isn’t fast enough. The flash chips I use are all fast, which could be why they work fine. Or it could be that the ROMs are just crappy, but I doubt that since they seem to be the same type used in other 3rd party games.
jojobean wrote:
i have no idea why you assume you have been in the vb market longer than i have dogp. not only was that an unjustified assumption; it was wrong. in 2000 is when i made my first step towards buying games that were a little more rare, such as insmouse and space squash.
I apologize… I was wrong, although you seem to be taking it personally… I said “I’m guessing” because I didn’t know, although my assumption was from being in the scene so long, and never talking to you or hearing of you until this year (and seeing your join date of this year).
jojobean wrote:
as far as i see it, i’m done arguing this. we’ve made our cases known and now we’re getting to a point of who’s the more uber collector. lets stop.
I agree… I’m done w/ this thread… although sorry if you took it as trying to prove who’s the uber collector… I don’t claim to be, because there are many others out there with much nicer collections than I (and I’m pretty good friends with several of them). As most people should be able to tell, I’m more interested in VB hacking/dev than collecting, although that really doesn’t have anything to do w/ this thread.
Anyway, maybe one of the mods can lock this thread so nobody can revive this thread later.
The last sale of the rares that I know of was a Virtual Bowling and SD Gundam for $1800 earlier this year. So, either $900 a piece, or more realistically, $1000 for Bowling, $800 for SD Gundam. So yes… the prices, at least then, were still up there. And I’m guessing I’ve been in the VB market a little longer than you jojobean… I’ve been collecting since 2000. I’ve seen things go up, down, and fluctuate like crazy. But I have still never seen a Gundam sell for less than $600 or a Bowling for less than $750 (but as I’ve said many times, I’m not talking about long term prices or trends, because that has nothing to do with the single event of releasing a ROM).
Murfo: If you’re trying to slam on me for arguing that value will drop from a released dump (with proof to back up my statements, unlike your unsubstantiated claims that nothing happens), sorry… I don’t have a financial interest in these games… I don’t own SD Gundam or Bowling… and I really don’t care about the couple hundred that my VLab or Space Invaders will drop… I’m just stating facts. Lets see some proof of any of your argument… or better yet, let’s see your argument… all you’ve said is an opinion that dumped games won’t change anything.
And if I sound angry about those dumps getting released, it’s because I am… those dumps that were released were dumped in confidence of the original owners so that there’d be a safe backup of the games. The agreement with the owners was to not release them. I would have had no problem at all had they been new dumps created from their own carts, or with permission of the cart owners. I would have personally liked that actually, because I don’t think dumps should be hoarded… but I completely understand why the people that own the carts won’t agree to have them dumped unless they’re kept private. I just REALLY hope this one incident won’t affect our ability to get prototypes in the future, but sadly, I wouldn’t be surprised if collectors wouldn’t trust anyone in the VB community to dump their rare stuff anymore.
Ugh… I’m not even gonna start again… I’m just gonna state DC games at $100 is chump change… Jack Bros has been dumped for many years and still gets over $100… how many DC games sell for almost $1000?
If you think that Jack Bros and Waterworld are relevant here, we’re arguing two completely different points. I’m not talking at all about price fluctuations/changes over long term, because yes… certain games increase/decrease/fluctuate in value over time, and for lots of reasons. I’m talking about the change in price at the instant that the ROM gets released, ie. Value1->ROM Release->Value2. The delta (Value2-Value1) is what I’m talking about. And the reason for the rares’ slow continuous drop in value could very well have been the ROM getting traded within the community.
Jack Bros and Waterworld have had their ROMs available for what I’ll call “forever”. To make a comparison to what I’m talking about, we’d have to go back to the day those ROMs were released and check prices before and after the release. But even that wouldn’t be a good comparison, because like I said… there’s value in being able to play the game, and also in collecting the cart. When these ROMs were released, there were no readily available flash carts, and VB emulation was basically non-existant.
If you want to somehow compare them, I still have never seen either of those two games sell for more than any of the 4 rare Japanese games… but the only thing these games have in common is that they plug into a Virtual Boy.
Maybe you missed it, but those Space Pinball “prototypes” being sold on ebay are fakes… they’re a blank dev cart (which sold on Yahoo JP a few years ago for ~$150 each), that they burned the Space Pinball ROM to on some blank EPROMs. I picked up one of those carts: http://home.comcast.net/~virtual.boy/projectvb/tech/carts/nineprom.html … If the Space Pinball ROM was released tomorrow and I burned it to EPROMs and tried selling it on ebay, do you think I could get $1000 for it? The only value of the cart would then be the physical cart and the physical EPROMs (and a few bucks for labor of burning the chips). Therefore, the value with the ROM released would be the current price (>$1000) minus the physical price (~$200), or about $800 less.
About the prices of WW/JB, those aren’t relavent here, because those ROMs have been available “forever”… I’m not saying prices don’t fluctuate, I’m talking about the price difference between before the ROM is released and after the ROM is released.
