I completely understand emulating something at higher speeds if possible. I also get that if there isn’t any doc on something like VIP timings it makes it rather difficult to emulate. It just would have saved me a ton of time since I don’t actually have a VB and was expecting better performance out of the hardware. Finding what pieces of my code are actually bottlenecking on the hardware is near impossible since I can’t test on hardware and they don’t appear to be bottlenecking on the emulator at all.

Anyway thanks for the replies and info. Appreciate it.

Just to add a little to what HorvatM said, the VIP basically runs on its own and can’t be manipulated by code. So for example i can’t ask the VIP to add 1+1 for me. What I can do is fill or manipulate all of the memory areas the VIP uses which consist of characters, bgmaps, objects, and worlds. So for example if my game has a static background I can create my bgmap and fill in the world information for it one time and the VIP will automatically render it to the screen each game frame without me having to create the background again or worry about writing each pixel of the image to the screen. As of yet, nobody has come up with a way to utilize the chars, bgmaps, and worlds for wireframe rendering (i doubt it could be done with any efficiency but i’ve been proven wrong many times before). And in case your wondering Red Alarm didn’t use them either for its wireframe (I checked). Red Alarm did use the VIP for things like the HUD and player information and the alerts that pop up. So if you want to do wireframe you have to write every pixel to the screen yourself and actually “short circut” the VIP by telling it not to render all the worlds so you have a little bit more time for your code to perform all the calculations it needs. While some may cringe when I say this the truth is the only way to squeeze out any decent performance is to code every critical function in assembly. Which is what my next release of the wireframe library will be close to accomplishing. My last performance test showed a 500% increase in performance using assembly over c. I have a few more functions to code in assembly (believe me writing a rendering pipeline in assembly is not the easiest thing to do) but most of them don’t run on every vertex and won’t boost performance all that much.

I too have a demo ready that I could submit today if I had to. Hopefully it will end up becoming a full blown game. I’ve been working on my wireframe library code mostly but was able to use it to get a game started. (My only hint at this point is it’s not a Star Wars game). My major set backs have been FPS. 20MHz gets used up real quick when doing graphics calculations using the CPU instead of the VIP. I’ve been shooting for 30FPS ish and even that has proven fairly difficult. I had to recode almost all my library functions in assembly and squeeze every ounce of performance I could think of. Of course after the compo deadline all the source will be open and everyone else can optimize it. Right now it runs great in mednafen but slower on actual hardware (still a large improvement over my first demos). I’m spending most of my time trying to find that balance between amount of graphics rendered and FPS. My library now performs simple versions of z-clipping and object clipping and my demo uses frame skipping to help with FPS.

As for the game, I just finished with a map layout concept for creating levels so in theory a level generator could be created to allow others to make levels even with no programming knowledge.

I’m planning on asking for the communities help to finish the game (providing anyone even wants it finished of course).

Thanks to HorvatM for finding a bug in my OBJ parser I fixed that little program and now 3D Wavefront OBJ files are correctly converted for use inside the library. So 3D artits can help contribute to games using this library as well.(Although most modern software will create relatively large objects causing FPS to drop.) I’ve actually created all of my game objects using nano (linux ver of notepad) and just hand typed the OBJ format. I think the biggest problem for most artists will be trying to create acceptable objects with the least amount of vertices/lines possible and still be willing to put their name to it.

Looking forward to all the submissions and learning from eveyone else’s hard work as well.

(programming == procrastination)?(“Yes”):(“No”);
Result: Yes

These two things are just constants with different names 🙂

Welcome, you’ll find a great community here. Glad to have you aboard. You’ll find a lot of VB Fanatics here. Personally I love the development community. I’ve learned more here in a year or so than I probably have my entire working career of over a decade.

If you havent read through the following forum thread it would be a good idea. A lot of good points are brought out about memory and how/where variables are stored and when.
Forum Thread
If you add

-Map,($Target).map

in your makefile v810-gcc.exe command parameters the compiler will generate a memory map of all of your allocated variables and where they are stored. It might give you an idea of which area of memory you’ve hit a limit on.
More than likely it’s the
Name Origin Length Attributes
wram 0x05000000 0x00010000 !r
section.
For example in my program the last entry for that area is 0x05005320 cam
so I know I’m getting close to half of the allowed memory usage which would be at 0x05008000.

It’s not a perferct science but it can give you an idea.

Same folder as the .c file you ran the compile against. It will only be there if the compile was successful.

