Need help on this: Reading directly from a file or handler...

[Jose]

Hi. I want to manipulate data directly in the queue-handler device. At least if that's not possible I don't want it to send the whole buffer to the destination buffer when I use the action_read packet (or something like this name..). I want to be able to chose the place on the buffer I want.
But what I'd really want is to manipulate the data anywhere in that handler's buffer directly or copy it directly to the CPU registers without having to copy it to other memory location again before processing it.
I noticed that the hadler doesn't support an action_seek packet so maybe it's not possible.

Is this possible at all? Preferably using OS functions and the fastest possible. 8-)

By the way, how would you do the exact same thing with the ramdisk? There seems to also be no information on the ram handler but maybe you just use it as if it was another volume in the filesystem. Is this correct and if it is doesn't it slow things comparing to direct memory manipulation?

The reason for all this is because for now I'm using as input the output of another program wich outputs files to  where I choose. Maybe I could use the cliboard device but then I'd want to do then same, manipulate the data directly on it to speed things up.

So as you can see I'm kinda lost in here...

[Piru]

I want to be able to chose the place on the buffer I want.

ACTION_READ is given address to read the data to. If the handler itself buffers something in memory, you don't know that.

But what I'd really want is to manipulate the data anywhere in that handler's buffer directly or copy it directly to the CPU registers without having to copy it to other memory location again before processing it.

Not possible without hacking. The handler itself is a blackbox you access thru well defined interface (dospackets, dos.library uses doscpakets internally).

If you want to use asyncron I/O, I suggest you look into asyncio.library.

[Thomas]

IMHO working with DOS packets is not the easiest way and using an external handler makes you dependent of the user having it installed. Especially the pipe handler is one which is often replaced by other ones which might react different on your packets.

Why don't you just start a thread which does the I/O with standard dos.library functions and uses PutMsg/GetMsg to communicate with the main task. This way you have the total control over what is going on and use standard functions which are available on all Amiga systems.

Bye,
Thomas

[Jose]

"Why don't you just start a thread which does the I/O with standard dos.library functions and uses PutMsg/GetMsg to communicate with the main task. This way you have the total control over what is going on and use standard functions which are available on all Amiga systems."

I can't use standard dos.library functions to do the I/O because I'm using a  a free program from Aminet (Digicam) to send the input from a Digital camera. The program writes files. I also prefer not to try to modify the source, wich is available. I've also noticed some other programs of the same type for other cameras on Aminet and I think it would be cool to be able to use them to send the input too, so that people with different cameras could also try it out. Those programs also write files. I think I'm gonna let it be like that (just read the files again) and in the future take a look around to try to make an interface for drivers. Just an idea I'm really a bit lost as to if it would be worth it. Souldn't be much more them sending a few commands if the protocol to the cameras has been found I guess, because I wouldn't need to be using all camera functions of each camera.

Actually two separate tasks, one for the I/0 and buffer,the other to do the magic, is how it is now, mainly so that the buffer can be independent and to avoid loops. I read somewhere that Exec relies on interrupts to activate the scheduler between the time slice of each task, so it should be the most effective way also, I think.

I'm very slowly getting it done... :-)

[Jose]

I just bought a The AmigaDOS Manual from Commodore Amiga Inc. and Bantam, 3rd edition from 1991. I think it's the last edition.
There's info in there that doesn't seem to be in another places at least all in one place.

I'm pretty sure the ramdisk also uses the Amiga filesystem doesn't it ?
If so I'll be able to configure the external program I'm using (Digicam) to save to the ramdisk and then hack into the filesystem directly. After I have read about it of course...
What do you think ?

[Piru]

I'm pretty sure the ramdisk also uses the Amiga filesystem doesn't it ?

What do you mean? Does it use dospacket interface? Yes, all filesystems do. Does it use FastFileSystem? No. Ramdisk uses custom filesystem (ram-handler) and it uses no exec device (such has scsi.device or ramdrive.device).

If so I'll be able to configure the external program I'm using (Digicam) to save to the ramdisk

If the program saves to a file, and you can configure it to save to any path, why not?

and then hack into the filesystem directly.

Do what exactly?

[Jose]

@Piru

"No. Ramdisk uses custom filesystem (ram-handler) and it uses no exec device (such has scsi.device or ramdrive.device)."

Yes. I know that now... It's the RAD drive that can use HD filesystems. I couldn't find information on the DevCD about the the way the ram-handler lays out data into memory though.

" and then hack into the filesystem directly.

Do what exactly?"

I just want to be able to copy the data directly to the CPU registers to avoid the overhead of having to copy it somewhere in memory first as is the case if I use DOS functions wich use the ACTION_READ packet anyway (I think).
No direct data modifications though. After I copy it to the CPU registers it would be placed somewhere else if necessary, after the checking I want to do with it.

[Jose]

@Thomas

I guess I ended up not answering very directly to that...

"Why don't you just start a thread which does the I/O with standard dos.library functions and uses PutMsg/GetMsg to communicate with the main task."

Because I want to avoid the overhead of having to copy the data somwhere again. I want to read it to the CPU registers directly. Even if I use PutMsf/Msg to signal the main task that data has arrived, there doesn't seem to be no system friendly direct way of the main task then reading parts of the data in the RamDisk  directly to the CPU registers without having to copy it to some buffer in memory defined by me first.

[Piru]

I couldn't find information on the DevCD about the the way the ram-handler lays out data into memory though.

It's quite obvious: The internal memory layout is implementation specific stuff, and it can change from version to version. You don't know how the handler stores the data internally! Remember that filesystem is a blackbox that you *only* can access thru defined API, that is dospackets.

I just want to be able to copy the data directly to the CPU registers to avoid the overhead of having to copy it somewhere in memory first as is the case if I use DOS functions wich use the ACTION_READ packet anyway (I think).

You can't do this. Read above.

No direct data modifications though. After I copy it to the CPU registers it would be placed somewhere else if necessary, after the checking I want to do with it.

No excuse. Since you don't know how the data is stored in memory, you can't peek it directly.