Mail Archives: djgpp/1997/10/02/13:37:57
Bill Currie <billc AT blackmagic DOT tait DOT co DOT nz> wrote:
> On 1 Oct 97 at 14:49, Salvador Eduardo Tropea (SET) wrote:
>
> > My example uses packets similar to network ones, seems that here the
> > solution is use the channel as a Level 0 layer of a net. Another
>
> I agree. Do we go for best effort or reliable delivery? I think it
> sould be best effort and the applications can implement the
> reliability. This means that the driver could get quite complicated!
> (either delivery method) This is because I feel the driver should
> help out with the synchronisation.
The only reason to let the user make the synchro. is because the driver is real
mode and Windows won't stop the execution in the middle of it to give the
control to another DOS box (or can make that?).
But if we add a cli/sti to the C code I guess it will be faster and more
flexible.
About reliable delibery ... depends on how the TSR will be arranged, to make
that we need to make something like: The TSR receives a pointer to an structure
in base memory, copies the content to the channel, if the TSR gets the
acknowledge sets a flag in the structure, etc. Makes the thing more
complicated, I don't know.
> The only problem I can see is
> obtaining the PID (or whatever is used) of the destination. But then
> again, we could always use ARP or something similar, but what do we
> use for the higher level addresses?.
>
> For the low level, we can either use 16 bit addresses (the PID, int
> 2f/1683) and use 0 as a broadcast address, or go for 24 or 32 bit
> addresses with 0-65535 as normal addresses and 65536-16M or 4G for
> broadcast and multicast addressing.
Depends where you cut the levels. If the first level after the driver isn't in
the driver you can use 32 and 32 bits after all djgpp programs works better
with 32 bits values. In this case the C program uses just your PID when talking
with the driver, the rest is internal.
> > thing Michael have some problems to get TB working under W95, any
> > idea?, your own TSR works.
>
> I think mine works under w95 because it is loaded long before windows
> is and (as I understand it) drivers that get loaded before windows
> are common to all virtual machines, unless they tell windows
> otherwise (via the int 2f/1605 windows init callout). NOTE: I haven't
> actually tried my tb under w95, only msdos 6.?? and opendos 7.01.
Was the space!
> Hey! this is getting interresting. I'm getting all sorts of ideas on
> how this could work. The driver can have a total buffer size of say
> 32k and can use 16k for inter process communication and the other 16k
> as a per-process transfer buffer (via windows instancing). The
> application can then put its data into the pp (per-process) buffer
> and request the driver to `transmit' the buffer to the destination
> processes. The driver then copies the data from the pp buffer to the
> ip buffer (inter process buffer), changes to the destination virtual
> machine (int 15/1685), and copies the ip buffer to the pp buffer,
> maybe with a callback to the destination program. The question then
> is: does the driver return to the calling vm? broad/multicast
> addressing would be slightly more complicated (and a lot slower) but
> the driver can just go through the possible PID's (maybe there's a
> better way?). the pp buffer will probably have to be split into an
> incoming and an outgoing section.
:-))), and then you implement multitasking in the same TSR, because it knows
all the PID's, it can call to each one, etc ;-)))).
Ok, but why don't make first a simple version with an API ready for a next
generation?
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -