Hmm cdvd_info works for me:
There are problems trying to inject from MacOS X though :-(
$ hdl_dump cdvd_info mame.iso
"PS2MAME.ELF" "MAME" 48326KB
Net access "Not a PS2 Hard drive"
Local access "Not a PS2 Hard drive"
are up shits creek...
Can anyone tell me where I'm going wrong?
cpu endian issues
I've noticed that the code appears heavily dependant on cpu specific integers.
I've been hacking the code to perform byte swapping and have "toc" and "hdl_toc" commands working on a big endian cpu (OSX/PPC) but it's all hard coded so these hacks won't work for little endian cpus. I guess you could make a #define or detect it at runtime.
It could take someone who doesn't know the code quite sometime to find all the ints and shorts that need swapping. I've been finding them by trial and error but I'm sure if I miss any I may end up with a corrupted harddisk instead.
Maybe someone who is more intimately involved with the code could make it more independently cpu endian friendly.
So what needs to be done is to make the code endian independant?
In case I did not post it before, this:
is what I added to the top of "osal_unix.c" it makes: cdvd_info work, I believe.
#if defined ( __APPLE__ )
# define _BUILD_UNIX
# define lseek64 lseek
# define stat64 stat
# define open64 open
# define off64_t off_t
# define fstat64 fstat
# define O_LARGEFILE 0
And I have strange feeling that 32-bit is pre MacOS X when it comes to disk stuff,
while 64-bit is the same as MacOS X when it comes to disk addressing.
I'm not sure if this is the right approach.
If you are on a machine with a different byte ordering than the machine that you are reading binary multibyte numerical values (int and short), you must byte swap that value before you can do any numerical operations on it.
I assume that you all know the difference between a big endian machine and a little endian machine? The mips cpu is little endian, and so is the x86 cpu so the code works easily on x86 based machines. However if you attempt to compile this code on a big endian cpu (PPC, Sparc, Alpha etc) the code will not work as all the values will be interpreted incorrectly.
for example, this is the code that defines the Partition magic number;
for the code to work on a big endian cpu the it looks like this; of course this doesn't work on a little endian cpu.
#define PS2_PARTITION_MAGIC 0x00415041 /* "APA\0" */
#define PS2_PARTITION_MAGIC 0x41504100 /* "APA\0" */
and here is the checksum routine from apa.c re-written for a big endian cpu...
There is probably a better way to swap the bytes, than my quick hack.
u_int32_t llsbmsb (u_int32_t b)
unsigned char *c,t;
c = (unsigned char*)&b;
t=c; c=c; c=t;
t=c; c=c; c=t;
apa_partition_checksum (const ps2_partition_header_t *part)
const u_int32_t *p = (const u_int32_t*) part;
register size_t i;
u_int32_t sum = 0;
for (i=1; i<256; ++i)
sum += llsbmsb(p[i]);
So everytime you make reference to a 16 or 32 bit value that is read from the harddisk you must swap it but only if the machine you are running on is a different endian than the machine that the data was read from.
I hope I've explained the problem well enough.
To summarise. you need to test that you are on a big endian machine and if you are, you need to swap any 16 or 32 (or 64) bit values that you read from the harddisk.
Actually I've just had a thought, the command 'ntohl' performs a similar operation. As network byte ordering is big endian, the above function does nothing on a big endian cpu but byte swaps on a little endian cpu. You could probably put that function into my llsbmsb (and call the function mipstohl) on a little endian cpu it would swap the bytes twice, thus doing nothing and on a big endian cpu would swap them once, making the function endian independent. I'll re-write apa.c to be independent... I'll see how I go.
It's great to see that you guys are tring to make some progress on this! I'd love to see a OS X or Linux version available.
I *think* I have it working.
I've made modifications to hdl.c and apa.c, the code will work on both PPC and x86, I'm not sure how people would like these mods. I can put the c files or diffs up somewhere. Let me know.
I have tested;
toc, hdl_toc, extract
extract (over a network) seems to be horribly slow, I'm getting 80k/s so it will take about 15 hours to transfer a 4gig image to see that it is working. I'll let you kno, if it works, in a day.
I'd love to test it out over network and locally on my Linux machine and OS X machine. Please post the full or diff files here. I believe that's ok to post, if not, please PM me.
What would be nice to test is inject of homebrew, as that is my major concern...
I'd like MAME and SNES loading from HDLoader.
I'm not game enough to try writing to the harddisk, I have no idea if I've missed anything and that it may corrupt your harddrive. You can find my modified code in the link below.
I've put the 64 bit file defines in osal.h
I wasn't sure where to put the LSB<->MSB functions. I've stuck them in apa.c and put the prototypes in common.h, there should be a better place for it, but...
It was modified from this version "0.7.3 - 20040926"
Hope this helps.
Hmm I might have a disk that fits the purpose, I have a 3 GB HD but it has bad blocks :-(
Will HDLoader attempt to use them or mark them bad?
Please continue this thread here: http://www.psx-scene.com/forums/showthread.php?t=29071