BL> I am reading memory directly at address $0040:$006C which gives
 BL> me the ticks since midnight and works very well... but it won't
 BL> work when the vampires come out.

 BV> Are you trying to write something for DOS or Windows ?

  I am learning about serial comms.

 BV> As each is a different environment, you really can't use the
 BV> same technique for both.

  I didn't know that. I thought Windows was just DOS in colour .

  Doing it in the Windows API was too easy, so I decided to go under
that to the hardware itself, and see what actually happens. This is
really fascinating! I've got it pretty-well worked out now.

 BV> If you're trying to write for Windows, then you shouldn't be
 BV> looking at 0x0040:006c as Windows has it's own API call which
 BV> will provide the same information. - I can't recall what it is
 BV> at the moment (half my library is in storage and it always
 BV> seems to be the half that I want to look at ), but I'm
 BV> sure you can find it easily enough. Anyway, why are you looking
 BV> at a timer to determine how much time has passed ?

  Asynch is *all* timing, but this particular one is a maximum-wait
timeout loop that I slip in everywhere.

  After a string  of data from the inrterrupt handler, you don't know 
if it's finished or just thinking about it, so you need a timeout limit 
to stop waiting for more data forever... but the timer loop has to be 
*fast* or you'll miss the first character.

 BV> I'm guessing that you want to be told when to look at the input
 BV> buffer, is this right ? If so, there are a couple of ways you
 BV> can do it. In Windows, you can simply get teh COM API to notify
 BV> you when there are a certain number of characters in the buffer
 BV> and you don't need to worry about time at all, provided you get
 BV> to service the buffer before it overflows.

  I'm doing the same in DOS. It took me a long time to cognite on how
you knew something was coming in... just check the buffer! Windows is
very interesting. At 57600, you can't really service the buffer with
task sharing. It breaks even at about 19200, so to go faster you need
to organise spare time.

 BV> In DOS, what you should be doing it hooking an interrupt Int
 BV> 0x08 and then you will get called every 55m-sec. There is a
 BV> "trick" with this though because 55-msec is to slow for you, so
 BV> what you need to do is to speed up the timer and make sure that
 BV> you pass on the correct Int 0x08 when the right number has
 BV> rolled around. IOW, you can re-program the timer to give you an
 BV> Int 0x08 every 200us, but you must keep track of how many times
 BV> you've been called and on every 275th call you then pass the
 BV> Interrupt through you to whoever had it before you stole it,
 BV> then the bloke further down the chain will do his thing and
 BV> everyone will be happy.

  By "hooking an interrupt" do you mean writing an interrupt service
routine and passing its address to Int8 (IRQ0... $08)? I'll give it a
go, but I've worked out an easy way to get around the midnight thing
anyway... just time it again if it rolls over.

  I understand reprogramming the PIT, but 55mS is fine for me; just as
long as I can make the call in under 100uS. 

 BV> But all of this is the HARD way of doing it. Just grab each
 BV> character as it comes in and stick it in your own buffer. You
 BV> know how many characters are in the buffer and you service it
 BV> whenever you need to.

  The trick is "whenever." 

  I'm not going to need any of this with zmodem anyway. Basically
all zmodem does is slow things down with a wait every 1024 bytes, but
I've been trying to run it flat out at 57600.

 BV> I realise that this answer doesn't really give you anything
 BV> specific but there are quite a few different ways to do
 BV> whatever it is you are trying to do and you've got to use
 BV> whatever mechanism you feel will work for you.

  What I'm trying to discover is the "right" way to do it; the way
that gives the most leeway. I've already got the idea of what it's
all about and I'm homing in on foolproof HS comms. I hope that when I
finally get to write it for Windows, I will understand what the API is
actually doing. 

 BV> If you're just trying to tell is a certain amount of time has
 BV> passed, you might want to have a look at Int 0x1c There is a
 BV> way you can get it to act like an Alarm, but I forget how now.
 BV> It's a bit tricky though an may not be suitable, but it could
 BV> be worth a thought.

  I can't work out what I'm supposed to do with Int1C. Ralf says it's
called by the int08 handler, so why not use Int08? An interrupt call
to the Dos Int21 is too slow.

  This is great fun! I'm learning a hell of a lot about the hardware
do-hickies and I'm only destroying the computer once a day now,
instead of once every five minutes.

BTW, why is Hardly Normal selling Win95 for $60? Is a new version due?

Regards,
Bob

Regards,
Bob

     
___ Blue Wave/QWK v2.12
@EOT:

---