I successfully built native Win32 gcc/binutils using Jorge’s patches under Mingw (specifically, the version distributed by the RubyInstaller folks for compiling native Ruby gems). The files are still completely untested, at this point. They may not work, or they may only work on my system (due to missing files, etc.). Since it’s too big to attach to a post:

https://dl.dropboxusercontent.com/u/5754740/gccvb.7z

@blitter:

I am going to try again using your files (and possibly with an “official” install of MSYS/Mingw), but it would be nice to know the following before I do:

1. What do your files add that would make this worthwhile?
2. (With all due respect) are you sure that your changes are not responsible for the problems you observed in the generated function call code?

DogP wrote:
Yeah, recycling the existing one should work… I had no problem peeling it off and re-sticking it to a destroyed cable (the adhesive tape stayed on the stiffener). I think that might be the best way to go (or just re-creating the stiffener with some other material). I tried using 3 VB cables in a stack to get an idea how stiff a triple-thick cable would be, and I think it’d still be pretty flexible, and annoying to try sticking into the socket (though I’ve noticed that lots of FPCs feel different… some are really flimsy, others are pretty stiff).

I looked more closely at the specs… the vias at the bottom of the cable will be a little bit tricky. When I quickly looked at them last time, I had seen the 0.5mm hole to hole spacing… but looking again, I see 0.2mm minimum annular ring and 0.2mm minimum hole diameter, which means the via pad has to be 0.6mm in diameter… which is the pitch of that connector.

I think they could be staggered, which would actually be nice, because it’d add support at the top and bottom of the connection to the display… but I really want the vias to be cut in half, exposing more copper to give a nice solder joint, rather than trying to get solder to flow through a 0.2mm hole. But this will require a route down every other finger, slicing into the via… but their rules say min copper to outline is 0.2mm. So if their DRC doesn’t complain about having vias cut in half, and narrow strips of material routed out, then we should be good… but if those are strict rules, I don’t think that’ll work. Looking at their example picture, it looks like they do allow copper to the edge though, which technically violates that rule.

We’ll see what they say. 🙂

DogP

I didn’t think about putting vias in the actual “fingers” of the solder joint; that’s a good one! I was just talking about putting a couple of vias in each trace, toward the ends, to connect them electrically.

If you want half-vias for better solder access, couldn’t you keep them far enough away from the board edge for their liking, and just cut them in half yourself when you’re cutting apart the cables? It would be a bit tougher on the cutter, wouldn’t it? I like the idea of staggering them for more support over the whole length, too.

Since they’re plated through, wouldn’t whole vias still work if you tin the pads (on the display), add some flux, then heat the top of the via? I’m not sure I like the idea of wrangling thirty separate .6mm wide fingers…

blitter wrote:
The Rift needs whatever software running to warp each half of the side-by-side image to counteract the pincushion distortion done by its lenses (I have two of them and have written software for it). Any software supporting stereoscopy alone won’t do the trick– there needs to be a postprocessing shader in the pipeline.

I suggested this to Ryphecha in IRC a week or so ago. Don’t know if anything will come of it, but it’d certainly be really cool to have.

Well, I knew about the distortion thing, but I thought it only came into play when you were trying to wrap a first-person view around the user’s entire FOV. I assumed it would work okay to put a smallish VB screen in the center of the FOV (like it is on a real VB) and live with a tiny bit of pincushion at the corners. I guess it depends on the user, though.

I hope the Rift support in Mednafen (if it ever happens) takes the form of a general, user-defined, fragment shader system. That would have so many uses besides aspheric lens correction!

You really shouldn’t volunteer others, morintari, especially using the wrong user name (it should be “TheForce81”). We’re perfectly capable of contacting those in need of our services.

@DaG: I would offer to help, but I really don’t like dealing with all the customs stuff, and the shipping would be much higher for you. But, if you definitely can’t get anyone nearer to you to do it, send me a PM.

I don’t have a Rift, so I don’t know why it requires a special version of the emulator. You could try running mednafen itself and messing with the graphics configuration until you get something acceptable. An advantage to this option is the updated emulator (which, for example, supports Hyper Fighting).

If you can’t get it working, post your specific problems and I’ll try to help (I have some experience getting it to work with other stereoscopic devices).

Excellent! Can’t wait to hear what you find out/decide.

Regarding the stiffener: would it be better to try to match the thickness of the original cable as close as possible and just recycle the existing stiffeners? Maybe they would send you samples of the material (they must have off-cuts of some kind) that you could test in the sockets. I think I would rather just go with the thickest copper, for durability, even if I have to jury-rig the connection to the VB.

HorvatM wrote:

Maybe there should be an option to use a file that contains a list of files to process and how to name the resulting arrays? This way, it would also be possible to specify different settings for each image and different output filenames.

