»

[Jose]

Hehe not what it seems ... this pipe and stuff are different:-D

I'm getting tired of when I get to write something end up discovering I need to read about some more other thing(s). :-x

Basically I had this program that I wanted to write that gets some images in and I'd do something with them in pairs (nervermind the details... 8-) ) of two: the next one with the previous one. I'm gonna use a shell prog from Aminet to get the images in from the serial port but that is only temporarily to test the thing.
I wanted it to be fast so I was thinking about minimizing the time it takes to receive the images.. I was initially gonna do some kind of ring buffer thing but ended up, because of a hint of someone in here sometime ago, going for the pipe. Now I've been reading some stuff on the RKM LIbraries book wich I have ( also got the Dev CD 2.1), and I thought what I know was enouph but ended up stumbling with stuff like sending packets to handlers (in this case the queue handler), locks and filehandles. I thought to myself well there must be something on the DevCD, but no, what's there is not enouph. There is some stuff about the 1.2 DOs packets or something that I don't even know if is up to date, and mentions that the DOs Manual has more info (though not full description of all packet types wich is on that part of the Dev CD).

TO make this thing short I need two things:

1- Where can I read about Locks, filehandles and packet sending to hanglers and filesystems and any more related necessary stuff? (Ok the mentioned DOS Manual is one...)

2- Is there a better way to do what I want to do without using the pipe? I want to minimize the time my program takes to receive the images and to put them in a buffer and then copying them over seems unecessay to me. Maybe I could read the pipe directly ? It seemed a good buffer though. FIFO order like I want, can be easily setup to different buffer sizes....

3- By the way is the Pipe fast?

4- What about using some ramsdisk kind of thing (wich I would still have to learn about too ) to store the consequent images and then making some kind of circular buffer within a directory with the files received? But that would eliminate the possible use of streams right?

[Thomas]

I still cannot imagine what you are going to do. Could you be more specific ?

I've understood, you have several images. Let's say image1, image2, image3 and image4. Now you want to convert or combine the images applying any new image to the former result. So you load image1, apply image2, save result1, apply image3, save result2, apply image4 and save result3.

Currently I don't see why you need a pipe or where you want to speed up. It is a sequential processing, one image is processed after the other. As we are on a single-processor computer, asyncronous loading and saving won't speed up things. Loading from harddisk (which is the only thing which would benefit from asyncronous processing because of DMA) is very fast. The main issue is decoding the data and this is done by the processor.

Certainly you should keep the results in memory. If you reload e.g. result1 before you apply image3, you have a major performance decrease.

Bye,
Thomas

[Jose]

Dammit I just spent some minutes writting a reply and this PC hanged completely...

"I still cannot imagine what you are going to do. Could you be more specific ?"

Hi Thomas. Well if I'm more specific I'll tell everyone what my idea for the program is... but you got it right, it's a sequence of images processesd in pairs like you described.

I think a buffer like the pipe would still speed things up. In cases where the input is slow, like the serial device I'm using currently, I could be receiving an image and processing the previously received image whith the one before that one at the same time. When the current image is received I'd start processin it with the previous one and receiving the next one at the same time.
By the contray if some pair of images is particularly processor intensive the buffer could still be receiving two or three images ahead without stoping. This could be handy if I was receiving images from some external device that just sends them. The pipe or a pipe like buffer would be particularly handy here, because I could define the maximum size of it and it would hang a bit the input if the buffer got full. This type of buffer would also enable the program to receive video streams I think ( that's what I was thinking when I mentioned streams above).
But if I'm not making sense let me know.

By the way, does anyone knows what's the latest edition of the AmigaDOS manual they mention on the DevCD?

[Piru]

1- Where can I read about Locks, filehandles and packet sending to hanglers and filesystems and any more related necessary stuff? (Ok the mentioned DOS Manual is one...)

DosPktGuide.lha has some documentation about dospackets, but is incomplete. Read dos.library audodoc about AllocDosObject(), FreeDosObject(), DoPkt(), SendPkt() and WaitPkt(). Also see dos/dosextern.h for struct DosPacket, struct FileHandle and struct FileLock.

Check examples found by aminet find: packets

[Noster]

Hi

I don't understand why you want do do packet-handling by your own, you could use the functions of the dos.library for accessing the pipe instead (Read(), Write(), Open(), etc.)
To your questions:

1 - a very good source (the best ?) for informations about AmigaDOS and the related stuff like FileHandles, packets, handlerIO etc. is "The Amiga Guru Book" from Ralph Babel. But unfortunately it is sold out since years and very hard to find :-(

2 - ? The pipe seems to be a good idea, but since you are the only person that really knows what you're want to do with this program, I can't say if there is a better solution.

3 - I've never tested it, but it should be much faster than the ramdisk, because it must not matter about filestructures, directories and shared access (one process puts data into the pipe, anotherone reads it and no more)

4 - The ramdisk should be much slower and there should be no mayor difference in writting the code that opens a file in the ramdisk and writes the data into it resp. reading it from the file than to do this with a pipe.

Noster

[Jose]

@Noster

"I don't understand why you want do do packet-handling by your own, you could use the functions of the dos.library for accessing the pipe instead (Read(), Write(), Open(), etc.)"

Because I was hoping that using packet's I would be able read a file at the same time it was being writen. I know it doesn't make sense, but it was just to speed things up when using Dos programs that download files from digicams, to serve as the input for the sucessive of images.

The best would be if there were drivers for certain protols(maybe as a device?), and one just accessed the device.