All Posts (blitter)




#1
Re: Fixing GCCVB 4.x Issues
Posted on: 4/3 9:15
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
v810 support hasn't been in GCC mainline since version 2.x IIRC. I got the 4.4.2 patches from dasi; perhaps he wrote them originally but I honestly have no idea. I think the v810 patches are largely based on existing support for the v850, which is similar.

The 4.8 patches are part of "devkitV810," which as far as I can tell is just a fancy name for GCC + some auxiliary tools. It's supposedly being worked on by dasi and/or Guy Perfect, but I haven't seen or heard anything from either of them regarding that project in a long time. I think they might be floating around out there on a Git server somewhere...
Top

Topic | Forum


#2
Re: Fixing GCCVB 4.x Issues
Posted on: 4/2 6:58
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
See also this post: http://www.planetvb.com/modules/newbb ... t_id=30370#forumpost30370
Top

Topic | Forum


#3
Re: Fixing GCCVB 4.x Issues
Posted on: 4/2 6:55
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
Off the top of my head:

1) Biggest problem so far is that GCCVB 4.x will sometimes generate relative jumps that are offset by some power of two ahead of where their proper destination should be. This becomes a huge problem when these jumps are executed repeatedly, as eventually the PC will wrap and wind up in video memory or elsewhere. I wrote a tool that operates on the final .elf file and attempts to correct these bogus jumps, but it's more of a bandaid than a solution. http://www.planetvb.com/modules/newbb ... t_id=31203#forumpost31203

2) Optimization is lousy. It's better in 4.x but still carries the baggage from the 2.x patches upon which the v810 support is based. So some operations such as 32-bit loads and subroutine calls are hardcoded as a certain sequence of assembly instructions when the compiler might be able to be clever about it (for example, doing several consecutive loads of RAM addresses-- movhi hi(0x05000000),rN should only need to be done once)

3) Found a bug recently in the version of gas that ships with GCCVB 4.x where sometimes a bne instruction-- written in the assembly source *as a bne instruction*-- will assemble to a be and a jr instruction. There is no reason whatsoever that I can think of why this should happen.

4) The frame pointer is assigned to register r29 I think, which is normally used by the bitstring instructions. I've never seen documentation for the v810 that says where the frame pointer should go, but since the frame pointer is irrelevant for VB development, I just pass -fomit-frame-pointer when compiling. I mention it here for completeness.
Top

Topic | Forum


#4
Re: gccVB 4 and PC-relative calls/jumps
Posted on: 1/27 4:03
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
D'oh, I meant MinGW. Whenever I use the GCC suite in Windows I'm conditioned to assume it's Cygwin.

And yeah, 32-bit multi-char literals have been a staple of Mac development since the dawn of time. Tells you where I wrote it. ;)
Top

Topic | Forum


#5
Re: gccVB 4 and PC-relative calls/jumps
Posted on: 1/25 10:17
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
I know that linker order can affect the visibility of symbols across object files, but I've never before seen a case where the order can directly affect the addresses generated for visible symbols. I fear something more sinister is at play here. At any rate, switching the linker order can appear to fix some instances of this problem, but I've run into this when building assembly-based projects too, where multiple symbols may be defined within a single translation unit, and a deliberate order determines where the assembly is placed in the binary. Changing the linker order here means changing the layout of the binary, which in my case could break execution since pieces of my code expect functions to live in certain areas of ROM.