Providing you left everything as default you’ll want to use the notepade++.exe editor found in the editors\npp.6.2.3.bin.minimalist folder within the vbde folder. Open you c code file and you’ll see the second button from the left of the screen under the file menu looks like a little Green arrow pointing down. That is the compile button. It calls the makefile found in vbde->libs folder. So if you want to make any modifications to the compile options edit the makefile and when you press the compile button in notpad++ it will use your changes.

Almost forgot, make a new folder in the vbde->projects folder for your project and put your code in there. You’ll also need to make a .vbh file. Just copy from one of the sample projects and edit the file. Give it the same name as your main c file with a .vbh extension. The compile process should build a .vb file with your main file name.

Good luck

Thanks I’ll check those out sometime. I did find the files by manually searching for the MFT records, finding the data runs for the files, and manually extracting the data. Unfortunately even after all of that I found that the data was still corrupted. I kinda figured it would be (ddrescue showed 36GB worth of bad data which was basically everything). I did try testdisk. It was unable to find anything when I ran it.

I’m not sure even two months will be enough time for me but it will definitely help.

[Greg Stevens]

Thanks for the suggestion but I’ve already looked into that one. It is one of the programs that uses headers and footers to find files. Wouldn’t work on a Quickbooks file.

I did find something called CnW that seems to do what I want but it’s not free and I’m not getting paid for this so that ain’t happening.

I’ve spent a lot of time looking for something that is free and have come up empty.

Within a few days though there should be something available if I can get my little program finished 🙂

• This reply was modified 10 years, 11 months ago by Greg Stevens.

Aww man. Looks like DogP and I are doing the same game 🙂

Hope everything works out morintari. Get well soon. I know a little bit about medication side effects so I hope the doctors get it straightened out soon.

Best wishes.

Sweet. Thanks. I’ll ckeck that out.

RunnerPack wrote:
Well, that’s essentially what I did, since the order of the .o files in the OFILES variable is derived from that of the .c files in the CFILES variable. COBJS consists of the filenames in CFILES with “.o” stuck on the end of each, and OFILES contains COBJS, verbatim.
Anyway, does using the right link order fix all of the known issues, or is gcc still doing other, unrelated weird stuff?

Ha, and apparently my understanding of make files was even less than I thought. I didn’t pick up on that. I should probably study the syntax at some point.

I have not seen any other anomalies but I don’t usually link multiple object files together either. I couldn’t find anything else in these test files.

[Greg Stevens]

Next, I changed it to put isr.c after the other files. This did produce a difference. I’ve attached the three ROMs and their disassembler listings for those more experienced with v810 assembly to look at 😉

Also, I find it much easier to look at the .ELF file before the objcopy command is used on it since it still has the symbols in it.

I just use v810-objdump -d musictest.elf > disassembly.txt
and the listing is much easier to interpret at a glance.

here is main and the incorrect function call which looks like __vbvectors_end+0x3f0311 since it went beyond the end of the linking area. I still don’t understand how it calculated a mirrored address correctly though.

07000374 <_main>:
 7000374:       5f 01           mov     lp, r10
 7000376:       00 ac ca 0f     jal     7001340 <__save_r31>
 700037a:       40 bd 00 02     movhi   512, r0, r10
 700037e:       4a a1 24 00     movea   36, r10, r10
 7000382:       6a c1 00 00     ld.b    0[r10],r11
 7000386:       6b b5 ff 00     andi    255, r11, r11
 700038a:       6b b1 01 00     ori     1, r11, r11
 700038e:       6a d1 00 00     st.b    r11, 0[r10]
 7000392:       3f ac 7e ff     jal     7400310 <__vbvectors_end+0x3f0311>
 7000396:       00 ac 32 01     jal     70004c8 <_initmusic>

and here is the exact same section of code after switching the isr.c.o and main.c.o in the v810-ld command

070002b8 <_main>:
 70002b8:       5f 01           mov     lp, r10
 70002ba:       00 ac 86 10     jal     7001340 <__save_r31>
 70002be:       40 bd 00 02     movhi   512, r0, r10
 70002c2:       4a a1 24 00     movea   36, r10, r10
 70002c6:       6a c1 00 00     ld.b    0[r10],r11
 70002ca:       6b b5 ff 00     andi    255, r11, r11
 70002ce:       6b b1 01 00     ori     1, r11, r11
 70002d2:       6a d1 00 00     st.b    r11, 0[r10]
 70002d6:       00 ac 6e 00     jal     7000344 <_initisr>
 70002da:       00 ac ee 01     jal     70004c8 <_initmusic>

