You are not logged in.
Lost Password?

All Posts (jorgeche)




#1
Re: Insect Combat
Posted on: Yesterday 21:44
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
I did a quick, and not very scientific test, and 0x2000 should be enough to prevent the access to the work RAM before it stabilizes. Besides that, I wasn't able to reproduce a similar problem with our game by turning on and off the VB very quickly. So, my conclusion is that your problem is either related to the usage of local non-initialized variables or some other bug in your program. Sorry if that is not helpful enough.
Top

Topic | Forum


#2
Re: Insect Combat
Posted on: Yesterday 5:14
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
Turns out it didn't work after all. Should I try increasing it to 4,000?


I will have to make some tests to try to infer how big a value is needed to achieve the 200usec wait. In the meantime, you could give 0x4000 a go (or even 0x10000)

BTW: How quickly are you turning the VB on and off? I've noticed that our game doesn't work if I turn on and off the VR very fast. Although, I haven't checked if the problem happens with commercial games, will check it tomorrow.
Top

Topic | Forum


#3
Re: Insect Combat
Posted on: 3/22 12:50
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
I increased the 2000 number to 3000. At first I thought it was broken because it didn't start, but it eventually started up and works great! I want to thank you tremendously for your help.


You're welcome, I'm glad it finally worked. :)
Top

Topic | Forum


#4
Re: Insect Combat
Posted on: 3/22 4:50
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
OK, I figured out how to put your code into the file. I get the following message when compiling my code with gccvb:

crt0(.text+0x2): undefined reference to '_bss_start'
crt0(.text+0x6): undefined reference to '_bss_start'
crt0(.text+0xa): undefined reference to '_bss_end'
crt0(.text+0xe): undefined reference to '_bss_end'


You already have the code to clean the bss section. Roll back your crt0.s to its original form.

I suspect that the problem is caused by not waiting for the work RAM to stabilize before cleaning it, so, after rolling back to the original crt0.s, add this to it just after "_start":

/* wait for WRAM */
movea 0x2000, r0, r6
wait_for_wram_loop:
add -1, r6
bnz wait_for_wram_loop

Recompile it with "as" and try again. If the problem persist, try increasing the 0x2000 value an give it a couple more tries.
Top

Topic | Forum


#5
Re: Insect Combat
Posted on: 3/22 3:14
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
I meant I don't have the crt0.o file. Sorry about the confusion.


If you're using this version of GCCVB
(http://www.planetvb.com/content/downloads/tools/gccVB%202.95%20(Precompiled%20NVC%20Version).zip)
then you have crt0.o. It is located in v810/lib/. There are even two versions of it: crt0.o and crt0.o.bak.
Top

Topic | Forum


#6
Re: Insect Combat
Posted on: 3/21 4:03
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
I think I might have found a folder for the one I'm using, but it doesn't have that crt0.s file, but it does have a crt0.o file in it. Apparently I'm using gccVB version 2.95.


I guess that you have the version published in

http://www.planetvb.com/modules/tech/?sec=tools&pid=gccvb

If so, then you already have a ctr0.o file that is cleaning up the bss section and the stack's space provided that it was compiled from crt0.s and not from crt0_old.s (didn't bother checking its contents).

You can get crt0.s from GCCVB 2.95's source:

http://www.planetvb.com/content/downl ... ols/vb_v810_gcc_03.tar.gz

You already have the "as" command, so you can use it instead of "v810-as" to compile crt0.s, just to make sure that the cleaning of WRAM is in the crt0.o file that you're using (don't forget to make a backup of the one that is currently working for you before replacing it!).

Just for completion, this is the code that does the cleaning:

/* clear .bss section and unintialized RAM */
movhi 0x0501,r0,r4
jr loop_start1
loop_top1:
st.h r0,0[r5]
add 2,r5
loop_start1:
cmp r4,r5
blt loop_top1

