Jump to content
Jagware
GroovyBee

Developing in "C" in windows xp

Recommended Posts

GroovyBee    0

Development on windows using the Remover's standard "C" library is now possible :D. I also have a nearly complete version of the Jaguar hardware specific Remover's library working but I encountered some problems during the port.

 

This is how the Remover's standard "C" library was ported: First I downloaded the current source code from the Remover's web site. After converting all the *.c, *.h, *.s, and *.inc from UNIX to DOS text file format I started my investigations.

 

The first thing I noticed was that the initialised data section (called "DATA") would only work for games released as BJL or a CD binary image. For cart based game's the DATA section was not copied from ROM to the final link addresses in RAM. This was first on the list of problems to fix.

 

The second issue was the fact that there was some start-up code to get the jag into a good state before handing control over to main. With the upcoming "C" interface to Reboot's RAPTOR engine this may have caused problems down the line so it was also noted as an area to fix.

 

I struggled for a while trying to get the existing makefiles to build the source code in each separate directory (like in Seb's original code). This caused too many headaches so all the *.c and *.s files were copied into a directory called "src" and the *.h and *.inc into "include" and "include\asm" respectively. This made the make file system much simpler.

 

The files stddef.h and stdarg.h where missing from the VBCC distribution available from Hill Software's website so a public domain version stdarg.h was located and I created a simple stddef.h. The version of ctype.h included in Seb's source code was also modified.

 

Once the library was building with 0 errors and 0 warnings it was time to tackle the outstanding issues.

 

To solve the DATA section issue a helper function called InitDataSection was created in the file starta.s. To ensure that only one library is needed for BJL/CD and cart images the function checks the program counter to see if bit 23 is set. If it is set, the program counter is greater than 0x00802000 and therefore its a cart image so the DATA section is copied from ROM to RAM. This might seem an unsafe thing to do but the function is called very early on in the boot-up sequence. If bit 23 isn't set the function returns immediately because the data was already copied there by the CD or BJL BIOS.

 

To solve the start up issues I removed crt0.s from the library (very common in embedded programming) and added another helper function to starta.s called InitBssSection. The purpose of InitBssSection is just to clear out the BSS section.

 

Both InitDataSection and InitBssSection are called from a single entry point in the library called InitStandardLib (located in start.c). Both these functions also use information provided by the linker as to the location and sizes of their relevant sections of interest.

 

To test the code I modified the hello example code so that it would display the contents of some variables in the BSS and DATA sections using sprintf (for number conversion) to verify the results (and manual checks of the symbol tables etc.). I also checked that malloc/free were functioning correctly. Along with the creation of two linker scripts, one for BJL/CD game images and the other for cart ROM images I was able to test the ROMs in Project Tempest (PT) and eliminate any bugs. I don't have any way of testing on real hardware and PT allows you to "loan-n-go". It also meant that different start-up code could be used as long as the single entry point in the library was called.

 

This is how the Remover's jag specific library was ported: Again the files were converted from UNIX to DOS and then separated into "src" and "include" directories. The first pass through VBCC produced a load of warnings and errors. That was to be expected given the very specific nature of the project. The "C" files were placed in the new makefile first on the grounds that they'd have easier bugs/warnings/errors to fix.

 

The most common warning was the complaint about bit fields not being portable. This was fixed with a #pragma in the relevant header files. Some header files had structs without any identifiers so they were an easy fix too. The "C" code eventually compiled with only 2 warnings (that still require investigation and fixes).

 

Two files in the assembler part of the make process caused SMAC to produce internal error 7. Although SMAC can produce a listing of the file the error happens when it is fixing things up (so its an internal tool error). With that in mind render.s and sound.s are both omitted for now. Eventually the library built relatively cleanly with only multiple label errors to solve. After that I had to tell the linker that it was building a jag specific library before a final output file could be obtained.

 

I started with remover's example 1 and it compiled OK but didn't link due to multiple instances of calls to a function called __lshint64. With all the long long variables used in the Remover's headers I figured it was probably a compiler helper function dealing with some aspect of 64 bit numbers. Eventually I tracked it down (with some Googling) to be a shift left for 64 bit variables compiler helper function. With no register specification for the function I took a best guess at the API for it. With this being a crucial function to the Remover's library it was simulated first before being placed in the standard library. With some experimentation I found that the same function is called from signed and unsigned 64 bit shifts. That makes sense really when you are shifting left. For completeness I also added __rshuint64 which is only for unsigned long long shifts right.

 

I expect that my 68K assembler is not very efficient for these routines but I haven't coded any really serious algorithms in it since my ST days (long ago ;)). To check that the 64 bit left/right shifts were working as expected some more test code was added to the hello example.

 

After some changes to the linker scripts and make files the Remover's Example1 burst into life in Project Tempest. I moved onto Example2 (and worked through it like the others) but it didn't build so I had to provide some stubs in the Removers library for sound. Even after that it still doesn't work at all :(. so that is the current state of play.

 

 

Share this post


Link to post
Share on other sites
GroovyBee    0

The first steps in getting "C" going in Windows are :-

 

1) Download the VBCC compiler/linker/SMAC from the Hill Software web site. Its just over a 5MB download.

 