That said, and since I have not the desire to dig into GCC to find the root cause of this (I'd rather be developing for the VB itself), I decided to hack my way around this problem by writing a small tool that patches ELF files with bad jumps. As an example:


mbp
:jmptool blitter$ ./jmptool ../../isrtest/output/IsrTest.elf IsrTest_fixed.elf
Total ELF sections
12
Last ELF section address is 0x0707FDE0
size is 0x00000220last byte 1 is 0x07080000
disp26 mask is 0x0007FFFF
disp26 shift is 7
Found a bad jump at 0x0700003A
jr    0x07400022 [(int26)0x003FFFE8]
    
Correcting to 0x07000022 [(int26)0x03FFFFE8]
Found a bad jump at 0x070000ACjr    0x07400022 [(int26)0x003FFF76]
    
Correcting to 0x07000022 [(int26)0x03FFFF76]
Found a bad jump at 0x07003472jal    0x07403404 [(int26)0x003FFF92]
    
Correcting to 0x07003404 [(int26)0x03FFFF92]
mbp:jmptool blitter$

Keen eyes may notice that the bad jumps are 8 bits away from their corrected versions-- the bad jumps are coded as 18-bit displacements when they should be 26-bit. Maybe this can help somebody (dasi? Guy Perfect?) but I've given up solving this problem since GCC is quite the complicated beast and this tool works well enough when stuck between ld and objcopy. :)

I built this tool for OS X and also in Cygwin on my Windows 8.1 machine, but the source is included too just in case. Hope this helps someone else out there.

Attach file:


zip jmptool.zip Size: 46.40 KB; Hits: 9
Top

Topic | Forum


#6
Re: Game idea & mockup thread
Posted on: 1/13 4:55
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
+1 for Tempest/T3K. I wonder if Jeff Minter would consider a VB side project...
Top

Topic | Forum


#7
Re: Which way do your VB legs go?
Posted on: 2014/12/31 18:06
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
I believe Nintendo's sanctioned way according to the manual is with the legs pointing away from you, so that the controller is behind the system and you look like you're "hugging" the VB while in use. I play this way and it's very comfortable. Holding the controller in front of me with the legs pointing towards my body makes me feel like I have T-rex arms and gets tiresome after a while.
Top

Topic | Forum


#8
Re: Super Mario Bros, Virtual Boy
Posted on: 2014/10/22 7:42
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
Probably fake. At 0:53 you can see the left half of the Goomba's sprites disappear as it moves offscreen-- This happens naturally on the NES but is a rendering artifact very unlikely to survive in an engine rewrite, which a port to the VB would require.
Top

Topic | Forum


#9
Re: gccVB optimization options and assembly code
Posted on: 2014/10/19 22:57
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
Quote:

cr1901 wrote:
I HATE to be the one to bring this up, but perhaps it's time that some of us take a look at GCC internals to see what's going wrong? I'm taking a bit of a break from VB coding (call it "guilt that I'm letting my other code rot") anyway, and I probably could take a look if I had some code that is known to generate bad jumps.


If somebody wanted to take a look at the GCC 4 patches, I know of a few spots that look suspicious:

- The "return "movhi hi(%1),%.,%0\n\tmovea lo(%1),%0,%0";" in output_move_single, line 2255 or thereabouts in gcc-4.4.2-vb.patch. 32-bit loads are always encoded this way, even if the high word doesn't change between consecutive loads. This line also shows up elsewhere in that function for handling other such loads.

- "sprintf (buff, "mov r31,r10\n\tmovhi hi(%s), r0, r11\n\tmovea lo(%s), r11, r11\n\tjal .+4\n\tadd 4, r31\n\tjmp r11", name, name);" in construct_save_jarl, line 3797 or so also in gcc-4.4.2-vb.patch. While this isn't bogus code-- this code works-- I don't think we need to be doing long jumps in this way since jal takes up to a 26-bit displacement, which if my math is correct means up to an almost 64MByte jump in either direction-- well more than we need on the VB.

- Prologue and epilogue function generation. Building with -O3 or -Os in gccVB 4.8 (part of dasi's devkitV810 WIP) is totally broken here, generating unnecessary epilogue functions that clobber lp, leading to subroutines that in my testing return to address 0 (the first framebuffer), causing a crash. This can also happen occasionally in gccVB 4.4.2, though I haven't been able to create a minimal example yet.

- Lines 837-849 in binutils-2.20-vb.patch, beginning with "HOWTO (R_V810_9_PCREL,": This might be what's causing the bad jump logic, creating relative jump addresses that are multiples of 0x400000 from what they should be, eventually wrapping around to the beginning of the address space and crashing. Not sure why the entry for 9-bit branches uses 26 for bitsize and type 'long.' I posted some code that exhibits this bug a while ago-- http://www.planetvb.com/modules/newbb ... t_id=26069#forumpost26069 -- would be happy if somebody took a good hard look at what's going on. (EDIT: It might just be a linker order problem, but would be nice to know for sure.)

:)
Top

Topic | Forum


#10
Re: gccVB optimization options and assembly code
Posted on: 2014/10/19 5:54
Nintendoid!
Joined 2007/12/14
119 Posts
CoderLong Time User (7 Years) App Coder
Some of it yes, some of it no. I've thought of this-- in fact I wrote a tool that post-processes my ROM to poke addresses directly into the assembly, saving runtime lookups-- but any processing that adds or removes instructions would be non-trivial since that would throw any other instructions that deal with addresses completely out of whack.
Top

Topic | Forum




You are not logged in.
Lost Password?
Register Resend Activation