Need for a program loader ?

vreuzon

New Member
Looking at the collection of sample progs in the dev section, I though it would be good to have these samples on a single iso. Loading could be done via a simple text-menu .bin loader/chooser as 0sl.bin.

So does anybody know how to load and run a .bin, using the sgl or anything else ?

Thanks
 

slinga

Member
I agree with you...

I looked through the SGL docs I had but I couldn't find anything. The closest thing I found was SlExecuteEvent, but I doubt that's it.

Dumb Question: How do you uncompress bz2 files? I tried downloading some files from Antime's site, but I couldn't uncompress them...
 

antime

Extra Hard Mid Boss
You unpack bzip2 files with bzip2. Some other programs (eg. WinRAR) should also handle them.

As for the original question, the samples that are to be run through a Commlink are usually loaded and run from address 0x6004000. Put your program somewhere safe in memory, load the file to that address then jump to that location. You can use a C function pointer to do that, something like

Code:
void (*binfile)(void);

binfile = (void *)0x6004000;

binfile();

might do the trick. Then watch the program you run crash horribly as the original programmer fails to initialize his code properly, instead relying in the bootup values.
 

Reinhart

New Member
I believe the SGL functions about cd stuff are located in the SGL Developer's Manual Tutorial. I'm still unable to used them.

Originally posted by antime@Jan. 14 2003, 12:23 am

Then watch the program you run crash horribly as the original programmer fails to initialize his code properly, instead relying in the bootup values.

What do you mean exactly ? It's not the right way to load a .bin ?
 

antime

Extra Hard Mid Boss
Originally posted by Reinhart@Jan. 14 2003, 10:47 am

What do you mean exactly ? It's not the right way to load a .bin ?

I mean that after you've run one program (the menu/loader) the hardware may be in a state the programmer didn't anticipate. A typical case is that some hardware isn't set to a known value, as whatever value is in the registers after the machine is started happens to work. When this no longer holds, the program blows up.
 

slinga

Member
Help me with my code...this is based on that save game copier I did. This code works if the file I'm loading is small, I tested it with a 50k file and it worked fine. If I try with a large file, like say 150k, it stays in the while loop forever, and the status never updates. Any idea where I'm screwing up?

Code:
#include "sgl.h" // Required for basic sgl functions

#include "sgl_cd.h" // Required for cd access

#include "stdlib.h" // Don't know why I need this...don't feel like burning another cd to find out

#define MAX_FILE 256 // Needed for CD functions

#define READSECT 50 // Needed for CD functions

Sint32 dirwork[SLCD_WORK_SIZE(MAX_FILE)/sizeof(Sint32)]; // Needed for CD function

Uint8 readbuf[(READSECT*CDBUF_FORM1/sizeof(Uint8))]; // Needed for CD function

void ss_main(void)

{

	Sint32 ndir;

	CDHN cdhn;

	CDKEY key[2];

	CDBUF buf[2];

	Sint32 stat;

	Sint32 len[2];

	Sint32 ypos=1;

	Uint8 tempCounter=5;

	slInitSystem(TV_320x224, NULL, 1); // Initializes screen

	ndir=slCdInit(MAX_FILE, dirwork); // initializes cd

	slPrint("SlCdInit:", slLocate(1, ypos));

	slPrintFX(toFIXED(ndir), slLocate(11, ypos));

	ypos++;

	key[0].cn=key[0].sm=key[0].ci=CDKEY_NONE;

	key[1].cn=CDKEY_TERM;

	cdhn=slCdOpen("DUKE\\BONUS.BIN", key); // opens cd

	slPrint("slCdOpen:", slLocate(1,ypos));

	slDispHex((Uint32)cdhn, slLocate(11, ypos));

	buf[0].type=CDBUF_COPY;

	buf[0].trans.copy.addr=readbuf;

	buf[0].trans.copy.unit=CDBUF_FORM1;

	buf[0].trans.copy.size=READSECT;

	buf[1].type=CDBUF_TERM;

	slCdLoadFile(cdhn,buf); // loads file from cd

	ypos++;

	while(stat=CDSTAT_COMPLETED)

	{

 slSynch();

 stat=slCdGetStatus(cdhn, len);

 slPrint("stat:", slLocate(1, ypos));

 slDispHex((Uint32)stat, slLocate(7, ypos));

 ypos++;

 if(ypos>=27) ypos=1;

 if(stat==CDSTAT_COMPLETED) break;

  	

	}

	slPrint("Bin final test loaded......................", slLocate(1,ypos));

	

	while(1)

	{

 slSynch();

	}

}