When you install the compiler system it adds a directory path to the environment variable called PATH that points to where the VBCC tools are and also another environment variable called VBCC. If like me, you have several compilers it might be worth opening a dos box in windows and typing :-

 

SET PATH=%VBCC%;

 

And then proceed to build the libraries.

 

This zip contains the linker files. Just copy the cfg directory to be at the same level as BIN, LIB etc. from the VBCC release :-

 

This file contains jlibc the Remover's Jaguar standard library. Again extract the contents to be at the same level as BIN etc :-

jlibc.0.5.9a.win.zip

 

This file contains the Removers jag specific stuff (partially working) :-

rmv.1.3.4a.win.zip

 

This file contains Remover's Example1 :-

rmv.example1.1.00.win.zip

 

Once installed you should have the following directory structure (of importance) :-

 

..\bin

..\lib

..\jlibc

..\jlibc\docs

..\jlibc\include

..\jlibc\include\asm

..\jlibc\src

..\rmv\docs

..\rmv\include

..\rmv\src

..\cfg

..\example1

 

To build everything :-

Navigate to ..\libc\src and type make or nmake (depending on your environment).

Navigate to ..\rmv\src and type make/nmake

navigate to ..\example1 and type make/nmake

 

Test the final binary in PT with a load and run address of 0x802000. To build BJL versions just edit the example1\makefile and change the word "cart" to "bjl" and build again.

 

The final executable has been tested on real hardware courtesy of sh3-rg. Many thanks for that :D. Any questions just ask.

 

vbcc_linker.1.01.win.zip

Share this post


Link to post
Share on other sites
GroovyBee    0

Thanks guys. Hopefully it'll make jag development easier for people who dont want to learn linux.

 

Feel free to investigate the smac bug too. Then I can get the rest of the examples working.

Share this post


Link to post
Share on other sites
GroovyBee    0
Excellent work ! :yes:

 

Thanks for the compliment Zerosquare. I'd be interested in knowing how my solution compared to the one you were working on and also your thoughts on what causes the smac fatal error bug.

Share this post


Link to post
Share on other sites
SCPCD    0

if there is not too much depends for asm files that crash smac, i can take it a look :)

 

Share this post


Link to post
Share on other sites
SebRmv    2

Great! Thanks for doing this!

 

==

 

I read quickly your first post. Are you sure it is needed to copy DATA section into RAM at startup?

Maybe it is a problem of Read-Only Data vs Data ? Clearly, it is assumed that Data are Read-Only. So if it's not the case, Data has to be copied in Ram.

 

In the Jaguar specific case, I think it is the programmer responsability to know which data should go in RAM and which could stay on the Cartridge.

For instance, for my Another World port, every single piece of Data is on the cartridge but it is loaded on demand in Ram when needed.

Otherwise, the game won't simply run, because of a lack of memory.

 

 

Share this post


Link to post
Share on other sites
GroovyBee    0
if there is not too much depends for asm files that crash smac, i can take it a look :)

 

Any help would be appreciated. Have a look at sound.s and render.s. They are the only files that cause the fatal bug.

Share this post


Link to post
Share on other sites
GroovyBee    0
Great! Thanks for doing this!

 

Thanks for the compliment.

 

I read quickly your first post. Are you sure it is needed to copy DATA section into RAM at startup?

 

It is the programmer's responsibility to decide where variables go. As an example consider the following "C" statements declaring several variables :-

 

unsigned long int wilma;

unsigned long int betty=0xF00D;

const unsigned long int fred=0xABBAD00;

 

1) unsigned long int wilma;

 

The variable "wilma" will be placed in the BSS section and its 4 bytes zeroed on initialisation.

 

2) unsigned long int betty=0xF00D;

 

The variable "betty" will be placed in the DATA section and the value 0xF00D will be copied to its 4 RAM locations on initialisation.

 

3) const unsigned long int fred=0xABBAD00;

 

Because of the const keyword the variable "fred" will be placed in RODATA if the section exists. If the compiler doesn't support RODATA it will be placed in the TEXT/CODE sections instead.

 

If I try and do :-

 

fred=0xCAFE;

 

in the code the compiler displays the error "assignment to constant type".

 

I added the 3 "C" lines above to example1.c and enabled the symbol table and made a cart ROM image. The symbol table contained :-

 

Symbols of .text:

...

_fred: global reloc, value 0x80e7e4, size 0

 

