diff options
| -rw-r--r-- | FAQ-cd.txt | 959 |
1 files changed, 684 insertions, 275 deletions
@@ -1,16 +1,127 @@ + ._. _____ .____. __ + .JNNNN) (NNNN_. NNNNNNNNNNNNL .NNNNNNNNL JNNNNNNNN. (NN + .NNNNNNN) NNF4NNNL NNNNNNNNNNNNF .NNNF" "4NN JNNN"` `"NN) NN) + JNN" `NF (NN `NNN. NN) (NNF (NN NNN` NN) (NN + .NNF NN) 4NN (NN JNN` (NN .NNF NN) NN) + (NN` (NN (NN JN) (NN` .NN` NNF JNF (NN + (NN` NN) (NF ._____. NN NN) NNF (NN (NN` NN` + NN) (NF .NN` NNNNNN` (NF (NN .NNF NN) JNN` (NF + (NN _N) NN` JNN` NN` (NN. JNNF NNL .NNN` NN` + (NNN_JNNNN` (NNN__NNNNF` (NF `NNNN__NNNN` 4NNNL_JNNNF (NN_NNNNN)N + 4NNNNNF` `NNNNNNNF` 4N` `NNNNNNF` 4NNNNNN" NNNNNNNN" N + + @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ + @###########################################################@ + @# #@ + @# C D - T O O L #@ + @# #@ + @# F R E Q U E N T L Y A S K E D Q U E S T I O N S #@ + @# #@ + @###########################################################@ + @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -Q: What is this tool aimed at anyway? + +INTRODUCTION +------------ + +§ Do I have to know something really specific to read this FAQ ? +§ What is this tool aimed at? +§ What is an ISO image by the way? +§ Are all ISO formats handled? +§ Is Nero's file format supported? +§ Why? Nero is a wide-spread software! +§ What is this tool/library able to do? +§ I have heard CDmage or ECCRegen can also correct the sectors for me. +§ So, what is the goal of this software? + + +RUNNING CD-TOOL +--------------- + +§ Well... er... How do I run cd-tool ? +§ Is there something elese I should know when using the 'cd-tool' command ? +§ I found a bug in your software. What should I do ? + + +LEGAL INFORMATION ABOUT THE CODE +-------------------------------- + +§ Where does the source code for the CRC/ECC comes from? +§ Do you have the right to do so? +§ What a strange name, 'yazedc' +§ So, I can modify your code too, create a new tool, and diffuse it? + + +STRUCTURE OF A CD-ROM +--------------------- +§ With which information did you write this software ? +§ So, what is exactly the format of a CD-Rom? + - Books + - General information about a CD sector + * sync bytes + * localisation + * mode byte + * subheader + * CN Byte + * CI Byte + + +INFORMATION ABOUT LUA API +------------------------- + +§ What is with all this LUA stuff? +§ What is your LUA API? + - Basic layer + - Objects and Files + - Handles + - CD Specific Classes + * cdutils + * Direntry + * cdfile + - ISO reconstruction + * cddate + * PVD + * DirTree + * isobuilder + * Extra isobuilder methods + - Example +§ Tell me more about the 'interactive' Option, please. +§ What patch did you apply to the LUA compiler? + + +LIST OF OBJECTS, FUNCTIONS, ETC. DESCRIBED IN THIS FAQ +------------------------------------------------------ + + +CREDITS +------- + + + + +%%%%%%%%%%%%%%%%%% +% % +% INTRODUCTION % +% % +%%%%%%%%%%%%%%%%%% + + +Q:Do I have to know something really specific to read this FAQ ? +A:It should be better for you to know about LUA and how to handle it. + + +Q: What is this tool aimed at? A: It is designed to handle ISO images you make from CDs. -Q: What is an ISO image anyway? +Q: What is an ISO image by the way? A: You can create an ISO with free tools like cdrdao in raw mode, or others, like cdrwin, CloneCD, etc... -Q: Are all the ISO formats handled? +Q: Are all ISO formats handled? A: No. Only raw-2532 images files. Always the file format outputted by CloneCD and cdrwin, and the format outputted by cdrdao with the --read-raw option. @@ -19,25 +130,25 @@ Q: Is Nero's file format supported? A: No. -Q: Why? Nero's a spreaded software! -A: It's a commercial tool. Since I don't use any commercial tool, and that no - GPL software generates Nero ISO, it won't be supported. +Q: Why? Nero is a wide-spread software! +A: It is a commercial tool. Since I do not use any commercial tool, and that no + GPL software generates Nero ISO, it will not be supported. -Q: What is this tool/library able to? -A: First, you can read/write sectors from/to an iso file. You can also read - informations about an iso file. You can extract/insert files from/to - an iso file. Depending upon the mode you'll be using, it will compute - the right CRC/ECC code for the given sector. The whole in the following - (eventually mixed) modes: MODE_1, MODE_2, MODE_2_FORM_1, MODE_2_FORM_2. - Additionnaly, it is able to produce patches (.ppf files) instead modifying - the iso file, saving you time when you use the right softwares. - Actually, it is quite "oriented" on the MODE_2* formats, since it's - the PSX's formats. And now, it is able to interpret LUA scripts. +Q: What is this tool/library able to do? +A: First, you can read/write sectors from/to an ISO file. You can also read + information about an ISO file. You can extract/insert files from/to + an ISO file. Depending upon the mode you will be using, it will compute + the right CRC/ECC code for the given sector. Everything I just said can be + done in the following (eventually mixed) modes: MODE_1, MODE_2, MODE_2_FORM_1, + MODE_2_FORM_2. Additionnaly, it is able to produce patches (.ppf files) + instead of modifying the ISO file, saving you time when you use the right + softwares. Actually, it is quite "oriented" on the MODE_2* formats, since it + is the PSX's format. And now, it is able to interpret LUA scripts. -Q: I've heard CDmage or ECCRegen can also correct the sectors for me. -A: Maybe. Since they only run on Win32 platforms, I've never tried them. +Q: I have heard CDmage or ECCRegen can also correct the sectors for me. +A: Maybe. Since they only run on Win32 platforms, I have never tried them. Q: So, what is the goal of this software? @@ -47,35 +158,99 @@ A: To modify (patch) ISO images. Nothing else. And of course I want it free, can find in DevC++) + +%%%%%%%%%%%%%%%%%%%%% +% % +% RUNNING CD-TOOL % +% % +%%%%%%%%%%%%%%%%%%%%% + +Q: Well... er... How do I run cd-tool ? +A: This software is command-line based. So, you have to use it this way + (open a Dos window when using Windows) : + + cd-tool [options] [lua-script1] [lua-script2] ... + + Options: + -v for verbose mode. + -f <iso> to load an initial iso file (object cdutil). + -w to open the previous iso file in write mode. + -o <iso> to start creating an output iso (object iso). + -a <paq> to load an additionnal archive file. + -c <out> to dump the compiled byte code to file. + -d to enable debug mode (ie, do not strip) + -i to start interactive mode. + -l to turn off the exec on end line. + -e <cmd> to execute this single command in LUA. + -b to force the use of the built-in cd-tool.lua + -p to run a CD device probe. + -h for a help page. + + +Q: Is there something elese I should know when using the 'cd-tool' command ? +A: Yes... Actually, it seems important to me that you know that : when starting, + cd-tool will automatically load the "cd-tool.lua" file. If it cannot find it, + it will load the built-in copy instead. You should know that this file contains + lots of useful functions that will speed up your work. + + So, I advise you to read the "cd-tool.lua" file in order for you to : + -> have other LUA-coding examples + -> know the list of the functions contained in this file + -> write (and, if you feel like it, send me ;)) new functions + + +Q: I found a bug in your software. What should I do ? +A: Please report it to me, using my email address : pixel@nobis-crew.org + But, please, send me a versatile bug report. Don't waste my time with "It hung + up" or "it doesn't work". In order for me to be able to process a bug, I need to + fully know the context in which this bug occurs, so, don't hesitate to send me + all the infos you can. Moreover, if you can reproduce this bug, please provide me + a lua source code that hits the bug. + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% % +% LEGAL INFORMATION ABOUT THE CODE % +% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + Q: Where does the source code for the CRC/ECC comes from? A: Originally, it has been taken from cdrdao. Yazoo has given some - modifications to it. Then I've cleaned it up and made some minor + modifications to it. Then I have cleaned it up and made some minor modifications on my self. The source code was called 'yazedc'. Q: Do you have the right to do so? -A: The software is GPL'ed. I've got the right to give modified versions - of it, as long as I don't claim the modificated thing it the original, +A: The software is GPL'ed. I have got the right to give modified versions + of it, as long as I do not claim the modificated thing is the original, and as long as I mention the original authors in it. Q: What a strange name, 'yazedc' ? -A: I've got my own ideas about the name's origin... The easy solution: +A: I have got my own ideas about the name's origin... The easy solution: "YAZoo EDC", where EDC is the field name of one of the things it will - recompute. But there is a more... complicated solution I won't give. + recompute. But there is a more... complicated solutions I will not give. Q: So, I can modify your code too, create a new tool, and diffuse it? A: Yes, as long as you give me back your changes if I ask them, that the new software is also GPL'ed, and that you mantion me as the original - writer of the software, you can. Read the GPL carefully, it's very + writer of the software, you can. Read the GPL carefully, it is very interesting and instructing. -Q: With which information What is exactly the format of a CD-Rom? + +%%%%%%%%%%%%%%%%%%%%%%%%%%% +% % +% STRUCTURE OF A CD-ROM % +% % +%%%%%%%%%%%%%%%%%%%%%%%%%%% + +Q: With which information did you write this software ? A: Firstly, when you have a raw sector, you have to understand its primary form. - Secondly, the whole CD has an internal format, called the iso9660. The format - of the iso9660 is easy to find on the internet. Here is one first easy link: + Secondly, the whole CD has an internal format, called the ISO9660. The format + of the ISO9660 is easy to find on the internet. Here is one first easy link: http://www.ccs.neu.edu/home/bchafy/cdb/info/iso9660.txt Then you have two more difficult documents: http://www.ecma.ch/ecma1/stand/ecma-119.htm @@ -85,10 +260,16 @@ A: Firstly, when you have a raw sector, you have to understand its primary form. All those links were taken from the page http://www.ccs.neu.edu/home/bchafy/cdb/info/info.html - The sector format is a bit complicated to find on the internet. Here is what - I've found. - - First you have to know that there is many formats that describe the sector's +Q: So, what is exactly the format of a CD-Rom? +A: The sector format is a bit complicated to find on the internet. Here is what + I have found. + + +--------- +- BOOKS - +--------- + + First you have to know that there are many formats that describe the sector's organisation. Those are called "Books". There is the Red Book, the Yellow Book, the Blue Book, the Green Book, the Orange Book, and the White Book. @@ -97,26 +278,37 @@ A: Firstly, when you have a raw sector, you have to understand its primary form. for CD-R cds. And the White Book seems to be a replacement of the Green one. This is quite unclear and you have to actually buy the books since they - aren't in public domain. + are not in public domain. - So the informations I'll give comes from various source of various free + So the information I will give comes from various source of various free softwares. Should I mention two: cdrdao http://cdrdao.sourceforge.net and ECCRegen http://web.tiscali.it/eccregen as the most useful sources. + +----------------------------------------- +- GENERAL INFORMATION ABOUT A CD SECTOR - +----------------------------------------- + Here is the general form of a CD-Rom sector: <--------------------------- sector: 2352 bytes ------------------------------> <- Header: 16 bytes -><---------------- Datas: 2336 bytes --------------------> - Let's move to the header description: + Let us move to the header description: <--------------------------- header: 16 bytes ------------------------------> <-- sync bytes: 12 bytes --><-- localisation: 3 bytes --><-- mode: 1 byte --> + +** SYNC BITES ** + The sync bytes are easy: it is always 00 FF FF FF FF FF FF FF FF FF FF 00 They are supposed to help the CD reader to synchronize enough to be able to read the sector correctly. + +** LOCALISATION ** + The localisation is the sector "position" described in time. For example, the sector 200000 of a CD is at the "time" 44:28:50. The first is the number of minutes, the second is the number of seconds, in the range 0-59 and the @@ -129,9 +321,9 @@ A: Firstly, when you have a raw sector, you have to understand its primary form. <-------------------- localisation: 3 bytes --------------------> <-- minute: 1 byte --><-- second: 1 byte --><-- frame: 1 byte --> - That's seems to be all right *BUT* the fact is that the bytes are stored + That seems to be all right *BUT* the fact is that the bytes are stored in packed BCD format. You may know what the BCD format is if you are "old" - enough for that. I won't enter into the details so if you want a more + enough for that. I will not enter into the details so if you want a more detailed description of the BCD format, look into the net. You only have to know that: typedef unsigned char uchar; @@ -141,54 +333,60 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} Last hint: when you look at a BCD packed number, you have to read it in hexadecimal, and then you will see a "decimal" number. So when you count - in BCD, you'll have this: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, - 0x08, 0x09, 0x10, 0x11, 0x12, etc... You see? You've got a "gap": no 0x0a, + in BCD, you will have this: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, + 0x08, 0x09, 0x10, 0x11, 0x12, etc... You see? You have got a "gap": no 0x0a, 0x0b, 0x0c, etc... So the BCD is only a trick for an easy reading of hexa - dumps of various informations. + dumps of various information. + + +** MODE BYTE ** All right. This was for the localisation part. The last part is the mode byte. It is really simple actually. It is 0 for an empty sector, 1 for a sector in MODE1, and 2 for a sector in MODE2. Easy as hell. - Ok here we are: we know the basic form of a CD's sector, and even know the - MODE of the sector. Now the datas depends upon the sector mode. Here you have + Ok here we are: we know the basic form of a CD sector, and even know the + MODE of the sector. Now the data depend upon the sector mode. Here you have the various kinds: - <-------------- MODE 1 FORM 1 Sector datas: 2336 bytes ----------------------> - <- datas: 2048 bytes -><- EDC: 4 bytes -><- 0s: 8 bytes -><- ECC: 276 bytes -> + <-------------- MODE 1 FORM 1 Sector data: 2336 bytes ----------------------> + <- data: 2048 bytes -><- EDC: 4 bytes -><- 0s: 8 bytes -><- ECC: 276 bytes -> - <---------- MODE 1 FORM 2 and also MODE 2 Sector datas: 2336 bytes ----------> - <----------------------------- datas: 2336 bytes ----------------------------> + <---------- MODE 1 FORM 2 and also MODE 2 Sector data: 2336 bytes ----------> + <----------------------------- data: 2336 bytes ----------------------------> - <-------------- MODE 2 FORM 1 Sector datas: 2336 bytes ----------------------> - <- SH: 8 bytes -><- datas: 2048 bytes -><- EDC: 4 bytes -><- ECC: 276 bytes -> + <-------------- MODE 2 FORM 1 Sector data: 2336 bytes ----------------------> + <- SH: 8 bytes -><- data: 2048 bytes -><- EDC: 4 bytes -><- ECC: 276 bytes -> - <-------------- MODE 2 FORM 2 Sector datas: 2336 bytes ----------------------> - <- SH: 8 bytes -><---------- datas: 2324 bytes ----------><- spare: 4 bytes -> + <-------------- MODE 2 FORM 2 Sector data: 2336 bytes ----------------------> + <- SH: 8 bytes -><---------- data: 2324 bytes ----------><- spare: 4 bytes -> - Well, I *really* don't know how to distinguish the different "FORMS" from - each others for the MODE 1. Have to look further for this. - - The ECC and EDC are controls blocks. The yazedc code can compute them, so - don't worry about them. + Well, I *really* do not know how to distinguish the different "FORMS" from + each others for the MODE 1. Have to look further about this. + The ECC and EDC are control blocks. The yazedc code can compute them, so + do not worry about them. + + +** SUBHEADER ** + The 'SH' (SubHeader) field is the most "complicated" one. Those eight little - bits are the only one I'm really not sure of. All of that because you have to + bits are the only one I am really not sure of. All of that because you have to buy the Books to find the information. This SubHeader is only found into MODE_2_FORM_1 and MODE_2_FORM_2 sectors. - Here you have the informations I've been able to gather: + Here you have the information I have been able to gather: - -) The SubHeader has 8 bytes, but it's twice the same 4 bytes. + -) The SubHeader has 8 bytes, but it is twice the same 4 bytes. -) The 4 bytes are described using the following fields: o) 1st byte: File Number (FN) o) 2nd byte: Channel Number (CN) o) 3rd byte: Sub Mode (SM) - o) 4st byte: Coding Info (CI) - -) The SubHeaders seems to be very important when dealing with STR files, - since it's the only way to distinguish a video sector from an audio - sector. But it seems that it doesn't matter when dealing with normal - files. It might be obvious since the iso9660 format doesn't care about + o) 4rth byte: Coding Info (CI) + -) The SubHeader seems to be very important when dealing with STR files, + since it is the only way to distinguish a video sector from an audio + sector. But it seems that it does not matter when dealing with normal + files. It might be obvious since the ISO9660 format does not care about those bits. But better try to patch them if necessary... -) The Sub Mode byte is a bit field which seems to be described like this: 0: End of Record (EOR) @@ -200,79 +398,98 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} 6: Real Time (RT) 7: End of File (EOF) - Of course, the PSX has the CDs in MODE 2... So the common files are - stored in MODE 2 FORM 1, the STR/XA files are stored in "MODE 2" but + Of course, PSX CD's are recorded in MODE 2... So common files are + stored in MODE 2 FORM 1, STR/XA files are stored in "MODE 2" but actually they are in MODE 2 FORM 1 and 2. The MOVCONV tool will in fact - produce files that does contain the subheaders. + produce files that contain the subheaders. - Those subheaders are very likely to vary, and seems to be very important for + Those subheaders are very likely to vary, and seem to be very important for stream processing. Please note that "str" video sectors are considered as data sectors, and not as video sectors. - + + +** CN BYTE ** + The CN byte indicates the channel number of the current sector. The XA format may contain interlaced channels. So for example, if you have a - file that does contain 8 channels, you will have first the first sector + file that contains 8 channels, you will have first the first sector of the channel 0, then the first sector of the channel 1, etc... This is also a bit more difficult when you know that video is also interlaced and considered as a channel itself. The common interlacement is 7 video sectors for 1 audio sector, but this may vary. And all the - channels may be completely independants. For example, you may have a - sound-free video that does contain an audio channel, this audio channel + channels may be completely independant. For example, you may have a + sound-free video that contains an audio channel, this audio channel may be used for another part in the game. This is to optimize the reading process. Since the cd reader is a 2x cd reader, it *HAS* to read data in full 300KBps. So, if you have a sound free video, the reading process will be faster than the decoding process, and everything should crash. This is about the same for the audio sectors. - The 'leap' sector function of MOVCONV does add blank sectors in order to + The 'leap' sector function of MOVCONV adds blank sectors in order to pad the channels that may have stopped before the others. - One "speed" of the CD reader corresponds to four time the playback speed + One "speed" of the CD reader corresponds to four times the playback speed of a stereo audio channel at 37800Hz. So at full speed you can have eight stereo audio channels at 37800Hz. Or you can have 32 mono audio channels at 18900Hz. - Common video str files needs 7/8 of the full speed of the CD reader. + Common video str files need 7/8 of the full speed of the CD reader. "Common" means 320x224 videos at 15fps. So you can have a full movie in 320x224x15fps with a stereo sound track at 37800hz. So, now, you may understand why the common interlacement may vary. + + +** CI BYTE ** - The CI byte does contains some flags about the current sector, but I'm - yet unable to give a full description of them. I've only got this: for + The CI byte contain some flags about the current sector, but I am + yet unable to give a full description of them. I have only got this: for XA audio sectors, the bit 0 is set when you have stereo sound, and the bit 2 is set when you have "half frequency", ie 18900Hz instead of 37800Hz. The Video frames are in plain Form 1, and the Audio frames are in plain Form 2. But it _seems_ the Video frames are not checked against ECC/EDC, - and filled with zeros instead. + and filled with zeroes instead. - The last but not the least: the MODE 2 FORM 1 and MODE 2 FORM 2 are also - called XA-Mode1 and XA-Mode2 or simplier: XA-1 and XA-2. + Last but not least: MODE 2 FORM 1 and MODE 2 FORM 2 are also called + XA-Mode1 and XA-Mode2 or simplier: XA-1 and XA-2. I hope this will help you as it helped me writing this software. -Q: What's with all this LUA stuff? -A: LUA is a scripting language. There, in cd-tool, it enables you to create + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% % +% INFORMATION ABOUT LUA API % +% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +Q: What is with all this LUA stuff? +A: LUA is a scripting language. Here, in cd-tool, it enables you to create custom patches, or evoluted "mini softwares". If you want to use it, you first have to learn how LUA works and how you can program it. Look at the - official web site for more informations about this language: www.lua.org + official web site for more information about this language: www.lua.org Please, do not bug me about LUA syntax. The huge load of documentation about this language should be really enough. -Q: What's your LUA API? +Q: What is your LUA API? A: First of all, my LUA distribution is the 5.0, slightly modified. The basic LUA compiler is not able to understand hex or octal numbers. I made a patch - of my own to add this support. You'll find this patch at the very end of + of my own to add this support. You will find this patch at the very end of this document. - + + +--------------- +- BASIC LAYER - +--------------- + Now, for the API itself. As basic layer, there are some functions that you will surely need. Those are "andB", "orB", "xorB", "notB", "shr" and "shl". - The and, or, xor and not are there because there is no binary equivalent of - those functions into native LUA. The two others, shr and shl, are - respectively "shift right" and "shift left". All the functions work + The "and", "or", "xor" and "not" are there because there is no binary + equivalent of those functions into native LUA. The two others, "shr" and "shl", + are respectively "shift right" and "shift left". All the functions work internally using 32 bits unsigned integers. There is a little 'debug' function that can help: "hex". Its syntax is: @@ -284,10 +501,18 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic So, you can actually mess up with the format, and display something else than plain hexa. And even cause the C host to crash, if you put an incorrect format string. + + + When needed, you can use this function (very useful, heh) : + + load([script]) + + will load a LUA script where script can be a handle (see below), + or a filename, which defaults to "cd-tool.lua". - - You also have a "print" function, which takes a string as arguement. Its - display form is platform independant (a newline is automatically added) + + You also have a "print" function, which takes a string as argument. Its + display form is platform-independant (a new line is automatically added) but for this actual version of CD-Tool, will only be displayed on verbose mode (option -v in the command line) @@ -298,18 +523,23 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic base, math, string, table Please read the LUA manual about those libraries. (Note that the "print" - function of the base library is not here, and is replaced with mine) - - Let's talk about objects now. My API supports two kind of objects. Objects + function of the "base" library is not here, and is replaced with mine) + + +--------------------- +- OBJECTS AND FILES - +--------------------- + + Let us talk about objects now. My API supports two kind of objects : objects created from within LUA, and objects exported from the C++. Usually, the objects created by LUA will be destroyable. It means they have a garbage - collector metamethod, and also a ":destroy()" method, to forcabily destroy - the object. The objects exported by the C++ code will be NOT destroyable, + collector metamethod, and also a ":destroy()" method, to forcibly destroy + the object. The objects exported by the C++ code will NOT be destroyable, and any try to call the :destroy() method will just fail. - Now, about files. My API supports three "kind" of files. Input files, + Now, about files. My API supports three "kinds" of files. Input files, Output files, and Buffers. Each of them have exactly the same API. The - Buffer one has one more feature that I will discuss below. But first, + The Buffer one has one more feature that I will discuss below. But first, here are the constructors. Input(filename) @@ -318,10 +548,15 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic The variable 'filename' is a string, and 'seekable', a boolean. All those three functions will return what I call a "handle". Several functions of - the API will take those handles as arguments. The variable seekable is - false by default. A non-seekable buffer is a fifo. You won't be able to - seek through it. But it will take less memory than a seekable one. - Output will always create an empty file, erasing any existing one. + the API will take those handles as arguments. The variable 'seekable' is + false by default. A non-seekable buffer is a "FIFO". You will not be able + to seek through it. But it will take less memory than a seekable one. + 'Output' will always create an empty file, erasing any existing one. + + +----------- +- HANDLES - +----------- Now, what you can do with handles. Well, here you have all the "methods" you can call on these handles: @@ -365,17 +600,17 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic Will read up to 'size' bytes from the given handle, and put them inside of the calling handle. If not present, size will be "-1", which means - "up to the end". The 'source' handle will then be closed (since it hit + "up to the end". The 'source' handle will then be closed (since it hits the end of file) :copyto(handle[, size]) - This is just the countrary of the function above. And to conciliate minds, + This is just the contrary of the function above. And to conciliate minds, I also have the following global function: copyhandle(source, destination[, size]) - which has still the same meanings than above. + which has still the same meaning than above. Now for some booleans methods: @@ -396,23 +631,23 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic :getsize() - Will return the handle size in bytes. If it's a Fifo, it will return the + Will return the handle size in bytes. If it is a Fifo, it will return the number of remaining bytes. :close() - Will close the file, and flush the remaining datas in caches. + Will close the file, and flush the remaining data in caches. :flush() - Will only flush any datas remaining in caches. + Will only flush any data remaining in caches. :seek(pos[, wheel]) - Will seek the file pointer at position "pos". The wheel argument is here to - tell from which point of view "pos" should be seen. By default, wheel is - SEEK_SET, which tells that "pos" is referring from the start of the file. - But you can also have SEEK_CUR, which says that "pos" is referring from the + Will seek the file pointer at position "pos". The "wheel" argument is here + to tell from which point of view "pos" should be seen. By default, "wheel" + is SEEK_SET, which tells that "pos" refers to the start of the file. + But you can also have SEEK_CUR, which says that "pos" refers to the actual file pointer. And SEEK_END, which will then make "pos" to be seen as a relative position from the end of the file. Thus, having a negative value for "pos" is completely legal. It will return the actual file pointer. @@ -425,7 +660,7 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic a Buffer will simply fail. When a handle is :setz(), any further read or write will be transparantly made through the zlib. Thus, if you open an Output file, and immediately specify a :setz() on it, it will produce a - .gz file, that you can decompress using a lot of well known decompressor + .gz file, that you can decompress using a lot of well known decompressing softwares. @@ -435,25 +670,33 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic work with the writing pointer. Moreover, you can access a seekable buffer as an array, starting from 0. + + +----------------------- +- CD SPECIFIC CLASSES - +----------------------- + + That is all for basic files. Let us move out to CD specific objects. Here are + the basic "types" we will work with: - That's all for basic files. Let's move out to CD specific objects. Here are - the base "types" we will work with: - - cdutils, direntry, cdfile, cddate, PVD, DirTree, and isobuider. - - Let's discuss them now. A "cdutils" is usually created from "cd-tool", and + cdutils, direntry, cdfile, cddate, PVD, DirTree, and isobuilder. + + +** CDUTILS ** + + Let us discuss them now. A "cdutils" is usually created from "cd-tool", and passed to the LUA script as the "cdutil" variable. This object holds the - power to read, and eventually write to the iso file, or CD device the user + power to read, and to write to the ISO file, or the CD device that the user specified as argument. Of course, if the user specified a device, you will - not be able to write to it. The LUA code can not create a cdutils object. - Coming with the cdutils object are some global variables. These are: + not be able to write to it. The LUA code can not create a "cdutils" object. + Coming with the "cdutils" object are some global variables. These are: MODE0 = 0, MODE1 = 1, MODE2 = 2, MODE2_FORM1 = 3, MODE2_FORM2 = 4, MODE_RAW = 5, GUESS = 6 They should be used each time a "mode" is needed as a sector mode argument. - Many methods of cdutils will ask an optionnal "mode" argument, and will + Many methods of 'cdutils' will ask an optionnal "mode" argument, and will default to "GUESS" if not specified. You can also access these three helpers arrays: @@ -461,15 +704,15 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic sec_sizes, an array of sector sizes, depending on the mode sec_offsts, an array of the actual start point of the sector inside the raw sector, and - sec_modes, an array of strings that describe the sector modes. + sec_modes, an array of strings that describes the sector modes. - The least but not the last, it comes with these functions: + Last but not least, it comes with these functions: - swapword(number) swap endianness of given 16 bits number - swapdword(number) swap endianness of given 32 bits number + swapword(number) swaps endianness of given 16 bits number + swapdword(number) swaps endianness of given 32 bits number - from_bcd(number) convert byte from BCD notation - to_bcd(number) convert byte to BCD notation + from_bcd(number) converts byte from BCD notation + to_bcd(number) converts byte to BCD notation is_valid_bcd(number) returns a boolean from_msf(msf[, start) @@ -477,8 +720,14 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic converts a MSF sector address into a plain sector number. By default, "start" is 150 (a CD usually starts at 0:02:00, which is 150 sectors) - - The methods of the cdutils object are: + + to_msf(sector[, start]) + converts a plain sector number into a MSF sector address. + By default, "start" is at 150. The function will actually + return 4 numbers, as in: (msf, m, s, f) = to_msf(sector) + + + The methods of the "cdutils" object are: :sectorseek(sector) @@ -492,35 +741,52 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic :readsector([sector[, mode]]) - Will return an array containing the user datas for the specified sector. - It means that, if "mode" is different of MODE_RAW, that only the user part + Will return an array containing the user data for the specified sector. + It means that, if "mode" is different of MODE_RAW, only the user part of the sector will be returned. - :readdatas(size[, sector[, mode]]) + :readdata(size[, sector[, mode]]) - Will return an array containing the user datas for the sectors starting at - "sector", by only reading the user datas specified by the "mode". + Will return an array containing the user data for the sectors starting at + "sector", by only reading the user data specified by the "mode". :readfile(handle, size[, sector[, mode]]) - Will basically do the same, but will write down the datas to the specified + Will basically do the same, but will write down the data to the specified handle. Will return nothing. :writesector(array[, sector[, mode]]) Will write the array inside the specified sector, using the specified mode. - That is, it will only write inside the user datas of the specified sector. + That is, it will only write inside the user's data of the specified sector. - :writedatas(array, size[, sector[, mode]]) + :writedata(array, size[, sector[, mode]]) Will write "size" bytes from the array inside the sectors starting at - 'sector', writing only inside the user datas parts. + 'sector', writing only inside the user's data parts. :writefile(handle[, size[, sector[, mode]]) Will basically do the same, but will read from the specified handle, up to its end if size equals -1 (default) + :updatesize(path, newsize) and :updatesector(path, newsector) + + Will update the direntry associated to the given path accordingly to its + argument. Warning: no sanity checks are done. You can easily crush the + filesystem if you are not paying attention. + + :createsector(mode, sector) + + Will create a blank sector of given mode and address. This can either be + used to blank one existing sector of the cd, or to add new sectors at the end + of the cd but this is a depreciated action: if you have to enlarge an iso file, + you are encouraged to create a completely new iso, by using the isobuilder + class described below. + + +** DIRENTRY ** + Now, the following methods will return a "direntry" object. I will discuss them shortly after. @@ -528,20 +794,22 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic For the three functions, the "path" is a string. For the definition of a path, it can be a directory name, or a filename. It is absolute if it - starts with a "/". Each subdirectory is separated by a "/". Beware: usual - iso9660 filenames ends with the string ";1" + starts with a "/". Each sub-directory is separated by a "/". Beware: usual + ISO9660 filenames end with the string ";1" and the functions are case + sensitive. So, ":findpath" and ":findparent" will look for the directory entry of the exact path, or the parent containing the path specified in argument. They - will return a "direntry", which is a kind of "dump" of the iso structure + will return a "direntry", which is a kind of "dump" of the ISO structure that corresponds to this entry in the file table. The last function, ":finddirectory()", will look inside of the directory specified as argument for the relative (unique) filename (that can be either a file, or another directory). Beware: if the specified direntry points to a file, and not - a directory, it will fail. - - So, what's a "direntry" object ? It's a destroyable read-only object - returned by these three functions, which contains the infos from the + to a directory, it will fail. + + So, what is a "direntry" object ? It is a destroyable read-only object + returned by these three functions (:findpath :findparent :finddirectory + that we've just discussed about), that contains the infos from the directory entry corresponding to a specific path (a file or a directory) You can read a direntry object as an array, which has the following @@ -558,7 +826,7 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic Minute number - date & time Second number - date & time Offset number - date & time - Flags number - entry flags (see an iso9660 doc) + Flags number - entry flags (see an ISO9660 doc) HandleUnit number - should be 0 HandleGap number - should be 0 VolSeq number - should be 0 @@ -568,7 +836,7 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic Moreover, it has the following boolean methods that can query a direntry: :ishidden() :isdir() - Will query the Flag entry. There are other entries, but I don't + Will query the Flag entry. There are other entries, but I do not think they are useful. :hasxa() @@ -578,46 +846,58 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic If the direntry has an xa entry, this will query it. - Now for a quite interesting object. It's the "cdfile" object. It is a +** CDFILE ** + + Now for a quite interesting object. It is the "cdfile" object. It is a derivate of the "handle" generic object, and thus, will have exactly the same behavior as an "Input" object. The big thing is that this file comes - from inside the iso file directly, with intelligent sector reading (read: + from inside the ISO file directly, with intelligent sector reading (read: it will extract correctly STR files) So, if you remember all the methods of a handle object, I only have to - tell you how to construct a cdfile object. There are two constructors. + tell you how to construct a cdfile object. There are two constructors + that are actually two extra methods in the class cdutils: - cdfile(cdutils, direntry[, mode]) - cdfile(cdutils, sector[, size[, mode]]) + :cdfile(direntry[, mode]) + :cdfile(sector[, size[, mode]]) - The first one is evident. It will simply clone the given direntry object + The first one is obvious. It will simply clone the given direntry object into a readable handle. - The second one is a little bit tricker. You specify a sector number, and + The second one is a little bit more tricky. You specify a sector number, and a filesize. But by default, size is -1, which means "autodetect". Yeah, I know this may sound strange, but, on mode 2 CDs, there are sector flags - that helps delimiting files entries. And since the "tricks" used in games + that help delimiting files entries. And since the "tricks" used in games like Xenogears or Chrono Cross are only directory hiding, those flags were constructed, and are still here. So, the autodetection will try to find the correct file size using these flags. Beware, it may fail, and it will not work at all on mode 1 CDs. + + +---------------------- +- ISO RECONSTRUCTION - +---------------------- - - Okay, I discussed a lot about iso readings, and small patching. Now for - the real thing: iso reconstruction. - + Okay, I discussed a lot about ISO readings, and small patching. Now for + the real thing: ISO reconstruction. + + +** CDDATE ** + First, I have to introduce three structures used actively by the functions. The first is the "cddate" structure. It holds any data necessary to set up - a date for various places in the iso structure. You can read/write the - fields of a cddate. All of them are numbers, and should be - self-explanatory: + a date for various places in the ISO structure. You can read/write the + fields of a cddate. All of them are numbers, and should be self-explanatory: year, month, day, hour, minute, second, hundredths, offset The function "cddate" will return an empty destroyable cddate. - + + +** PVD ** + The second structure I have to introduce is the "PVD" structure, which - stands for "Primary Volume Descriptor". It is the basic datas that every + stands for "Primary Volume Descriptor". It is the basic data that every CD has. As the cddate structure, you can access the PVD structure as an array, which fields are: @@ -636,34 +916,36 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic voleff data - effective volume date The last field, "appdata", is hidden. It is a 512 bytes array which - contains "application datas", usually zeroes. You can access these bytes - directly by using number as indices of a PVD structure. Starting from 0. - SONY usually puts datas in there, so... + contains "application data", usually zeroes. You can access these bytes + directly by using numbers as indices of a PVD structure. Starting from 0. + SONY usually puts data in there, so... In order to create a PVD structure, you have several ways. You can create - an empty PDV using the "PVD" function. But there is also three functions + an empty PDV using the "PVD" function. But there are also three functions that will clone an existing PVD. Those are: createpvd(cdutils) createpvd_handle(handle) createpvd_array(array) - The cdutils one will automatically look for the sector 16 of the input iso - in order to clone it. The two others will just wait 2048 bytes of data + The cdutils one will automatically look for the sector 16 of the input ISO + in order to clone it. The two others will just expect 2048 bytes of data that contain the user data of a PVD sector. - + + +** DIRTREE ** The last useful structure is the "DirTree" structure. It is used for - building the iso directory structure. When finalizing the iso file, these + building the ISO directory structure. When finalizing the ISO file, these structures will be dumped as "direntries". So they mostly have the same fields and meanings. LUA code should not construct DirTrees directly. It is possible though, - through the "DirTree" function. Here's the syntax: + through the "DirTree" function. Here is the syntax: DirTree(father[, isdir]) The "father" argument should be the other DirTree which is the parent of - the newer one, or "nil" to create a root directory (*really* not - recommanded imho. I really do not see why you would do that. Apart of + the new one, or "nil" to create a root directory (*really* not recommanded + in my humble opinion. I really do not see why you would do that. Apart from creating a fake rootsystem, which is doable, but not tested though, and was not designed for it (yet)), The "isdir" argument is a boolean, which defaults to true. You *have* to set it to false in order to create a plain @@ -688,10 +970,10 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic beware: this "mode" entry is to tell how to store the direntry, not the file pointing to it. - father, child, brother are read only entries. They are non destroyable + father, child, brother are read-only entries. They are non destroyable DirTrees and are used to browse the actual directory tree. - The "hardhide" attribute is to tell the system to "not dump" the entry + The "hardhide" attribute is to tell the system "not to dump" the entry when finalizing the CD. Useful for "hidden" filesystems, like Xenogears. And finally, the methods for this object: @@ -713,9 +995,11 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic dir.xa_audio = false dir.xa_dir = dir.isdir - - Pfiew, only one object remaining. Here it is. Its name is "isobuilder". - It will control and administrate the creation process of an iso file + +** ISOBUILDER ** + + Phew, only one object remaining. Here it is. Its name is "isobuilder". + It will control and administrate the creation process of an ISO file by using all of the above structures and functions. You can create one from LUA, but CD-Tool might just give one to your @@ -725,13 +1009,13 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic isobuilder(handle[, mode]) This will return an isobuilder object, that will write everything out to - the specified file, and will create a 2352-raw iso using the given sector + the specified file, and will create a 2352-raw ISO using the given sector mode (mode 2 form 1 by default). Actually, it would be nonsense to put something else than "MODE1" or "MODE2_FORM1" as 'mode' here. I have to explain a bit how this isobuilder object works. You will be able - to "append" datas, and retains the sector numbers where the datas were - storen inside the DirTree structures. So, when you're done with putting + to "append" data, and retain the sector numbers where the data were + stored inside the DirTree structures. So, when you are done with putting your files, the isobuilder object will create all the necessary structures all around the CD, where it spared some space. @@ -741,39 +1025,39 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic :foreword_handle(handle[, mode]) :foreword_array(array[, mode]) - That will create what I call the "forewords" of the CD, ie the 16 first - sectors. The "cdutils" version will automatically takes the 16 sectors - from the input iso. The two others will read the 16 sectors from the - datas you give it, using the specified mode, which defaults to 2352 bytes + This will create what I call the "forewords" of the CD, i.e. the 16 first + sectors. The "cdutils" version will automatically take the 16 sectors + from the input ISO. The two others will read the 16 sectors from the + data you give it, using the specified mode, which defaults to 2352 bytes per sector, that is, exactly 37632 bytes. Next to it, you have the method :setbasics(pvd[, rootsize[, ptsize[, nvd[, rootsect]]]]) - that will create the first structures, and return the root DirTree of your - new iso. By default, rootsize = 1, ptsize = 1, nvd = 1, and rootsect = -1. + this will create the first structures, and return the root DirTree of your + new ISO. By default, rootsize = 1, ptsize = 1, nvd = 1, and rootsect = -1. Please retain the "rootsize" in memory a little bit, we will discuss it right after. "ptsize" is the size of the path table, in sectors. Note that - there is 3 copies of the path table. So, in reality, this number will be + there are 3 copies of the path table. So, in reality, this number will be multiplicated by 4. NVD is the number of volume descriptors. We currently set the "Primary" volume descriptor, and the end marker, at respectively sector 16 and 17. So, if you want more volume descriptors, you should set - this variable to another value, and then start to write your custom volume + this variable to another value, and then start writing your custom volume descriptors at sector 17. Do not forget the end marker, it will always be put at the sector 17, even if you have several volume descriptors. And finally, the rootsect is the sector of the rootdirectory, if you want to place it at a certain sector, and thus, reserving some sectors between the path table and the rootsector. Note that the default value, -1, just - tell to compute it. + tells to compute it. :createdir(dirtree, name[, size[, direntry[, mode]]]) - This will create a subdirectory in the specified dirtree object. Size is - defaulted to 1, direntry to nil, and mode to -1. When creating a directory - the isobuilder will hold one or more sectors for it in the iso file. You - can't really tell by advance how much sectors you need however. But since + This will create a sub-directory in the specified dirtree object. Size is + defaulted to 1, direntry to 'nil', and mode to -1. When creating a directory + the isobuilder will hold one or more sectors for it in the ISO file. You + cannot really tell by advance how much sectors you need however. But since you are creating patches, you should know how much you actually need. So, you have to tell how much sectors you reserve for the directory. This is also true for the root, and thus, the "rootsize" in the :setbasics() @@ -781,53 +1065,56 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic object, when it exists, will help to clone the entry. If "name" is empty, it will also get cloned. If "size" is 0, it will also get cloned. And finally, if "mode" is different from -1, the directory will be stored - using this mode. Otherwise, the mode is the default iso mode specified + using this mode. Otherwise, the mode is the default ISO mode specified in the isobuilder object creation. :createfile(dirtree, name, file[, direntry[, mode]]) This is the companion of the previous method. It will create a file in the - iso, with basically the same behavior. It reads the file from a handle, up - to the end, and append it to the current iso. The argument direntry, if - not nil, will be used to clone the attributes. Even the name if the given - one is "". The file will be immediately stored on disk. The filename will - be automatically be followed by ";1" when dumping, so you don't have to - put it anywhere. + ISO, with basically the same behavior. It reads the file from a handle, up + to the end, and appends it to the current ISO. The argument direntry, if + not 'nil', will be used to clone the attributes. The same goes for the + name if the given one is "". The file will be immediately stored on disk. + The filename will be automatically followed by ";1" when dumping, so + you do not have to put it anywhere. :close([cuefile[, mode[, nsectors]]]) Will finalize the isofile, by dumping all the necessary structures. The - argument 'cuefile' is eventually a handle pointing to an output file where - the ".cue" file used for cdrwin will be put, but this feature is not yet - enabled. mode is there to override the default iso mode, as usual. And - nsector, which is defaulted to -1, will override the number of sector field + argument 'cuefile' is possibly a handle pointing to an output file where + the ".cue" file used for "cdrwin" will be put, but this feature is not yet + enabled. "mode" is there to override the default ISO mode, as usual. And + "nsector", which is defaulted to -1, will override the number of sector field written in the TOC (defaults to :getdispsect()) - + SO, you should only need that. But I also added some methods that you may want/need/etc... - + + +** EXTRA ISOBUILDER METHODS ** + :getdispsect() - This will basically return the iso file size in sectors. + This will basically return the ISO file size in sectors. :putfile(file[, mode[, sector]]) - This will write a bare file onto the iso. By default, mode is -1 and means + This will write a bare file onto the ISO. By default, mode is -1 and means "take the default iso mode", and sector is -1, and means "use the value - returned by :getdispsect()". The function will return the sector number + returned by :getdispsect()". The function will return the sector number that the file was put on. - :putdatas(array, size[, mode[, sector]]) + :putdata(array, size[, mode[, sector]]) Basically the same as above, but with an array of bytes rather than a handle. Beware, still starting at 0. :createsector(array[, mode[, sector]]) - Will write down a sector, by returning the address it was wrote. Array - begining at 0, mode = -1: default mode, sector = -1: use :getdispsect(). + Will write down a sector, by returning the address where the latter was writen. + Array begining at 0, mode = -1: default mode, sector = -1: use :getdispsect(). One interesting info to know about this function, is that, when using - mode 2 form X sectors, it will set basic subheaders, especially the flags + "mode 2 form X sectors", it will set basic subheaders, especially the flags "End of Record" and "End of File". So, when all the other functions will set them, for :createsector, you manually have to specify them using the following methods: @@ -835,7 +1122,7 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic :setEOF() :clearEOF() - Finally, I wrote one "helper" method, though you can't write it yet using + Finally, I wrote one "helper" method, though you cannot write it yet using this API: :copydir(dirtree, cdutils, direntry[, mode]) @@ -843,14 +1130,18 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic This will copy one directory from a cdutils object, inside of the isobuilder object. The argument 'dirtree' is the destination directory, 'cdutils' is the source thing, 'direntry' the directory entry from cdutils - to be copied, and mode is here to override the default mode. It will work + to be copied, and 'mode' is here to override the default mode. It will work recursively. If mode is MODE2_FORM1, and if it encounters a special XA - file stored in plain mode 2, it will compute the necessary datas in order - to correctly copy it. The function doesn't return anything. - - Okay, I presented everything. Now for a quick and simple example of use. - This LUA script, when used with the cd-tool's luapatch command, will act - exactly like the cd-tool's copy command: + file stored in plain mode 2, it will compute the necessary data in order + to correctly copy it. The function does not return anything. + + +----------- +- EXAMPLE - +----------- + + Okay, I presented everything. Now for a quick example of use. + This simple LUA script should show you a bit how cd-tool may be programmed : dir = cdutil:findpath "/" rsize = dir.Size @@ -866,62 +1157,38 @@ A: First of all, my LUA distribution is the 5.0, slightly modified. The basic iso:close() - Pwieew, all done! ;-) - - Well, almost actually. Only a few global functions remains. - - exists(filename) - - Will take a string as argument, and return a boolean to tell if the - corresponding file can be safely opened for reading. + Pwieew, all done. Good luck ! ;-) - bsdecode(handle, width, height) - Will return a buffer to a rgb24 picture (size width * height * 3) - corresponding to the decompressed bs picture passed as argument. Beware, - this function is weak, does no check at all, and will certainly crashes the - software if you gives a wrong type buffer. - - bsencode(handle, width, height[, max_size[, q_scale]]) +Q: Tell me more about the 'interactive' Option, please. +A: Well, this is the "-i" option you can use with the "cd-tool" command that + I explained in the first part. This interactive option add some functions : - Well return a buffer to an encoded bs frame, corresponding to the - input handle, which has to be in rgb24 format. Eventually, the function - will also return the buffer size as second returned value. q_scale - is the initial q_scale value (default = 1), and max_size is the maximum - frame size in bytes, which defaults to 14112 (standard STR size). The - function will redo the encoding process, increasing q_scale each time, - until the final frame size is <= the max_size. Eventually, the function - will return the final q_scale as the third value returned. - - blit(dest, source, dw, dh, sw, sh, sx, sy, bl) - - This will blit the source image buffer into the destination image buffer. - The destination is always a 24 bits RGB picture, of size (dw, dh). The - source buffer can be a 24 bits RGB, or a 32 bits RGBA picture, of size - (sw, sh), and shall be placed into the destination picture at position - (sx, sy) using the method described by bl. The depth of the source buffer - is determined by bl. This argument can be: - - BLIT_OVER - Source is 24 bits. Destination will be fully - overriten by the source picture. - BLIT_OVER32 - Source is 32 bits. Destination will be fully - overriten by the source picture. Source alpha ignored. - BLIT_ALPHA - Source is 32 bits. A full alpha blending will occur. - Alpha = 0: transparant, Alpha = 128: opaque. - BLIT_LIGHTEN - Source is 24 bits. The source will lighten the - destination. - BLIT_LIGHTEN32 - Source is 32 bits. The source will lighten the - destination. Alpha is used. - BLIT_DARKEN - Source is 24 bits. The source will darken the - destionation. - BLIT_DARKEN32 - Source is 32 bits. The source will darken the - destination. Alpha is used. + printn + + Works as "print", but won't add an automatic line feed at the end of the line + + quit or exit + + Will... err... exit the interactive mode + + infos([cdutils]) + + will display some basic infos about the cdutils object given (cdutil is used + by default) + + path([cdutils]) + + will print the path table of the cdutils object given + + printdir(path[, cdutils]) + + will display the contents of a directory - Good luck! ;-) - -Q: What patch did you applied to the LUA compiler? +Q: What patch did you apply to the LUA compiler? A: Only one of my own, to add support for hex and octal numbers. Here it is: + diff -u -r1.1 llex.c --- src/llex.c 6 Nov 2003 11:56:07 -0000 +++ src/llex.c 19 Nov 2003 23:03:35 -0000 @@ -1010,3 +1277,145 @@ diff -u -r1.1 lobject.c if (endptr == s) return 0; /* no conversion */ while (isspace((unsigned char)(*endptr))) endptr++; if (*endptr != '\0') return 0; /* invalid trailing characters? */ + + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% % +% LIST OF OBJECTS, FUNCTIONS, ETC. % +% DESCRIBED IN THIS FAQ % +% % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + + +--------------------------------------------------------------------------------------------------------, +NAME | OBJECT OR CHAPTER IT REFFERS TO | +--------------------------------------------------------|-----------------------------------------------| +:canread() | HANDLE | +:canseek() | HANDLE | +:canwrite() | HANDLE | +:cdfile(direntry[, mode]) | CDUTILS | +:cdfile(sector[, size[, mode]]) | CDUTILS | +:clearEOF() | ISOBUILDER | +:close() | HANDLE | +:close([cuefile[, mode[, nsectors]]]) | ISOBUILDER | +:copydir(dirtree, cdutils, direntry[, mode]) | ISOBUILDER | +:copyfrom(handle[, size]) | HANDLE | +:copyto(handle[, size]) | HANDLE | +:createsector(mode, sector) | CDUTILS | +:createdir(dirtree, name[, size[, direntry[, mode]]]) | ISOBUILDER | +:createfile(dirtree, name, file[, direntry[, mode]]) | ISOBUILDER | +:createsector(array[, mode[, sector]]) | ISOBUILDER | +:finddirectory(dir, path) | DIRENTRY | +:findparent(path) | DIRENTRY | +:findpath(path) | DIRENTRY | +:flush() | HANDLE | +:foreword(cdutils) | ISOBUILDER | +:foreword_array(array[, mode]) | ISOBUILDER | +:foreword_handle(handle[, mode]) | ISOBUILDER | +:fromdir(direntry) | DIRTREE | +:getdispsect() | ISOBUILDER | +:getname() | HANDLE | +:getsize() | HANDLE | +:guessmode([sector]) | CDUTILS | +:hasxa() | DIRENTRY | +:isclosed() | HANDLE | +:isdir() | DIRENTRY | +:ishidden() | DIRENTRY | +:isxaaudio() | DIRENTRY | +:isxadir() | DIRENTRY | +:isxaform1() | DIRENTRY | +:isxastr() | DIRENTRY | +:isxaxa() | DIRENTRY | +:putdata(array, size[, mode[, sector]]) | ISOBUILDER | +:putfile(file[, mode[, sector]]) | ISOBUILDER | +:read() | HANDLE | +:read(size) | HANDLE | +:readdata(size[, sector[, mode]]) | CDUTILS | +:readfile(handle, size[, sector[, mode]]) | CDUTILS | +:readsector([sector[, mode]]) | CDUTILS | +:readU16() | HANDLE | +:readU32() | HANDLE | +:readU8() | HANDLE | +:sectorseek(sector) | CDUTILS | +:seek(pos[, wheel]) | HANDLE | +:setbasics(pvd[, rootsize[, ptsize[, nvd[, rootsect]]]])| ISOBUILDER | +:setbasicsxa() | DIRTREE | +:setEOF() | ISOBUILDER | +:setz([level]) | HANDLE | +:tell() | HANDLE | +:updatesector(path, newsector) | CDUTILS | +:updatesector(path, newsector) | CDUTILS | +:write(size, array) | HANDLE | +:write(string) | HANDLE | +:writedata(array, size[, sector[, mode]]) | CDUTILS | +:writefile(handle[, size[, sector[, mode]]) | CDUTILS | +:writesector(array[, sector[, mode]]) | CDUTILS | +:writeU16(word) | HANDLE | +:writeU32(dword) | HANDLE | +:writeU8(byte) | HANDLE | +and | (basic layer) | +andB | (basic layer) | +Buffer([seekable]) | (files - function) | +cddate | (CDDATE - function) | +copyhandle(source, destination[, size]) | (HANDLE - function) | +createpvd(cdutils) | (PVD - functions) | +createpvd_array(array) | (PVD - functions) | +createpvd_handle(handle) | (PVD - functions) | +DirTree(father[, isdir]) | (DIRTREE - function) | +exit [ (used in interactive mode) | +from_bcd(number) | (CDUTILS object - function) | +from_msf(m, s, f[, start]) | (CDUTILS object - function) | +from_msf(msf[, start) | (CDUTILS object - function) | +hex(number[, format]) | (basic layer - function) | +infos([cdutils]) | (used in interactive mode) | +Input(filename) | (files - function) | +is_valid_bcd(number) | (CDUTILS object - function) | +isobuilder(handle[, mode]) | (ISOBUILDER - function) | +load([script]) | (basic layer - function) | +not | (basic layer) | +notB | (basic layer) | +or | (basic layer) | +orB | (basic layer) | +Output(filename) | (files - function) | +path([cdutils]) | (used in interactive mode) | +print | (basic layer - function) | +printdir(path[, cdutils]) | (used in interactive mode) | +printn | (used in interactive mode) | +quit | (used in interactive mode) | +sec_modes | (CDUTILS object - global variable) | +sec_offsts | (CDUTILS object - global variable) | +sec_sizes | (CDUTILS object - global variable) | +shl | (basic layer) | +shr | (basic layer) | +swapdword(number) | (CDUTILS object - function) | +swapword(number) | (CDUTILS object - function) | +to_bcd(number) | (CDUTILS object - function) | +xor | (basic layer) | +xorB | (basic layer) | +--------------------------------------------------------------------------------------------------------' + + + +%%%%%%%%%%%%% +% % +% CREDITS % +% % +%%%%%%%%%%%%% + + ________________________________________________________________ +| | | +| CD-Tool Coder | Pixel -> pixel@nobis-crew.org <- | +| | | + ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ + +FAQ's "raw-writting" : Pixel +¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ +Correction, shaping : GreatSkaori & Ti Dragon +¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨ + + +SPECIAL THANKS TO : +------------------- + +Yazoo
\ No newline at end of file |