This is upsetting to me as the current game I’m working on does not fit in its entirety on one VB cartridge, and I was hoping an evolution of the VBSD tech could map more Flash memory into the 0x07xxxxxx space and beyond, allowing for larger games. I left a comment on his page and hope Vaughanabe13 takes it to heart. Fingers crossed.

I can’t believe I haven’t responded to this yet… Absolutely put me down for at least two– one VB<->VB and one raw cable for my own projects. My own homemade cable looks shameful compared to this. Very pro. 🙂

Finding a project that exhibits this bug is kind of hit-or-miss, and I don’t want to post the code of what I showed earlier since it’s my contest entry, but I was lucky enough to find the bug in a test harness I’ve developed over the past couple weeks.

Attached is a zip file containing a work in progress of my game’s music player, source included. When compiled with GCC 4.4.2 and -O3, at 0x07000392 the call to initISR is translated to the address 0x07400310 instead of the correct 0x07000310. Since initISR is only called once, this bug doesn’t cause a crash in this case, but if this was a function called multiple times there would almost certainly be a crash.

Hopefully this helps any of you trying to track this down (*waves at dasi*) 😉

Attachments:

1. musictest.zip

RunnerPack wrote:

@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?

1) One patch defines ep as r30, so you can use it in inline asm. (See http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=13493#forumpost13493) Another patch redefines the frame pointer to be r25 instead of r29– this allows the bitstring instructions to operate correctly. The last of my patches redefines the v810 reloc_howto_structs to what I think they’re supposed to be, referencing elf32-v850.c from ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-release-6/src/external/gpl3/gdb/dist/bfd/elf32-v850.c (The last of these three patches I’m not sure makes a difference– I can build my smaller projects fine and the jal bug still exists in my larger project)

2) You’re not the only one who questions me sometimes 😉 I’m inclined to think not, since what sounds like the same issue with jal was reported by M.K. some time ago: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=10832#forumpost10832 Regardless of what causes it, I just want it fixed in GCC4! 🙂

Was about to ask why you’re using M.K.’s patches instead of my gccvb4 package with additional fixes, but then I went to the thread where I linked to them and… the links are dead. Oops. 😛

So… I took your changes and integrated them into my gccvb4 build package. Also modified the make script so that the GNU packages are downloaded with curl. Keeps the attachment size down and saves folks from having it all in one lump, in case they just want the patches.

I can build this successfully on my Mac OS X setup, but couldn’t get it to build in Cygwin or MinGW. I’ve been able to in the past, so it’s possible my Windows environment is busted, but maybe somebody else will have better luck.

RunnerPack wrote:
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!

That’s what I asked her for. 😉

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.

Whelp, tried my hand at fixing up that HOWTO macro in binutils, and after recompiling gccVB and building a fresh ROM…

…

… no change. 🙁

I’m scratching my head at this point, stumped. Back to the drawing board. For what it’s worth, I’ve attached a patch containing the changes I made.

Hi Mr. Anon, just have one question: what Hz are the sound effects sampled at?

Just loaded this onto my FlashBoy and wow, this is fantastic!

The sound effects in particular are very impressive! Aside from the occasional pop and hum, the audio is very clear. What are the SFX sampled at? 11Khz?

I kind of explained why I helped developed patches for GCC 4 in this post http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=13509#forumpost13509 but for me it came down to two major things: much better code optimization, and support of the .incbin directive for easily bundling data blobs into the ROM. Plus there’s the principle of the thing: it makes very little sense to continue supporting a 12-year-old compiler when its base code is still actively maintained and the v810 patches can be updated to support the latest version.

I did find some documentation on the reloc_howto_type structure and the HOWTO macro in this document: http://www.chameleon.synth.net/files/developer/pdf/gnu/bfd.pdf (page 40)

Does anybody know how to actually use the cartridge audio pins to mix audio into the VB’s final output? I’ve read somewhere that the voltages are not the same as a typical line-in (like on a stereo receiver), but does anyone know specifically what they are? Is the VB cartridge audio pinout electrically the same as in the SNES?