Symbols of .data:

...

_betty: global reloc, value 0x24744, size 0

 

Symbols of .bss:

...

_wilma: global reloc, value 0x264d8, size 0

 

Linker symbols:

_TEXT_START: global abs, value 0x802000, size 0

_TEXT_END: global abs, value 0x80e878, size 0

_DATA_LOAD: global abs, value 0x80e878, size 0

_DATA_START: global abs, value 0x4000, size 0

_DATA_END: global abs, value 0x24748, size 0

_DATA_SIZE: global abs, value 0x20748, size 0

_BSS_START: global abs, value 0x24760, size 0

_BSS_END: global abs, value 0x26c5c, size 0

_BSS_SIZE: global abs, value 0x24fc, size 0

 

Don't worry about the "size 0" it always states that. If you look at the "Linker symbols" section and compare the "values" e.g. address of the variables in the symbol table they are all placed in the expected sections.

 

Share this post


Link to post
Share on other sites
SebRmv    2

Does vbcc handle rodata and data sections?

And what about smac and sln?

If yes, that's great because the code would be clearer then.

 

==

 

Do you need me to change the way I distribute the source files?

Share this post


Link to post
Share on other sites
GroovyBee    0
Does vbcc handle rodata and data sections?

 

Yes! Read only data is placed along with the code in the .text section.

 

And what about smac and sln?

 

I dont think smac supports rodata but you can have constants in with the code. It does support .bss and .data sections. I haven't used sln because vbcc has its own linker.

 

Do you need me to change the way I distribute the source files?

 

Not yet! When all the code builds OK on windows we can look at joining both the source code branches back together again.

 

Share this post


Link to post
Share on other sites
SCPCD    0

Found the bug in smac :

 

you need to change those lines in "sect.c" in the "fixup" function :

   if(*fexpr == SYMBOL && fexpr[2] == ENDEXPR)
      if((attr & 0x0F00) == FU_JR) {         // <-- correct line
      //if((attr & 0x0200) == FU_JR) {      // <-- wrong line

 

then some lines before the end of the same function :

   if((attr & 0x0F00) == FU_JR) {         // <-- correct line
   //if((attr & 0x0200) == FU_JR) {      // <-- wrong line
      if(orgactive) *fchptr.lp++ = orgaddr;
      else *fchptr.lp++ = 0x00000000;
   }

 

If 0x0200 is applied to "attr", there will have not only FU_JR that will be valid, those next code also :

#define FU_JR        0x0200
#define FU_MJR       0x0300
#define FU_NUM31     0x0600
#define FU_NUM32     0x0700

Share this post


Link to post
Share on other sites
GroovyBee    0
Found the bug in smac :

 

Thanks for the help SCPCD. Remover's example 2 builds but doesnt work on Virtual Jaguar or Project Tempest. The original works fine on PT. Looks like I still have some other bugs to find in the conversion.

Share this post


Link to post
Share on other sites
Orion_    1

I always thought that VBCC was easier to use than gcc and could be great on Jaguar,

because I had very hard time trying to compile rmvlib on windows using gcc

congrats on using this with vbcc, should be a lot easier now to make games on jaguar using this lib !

 

Share this post


Link to post
Share on other sites
GroovyBee    0
I always thought that VBCC was easier to use than gcc and could be great on Jaguar,

 

I only downloaded VBCC a week ago on Sunday and up until that point I had no experience jag coding. I have used GCC for many years on several platforms and its very good for a free compiler system.

 

because I had very hard time trying to compile rmvlib on windows using gcc

congrats on using this with vbcc, should be a lot easier now to make games on jaguar using this lib !

 

Thanks for the congratulations. I hope that more people will start coding for the jag. When the "C" version of Reboot's RAPTOR engine is available there will be even more choices :D.

Share this post


Link to post
Share on other sites
belboz    0

Nice work GroovyBee!

 

Glad to see some people using the VBCC I threw together for the Jag. I really should update it. But to be honest I didn't think people were using it anymore. I may take some time in the coming weeks to update it.

 

 

 

 

Share this post


Link to post
Share on other sites
GroovyBee    0
How use data.o of l'exampLe1 please ?

 

Because it doesn't have any source code to generate it you should just add it as an object to link with.

Share this post


Link to post
Share on other sites
GroovyBee    0
Nice work GroovyBee!

 

Thanks for the compliment!

 

Glad to see some people using the VBCC I threw together for the Jag. I really should update it. But to be honest I didn't think people were using it anymore. I may take some time in the coming weeks to update it.

 

Dr Typo is using it for his games. He has released the source code to them if you check out his game threads over on AA. Maybe its not a popular choice because without a standard library you have to reinvent the wheel for memory copy/fill and malloc etc. Although that shouldn't really be an excuse to not start coding on a platform.

 

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×