I’ve decided that since I have absolutely no experience whatsoever playing RPGs, that I am not a good candidate of programming one, so instead, I’m going to work on a fighting game (while I also have no experience playing a fighting game, I’d figure it’d be a lot easier programming one than an RPG.) So here’s my latest brainchild: Insect Combat. Right now, it’s just a warning screen and a title screen. The only two characters I’ve thought of so far are Gi-Ant and Behe-Moth. Any other punny names you guys can think of would also be appreciated.

Attachments:

1. ic.vb

Hey, VirtualChris? Can you post version history for Insect Combat & links for each one?

Thanks in advance.

That would be a huge undertaking, since I had worked on the game for 6 years and there are probably literally hundreds of versions. I guess I’m not like most people, I like to share even slight modifications to programs.

[bodkinz]

Hope this is OK to post here… 122 versions of Insect Combat/Insecticide.

No version history though…

Hope it helps a little…

• This reply was modified 8 years, 10 months ago by bodkinz.

Attachments:

1. ic.7z

Wow! Thanks bodkinz!

@VirtualChris: I have an idea for a little easter egg for the game. On the character select screen, if you use the other D-Pad and press one of the directions, you can tilt the magnifying glass the other way and “burn” the insect (it dissolves into pixels).

I dont know. this game looks like it was made in MS Paint.

Pong had two lines and a square and it started a revolution.

I got the test cartridge and I have found a few problems. 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. I went through the code and I deleted all the //comments that were actual code. It used to be 3,500 lines. Now it’s 2,718, so I have slimmed it by a large margin. And this is something that I can’t experiment with on emulation. It must be done with my FlashBoy. And it requires load after load of attempt to fix it so everything resets to 0, and after failing a few times (and with my knee hurting, I hurt it a week ago somehow and it still hurts. I and the VB have to be on the floor for fear the cat may knock over my VB and break it.) I thought if some C & VB coding guru would take a look at my code and reset everything to 0, that it would save me a lot of time since I don’t know what I’m doing here. The code is here, and the H files are on the Insecticide website.

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

‘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.

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?

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.

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/downloads/tools/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

I meant I don’t have the crt0.o file. Sorry about the confusion.

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.

I don’t know what v810 is. There doesn’t seem to be a v810.exe file anywhere. Perhaps that’s why I got that message, because I don’t have it?

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’

I figured everything out, I got everything to compile, but it didn’t help. Perhaps I should just cancel the game.

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.

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.

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. 🙂