My main VB has the same problem (not the cables). If you were foolish enough to take apart your display elements you would see that there is a presure contact to connect the ribon connector to the actual LED array. This is where the problem is. Im guessing it would be easier to pick up a damaged VB off of the internet, etc, and canablize its displays than to fix it yourself.
Pull pin 5 high or low while the VB is running, that should let you know if it is a valid reset. As mentioned before it is trivial to make an interupt handler that waits for the expansion cart interupt. This way you can ‘break in’ anytime you want by pulling the cart interupt line. Not only would this let you do a reset, but you could also do memory/register dumps and you would be free to resume the games execution at will…
ps, the front end is pree-compiled with reality boy. If it fails when you try to compile it yourself what version of Visual Studios do you have? It should be strait Win32/C++ with no external dependancys but you know…
Please, let me know when and how it crashes and I will fix the bugs. You know, what OS, what games, what is the path to the exe, what version of RBoy, etc. And most import if it crashes during game play, when did it crash.
Oh, if you don’t have write permisions to the directory where the roms are stored you might get a crash when you save a screen shot. (I should test that out…)
Yea, a hardware link at the display side would be best, you just dont have enough bandwidth to move game state data over the link cable. It would be easy to implement if you were writing a game from scratch but almost imposible to retrofit into mario tennis, etc.
Reality boy 0.81 works with cyberscope and red pallets (and now includes a nifty launcher so you dont need red dragons gui)
ps. Has anyone tested red_dragon/reality_boy with a pair of shutter glasses or any 3D aparatus besides colored glasses? I would love to know if it works and if not, what I need to do to fix it.
It is an easy hack, but one I have never tried since I dont own a Genesis copyer, and i already have a VB dev cart.
Basicaly the genesis edge connector is the same as a ISA bus connector, so get one of thoes from jameco for $1. next get a bit of ribon cable , im guessing that any new IDE cable (the 80 pin ones with the extra ground lines) would work. And finaly you have to dismantle a VB cart (use mario tennis, they are cheap).
So basicaly as the poster said, folow the pinout in my document, wiring a1 to a1, etc. using the ribon cable to hook the ide connector tho the VB cart (solder the wires strate to the edge connector on the VB cart) and make sure you have a long enough cable so that the Genisis cart is not dangling when the contraption is pluged into the vb (that will relieve the stress on the cable).
As a final note, if you pull up the /CS line on the rom in the VB cart you can wire it to a switch that either ties it to ground or +5v and presto you can play the VB game or switch over to the Genesis cart.
Oh, and I dont know what to do with the ram, Im guessing that the genesis uses a compatible scheem for backup ram but I am not positive, use your head and follow the pinouts to figure it out.
Why mess around with a universal adapter? The VB uses the exact same power brick as the SNES (and posibly the N64, I cant remember anymore). You should be able to get a MadCat SNES brick for $6-$12 and all you need to do is wire it into the existing batery pack with aligator clips or something. Or plug it in if yo have the power adapter.
They all have very distinctive loop and functoin call code that could only be generated by some sort of a compiler (or a realy fancy macro assembler, but thats only 1 step below c anyway).
Whats more interesting is that there are only about four ‘engines’ in use. Most of the games are based off of the same code set even across company boundarys. For example (obviously) 3D Tetris, Red Alarm, and V-Golf all use the same underlying rendering engin and interupt structure.
I have always wondered if the developers where very free with there code or if Nintendo had several dem o programs that everyone based there code off of.
If anyone wants to undertake the task of moving reality boy off of Allegro and onto SDL or another cross platform library I would apriciate the help. Its realy quite simple I only use 5 or 6 allegro functions, just abstract them and swap out the underlying library. The big kicker is rewriting the key routines, but while your at it you could hack in joystick support and make the world a better place.
All of the comercial games use C, and you should to. The V810 was designed with compilers in mind (large register sets, many ways to optimize jums, etc) and it would be dificult to optimize your code to the same level that an optimizing C compiller can do it. I would save assembly for inner loops and critical sub sections only.
I would not waste my time with my java assembler (unless you want to improve it or are masocistic) It basicaly is just a bytecode reinterpreter and has veryy little in common with real assemblers. I would do almost anything to get GCC going and use that instead of any assembler (way nicer).
Have you thought about using a simple dos or linux emulator? vbGCC for dos should run nicely in any of the various dos mode emus for linux since it does not require anything fancy like a frame buffer.
On a side note, Reality Boy should compile nicely on your system. Let me know if it does or you have any troubles.
I second that, having worked hard to get 3D support in the emulator I would like to se as many people as posible experience the VB in true 3D. Most games are rather boring untill you see the 3D effects (space squash anyone).
Besides as stated above, it is trivial to convert a 3D capture to 2D. Basicaly you go into photo shop and split the red/green/blue bands apart and presto a perfect left/right image pair.
Actualy it would be trivial to remove the optics in front of the display and replace them with a magnifying glass. Than if you placed a fiew mirrors strategicaly in front of the display you could project the image back to the user at a much larger dimention. Go look at some older arcade cabinents for more on this idea.
It might be posible as well to feed a small amount of voltage to the LED array to increase the overall brightness of the display (like 0.5v to 0.8v) but your not going to make a 10′ projection with the VB displays.
Disk Drives:
Some IDE HD’s (the older ones) can be forced into a simple 16bit mode where they look almost like a memory device. With 32 address lines and 16 datalines and a simple read/write pin.
The problems withthis are of course speed, most HD’s can take seconds to access a sector on the drive. And dealing with the file system. Disks are block devices, meaning that they want to write data out 512KB (or so) at a time. If you don’t implement a filesystem you will be wasting 90% of the disk.
flash disks (AKA. SD, CF, MMC, etc)
Flash drives have two (or three) problems. First half of the devices are serial so a serial to parallel chip would be needed. Flash disks are very slow, and we need a sustained access faster than 100ms for our cartridge reads. And flash chips must be block written like HD’s but can be read out sequentially like a rom chip, so thats only a problem on writes which we don’t intend to do.
You can solve the above troubles by having a small block of sram or flash rom (not a flash disk) to act as a buffer letting the data get streamed from the HD/Flash Disk to the buffer and than executing the code from the buffer in turn. The downside here is that its complicated (not impossible), you would need a pic controller or other embedded device to handle the streaming and the timing on the VB bus would be critical to keep it from locking up. It is much easier to think about making a killer flash cartridge for the VB that would have enough storage to hold several games at once…
