The controls have momentum, so you want to just tap the direction you want to move, unless you need to go all the way across the screen. This is unlike Bound High where you hold the button while you want to go that direction.
I guess how I’d describe the game is Bound High meets Ice Climber. You can make your own levels by changing level1.h and recompiling… it can be as long as you want it to be (this one is only 200 lines, and relatively easy). 1 is a platform, 0 is space.
Correct, the column table is 512 longs total (256 longs per eye). But no, you can’t make pixels 10% taller, because the vertical height of a pixel is fixed by the LED bar. The column table is to coordinate LED timing while the mirror is scanning horizontally, so it could only adjust horizontal width.
Actually, mine is NTSC (though it could probably do PAL if I had a PAL TV to develop it on). It is B/W on TV (because of NTSC color bandwidth, it looked like crap in color), though it’ll do VGA in color… and both NTSC and VGA will do shutter glasses.
I believe the actual Video Boy requires a PAL TV though.
You SHOULDN’T pass a struct by value because it could take a LONG time every time you go into the function, if the struct is very large, and possibly overload the stack. That would copy the struct to stack… and you CAN’T do it because memcpy isn’t implemented in gccvb. It would be pretty pointless to do, since you most likely don’t want a temporary copy on the stack.
Something like: ships[end_ship] = i; shouldn’t have worked whether it was in a function or not either, since that should also require memcpy. The way to do it is to use copymem (check your lib, since there’s probably a few different ones). Basically, it’ll just copy the data from the location of one struct to another struct.
Do something like:
copymem((void*) ships[end_ship], (void*) i, sizeof(ship)); . IIRC it’s copymem(destination, source, size), but you should check, and I’m probably missing &’s or *’s somewhere in there, but you should be able to figure it out.
And yes, malloc doesn’t work… you need to do your own memory management.
Are you passing the struct, or the pointer to the struct? You should be passing just the pointer. How about posting an example of what you’re calling and your function prototype?
RidingHero wrote:
If you can just find an 850mA+ universal adapter that has the same plug size as an SNES, just get one that can output DC 10v with a negative center polarity/tip.
That’s what I was suggesting, except if he uses a JP tap, then he can use a universal adapter with a normal tip (the SNES has a funny tip, but the JP tap and AC adapter have a standard tip).
There should be no reason for the VB to need any stepdown for a JP adapter to work in the US. Even if the output voltage from the adapter is a little high, the VB has a switching regulator inside which is rated for 6V to 13V.
I think Akumie is asking about using it on 230V though… in that case, I’d get a JP tap, which has a standard connector, then get a standard 9V adapter with the same connector.
I’m not familiar with the MIDI interface part, but the UART part looks fine. Connecting directly shouldn’t be a problem, since you’re connecting input to output, and vice versa.
The clock pin on the VB side is an input or output, depending on whether the VB is set as the master or slave for the connection. In this case, you’d need it to be master (output), since the MAX3100 needs to be a slave on the SPI bus. Also, the sync pins aren’t exactly a clock… the sync out is a 50hz signal corresponding to the mirror oscillation, and though I’ve never looked closely at it, I assume that if the sync in pin actually does anything, it syncs the mirrors.
OK… I assume that open collector pin is the Ctrl line on the link port… how is this controlled in software? David Tucker’s VB Programmer’s Manual doesn’t provide much documentation on that, and neither does the Dev Wiki at the moment… does anybody know?
Yeah, it’s the COMCNT pin… you control it by writing to the COMCNT Control Register (0x02000004). Bit 1 is the value to write, Bit 0 is the read value. I assume you’re familiar with how open collector pins work.
Thanks for the suggestion– after doing some further research I think I may have found a solution with the MAX3100 SPI UART driven by a 1Mhz crystal. Now I’m not a EE/CE major– my degree is in programming– and electronics are more of a budding hobby for me, so I admit I don’t know much. 🙂 Do you think the +5v pin on the VB link port could handle a total draw of ~10mA for the entire circuit?
Yep… the +5V pin is shared throughout the system, and it can easily handle an extra 10mA.
I wish I had time to do some coding right now… my graphics and audio skills are lacking, so I tend to either rip stuff, or just make simple images/sounds.
Well, I assume the VB isn’t just a consumer, since he said better in-game music… which means that the VB would have to request music to be played. And yeah… if you want to modify a cartridge, you have a lot of options, like adding a UART to the cart bus, as well as mixing the raw audio into the audio stream right on the cart.
Short answer… No. I’m not familiar with MIDI, but I’m very familiar with RS232, and The link port is synchronous while RS232 is asynchronous. I can’t say that it’s IMPOSSIBLE if you’re REALLY clever, but I can’t think of any good way to make it work (especially at 31250bps).
You don’t get any manual control of the Rx and Tx lines in software… basically, you load an 8 bit register, then tell it to go… in Master mode, it clocks those bits out at 50KHz. It’ll clock them out faster in slave mode, but you’ll need an external crystal (which you could possibly make work using a crystal at 8*31250). The 8 bits are automatically clocked into a register. You do have software control of one open collector pin, but that’s not very helpful if you need bidirectional communication.
If you’re really looking for ideas to make it work, here’s a doc I’ve looked at before to do something similar on a TI DSP: http://focus.ti.com/lit/an/spra633c/spra633c.pdf . The McBSP is much more configurable than the VB link port though.
IMO, I’d use a microcontroller between the VB and MIDI to convert the synchronous signal to asynchronous… or possibly even just use an SPI UART device (the VB link port is very similar to SPI).
That one doesn’t look to have any sort of tilt to it, which would make it really tough to use… unless it tilts at the base.
I’m not really sure how you’d improve on the current stand design, except to keep the center piece from breaking. I never have problems with the height being wrong (I can adjust my chair height if I need to)… other than that, it has tilt, which IMO is the most important (depending on the position, sometimes it feels more comfortable to look down into it a little bit, other times it’s nice to look straight in).
I’d probably pay a few hundred for a real prototype, just because what it is… but I don’t think the design is very good to actual use, so I probably wouldn’t buy a reproduction.
No… I don’t think anyone has ever come across any bootleg VB games (unless you count the Hong Kong module, which is rumored to have existed… though there’s never been any proof, and I personally highly doubt exists). There would have been no money to be made from them, since original games were hardly selling.
KR155E wrote:
Yeah, a Bound High cart would be cool! I was thinking about making a run of carts with boxes and manuals, but it would not be possible without completely custom parts. Now it seems in reach! 🙂 Maybe I’ll finally get around to releasing BLOX 2 on cartridge?
BTW, how about making dust caps for that connector?