Edit: Nevermind I got it...something about having to reset the buffer...I added this code to the end of my while loop:

Code:
if(len[0]==CDBUF_FORM1* READSECT)

 {

  slCdResetBuf(cdhn, &(key[0]));

 }

Ok now that I have the bin file loaded (to where I have no idea), how do I execute it? It's death tank one if your curious, which I know for a fact works if its the first file on the cd.
 

TakaIsSilly

New Member
Ddeath tank zwei is coded to run (as far as I know) from adress 0x6004000, so you'll need to have all data there... In this case the pointer is in whatever readbuf is, and mutch unlikely in the start adress... if instead you wrote

Code:
(...)

Sint32 dirwork[SLCD_WORK_SIZE(MAX_FILE)/sizeof(Sint32)]; // Needed for CD function

/* Comment the next line out */

// Uint8 readbuf[(READSECT*CDBUF_FORM1/sizeof(Uint8))]; // Needed for CD function

void ss_main(void)

{

void (*readbuf)(void);

readbuf = (void *)0x6004000;

(load file...)

readbuf();

}

this will crash if you attempt to compile and execute on the ordinary location, but if you execute it from another location, death tank zwei should boot.
 

slinga

Member
I don't follow...I made the changes you said to but now the program doesn't even execute the while loop...how do I run my initial program at a different location than the default? I'm guessing I'd have to edit ip.bin.
 

TakaIsSilly

New Member
Well, you destroy the whole program if you compile it normally. The program starts at 0x6004000, your transfer too, and the DMA transfer doesn't give a damm where it is writing, so, it will write until it destroys the while loop, and then we're on random code land.


First you have to compile the code to boot at the specific location(this is easy, altough I don't really remember how, it was explained somewhere in the forum). Then, you have to hexsearch ip.bin for the 6004000 value... someone said it appears once or twice, so you have go by tries... unless it is defined in the format description and i don't know ^^;
 

antime

Extra Hard Mid Boss
If you're using the linkscript from the SGL demos, change SLSTART to an address higher up. As TakaIsSilly already mentioned, at least the "1st Read Address" in the IP must also be changed.

By the way, if I may offer some unrelated critique, your loop

Code:
while(stat=CDSTAT_COMPLETED)

{

 slSynch();

 stat=slCdGetStatus(cdhn, len);

 ...

 if(stat==CDSTAT_COMPLETED) break;

}

could be better written as a do..while loop, ie.

Code:
do {

 slSynch();

 stat=slCdGetStatus(cdhn, len);

 ...

} while (stat != CDSTAT_COMPLETED);
 

slinga

Member
In IP.bin, I changed the first location of 0600 4000 to 0200 0000, 0601 0000, and 0600 6000, but no dice. It crashed each time at the Sega logo with "Invalid Opcode." When I put the code back to 0600 4000 it works and text is displayed on the screen.
 

antime

Extra Hard Mid Boss
The first read address is located at offset 0xf0 in the IP. If you changed a value before that, you probably changed the master or slave CPU stack setting and wrote garbage all over your code. I don't know if you can load directly to low RAM, as you can't do SCU DMA transfers to that area (see the SCU Precautions doc, item 4). Manual transfers or CPU DMA transfers should still be possible, but whether SGL supports that option is another matter.
 

TakaIsSilly

New Member
Huh, looks to me like the first read is on that pointer, but the file is still loaded at the original location. It could also be that emulators are not ready for sutch IP modifications and load all files in the default position (what seems unlikely).
 

antime

Extra Hard Mid Boss
slinga, if you're testing this with an emulator use its debugging facilities to verify that your program is being loaded to where it's supposed to. At least Satourne lets you do this.
 

printf

New Member
slinga, Taka, antime:

You can load programs (using IP.bin) from 00200000 to 00300000 (low ram) or 06003000 to 06100000 (work ram) just fine. At least the Saturn allows for this to happen. I have no idea what emulators think about this.


printf
 

printf

New Member
This is a really dumb question, but did you change the IP.bin read address for the program and compile your code to that same location?


If you use the compiler setup from Taka's tutorials, the compile and execute address is in the linker script. Please make sure this address and the one from IP.bin match, otherwise it will not work. Then, also check that you got the right size for your program put into IP.bin as well, right next to the location of the first value you changed I believe.

Is that a US Saturn you tested the burned CDs on?

printf
 

slinga

Member
Ok I changed the value of slstart in ip.bin...still no luck. I burned a few cds, all coasters. They freeze up at the Sega screen. In satourne I can see that that my code is executing at 0020 0000, but I can only see that nothing is being written to 0600 4000. I'm not sure what's wrong....
 
Top