Re: Burning \ Making SBI's
I don't know anything about compiling projects for the DC, but I know quite a bit about SBI's.
The bins within SBI files have to be unscrambled. DreamInducer will not load scrambled binaries. So, using the bin that you made from:
Code:
scramble tunnel.bin tunnel2.bin
absolutely will not work. That will cause the DC to reset when you select it from the menu.
I'm not quite sure why the other one isn't working, unless it's just not compiled correctly. I know I have had issues when I used to try hex-editing binaries (before I knew the rules about hex-editing bin files).
Re: Burning \ Making SBI's
You could try Demo menu or DCHakker, boot either one up and swap in the CD you made - browse for the binary and see if it loads correctly for you. Both apps will boot scrambled and unscrambled binary files and although old now, are very useful for testing binaries, you can also use multi session CDR's to save making a pile of coasters.
Re: Burning \ Making SBI's
Alright, first: thanks for the DcHakker \ Demo Menu, nice coaster one, btw.
Second: now when I boot with either DcHakker, or Demo Menu, all the bin files that I've compiled don't work.
I'm simply compiling (without error) the example's that were included in this rar:
http://la.cible.free.fr/DreamCast/De...%2B%2B-0.2.rar
I've put the tunnel and PNG binaries (both scrambled and unscrambled) on a disc, and neither DcHakker or Demo Menu will load them, sometimes it will reset the Dreamcast, other times it will just lock up.
I'm not sure what these examples do, as they aren't documented (but the source is commented enough that I can get an idea), but if anyone has these compiled I would like to see if I could load your binaries, and if you have gotten this to work, how did you do so?
I'm really happy to see that Dreamcast uses OpenGl for graphics, as I love working with gl..
But back on topic, if anyone has any ideas as to why I can't get Dev-C++ to compile working examples, I would appreciate the info.
Thanks,
)>- PS2Atari -<(
EDIT:
After a bit of research, I found that the problem might be the way that I'm linking.. I have to link startup.o first?
this is what my .mak file looks like:
[hr]
LIBS2 = $(patsubst startup.o, ,$(LIBS))
BIN2 = $(patsubst %.elf,%.el2,$(BIN))
RBIN = $(patsubst %.elf,%.bin,$(BIN))
FBIN = 1st_read.bin
romdisk.img :
genromfs -f romdisk.img -d romdisk -v
romdisk.o : romdisk.img
bin2o romdisk.img romdisk romdisk.o
all-before : romdisk.o
$(BIN2) : $(BIN)
$(CC) startup.o $(LINKOBJ) -o $(BIN2) $(LIBS2)
Strip : $(BIN2)
sh-elf-strip $(BIN2)
$(RBIN) : Strip
sh-elf-objcopy -O binary $(BIN2) $(RBIN)
all-after : $(RBIN)
scramble $(RBIN) $(FBIN)
[hr]
If you see any problems with that, can you please correct me? so that the BIN files can be launched? Thanks!
Re: Burning \ Making SBI's
I found the source of my problems, this is something important, and should be noted:
The .mak script I used (above) worked fine. the error was actually within DcHakker \ Demo Menu
if you have a cd, with the directories like so:
root\tunnel\
root\binarys\tunnel\
root\tunnel_2\tunnel\
root\test\tunnel\
if you try to "explore" binarys, tunnel_2 or test, the files inside wont show, instead the contents of root\tunnel will show.
so I kept recompiling and burning different link combos.. turned out that it was infact just running the same (first) binary each time, I never actualy got to access the newer files until I made an entirely new directory name.
Knowing DcHakkers \ Demo Menus glitches is something newbs like me should be aware of!
anyway the demo's compile fine now, and execute no problem.
I look forward to developing for DC, thanks all.