as you can see _initISR now shows up with the correct address instead of the vbvectors+ address.

Also if my theory is correct I should be able to cause more issues by moving musicPlayer.c.o before main.c.o and here is the result of that test

070011f8 <_main>:
 70011f8:       5f 01           mov     lp, r10
 70011fa:       00 ac 46 01     jal     7001340 <__save_r31>
 70011fe:       40 bd 00 02     movhi   512, r0, r10
 7001202:       4a a1 24 00     movea   36, r10, r10
 7001206:       6a c1 00 00     ld.b    0[r10],r11
 700120a:       6b b5 ff 00     andi    255, r11, r11
 700120e:       6b b1 01 00     ori     1, r11, r11
 7001212:       6a d1 00 00     st.b    r11, 0[r10]
 7001216:       3f ac fa f0     jal     7400310 <__vbvectors_end+0x3f0311>
 700121a:       3f ac 7a f2     jal     7400494 <__vbvectors_end+0x3f0495>
 700121e:       c0 bc 00 07     movhi   1792, r0, r6
 7001222:       c6 a0 08 41     movea   16648, r6, r6
 7001226:       3f ac 4e f1     jal     7400374 <__vbvectors_end+0x3f0375>
 700122a:       00 8a           br      700122a <_main+0x32>

So initMusic and playMusic now show the same odd jal instructions since I linked them before their calls in main.

I got most of my information from the following link in case anybody is interested…
http://stackoverflow.com/questions/45135/linker-order-gcc

• This reply was modified 11 years, 1 month ago by Greg Stevens.
• This reply was modified 11 years, 1 month ago by Greg Stevens.
• This reply was modified 11 years, 1 month ago by Greg Stevens.
• This reply was modified 11 years, 1 month ago by Greg Stevens.

[Greg Stevens]

The makefile changes were pretty simple. I just changed the definition of the “CFILES” variable as follows:

I would actually be surpised if the CFILES order made a difference. I was actually referring to the $OFILES in the make file.
I believe the command needing changed is

$(ELFFILES): $(OFILES)
	$(LD) $(OFILES) $(LDFLAGS) -o $@

on my system the output of the command looks like this

/home/user/.wine/drive_c/vbde/gccvb/bin/v810-ld output/crt0.s.o  output/isr.c.o output/main.c.o output/musicPlayer.c.o output/noiseChannel.c.o output/notemap.c.o output/SCIFI.SNG.o -L/home/user/.wine/drive_c/vbde/gccvb/lib -L/home/user/.wine/drive_c/vbde/gccvb/lib/gcc/v810/4.4.2 -Tvb.ld -nodefaultlibs -lgcc -gc-sections -o output/MusicTest.elf

If I modified the above statement and placed main.c.o before isr.c.o that seemed to fix the error (on my system anyway).

I believe your change is what is needed but to the $OFILES variable instead of the $CFILES variable.

If I understood make files better I would offer a solution but I always use the bare minimum necessary to compile and haven’t really delved into the symantics of it.

• This reply was modified 11 years, 1 month ago by Greg Stevens.

From doing some internet searches it seems linking order does matter. If A depends on B then A needs to be linked first. Since main depends on ISR main needs to be linked first. So since memory is mirrored maybe it just found the next mirored occurance somehow of the function. I’m guessing at this point a modification to the make file is all that’s needed to fix the issue

This music sample is great. Nice work. I’ve been playing around with compiling this and looking at the odd jal instruction. I don’t have any answers but I did find something interesting that may point someone else in the right direction. I simply modified the linking statement to have main.c.o linked before isr.c.o and the odd jal instruction goes away. After that change the disassembly line for the call to initISR looks like this
70002d6: 00 ac 6e 00 jal 7000344 <_initisr>
which is correct and I don’t find any 7400000+ addresses anywhere.
So my guess is that the linker is having some issue when trying to link to something that the address pointer needs to move backwards for and that address is in a separate object file than the calling instruction.?!? It seems to work fine when calling addresses that are within the same object file and are prior to the instruction call. Haven’t tested this theory though. Doesn’t really make any sense to me but maybe someone else might be able to make more sense of it. My eyes are hurting from staring at the screen all afternoon so I’m going to bed…

Yes the star wars idea is still on the table. However I’m going to try something a little different for the coding competition. I want to use this library for it hence the renewed work on it to get it ready for actual game use.