Time to update to gcc 4.6.2

[Chilly Willy]

Thanks! I managed to draw a pixel

Is RLE mode implemented? There doesn't seem to be any code doing anything with it.

You can set it with Hw32xInit(), but you would need to do everything else yourself. The print routines are for 256 or 32K color modes. RLE isn't a very useful mode... it might make static screens a little smaller... or maybe it won't. It might make flat-shaded polys easier to render... or it might not. They should have left out RLE mode and used the extra gates for more drawing hardware than a plain line fill. You can see where someone thought it a great idea - all the old graphics formats used RLE encoding. They forgot to ask the programmers just how useful RLE REALLY was. While RLE COULD save a lot of space, in real world usage, you normally barely save 10%. Many images are actually BIGGER in RLE mode - it depends on how "busy" the image is. RLE depends on having large areas of flat color to save space.

[djcouchycouch]

My current idea is to play around with flat shaded polygons so it appears interesting to me.

Any idea or docs about how RLE mode works in practice? Every pixel has a palette color index and a length, but it's not clear what happens with two adjacent pixels where the first pixel has a length that in theory overlaps the second.

Or is each line seen as a stack of paletteindex-length pairs with a maximum of 320 entries?

[Chilly Willy]

My current idea is to play around with flat shaded polygons so it appears interesting to me.

While at first it appears to be ideal for flat shaded polys, the RLE aspect means it's much more difficult to insert segments into a line, and hence much slower than just drawing the segment (using the line fill hardware, for example).

Any idea or docs about how RLE mode works in practice? Every pixel has a palette color index and a length, but it's not clear what happens with two adjacent pixels where the first pixel has a length that in theory overlaps the second.

Or is each line seen as a stack of paletteindex-length pairs with a maximum of 320 entries?

Every "pixel" is a word, and uses the same rules as 32K color mode.
The start of each line is determined by the line table.
Each "pixel" is of the form: MSB=length-1, LSB=palette entry.
The display stops after 320 pixels, even if more are indicated by the RLE, and starts at the next line indicated by the line table. So you don't have to worry about keeping line to exactly 320 pixels.

Hmm - looking at Hw32xInit(), I don't handle RLE mode. It would need another else if part for MARS_VDP_MODE_RLE that setup the line table like 32K mode. Like this

Code: Select all

    else if (vmode == MARS_VDP_MODE_RLE)
    {
        // Set 16-bit direct mode, 224 lines
        MARS_VDP_DISPMODE = MARS_224_LINES | MARS_VDP_MODE_RLE;

        // init both framebuffers

        // Flip the framebuffer selection bit and wait for it to take effect
        MARS_VDP_FBCTL = currentFB ^ 1;
        while ((MARS_VDP_FBCTL & MARS_VDP_FS) == currentFB) ;
        currentFB ^= 1;
        // rewrite line table
        for (i=0; i<224/(lineskip+1); i++)
        {
            if (lineskip)
            {
                int j = lineskip + 1;
                while (j)
                {
                    frameBuffer16[i*(lineskip+1) + (lineskip + 1 - j)] = i*320 + 0x100; /* word offset of line */
                    j--;
                }
            }
            else
            {
                if (i<200)
                    frameBuffer16[i] = i*320 + 0x100; /* word offset of line */
                else
                    frameBuffer16[i] = 200*320 + 0x100; /* word offset of line */
            }
        }
        // clear screen
        for (i=0x100; i<0x10000; i++)
            frameBuffer16[i] = 0;

        // Flip the framebuffer selection bit and wait for it to take effect
        MARS_VDP_FBCTL = currentFB ^ 1;
        while ((MARS_VDP_FBCTL & MARS_VDP_FS) == currentFB) ;
        currentFB ^= 1;
        // rewrite line table
        for (i=0; i<224/(lineskip+1); i++)
        {
            if (lineskip)
            {
                int j = lineskip + 1;
                while (j)
                {
                    frameBuffer16[i*(lineskip+1) + (lineskip + 1 - j)] = i*320 + 0x100; /* word offset of line */
                    j--;
                }
            }
            else
            {
                if (i<200)
                    frameBuffer16[i] = i*320 + 0x100; /* word offset of line */
                else
                    frameBuffer16[i] = 200*320 + 0x100; /* word offset of line */
            }
        }
        // clear screen
        for (i=0x100; i<0x10000; i++)
            frameBuffer16[i] = 0;

        MX = 40;
        MY = 25/(lineskip+1);
    }

That would leave the most space per line that the mode COULD require (the same as 32K mode). That also means 200 lines since there's not enough ram for more than 204 lines. If you wanted more lines, you'd have to assume that individual lines used less space than the max and enforce that during drawing.

Clearing the frame buffer for this mode is fine because 0 simply means 256 pixels of color 0.