That is an excellent idea which I fully support. It sounds pretty easy to implement, too; just pass each line of the file through your command-line argument parser.

BTW, what does your program do when the files you give it generate more than 2048 chars?

jrronimo wrote:
I think you can probably use a NES/SNES USB conversion kit from RetroUSB. I bought a couple to try out but haven’t had the time to deal with it lately. They used to sell a VB-specific kit.

He seems to specifically want to connect the VB pad to other game consoles, so this wouldn’t really work. Although, with suitable firmware, that would be compatible with the PS3/4 and Xbox/360/One, I guess. I hope you get back to that project, someday; it would be nice to know if it supports the extra buttons on the VB pad. I wonder why they got rid of the VB one…

If you haven’t already, you’ll probably want to check out “gritmake.htm” from the grit website (and maybe put it and the rest of the docs near grit itself in the downloads section).

After that, the first thing I would do is make a global “vbde.grit” containing the relevant grit options, to make it easier to write the makefile/batchfile.

Next, you should add a rule to the makefile to assemble “.s” files into “.o” files. It should be as simple as passing the file to the “gcc” command and letting it call the assembler appropriately. I don’t think any specific options are required, but problems can be dealt with as they appear.

Once that rule is ready, you just have to tell make to find the image files, run grit on them to produce the “.s” and “.h” files, assemble the .s files into .o files with the aforesaid rule, then link said objects with the game code into the final executable ROM as usual.

Regarding changes to VBDE: In light of blitter’s reported problems with gcc 4.x, are there any plans to try to incorporate 2.95.whatever as an alternative? Although, I suppose two versions of the library would have to be maintained (or a bunch of “#ifdefs” inserted), among other things, for this to work, to say nothing of how one would switch between the two…

Anyway, let me know if I can be of further help.

HorvatM wrote:

RunnerPack wrote:

2) User is required to specify all filenames, without extensions

This makes it harder to use in a makefile.

What’s your proposed alternative?

Well, being the programmer, I would say that’s really your decision, but here’s what I know:

Make’s job is to make an output file for each input file – whenever the input file is newer or the output file doesn’t exist – using a set of rules. When a rule is executed by make, it will insert the name of the input and output files into the rule’s command-line(s). You can tell make to provide the name without the extension, but it would be nice if it wasn’t necessary.

This is really the only problem, since your goal of making one charset out of a series of images doesn’t really mesh with make’s idea of calling a tool once for each input file, anyway. I’ll write more about this in the gritVB thread…

3) Only C or raw binary output

Right. What does it need? A label and a list of .dbs?

Yes, the assembly file needs a label and the actual data directives, but you also need a header with the C declaration. Note: while gcc 2.95 does use .db, .dw, and .dd, version 4.x uses .byte, .int, and .word, respectively. I guess these guys never heard the one about not fixing what isn’t broken 😛

Here’s a before and after example:

The existing C header:

const u16 maptest[] = {
0x0000, ...

The desired ASM code:

    .global maptest

maptest:
    .dw 0x0000, ...

Or, for GCC 4.x:

    .global maptest

maptest:
    .int 0x0000, ...

Now, to get the C compiler to see the label, it has to be declared “external” like so:

    extern const u16 maptest[];

(Not sure about the const part, actually).

Another thing I noticed when I tried VBIMGC is that your headers don’t have “guards” around them to prevent multiple declarations, and such. You might want to do something like:

#ifndef _MAPTEST_H_
#define _MAPTEST_H_

const u16 maptest[] = {
0x0000, ...
}

#endif

Although I haven’t yet had need to try it, from the docs it seems to have a few limitations. While none of these is a “deal-breaker”, they can make it a bit harder to use.

1) Limited to Windows BMP files for input

You might want to check out FreeImage. It’s cross-platform, very easy to use, and supports tons of input formats! It even has handy auxiliary functions; e.g. to reduce colors or convert an image to greyscale.

2) User is required to specify all filenames, without extensions

This makes it harder to use in a makefile.

3) Only C or raw binary output

C takes longer to parse, and binary requires an asm “stub” to link. GNU assembly output shouldn’t be too hard to add, right?

4) Not open-source

😉

Try adding: “-mLs”. If that doesn’t work, my only theory is that the “-o” switch is messing something up. I don’t think it’s necessary, anyway. It’s just a matter of finding out how it generates filenames (probably just changes the extension) and getting make to do it the same way.

If that doesn’t work, maybe you could split it into two calls; one generating maps and one generating chars (kind of inefficient, but probably not too bad on modern hardware).

Another idea that might work is adding the “-gS” switch to generate shared chars from all the images, and “-O” to specify the filename.

When you get this working, could you share the changes for those of us who already have it installed? (Or will there be a good reason to reinstall the whole thing?)

Welcome to the forum, HPL!

