DaVince wrote:
I thought he said he wants scans of Teleroboxer in the same hi res as the pics he posted?
No, he wants scans in the format he posted (both sides of the flattened box) except at 600 dpi resolution. I’m pretty sure he’s smart enough to know that the images he attached aren’t 600 dpi…
e5frog wrote:
I expect it to have a lot better 3D effect than the 3D TV:s they have begun to sell. With your eyes 12 cm apart (or whatever) and sitting 3m away from a 40″ TV – how narrow is the viewing angle if wanting to achieve the 3D effect?
I’m guessing the person in the middle and that’s it…
It’s my understanding that, unlike the 3DS with it’s auto-stereo display, all 3-D TVs currently on the market make use of some kind of eye-wear, which would mean the viewing angle for 3-D is the same as that for 2-D (which is quite good on high-end panels; approaching 180-degrees horizontal and vertical).
That being said, I have noticed that the apparent depth of a 3-D scene decreases as you get closer to the stereoscopic display, and vice-versa. I would assume the relative size of the screen (for a given viewing distance) causes a similar effect.
game freak wrote:
That’s reasuring. I had just got this Virtual Boy of eBay and was still waiting for my games to come in so I was super dissappointed when it crapped out on me as soon as I tried out my brand-spanking-new copy of Wario Land. Another minor issue I’ve had is that sometimes the left display would mirror temporarily while I played. Was that probably a cable issue too?
Before I forget, do you know where I can get a good screw driver or bit for this? I’ve heard that the Virtual boy needs a super long screw driver to open.
Yeah, the mirroring thing is definitely a cable issue.
About opening the unit: there has been a lot of discussion about it on the forum (the search box is your friend ;-)). I think the general consensus is that no one makes a bit that fits out-of-the-box. They all need to be modified in some way to reach the four deepest screws. The short ones need the corners ground off and a slot cut in the back to drive with a flat screwdriver. The longer ones (that supposedly work on the VB) need just a bit of the corners ground off and then will work in a standard hex driver, I think.
There is one manufacturer that makes a one-piece screwdriver (as in, a plastic handle with an embedded metal rod) that works, but I have no idea where to get one outside of Japan (or inside Japan either, for that matter ;-)).
And then there is just cutting a notch in a flat screwdriver (which is what I did) or the “pen melting trick” which I never got to work.
Wow! I’ve never heard of the image shifting up/down before, or of the displayed image having such a powerful effect on the display quality (although it is a common symptom). I would start by repairing the cable connection with one of the methods detailed here in the forum. If that doesn’t, or doesn’t completely, fix it (which it should) then you can tackle the alignment (which is probably fine).
Raverrevolution wrote:
Just curious, why not use a widely available cheaper chip that’s close to the one you need. Will the whole cart circuit board have to be remade? And if so, how much more work could that take being that you have completed the older chip model?
Besides a possible board re-design (and probably an attendant firmware re-write), there’s also the simple fact that 5V devices are getting rare (I’m not even sure if they are still being made). Chips with 5V-tolerant I/O should be available for a while, but are probably more expensive than purely “low-voltage” devices. However, even if 5V-tolerant devices are used, the board will probably need a re-design to include the 3.3V (or lower) regulator to supply the chip(s). And if purely-low-voltage devices are used, there’s the regulator and voltage conversion for all the I/O. So, it’s better all-around to use the current device, as long as it’s economically viable.
DevilsAvocado wrote:
We’re going to try a mid-90’s techno sound with EON and if I don’t use any EON tune it’ll be something very similar. The beeps, bleeps and bass are all perfect for the style of title animation I have created and the music itself is particularly reminiscent of the mid-90’s computing technology.
So that broken crt0 was causing the problem… 😛 I wonder why it didn’t work for me when it worked for everyone else?
That’s a good question. I hope whoever is working on the gcc patch project checks the crt0 code they’re using.
On a side note, when I was looking through jorgeche’s crt0.s that I compiled, I noticed that it defines .global _rom_title… Since my games aren’t called Snowball Wars, I just refilled the relevant data with the proper blanks, but is there any way I could use this in my code to set the rom info?
Not really, since it defines an address in ROM. But, you could move this code out to an assembly file in your project, which is exactly how the old win32 version worked–that’s what the whole .vbh file business was about. You just have to make sure the reset and other interrupt handlers are correct and that you put things at the right addresses.
Maybe I’ll add some of what I learned about timer interrupts to the wiki if I get a chance to write up a solid article…
That would be great! Just don’t let it interfere with work on your compo entry. 😉
There’s something a little confusing about your code… You have all the “xxx_vector” functions defined in your code, but in my gccVB installation (4.2.2 under Cygwin) those are already defined in crt0 as pointers located in the jump table. I get errors if I try to redefine them. The way I understand it, as in DanB’s code, you would A) define these as externals, and B) set them equal to the address of your handler function(s). Something like this (from DanB’s snippet):
tim_vector = (u32)(timer_hnd);
I think you should go to this post and download the attachment.
It needs to be edited to uncomment the column table stuff (just look for a big commented block, you can’t miss it) then assembled:
v810-as.exe crt0.s -o crt0.o
And copied to /usr/local/v810/lib/crt0.o.
I also noticed that you commented out the contents of the interrupts.h you included with your previous code. These will have to be restored.
Anyway, I fixed your code as outlined above and it works in Mednafen (although I didn’t have font.h, so I substituted the IPD screen chars and it looks funky :-P). You’ll find it attached.
You should also stop being embarrassed or worried about seeking help. The community (and this forum, specifically) is here for that very reason! I wish more people were as eager as you are to learn new things. Also, I feel I must praise you for using the proper spelling of the word “poring”. I’m glad to know spelling isn’t a completely lost art 😉
I re-packaged and attached your code, for posterity and to see if it would go through for me (I thought maybe the attachment thing didn’t like bz2 files, or something; 7zips seem to work).
I have looked, but cannot find the bug. I modified your makefile (no need for the header to be compiled or depended upon) and some of your code, but it looks like it should have worked before, and still doesn’t. Something is getting mis-compiled, because none of your code seems to be running at all. As a quick test, I put this inside the while(1) loop (which should actually be a for(;;) loop):
VIP_REGS[BKCOL] = ~VIP_REGS[BKCOL];
It should make the screen blink on every frame, if all is well. No blinky…
Another symptom is that the character data is in the ROM, but it’s not being copied to the VIP (according to Red Dragon). If I had a way to step through the code, I could probably figure it out…
Also, in vip.h, the VIP_REGS pointer needs to be volatile, like:
(Actually, after I posted the request, dasi gave it to me on IRC, but I’m glad it’s here for completeness of the thread.)
I don’t know how, but the libgccvb I’ve been using is missing that stuff 😕 Now I’m wondering what else it’s missing… I guess I’ll have to go through every version I can find and compile (no pun intended) a new one. Or I could just wait until I need something and bother you again 😉
e5frog wrote:
Even if it’s Spansion it should handle the same, it’s just a different manufacturer of the same chip. Or have AMD changed names to Spansion?
You’re right, though: there could be quite a few parts that are functionally identical to that one, but it can be tricky. Sometimes a chip with the same pinout, footprint, etc. has a different programming algorithm. Although, in that case, it may be possible to change the firmware on the cart to compensate.
Fwirt wrote:
You were right RunnerPack, the header is getting added automatically. I opened one of the freshly compiled demos up in the header editor, and the ROM title is “change this title”. I wonder if there’s a way to set that during compile time…
I don’t think the built-in title etc. can be changed without editing the crt0, but I was thinking of making a command-line header editor that can be used in a makefile.
Personally, I think it would be great if all the VB software that has been written went open source…
I second that! Especially the tools released by Alberto “Virtual-E” Covarrubias. I would love to have the source for his assembler, C compiler, and VIDE.
Fwirt wrote:
Is having a ROM without a header a huge issue?
Considering the code that tells the VB where to start executing is located there, I’d say it’s pretty important 😉
The reason for tarsius4’s ROM working and Fwirt’s “cat demo.vb demo.hdr > final.vb” one not working could be that the header code has been incorporated into the crt0. The external “vbh/hdr” files are no longer required. However, this does mean that default values are used for the ROM name, manufacturer ID, etc. and will have to be changed afterward if desired (or changed once in the crt0, if you just want a generic one). lameboyadvance made a handy viewer/editor for VB header info. It’s Win32 only, but should work in Wine, or you could just use a hex editor.
Good job to both of you for detailing your process and results in building the new compiler. @tarsius4: I hope you can get it built on your 64-bit machine (even though I don’t own such a beast ;-)). I also hope someone is still working on the wonky function call generation problem (since I wouldn’t know where to even start looking for it, even if I had the time to do so :-P).
tarsius4 wrote:
Also, I looked through the patches and notice that they specifically add “v810” as a target for gcc. Would it then be possible to submit these patches for inclusion in the GCC, binutils, and newlib projects? If accepted, wouldn’t this alleviate the problem of gccvb aging as the other GCC et. al are updated?
That would be great, but whoever took v810 support out in the first place might do so again, anyway. But maybe patches produced for gcc4 can continue to be applied to the v810 patched version and we can keep it updated that way… Sounds like more research is required 😉
