PDA

View Full Version : NeoPop SDL



GPF
October 19th, 2004, 13:50
I finally got something to work, I think I got the code from Quzar awhile ago. And Finally had a chance to play with it.

Quzar did you post the code somewhere? Or did I port it I honestly don't remember.

Troy

quzar
October 19th, 2004, 14:11
no, i never ported it anywhere. Ive had it sitting here trying to fix it forever.

if you dont have it fully working, i could send you my source (if anything you might be able to tell me what i did wrong ). I still stand behind the "gcc 3.3.x broke it" defense =P.

GPF
October 19th, 2004, 14:27
ok, I just didn't remember. I now have my GCC 3.4.2 chain working. So I was messing around trying to get it to work last night. And I finally got my GBA emulator to compile also. Still slow though :)

I have MetalSlug 1 working on NeoPop. I have only tested it in Chankast though.

Only annoyance is the green square in the center of Chankast, I don't know if it will be different on a real dreamcast.

here is a binary http://s101533388.onlinehome.us/GPF/NeoPopSDL-jump.rar

it includes a PD rom called Jumpy in the romdisk, that I got from www.pdroms.de .

If someone could test it out on a real dreamcast I would appreciate it.

Thanks,
Troy

quzar
October 19th, 2004, 14:53
the green square is because that is supposed to be the rendering area. move the video display over it and ittle go away =P

wraggster
October 19th, 2004, 19:21
very interesting :)

if this works, will it support sound too?nice work though
:)

GPF
October 19th, 2004, 21:51
well its not working on my dreamcast, so far. In Chankast its working with sound, slowly.

Troy

GPF
October 23rd, 2004, 18:47
I think I figured out the problem, just don't know how to fix the problem. It appears that Chankast allows for unaligned reads/writes, but of course a real dreamcast does not.

The problem is when the memory is accessed for 32 bit and 16 bit reads and writes. I took a stab at fixing it but by bitshifting and masking experience is severly lacking :)

here is what I used for the 32bit write


void storeL(_u32 address, _u32 data)
{
/*_u32* ptr = translate_address_write(address);

//Write
if (ptr)
{
*ptr = htole32(data);
post_write(address);
}
*/
unsigned int word1=(data>>16)&0xffff;
unsigned int word2=data&0xffff;
address&=0xffffff;
storeW(address,word1);
storeW(address+2,word2);
}
this is how we fixed the alignment problem in neocd. But I need to change the storeW - 16 bit write and I don't know how to do that

here was my stab at it


void storeW(_u32 address, _u16 data)
{
/*_u16* ptr = translate_address_write(address);

//Write
if (ptr)
{
*ptr = htole16(data);
post_write(address);
}
*/
unsigned int word1=(data>>8)&0x00ff;
unsigned int word2=data&0xff00;
address&=0xfffffe;
storeB(address,word1);
storeB(address+1,word2);
}
and here is the 8 bit write function that appears to be working


void storeB(_u32 address, _u8 data)
{
_u8* ptr = translate_address_write(address);

//Write
if (ptr)
{
*ptr = data;
post_write(address);
}
}

and for reads here is the 32 bit


_u32 loadL(_u32 address)
{
/*_u32* ptr = translate_address_read(address);
if (ptr == NULL)
return 0;
else
return le32toh(*ptr);
*/
_u16 data;
address&=0xfffffe;
data=loadW(address)<<16;
data|=loadW(address+2);
return data;
}

need help with the 16 bit read


_u16 loadW(_u32 address)
{
//printf("address=%0x\n",address);
/*_u16* ptr = translate_address_read(address);
//printf("ptr=%0x\n",ptr);
if (ptr == NULL)
return 0;
else
return le16toh(*ptr);
*/
_u16 data;
address&=0xfffffe;
data=loadB(address)<<8;
data|=loadB(address+1);
return data;

}
and here is the 8 bit read


_u8 loadB(_u32 address)
{
_u8* ptr = translate_address_read(address);
if (ptr == NULL)
return 0;
else
return *ptr;
}

Thanks

Troy

quzar
October 23rd, 2004, 20:05
Are you positive that is where the error ends? I was able to trace the error in mine back to the le16toh and corresponding 'endian-fixing' functions. It seems that gcc does not properly handle the endianness of the dreamcast and no matter what I did, it would not let those functions run properly (even though they were empty).

GPF
October 24th, 2004, 01:27
my traces were leading back to TLCS900h_interpret.c in the fetch16 function, since the le16toh function is a do nothing function when specified to build little endian.


here is my debugging


KallistiOS ##version##: Thu Oct 21 19:20:23 CDT 2004
*tdavis@TDATHLON:/usr/local/dc/kos1.3/kos
thd: pre-emption enabled, HZ=100
maple: active drivers:
* *PuruPuru (Vibration) Pack: JumpPack
* *VMU Driver: Clock, LCD, MemoryCard
* *Mouse Driver: Mouse
* *Keyboard Driver: Keyboard
* *Controller Driver: Controller
*DMA Buffer at ac41a0a0
vid_set_mode: 640x480 NTSC
fs_romdisk: mounting image at 0x8c0d75a8 at /rd
dc-load console support enabled
maple: attached devices:
*A0: Dreamcast Controller * * * * *(01000000: Controller)
*D0: Keyboard * * * * * * * * * * *(40000000: Keyboard)
vid_set_mode: 320x240 NTSC
not using software YUV overlay
/rd/Chaos89(PD).npc is loading
line 146
line 110 /rd/Chaos89(PD).npc
/rd/Chaos89(PD).npc is 2097152 bytes
Memory allocated
line 161
line 148
line 151
fn = /Chaos89(PD).npc
Title = NeoPop - CHAOS89.COM
file loaded
reset
SDL_PauseAudio
start_state
Unhandled exception: PC 8c044856, code 1, evt 00e0
R0-R7: 8c0447a0 00400000 00200000 8c3b3668 00200041 800bebc2 00000000 000006c4
R8-R15: 8c443169 8c3f38a7 8c3f38a9 8c043540 8c048580 8c3a765c 8cffff84 8cffff8

SR 40000000 PR 8c04484c
-------- Stack Trace (innermost first) ---------
* 8c046010
* 8c047c8a
* 8c0485e4
* 8c044d58
* 8c03ca44
* 8c0a29ee
* 8c010064
-------------- End Stack Trace -----------------
kernel panic: unhandled IRQ/Exception
arch: aborting the system
#mkiso.bat

tdavis@TDATHLON ~/prj/DCNeoPop-SDL-0.2
$ /usr/local/dc/sh-elf/bin/sh-elf-addr2line.exe -e neopop.elf 8c044856 8c04484c
8c046010 8c047c8a 8c0485e4 8c044d58 8c03ca44 8c0a29ee 8c010064
Core/mem.c:355
Core/mem.c:352
Core/TLCS-900h/TLCS900h_interpret.c:86
Core/TLCS-900h/TLCS900h_interpret.c:573
Core/TLCS-900h/TLCS900h_interpret.c:957
Core/neopop.c:97
System_SDL/system_main.c:403
/usr/local/dc/kos1.3/kos/kernel/arch/dreamcast/kernel/init.c:177
??:0

the problem is not with the le16toh function but the *ptr , that I can tell. The dereferencing is whats causing the exception. In the above trace I was trying to print out the *ptr and it causes the same exception as calling le16toh(*ptr)

also I added a call to print the ptr out in binary.

u16loadW 0011000101101001 dreamcast

u16loadW 0110010101110001 windows

don't know why there is a difference yet, but goodnight

Troy