Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by GroovyBee

  1. Cartridges mechanical drawings / dimensions

    Thanks for converting them to *.PDF Zero. I think they might be easier to read if they had a black background. Cyan and yellow in on white are not the best colour combinations in my opinion.
  2. Fading/gradients with Jaguar's palette

    What I'd do is work on 8 bit values for R, G and B (24BPP) until you absolutely need to convert them to 16BPP mode then weight them accordingly (in a final pass). Are stepr, stepg, stepb floating point variables in your code?
  3. Removers's MOD Player vs U-235 Sound Engine

    Send a bug report to to Linkovitch and I'm sure he'll look into the problem for you.
  4. happy new year !

    Happy New Year! Good luck with all your projects. This year will be a good year for the jaguar (and the 7800 too ).
  5. Duckie Egg

    I don't think I went away. Thanks for the compliment.
  6. Up to date EEPROM.s?

    I've looked through Curt's files and I have found several versions of the file EEPROM.S. Which file is considered to be the most up to date? Thanks.
  7. Up to date EEPROM.s?

    I implemented a VBCC "C" save/restore wrapper for use in Chuckie Egg and its all working fine in Virtual Jaguar.
  8. Up to date EEPROM.s?

    Thank you! I can add high score saving to Chuckie Egg now .
  9. Find attached a utility I created at the weekend :- JagView.1.00F.zip It is a Windows GUI tool that will convert 24BPP Windows *.bmp file directly into a Jaguar ROM image that can be viewed in 16BPP on real hardware. Just press the "Browse..." button and choose an image and then use the "Convert" button to process it. A new file will be created that has a *.rom file extension. The ROM image is padded to the nearest 1MB so it can be used in emulators like VJ without conversion. Some notes :- Images must be 24BPP, 8BPP images are not supported at this time. Images larger than 320 c 200 (w x h) will be cropped to 320 x 200. Images smaller than 320 x 200 will be displayed in the centre of the screen. The utility is ideal for pixel artists who want to create in-game assets without needing a programmer to implement the features they need or to check out how screenshots or mock-ups would look. The application has been tested on XP fine and the ROMs on a PAL jaguar. (many thanks fto sh3-rg for testing) Load and execute the final ROM at 0x802000. Any problems let me know.
  10. JagView - A utility for displaying *.bmp files

    @Zerosquare and ggn: Thanks for the header information. I'll add COFF, universal header and BJL support when I get some free time. I'll probably just remove the dependence on the standard "C" library and make the code position independent as well. That'll make life easier and the final jag ROM binary should be a bit smaller too.
  11. JagView - A utility for displaying *.bmp files

    Thanks for the compliment. I'll change the name if I go back to the project.
  12. JagView - A utility for displaying *.bmp files

    Thanks for the compliment. If I go back to the project I'll rename it. True! But its a tool for game pixel artists to see how their work would look on real hardware. Most pixel artists I know always want to try something that I haven't implemented yet . So the tool allows them to experiment while I catch up or implement the code needed to drive the graphics.
  13. JagView - A utility for displaying *.bmp files

    Thanks for the compliment. Yay! I like suggestions . Sure can! Is there an "official" spec for it? To be honest I haven't really looked for that kind of information so apologies if its common knowledge. Possible, but I'm not sure how to coax a COFF file out of the VBCC compiler system. I could just rewrite it to be 100% assembler which would allow a multitude of different output formats. The blank space in the padding is full of 0xFFs which is the default state of any modern erased flash device so any good programming algorithm would just kip 16 bit words of 0xFFFF in the source image. No dither in this version. In my mind its a tool for viewing in-game assets so I wouldn't want to add extra visual information that isn't present in the original image. Although losing colours information is expected and therefore fine . Feedback is always good.
  14. Sinewaves

    If you just want a basic table then this will do it :- http://www.daycounter.com/Calculators/Sine...alculator.phtml if you want high level language then in "C" its something like this :- #define SIN_NO_OF_POINTS 60 #define SIN_SCALE 100 #define SIN_OFFSET 20 for (int c=0; c<SIN_NO_OF_POINTS; c++) { double angleInRadians=2*PI*(double)c/(double)SIN_NO_OF_POINTS; signed long int val=SIN_OFFSET+(signed long int)(sin(angleInRadians)*SIN_SCALE); //... Process val here. } You'll need to include math.h to get the sine function. The value of PI might be defined in that header file too, if not you'll have to #define it yourself.
  15. In the file rand.s the function _srand starts as :- _srand: move.l d2,-(sp) move.l #random_seeds,a0 move.l 4(sp),d1 move.l d1,d2 moveq #RANDGEN_K,d0 Which means that the new seed for the random number generator is actually the program counter of the instruction immediately after the "jsr _srand" in your program and not the new seed you passed to the function. It should be changed to :- _srand: move.l d2,-(sp) move.l #random_seeds,a0 move.l 4+4(sp),d1 move.l d1,d2 moveq #RANDGEN_K,d0
  16. Bug in srand (Removers standard "C" library)

    No problem! I only found it because I was setting the seed and wondering why my latest project always looked the same :- http://www.atariage.com/forums/topic/20161...r-has-jag-powa/
  17. Developing in "C" in windows xp

    Development on windows using the Remover's standard "C" library is now possible . 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.
  18. Developing in "C" in windows xp

    Thanks for the compliment! 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.
  19. Developing in "C" in windows xp

    Because it doesn't have any source code to generate it you should just add it as an object to link with.
  20. Developing in "C" in windows xp

    Has anyone figured out how to use the -O4 optimisation level in VBCC?
  21. Developing in "C" in windows xp

    No probs! I'll have another look at getting more of the Removers examples working at the weekend.
  22. Developing in "C" in windows xp

    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. 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 .
  23. Developing in "C" in windows xp

    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.
  24. Developing in "C" in windows xp

    Yes! Read only data is placed along with the code in the .text section. 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. Not yet! When all the code builds OK on windows we can look at joining both the source code branches back together again.
  25. Developing in "C" in windows xp

    Thanks for the compliment. 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.