Page 2 of 3
Posted: Tue Apr 03, 2012 2:17 am
by M-374 LX
Chilly Willy wrote:Is the advance reg set to 2 like it should be?
It is, but I got exactly the same tile when attempting to set the register to different values.
Code: Select all
volatile uint *pw;
pw = (uint *) GFXCNTL;
...
*pw = 0x8F02;
A single 32-bit write to VDP data port, like
*pl = 0x22222222, resulted in a line with the width of 4 pixels, rather than 8.
By writing separate 16-bit units, the result is still not as expected, but closer:
Code: Select all
*pl = 0x2222;
*pl = 0x2222;
*pl = 0x1112;
*pl = 0x1111;
*pl = 0x1112;
*pl = 0x1111;
*pl = 0x1112;
*pl = 0x1111;
*pl = 0x2222;
*pl = 0x2222;
*pl = 0x1111;
*pl = 0x1112;
*pl = 0x1111;
*pl = 0x1112;
*pl = 0x1111;
*pl = 0x1112;
It would be nice if the user also had the option to compile and install only the tools for the M68000 or only the tools for the SH2.
Posted: Tue Apr 03, 2012 7:13 pm
by Chilly Willy
Okay, current guess - you're ALWAYS using ulong pointers for all VDP accesses... which is wrong. Accesses to individual registers should be words unless you properly know what you're doing... which you clearly don't. For example, look at this from my assembly
Code: Select all
move.w #0x8F02,(a4) /* set INC to 2 */
In C, that would be like this
If you wished to use a pointer var, it would be like this
Code: Select all
volatile uint16_t *pw;
pw = (uint16_t *) GFXCNTL;
...
*pw = 0x8F02;
Be careful of those unintended side effects from writing longs to word registers and ports. Write words to the VDP except where tutorials and existing code shows how to properly take advantage of writing longs.
Posted: Wed Apr 04, 2012 2:32 am
by M-374 LX
My problems are now solved.
It seems that I had those problems with sizes because of differences between GCC and SGCC. While an int is 32-bit in GCC, it seems to be 16-bit in SGCC.
However, there is one more thing: I can only load tile data and maps from an array if it is const. May you tell me why?
Posted: Mon Apr 09, 2012 11:19 am
by mic_
I can only load tile data and maps from an array if it is const. May you tell me why?
The startup code you're using isn't correctly copying initialized data to RAM?
For const variables the data will always be in ROM, so that will still work.
Btw, anyone got prebuilt 4.6.2 (or later) SH/68K toolchains for Windows (cygwin)? My laptop auto-shuts down after a while when I try to build the toolchains. Dunno if it's overheating or what the deal is.
Posted: Mon Apr 09, 2012 6:31 pm
by Chilly Willy
To use initialized data from variables/arrays in ram, you need code like this in the startup:
Code: Select all
| Clear Work RAM
lea 0xFF0000,a0
moveq #0,d0
move.w #0x3FFF,d1
1:
move.l d0,(a0)+
dbra d1,1b
| Copy initialized variables from ROM to Work RAM
lea __text_end,a0
lea 0xFF0000,a1
move.l #__data_size,d0
lsr.l #1,d0
subq.w #1,d0
2:
move.w (a0)+,(a1)+
dbra d0,2b
The linker script puts all initialized data for the .data section into rom right after the .text section, so you copy everything in rom from the end of .text (__text_end) to the start of the ram set in the linker script (usually 0xFF0000); the amount of data to copy is set by the size of the .data section, which in my linker script is __data_size. My code above will only copy 128KB (64K words), but we know the work ram in the MD is only 64KB, so it's fine.
Re: Time to update to gcc 4.6.2
Posted: Fri May 04, 2012 1:54 pm
by Tomy
Here is an archive with three libraries. You will need them for the Tremor example. Build them BEFORE trying to build the Tremor test. Be sure to run "make install" to install the libraries into the toolchain so it can find them.
Hi Chilly Willy,
This link dead, can you fix it ? Thanks.
Re: Time to update to gcc 4.6.2
Posted: Fri May 04, 2012 5:58 pm
by Chilly Willy
Tomy wrote:
Here is an archive with three libraries. You will need them for the Tremor example. Build them BEFORE trying to build the Tremor test. Be sure to run "make install" to install the libraries into the toolchain so it can find them.
Hi Chilly Willy,
This link dead, can you fix it ? Thanks.
Weird... I wonder what happened to that file.
http://www.mediafire.com/?owe4vcpu8c2kftd
Posted: Tue May 22, 2012 4:22 pm
by flamkuch
Hi,
Just wanted to say that if your host compiler is gcc 4.7.0, then you have to compile gcc 4.6.3 for the toolchain, since 4.7.0 can't compile 4.6.2 (it will choke on gtype-desc.c).
I didn't have the patience to see if compiling 4.7.0 for the toolchain works (it takes so long to compile), but at least 4.6.3 does.
That said, thanks a lot for the helpful instructions!
Posted: Tue May 22, 2012 6:03 pm
by Chilly Willy
Thanks for the tip! Really odd that 4.7.0 won't compile 4.6.2, but you see odd things like that all the time.
I'll probably update to 4.7 once they get an update or two out for it. I don't care for using x.x.0 releases. The other way around, I don't think people will find much different between 4.6.2 and 4.6.3 other than the latter can be compiled by 4.7.0.
Posted: Fri Feb 01, 2013 2:16 pm
by Mixail
Why there was this error?
Posted: Sat Feb 02, 2013 8:23 am
by Mixail
etoD wrote:Thanks for this, it was really helpful.
For an archive which has everything up to step 5 completed:
http://projects.earthshine.it/sega/sega-builddir.tar.gz (135MB)
Then all you will need to do is extract this somewhere, and proceed from step 6.
CW, if you want somewhere to host those demos and other stuff, I can give you a few hundred MB on my server if you like, just to avoid the demon mediafire...
This link dead, can you fix it ? Thanks.
Posted: Tue Feb 05, 2013 1:18 am
by djcouchycouch
I confirm that the instructions for building on Windows as explained on SonicRetro work.
http://forums.sonicretro.org/index.php?showtopic=27955
Did it on an old Windows XP 64 machine. Took about 12 hours to build
Built and ran the C 32x tic-tac-toe example.
I'd suggest splitting "Copy the ldscripts and bin directories to /opt/toolchains/sega." into it's own step. I originally missed it because it was part of another step.
Posted: Tue Feb 05, 2013 2:13 am
by djcouchycouch
Looking at the tic-tac-toe examples, the 32X versions don't have a lot of 32X code in them, mostly using Genesis calls.
Where can I find an example of simply drawing a pixel on screen?
Posted: Tue Feb 05, 2013 3:16 am
by Chilly Willy
djcouchycouch wrote:Looking at the tic-tac-toe examples, the 32X versions don't have a lot of 32X code in them, mostly using Genesis calls.
Where can I find an example of simply drawing a pixel on screen?
hd_32x.c
Even though the example uses MD screen prints, you can use the 32X calls in that file. Call Hw32xInit() with the constant (in 32x.h) for which video mode you want (256 color, 32k color, or RLE); the lineskip variable will be 0 for a 224 line tall display, or 1 for a 112 line tall display. Then look at debug_put_char_8() or debug_put_char_16() to see how you draw to the frame buffer. Once you have the frame buffer the way you want, you show it by calling Hw32xScreenFlip(). If you pass a non-zero value, it will wait until the screen if actually flipped before returning. If you pass a 0, you need to call Hw32xFlipWait() to wait for the screen to flip before trying to draw the next display.
Posted: Wed Feb 06, 2013 2:56 am
by djcouchycouch
Thanks! I managed to draw a pixel
Is RLE mode implemented? There doesn't seem to be any code doing anything with it.