Re: asm.e questions
Wow. I've been away a day, look what happens 
Ok, one at a time. My apoligies to the repeated.
Bernie Ryan wrote:
> Nick
> Another thought if you are running in DOS why couldn't you use a
> RAM disk ?
> Bernie
By the stage I can consider using a ram disk, all the hard file-handling
work will already have been done. If the ram disk cannot offer me more
space than available physical memory without it, what benefit to use
it? It is much simpler and probably more efficient to store the sample
in allocated ram if it is smaller than what is available. The Direct to
disk recording / playback will be for samples longer than physical
memory. I often work with samples of many hundreds of megs as our band
records jam sessions on a hard drive. I would ideally like to take one
of these huge samples, play it back and mix other sounds with it in real
time for a post-mix with a live sound, or a really cool kareoke.
Everett Williams wrote:
> Nick,
>
> I would like to know what you mean about IO routines eating up too
> much CPU.
> I don't know how efficient Eu's file routines are, but IO typically is
> more
> a consumer of clock time than CPU cycles. Finding ways to make IO
> efficient
> on any particular configuration is no simple job, but CPU cycles are
> not
> usually the most prominent concern. Also, from what I can tell, all Eu
>
> driven file IO is synchronous...meaning Eu waits on the completion of
> IO to
> proceed to the next instruction. Buffering and caching external to Eu
> can
> improve the efficiency of such IO, but if the CPU has nothing else to
> do
> other than wait on the IO, much will go to waste. Even if you do all
> the IO
> in the background through some asm routine, you will still have to
> write
> some polling routine to tie the IO to the Eu code. I think that you
> said
> that this was to be done in DOS, where you have no call back ability.
> I
> don't see how you will get to what you want to do without moving to a
> Windows type setup.
The efficiency bottleneck is not really in Euphoria's IO routines, even
if they may be a fraction slower than pure dos, but in the wholesale
movement of large blocks of data between allocated memory (needed for
asm) and Euphoria variables (needed for IO). The added peek and poke
stages could slow down the whole operation many times over, as I have
found with trying other such asm / Eu interfaces. Thus the possibility
increases of buffer over/underrun on slower systems. All this could be
mostly avoided by using the dos file routines from within the ISR
itself.
The actual ISR will avoid the need for any polled servicing by being
completely self-contained. The interface to Euphoria can then consist
of simple "current operation is" flags, and Eu "trigger" functions to
begin the various real assembly routines. The ISR on it's own is the
callback routine, in a sense. There will be no Euphoria code in the
core routines anyway, so minimal inter-language juggling should be
necessary.
Kat wrote:
> Maybe you can call DMA routines if your motherbd supports such things,
> and
> call the DMA *before* you need the data, so it's ready when you are.
> Maybe?
I expect at least two dma channels to be very busy during direct-to-disk
recording / playback, one for the sound card and one for the hard
drive. I don't expect to program the hard drive dma directly though
(unlike the sound), not with DOS providing some very convenient
block-style transfer commands built right in.
> What he needs to do is set the hd as a buss
> *master* , not under the control of that chip. When the hd is running
> buss
> master dma, the dma chip on the motherbd does one job, the cpu does
> another
> job, and the card doing pci buss mastering does it's job. For
> instance, you
> could have the motherbd chip doing an ems page swap, the cpu running
> your
> app, and the hd dropping data into xms somewhere.
I'm fairly sure that knowledge of this kind of sophistication is not
really necessary.. I tells it what to do with a simple dos interrupt,
let it work out exactly how. The conceptual design of the library
should preclude possible dma conflicts between input and output, and I
am blissfully shielded from most of the rest.
----------
Many may consider this to be going about things the hard way, and I
admit it poses quite a challenge but it was for these kinds of
challenges that I started programming anyway, the ideal project
teetering on the edge of one's ability. I was dissapointed at the lack
of a callback in dos Eu, until I realized ways around it. Now to make
something useful of this, I decided, and myself. I have yet to produce
a real quality library...
Thanks all for the interest. :)
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
|
Not Categorized, Please Help
|
|
