Sorry to bump an old thread but I felt I had to put up my own story. About 8 years ago I got a job making video games from my VB connection.
About 12 years ago I was frustrated with my job programming for the government and decided to follow my dream of doing videogames. So I dusted off RealityBoy and sent out a bucketload of resumes. I actually got a few callbacks and one semi serious interview out of the effort. One was for a startup doing iPhone games, I blew that one by asking if there really was enough of a market at $2 a game to make a profit 🙂
Anyway due to a sickness in the family we moved to be closer to my inlaws and the videogame dream seemed dead. Fast forward a few years and the company I worked for was just a few months away from shutting down when out of the blue a game company called me up and asked for a face to face. They had seen my website and thought I would be a good fit, even though I was on the opposite coast from them.
I think the moment I got the job was in the interview when my future boss handed me a marker and asked me to outline how the virtual boy works. He grilled me for half an hour then took me to lunch. I got an offer the next morning.
I agree with DogP, never be scared to show off your nerd skills. Real developers want to know you have the passion. I always mention the virtual boy on my resumes and would hire anyone who could show me that much interest in there own work.
The frontend uses an old manifest file from VC6 to enable the XP look and feel. I suspect that is what is causing issues with XP64. I will fix the missing parameter and stop RB from exiting when passed a bad parameter. I agree it is a little harsh right now.
I definitely recommend downloading the ‘lite’ edition of visual studio 2005 from Microsoft, It would be a better platform than VC6 and would fix your compile errors.
The set_window_title error is probably caused by a different version of Allegro. I am using 4.22. The newer beta code is way to messed up to be usable. Also I am now linking Allegro staticaly, so no need for the allegro.dll. You need to rebuild allegro with the static option turned on.
If RunnerPack sends me code, I will gladly merge it in. I think all the options are covered except for -network, I was just to lazy to hook it up.
I have a copy of vista 64bit at work, I will test this out and fix the crash. I will probably be merging the front end directly into the win32 release so this acts more like a proper windows application. But that may take a while.
David
ps Many thanks to DogP he did 99% of this work, I can not take any credit.
I had not seen that Issue before but I have a pair of the glasses (they came with a box of markers). Basically each lens of the glasses has a prism in it, oriented in opposite directions along the horizontal. So when you look at a red object it appears closer than when you look at a green or blue object. This works ok in print but it looks terrible on a monitor, and is very dependent on color so it would do nothing for the VB.
Did you ever solve this? It sounds like you are overflowing the stack or ram. Maby you are passing a large struct to a function, or you are declaring ararys within functions without declaring them static (this includes images imported from external files).
My version of vbgcc came around from the need to compile a very large project (2MBit). It workes very well I might add (but the gcc optimization is not quite 100% yet). So any troubles you are having with the memory is a side effect of your own code.
Sorry I have not been around much but life got realy buisy once I moved.
I got my cables from a used videogame shop. (I use to repair videogames in another life) Usualy they have boxes of the things laying around in the back. Especialy concidering that the same AV cable worked for the SNES and N64 (and game cube?)
Boot block is usualy found in the 16 bit chips, but future designes should use theas anyway to save cost. You would only use the boot block feature once the code was stable enough to make permanent (aka when you ufinaly decide to make 50 carts and sell them) Once the boot block is set yo ucan do a whole chip erase. Also block by block is not bad, since in the future you will be stuffing multiple games in one cart (boot loader anyone) and block by block would program faster.
VirtualE’s link port hack works like a dream. I cut up two N64 AV cables and wired them into the VB in about a hour. (of cource I had a box of old AV cables laying around). Once we stabalizze the code you can put the program logic in the boot block and lock it down, that way a chip erase should leave it untouched.
Cool,
lets get some code out on the net so we can all start hacking a in system programable flash cart. I’ll try and unpack my VB and wire up /WE this weekend and see if I can replicate your work. I relay want a link port programmer going soon, I think it is the only way to realy make this work on a large scale.
On a Side note I moved to Tucosn, AZ so if any of you are down hear let me know. (sory Parasite, had to leave you)
The structs are defined in my affine demos. Its realy simple:
struct x{
int a;
int b;
…
} *x_ptr = 0xppppp;
You could come up with it on your own if you wanted.
As far as GCC goes: Mine is based on the same code as on this site, but… Mine has a working stdlib so things like floats work properly, and you can make fn calls from other c files. Also I rewrote the loader so that you dont need to run any extra programs to convert an object to a working .vb rom file. I of cource recomend using my own compiler iteration but no one else does so take it for what its worth.
Basicaly for the boot loader you have to take over the top block of flash ram and virtualize the interupt table. So make a 8k program that loads a list of avalible games from the top of saved ram space, and gives you a menu of games to play or the option to load a game from the link port. thain when a game is running and it throws an interupt your interupt handler just jumps to the relocated game interupt table located either at a blank area in rom or at the end of sram space.
Your cart could have a 32k sram chip (or larger) to add extra space for the jump tables and other values. Besides you want to sell the cart as a development device and not a space invaders loader. So having the uper 8k of rom being inacesible would not be a big deal.
Also when reflashing the cart you lock the uper 8k in a ‘boot block’ (so get a top boot block chip) that can not be overwriten without some extra gyrations. 8k would be enough for your loader, a flash routine, the GDB (GCC Debuger) loader/debug routines and a generic set of librarys.
Speking of GDB, gdb has a rom resident boot loader that is designed to run over the serial port. This is the best way to implement the serial port loader since it already does everything you would want to do (read/write in bytes/blocks to any address space) plus it would let you run a debugging session right in hardware, great for development.
DogP, your flash cart is beautiful! Please give me the schematics and I will add an sram and /WE controll logic for you. I have $50 in free PCB development coming to me and I want to use it up.
So, I to have been working on an in console flash cart for ever. But alass I get 3/4 of the way through the design and run out of time. Lameboy has it right. You need a flash cart that is programed form code loaded in to ram by a boot loader that connects to the pc via the link cable. We know how to do everything but do an in game flash of the rom cart. I think if you put some flipflops at a specific address in expantion ram you could initiate the activation of /WE by writing to a specific address. Unfortionently the flash requires several writes to program a single byte, the question is, will noise on the buss mess everything up? The answer is write a program an try it =0)
I would love to colaborate with someone on this. let me know if yo uare interested.
Sadly the state of hombrew development on the VB is in it’s infancy. Any code older thain about 3 years is junk, ignore it! That is to say there was no consistency between the librays and compilers used, so they wont compile and probably don’t make much sence.
Now that we have vbgcc and some sort of semi stable library things are better, but far from great. VBGCC is a poor implementation of C, with way to many restrictions to be practical. I have a new version of vbgcc (gccvb, all the same) on my website but you have to build it yourself and it totaly breaks (the broken) exiting librarys. So far I have not had time to come up with better librarys. Maby that is something you could work on since you are obviously no sloutch to programming.
Take a look at the very latest Affine mode demo on my page, it compiles with the new vbgcc on my website and in general should be a good example of how to code for the vb. (but a very simple example)
As stated before the Mac Emulator ViBe does support sound fairly well, and has for some time. Of cource Richard is a bit of a smuck since he ows me a bucket load of details for all the help I gave him but that is another story.
If you own a Mac than the ViBE emulator can play Golf. It has been a long time since i tested ViBE since I dont have a Mac…
My emulator (and all based off my source) has less than perfect interupt timming, and thus games that draw directly to the display (aka golf) dont play correctly. To be honist my interupt handling is Sooo bad I am suprised at how many games actualy play. I have spent most of my efforts on perfecting the graphics routines and just have not had as mutch time for interupts and timmers.
My emulator can play most of the games (except the wireframe games aka Red Alarm and Virtual Golf, etc) And is almost perfect with over half of the games. Except for sound fo cource. You can find it here: http://www.goliathindustries.com/vb/ if you want.
CVS Sucks Peaches! I have been realy happy with subversion but there is verry little web hosting support for it. Its sutch a simple problem, why do they make it SOO hard!
GCC development is a huge pain in the side. Mostly because there is NO documentation for anything. I think I have identified all of the areas that need to be modified in GCC 3.x but its the nity grity details that kill you.
So far I have only been improving the current release of gccvb and ahve not migrated any of the v810 code forward. But it will need to be done sooner thain later since 4.x GCC series no longer compiles the 2.x GCC code (grr!).
Im way buisy right now trying to get a job in Colorado at Idol Minds (makers of Neopets for the PS2) but I will try to find time to post all my new code and changes to my site soon (before I forget everything =0). Right now Im working on a PS2 remake of asteroids (in vector mode) but usig a 3D perspective (like my VB Asteroids 3D project).
Speeking of nothing, I have a new port of GCCvb and Reality_Boy almost ready to go but man I can’t find any free time.
I would love to pass GCCvb off to someone else so they can finish it up if someone wants to take it back. As of right now I have it working perfectly so you can use doubles, turn on optimization, support unary increments, etc. I even have new and delete stubed in (but I dont allocate a heap since we dont have enough memory).
I think this build would finaly be ready for someone to start porting code from the SNES to the VB. Or even some GBA code might run.