As thunderstruck mentioned, it’s a fairly simple serial protocol to handle. Are you familiar with any type of microcontroller? Just about any device with enough I/O to handle both the VB pad (2 out + 1 in) and target system would make short work of this. The Jaguar might be a little tough; IIRC, it’s a switch matrix.

You probably already have this link, but for the benefit of other readers: http://raphnet.net/electronique/electronique_en.php

Keep us posted on your progress!

Instead of printing them at home, one could have replacement cables made professionally (but you have to buy 50 at a time…):

http://imall.iteadstudio.com/open-pcb/pcb-prototyping/2layer-flexible-printed-circuits-fpc-10cm-x-10cm-max.html

Five cables fit on each of the ten “boards”. If you max them out with the 0.3 mm copper and ENIG (I don’t think black substrate is a worthwhile expense ;-)), they come to US$92 + shipping (which is a quite reasonable ~US$1.84 per). They’re double-sided, so they should be easier to solder and probably more durable (I also had the idea to add vias in the traces so the two sides can share the work; kinda like stranded wire with two strands ;-)). They don’t include a solder mask (can you even use solder mask on FPCs?) so, even with the gold plating, it would probably be a good idea to use some kind of compliant coating (packing tape? paint? PlastiDip?) to protect them.

I made an Eagle layout for the cable based on photos (and careful measurements) of the original (it’s not the one I made for you before, DogP). It’s not 100% exact like DogP’s, but I think it’s accurate enough to use as a replacement (although at least one other pair of eyes checking them before ordering would probably be a good idea) or maybe DogP’s version could be converted into something they’d accept.

I’d be down for at least four cables if anyone (bigmak? UncleTusker? DogP?) wants to organize a group-buy. I could do it myself, but I have neither the experience nor the infrastructure for a project like this. I’ve never used a PCB fabrication service, and I know next to nothing about the financial side of taking pre-orders. I thought about doing a KickStarter, but I don’t know if I could reach that many owners of VBs in need of such a thing (especially considering DogP’s recent “repairing spree” ;-))

Of course, the cables alone wouldn’t do most people much good (not speaking of DogP or SirGuntz here, obviously ;-)). They’d likely want someone to install them in their VB, too. It’s not likely to be much (if any) harder (and possibly even easier) than doing a standard cable repair, so I would be both willing and able to do this “pro bono” if sent the cables, displays (or whole VB), and return shipping costs. Conceivably, and with the right tools, one could remove the LIF sockets (as has been mentioned) and solder the cable directly in its place. This would also eliminate the “dimpling” problem. I haven’t tried this, but I had the idea of possibly removing only the top of the connector housing and soldering the cable to the contacts (probably wouldn’t work, but it’s an idea ;-)).

Not a huge fan of FPS games, but I agree that it would be great to finally see one of those ports. I have no doubt DogP can make it happen, too (although I would understand if he didn’t get enough free-time to finish).

Regarding thunderstruck’s question about “tool” entries: I’ve never thought it very fair to put them in with the games/demos. They should be judged on their own merits as compared with other development tools. Maybe there could be a separate category for tools, with the prize being a FlashBoy and/or a link cable (or the parts to make one). This would help the winner use his/her tool(s) to make more VB games (especially link-enabled ones)!

Since it doesn’t have to be played from VHS, why not go with DVDs and just use an inkjet/Kinko’s to print DVD case inserts? Although, there are probably more people with functioning VCRs than there are with Action Max consoles, so I guess it’s kinda academic at this point…

From the description on Wikipedia, it doesn’t sound too difficult to reproduce the functionality of the machine with a cheap microcontroller and a couple of phototransistors. With a slightly more powerful MCU and some kind of storage, you could even generate the video signal itself and make it completely self-contained (maybe enclosed in an old Zapper or other cheap light-gun).

It’s really hard to choose because there are so many greats, but I’m going to go with Lost Vikings II, followed closely by Lost Vikings. Puzzle-platforming at its finest!

I’d never even heard of S.O.S., but I think I’ll have to try it one of these days.

Just looks like a generic sans to me. Just try fonts like Arial, Tahoma, Helvetica, etc. (depending on your system) until you find one that’s suitable.

I’ll just leave this here:

Flattr this (VB logo font)!

😉

It’s more of a test, than anything, but if you feel like clicking it, I wouldn’t mind! 😀

(@KR155E: If you consider it spam, feel free to delete/edit.)

Putting something too heavy on it might crush the foam. Put just enough weight on it to keep it lying flat, and leave it for a week or so and it should be fine.

If you need it right now, you could probably use a low-temperature clothes iron on it, but it’s probably overkill.

BTW, morintari’s right about there being a very specific way to remove it from and replace it on the visor holder. Consult page 18 of the VB manual.

Also, the fact that you’re wearing a red shirt in that photo isn’t irony 😛 😉 It probably falls under the heading “coincidence”.