Jump to content
Jagware

GroovyBee

Members
 View Profile  See their activity

  • Content count

    31

  • Joined

  • Last visited

Posts posted by GroovyBee

  3. Posted · Report reply

    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

  4. Posted · Report reply

    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.

     

     

×