I’m not sure if you still have the drive, but… try ddrescue again. ddrescue takes TIME for it to do it’s job, but it has saved my rear-end before. I have a drive that “died” 3 years ago and can still extract data from the NTFS file system originally on it.

PhotoRec is also a great program if you have a shell script to organize by file extension. It claims to be able to detect fragmented files as well (I believe it, but have no way to test).

Actually, that cleared up A LOT of things. In an ideal world, the mirrors would likely vibrate at a constant speed and change direction instantaneously. But alas, we do not live in such an ideal world.

When viewed from the top down, the mirrors probably do follow a sinusoidal pattern. A single column of pixels doesn’t actually have a well-defined width because the mirrors do not reflect light at discrete intervals.

A follow up question: I remember reading that the VB will emit 4 or so LEDs out of the 224 at a time. Since the mirrors are always in motion, doesn’t this mean that even the angle of incidence for a single column of a frame will vary as each consecutive pack of 4 LEDs is lit?

I suppose it’s not noticable in practice (I mean, a straight vertical line looks pretty straight on the VB to me :P)… I’m just wondering.

Unfortunately, compiling all the object files in a single command line doesn’t solve the problem either- the minute that GCC defers to the linker is when the problems begin with the binary being too large (a SINGLE piece of data is placed at offset 0x0, and the rest begins at 0x7000000), and the file no longer being a power of two.

This leads me to believe the linker script is wrong, or I’m not using the correct command line switches :P. FWIW, I’m using RunnerPack’s MinGW version that uses GCC 4.4, which may not be well tested.

As an alternative for the time being, I’ll probably just go ahead and use the include approach… include guards between headers and the fact that function definitions are extern by default should permit me to compile successfully anyway.

DanB wrote:
Hi cr1901, welcome to the forums 🙂
Do you own that debugger? It looks like one of KR155E’s pics from this site, but from a different angle? 😕

Not in the least XD. I just chose a default forum avatar to give the impression that I’m going to attempt to program the Virtual Boy :P.

I’d love to own one one day, but I don’t think it’ll ever happen.

I can verify that I do NOT have an issue building binaries with RunnerPack’s MinGW binaries (you are a life saver, btw). They can build the first of the 6 simple C demos per the development wiki page just fine.

Were the issues with the other MinGW builds for GCCVB ever resolved? I’m thrilled that the GCC version is no longer limited to 2.95. Knowing how slow MSYS builds are, I can only imagine your pain (I didn’t even know native MinGW GCC builds were possible, actually).

I happen to have a Performance adapter as well. It came with the system when I got it for Christmas. From what I can gather, AC adapters for the VB are rather uncommon.

Come to think of it, I don’t think I’ve EVER used the VB with batteries. Does it drain them as fast as the rumors say?

Oh, and hi everyone :P, decided to join the fun!

Attachments:

1. 

   photo265.jpg
   

2. 

   photo267.jpg