Your drawing code would need to find the segment that holds the start of your new segment, split that segment, delete as many pixels as the new segment holds, and insert the new segment. While this is not complicated, you have to recursively search through the entire line until you find these points. Then you need to make the changes indicated, which may include shifting the contents of the rest of the line over an arbitrary number of words.

[Chilly Willy]

Actually, thinking about it a bit, a better change for the Hw32xInit for RLE would be the change the

Code: Select all

    else if (vmode == MARS_VDP_MODE_32K)
    {
        // Set 16-bit direct mode, 224 lines
        MARS_VDP_DISPMODE = MARS_224_LINES | MARS_VDP_MODE_32K;

into

Code: Select all

    else if ((vmode == MARS_VDP_MODE_32K) || (vmode == MARS_VDP_MODE_RLE))
    {
        // Set 16-bit direct or RLE mode, 224 lines
        MARS_VDP_DISPMODE = MARS_224_LINES | vmode;

Also, from memory, the RLE example Sega did builds a linked list of segments which contain a link struct, the start point, the length, and the color. While "drawing" it actually inserts the segments into the link list. Then when drawing is complete, it goes back through the list and creates the RLE line from the info in the segment list.

[Snesi]

Hi I keep getting error 127 when compiling it on Ubuntu 12.04, I have gcc-4.6.3 installed and I followed all the steps in the post.

These are last few lines that I get:

Code: Select all

> /home/nowcomputing/Downloads/logs/build-gcc-sh-elf-4.6.2-pass1.log
cd build-gcc-sh-elf-4.6.2;  ../gcc-4.6.2/configure --target=sh-elf --prefix=/opt/toolchains/sega/sh-elf --without-headers --with-newlib --enable-languages=c --disable-libssp --disable-tls --with-endian=big --with-cpu=m2 --disable-werror 
/bin/sh: 1: ../gcc-4.6.2/configure: not found
make: *** [build-sh2-gcc-pass1] Error 127

Please help, I really want to start md dev

[peekpoke]

Where u extracted gcc-4.6.2 sources? According to your output, you need gcc-4.6.2 directory to be at /home/nowcomputing/Downloads/gcc-4.6.2, but makefile script cant find it there

To check, just run this command in ur console:

Code: Select all

$ ls  ~/Downloads

you must see in output at least those items:
bin
ldscripts
binutils-2.22
gcc-4.6.2
newlib-1.20.0
makefile-sega

[Chilly Willy]

Downloads is where the arc is after downloading. You unarc the directories to wherever you put the makefile. I normally have a toolchains directory in the Projects directory, so the makefile will be in /home/jlfenton/Projects/toolchains/makefile, and the gcc directory in /home/jlfenton/Projects/toolchains/gcc-4.6.2, and so on.

The makefile expects all the directories to be in the same directory as itself. They don't NEED to be, but you would need to change the makefile to reflect where they actually were in such a case.

My toolchains directory has makefiles for all kinds of cross-compilers which all use the same gcc/binutils/newlib directories. That way I don't need a gcc/binutils/newlib directory for every toolchain I build.

[notaz]

I'm not aware of any emulator yet supporting the CD mode 1 in 32X mode. I had to get that working completely on real hardware via flash cart. Fusion supports mode 1 in MD mode.

A bit of a gravedig, but I wonder if we have anything that uses this? I could of course cook something myself, but maybe somebody has something already.

[Chilly Willy]

There was one commercial "game" that supported mode 1, but don't remember the name. There is a Sonic hack that uses mode 1, and my last update to Wolf32X uses mode 1. So there are a number of examples of using mode 1 available. If you wanted a specific mode 1 demo, I could put one together for you.

[Mask of Destiny]

There was one commercial "game" that supported mode 1, but don't remember the name.

Flux perhaps? I believe Pier Solar uses it as well.

[Chilly Willy]

There was one commercial "game" that supported mode 1, but don't remember the name.

Flux perhaps? I believe Pier Solar uses it as well.

Yeah, that's the one. And I can't believe I forgot Polo Solo.

[notaz]

Well I'm looking for mode1 + 32x, so it's Wolf32X only then. The Wolf32X release thread (first post at least) doesn't seem to mention mode1 though.

[Chilly Willy]

Well I'm looking for mode1 + 32x, so it's Wolf32X only then. The Wolf32X release thread (first post at least) doesn't seem to mention mode1 though.

Yeah, I keep forgetting to update the OP - it's way back towards the end of the thread... or you can get it directly:

http://www.mediafire.com/download/dl6ba ... 0120223.7z

http://www.mediafire.com/download/h10gv ... OD-bins.7z

The first is the original Wolf32X+Mode1 release with source. The second is just the binaries where the only change was to double the size of the save ram (someone noticed that you couldn't save with the original size on the higher skill settings (too many bad guys/things)).