If the problem persists, then it means that you already had the cleaning up in place. So, the issue could be related to how soon you're accessing the work RAM in your program. I will refer you to the official documentation, page 4-5-1. I'm completely ignorant regarding the relation between assembly operations and the amount of time the CPU takes to execute them, but the doc says that you need to wait 200usec before accessing work RAM, and the crt0.s file that you have access it almost immediately to clean it. So, it could be the case that the weird behavior is caused by not waiting for the work RAM to stabilize before trying to write the 0s of the cleaning. You can try the following and check if it solves the problem: add the following code to crt0.s just below "_start:" and recompile it:


/* wait for WRAM */
movea 0x2000, r0, r6
wait_for_wram_loop:
add -1, r6
bnz wait_for_wram_loop

The 0x2000 value is just arbitrary and a vague guess on my part so, if it doesn't work, try to increase it and repeat the test.

jorgeche
Top

Topic | Forum


#7
Re: Insect Combat
Posted on: 3/20 2:29
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
'v810-as' is not recognized as an internal or external command, operable program or batch file.

I put a batch file in a whole bunch of different folders and they all came up with this message. I'm afraid you're going to have to dumb it down for me. A lot.


What compiler and version of it are you using?
Top

Topic | Forum


#8
Re: Insect Combat
Posted on: 3/19 14:53
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Quote:

VirtualChris schrieb:
... The game itself works fine. It's the part where you turn it off and then turn it back on that is troubling me. You'd think when you turned off the Virtual Boy, everything in the code would reset to 0. But this is not the case for some reason. The trouble I'm having is making stuff reset to 0 by hand.


You cannot make that assumption. It is always a best practice to initialize all variables to a suitable value before using their data.

One way to make sure that all global / static non-initialized variables are set to zero when the program starts is to clear the program's bss section (they are allocated in it) in the crt0.s file before the call to the main function is done.

To clear the bss section, you need something like the following code. Take into account that it depends on how the program's sections are defined in the vb.ld script that you're using (that is, there needs to be something similar to __bss_start and __bss_end in it):

/* clear .bss section */
movhi hi(__bss_start), r0, r6
movea lo(__bss_start), r6, r6
movhi hi(__bss_end), r0, r7
movea lo(__bss_end), r7, r7
jr end_init_bss
top_init_bss:
st.h r0, 0[r6]
add 1, r6
end_init_bss:
cmp r7, r6
blt top_init_bss

You will have to recompile the crt0.s file into crt0.o and replace the one most likely present in your compiler's folders (were you should find its source too, the crt0.s file). To recompile it execute the following:

v810-as -o crt0.o crt0.s

For local variables, you're out of luck since they are allocated in the stack and it gets "dirty" during the program's execution. You can clear all work RAM, and hence the stack, in the crt0.s file too. That could make a difference, in your case, when you power off and on the VB since it is already working for you on a cold power up, but it would be kind of hack-ish and still prone to very hard to track down bugs because, eventually, the non initialized local variables will be used and produce undefined behavior. So, you should still properly initialize all the variables before using them.

jorgeche
Top

Topic | Forum


#9
Re: A newer GCC compiler.
Posted on: 2016/7/18 1:47
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
And thanks to ElmerPCFX, a couple of BIG issues with the VBJaEngine's architecture were found and fixed.

As he said, and besides a couple of small fixes that are pending on my side, the engine and the demo run properly with GCC's latest version, and they compile way faster too!

It was a great collaboration that I hope will help both communities. :)

jorgeche
Top

Topic | Forum


#10
Re: Perfect Timing
Posted on: 2016/7/1 21:41
Nintendoid!
Joined 2006/3/15
Ecuador
213 Posts
PVBCC 3rdCoderLong Time User (11 Years)
Hey Guy:

This sound amazing, if I understand it correctly:
Quote:


• The entire project will be open-source. The core functionality of the emulator (no bells or whistles) will be set up as a simple library that can be incorporated into any existing C-compatible application. Introducing Virtual Boy emulation capabilities into other projects will be very simple to pull off.


I'm starting to think about a level editor for the VBJaEngine, and having emulator capabilities in it could allow us to avoid the need to have to maintain in sync two versions of the engine. Do you think that it will be feasible to get your core emulator to work inside a custom Eclipse plugin (or any customizable IDE at all)?

Regards,
jorgeche
Top

Topic | Forum