Hi Greg, that’s the linker script I started with before trimming it down to what I posted earlier. Using the version you have actually makes it worse, but it’s apparent to me that it’s not just the linker script that’s the problem.

I’m actually suspicious of the following from the binutils patch file:

 /* A PC relative 9 bit branch.  */
+  HOWTO (R_V810_9_PCREL,		/* Type.  */
+	 2,				/* Rightshift.  */
+	 2,				/* Size (0 = byte, 1 = short, 2 = long).  */
+	 26,				/* Bitsize.  */
+	 TRUE,				/* PC_relative.  */
+	 0,				/* Bitpos.  */
+	 complain_overflow_bitfield,	/* Complain_on_overflow.  */
+	 v810_elf_reloc,		/* Special_function.  */
+	 "R_V810_9_PCREL",		/* Name.  */
+	 FALSE,				/* Partial_inplace.  */
+	 0x00ffffff,			/* Src_mask.  */
+	 0x00ffffff,			/* Dst_mask.  */
+	 TRUE),				/* PCrel_offset.  */
+
+  /* A PC relative 22 bit branch.  */
+  HOWTO (R_V810_26_PCREL,		/* Type.  */
+	 2,				/* Rightshift.  */
+	 2,				/* Size (0 = byte, 1 = short, 2 = long).  */
+	 26,				/* Bitsize.  */
+	 TRUE,				/* PC_relative.  */
+	 7,				/* Bitpos.  */
+	 complain_overflow_signed,	/* Complain_on_overflow.  */
+	 v810_elf_reloc,		/* Special_function.  */
+	 "R_V810_26_PCREL",		/* Name.  */
+	 FALSE,				/* Partial_inplace.  */
+	 0x03ffffff,			/* Src_mask.  */
+	 0x03ffffff,			/* Dst_mask.  */
+	 TRUE),				/* PCrel_offset.  */

If one of the branches is 9-bit, why is Bitsize 26?
Likewise, why does the comment say “A PC relative 22 bit branch” when Type and Name are both R_V810_26_PCREL?

Yep, I spoke too soon. The new linker script I attached above certainly helps, but it does not solve the problem. Seeing bogus jal instructions again with destinations in the 0x08xxxxxx range. At this point I can’t think of anything I can do outside of digging into the linker code, so I’ll continue forward there.

Hmm, well this is a pleasant surprise…

At your suggestion I went to grab the vb.ld file to attach to this post, but figured I should first try making a minimal version of that too. What’s attached is the result of that: a minimal linker script that actually seems to fix the problem for the moment– at least, I don’t see any bogus jal statements.

Hopefully I can close the book on this bug, but I’ll keep my eyes open. 🙂

I’m not going to post the source to my project right now, but I’ll try to put together a minimal example with source code in the next few days.

More progress!

I think I’ve found a pattern to the addresses that do get generated. Basically, jal is jumping way too far ahead– in multiples of 0x400000– but sometimes still landing in a mirror of the ROM, where everything seemingly works fine. However, as the code in the mirrored ROM continues to get executed, and the logic returns to that same jal instruction, it points to an address yet another 0x400000 ahead. Eventually this takes the code path somewhere beyond the 0x07xxxxxx range of the ROM, causing a crash.

I’ve attached a ROM of a trimmed down version of my current WIP. Start it paused in Mednafen’s debugger, then look at the instruction at address 0x07001d5e, 0x07401d5e, 0x07801d5e, and so on.

Some more info for anyone other than me who may be looking at this:

Running ‘v810-objdump -t’ on the ELF file reveals that the symbol table is correct– in fact, the bogus address highlighted in the screenshot above is nowhere to be found in the symtable. I’m inclined to believe therefore that this might be a linker issue, though the linker script I’m using works fine in gccVB 2, so this is a weak theory.

Also, for what it’s worth, the difference between the bogus address and the one in the symbol table is 16766404 (FFD5C4) bytes– almost 16M.

Nice work! Good to see more folks putting their work out there for others to take advantage of and build upon.