HDTenEightyP/NetNews huggingface dataset:
From: dlr@DAVER.BUNGI.COM (Dave Rand)
Newsgroups: comp.sys.nsc.32k
Subject: Re: Pseudo dma.
Date: 31 Aug 92 06:50:20 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos

[In the message entitled "Re: Pseudo dma." on Aug 31, 14:17, DALL@hfrd.dsto.gov.au writes:]
>  > 3) The 8490 can be polled (bit 6 HA 5) to determine the true state of DRQ.
>  > A proper ISR will poll this bit, and read the last byte if required.
> 
> The chip spec says that phase mismatch doesn't reset DRQ (section 3.0)
> and it also says (section 4.11.2) that the easi will stop driving the
> bus on a phase mismatch. It doesn't say that the situation arises, but
> I suppose that DRQ active means there is still a byte in the 8490 chip
> to be read. It is hard to see how this could arise on a write (if the
> scsi bus is already "not being driven" sending more data from the CPU
> to the 8490 can't do much good. Should that final read be done with
> EOP?

Yes, on a read, if DRQ (bit 6 HA 5) is set, there is a byte to be read
latched in the chip. Perhaps not on the bus, but it is on the chip. There
is no need on reads to do the EOP. On writes, it is *possible* that the
phase change occurs while you are loading the byte to be transmitted, but
then DRQ will not be asserted, and you know. If DRQ is asserted while writing,
there is no byte in the chip (unless at EOP).

>  > Again, for writes you could over-estimate if you use MOVD. If you use MOVB,
>  > and poll the DRQ bit, you *know* how many bytes were transferred.
> 
> How does this work? What I am concerned about is not the normal
> end-of-dma, which the enhanced mode seems to signal correctly, but the
> abnormal end-of-dma due to phase change etc.

See above. You will get a phase change interrupt, and there may or may not
be a byte in the 8490. Between the PC, the current count, and the DRQ bit,
you can calculate how many bytes have been transmitted.


> Also, do you recommend movb's or movd's? I am not sure if there is an
> appreciable difference in speed when the source or destination
> operands are the pseudo-dma buffer. I am getting 4.25 MB/sec using a
> loop of 32 movb's (DRAM to DRAM). I am sure a loop of movd's would go
> faster DRAM to DRAM, but since 4MB per sec nearly saturates a normal 8
> bit SCSI bus anyway, is there any benefit in going to movd's?  On the
> other hand, if the byte count is to be uncertain anyway due to the
> factors discussed, I suppose there is not much *disadvantage* in going
> to movd's.

MOVB's are OK, but there is slightly better bus utilization when doing
MOVD's. The refresh has better time to get in.

Good luck, and holler if you run into more troubles.


-- 
Dave Rand
{pyramid|mips|bct|vsi1}!daver!dlr	Internet: dlr@daver.bungi.com
From: sverre@nrel.GOV (Sverre Froyen)
Newsgroups: comp.sys.nsc.32k
Subject: Re: Pseudo dma.
Date: 26 Aug 92 14:08:38 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos

>From DALL@hfrd.dsto.gov.au:
>
>It seems like this must have all been solved before for minix (unless
>the minix drivers are as simple as the current mach drivers and don't
>support disconnection) and I would just as sooner not re-invent the
>wheel.
>

To my knowledge, the Minix dp driver does not support disconnects and
a working aip driver does not exist.

Sverre

-- 
Sverre Froyen (sverre@nrel.gov)
Newsgroups: comp.sys.nsc.32k
From: idall@eleceng.adelaide.EDU.AU
Newsgroups: comp.sys.nsc.32k
Subject: Pseudo dma.
Date: 28 Aug 92 02:46:20 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos

I wrote:
 > I've been trying to make pseudo-dma work for scsi device drivers for
 > mach.
 > 
 > [movsb doesn't protect against prefetching of operands...]
 > 
 > I can go to an unrolled loop of "movb"s but it is more difficult to
 > work out how many bytes have been copied.

I've done this now and it works better. I figure out how far into the
unrolled loop it is by examining what the pc was at the time of
interrupt.

If I read an 8k chunk from a tape which hits eof after 4k, the
residual is underestimated by one byte (or equivalently, the no of
bytes tranferred is over estimated by 1). This doesn't matter for
hitting a true end of file since the residual is read from the target
using a scsi (request-sense ?) command. But in the event of a
"save-pointers" message, in preparation for a disconnect, I believe
the number needs to be correct.

I believe the discrepency is explained as follows. The 532 is faster
than the peripheral. When the last byte of the tape file is read, the
532 goes on to the next instruction. The way the pal logic seems to
be, the next instruction completes when the byte is ready *or* an
interrupt occurs. There is no way to tell the difference between an
instruction that completed because it read real data and an
instruction which completed because a scsi interrupt occured. Merely
incrementing the residual is not correct because a) the 532 mightn't
always be faster than the peripheral, and b) the 532 could have ducked
off to service, say, a clock interrupt which would give the peripheral
time to generate its interrupt, before the next movb instruction is
issued.

I think what is really needed, from the hardware point of view, is to
abort the bus cyle (and thereby the instruction) if (and only if) an
interrupt occurs from a scsi device when a read/write cyle to/from the
pseudo-dma area is in progress.

I haven't had a good look at this, but I suspect it would need more
than just new pals.

 > A second problem with this "pseudo dma" business is on writes? In the
 > presence of the 532 write buffer, how does one know how many bytes
 > have successfully been copied to the dma buffer at the point where a
 > scsi interrupt (for disconnection (*)) occurs. It seems the number of
 > bytes could be over-estimated by up to two (or 8 if doing movd/movsd
 > rather than movb/movsb).

No progress on this one. Until I put in disconnect support, it is harder
to get a scsi interrupt in the middle of a pseudo dma transfer while
writing than reading.

 > The aic chip has dma count registers on it which should solve the
 > problem.  With the dp chip, however, one seems forced to rely on the
 > cpu to know how many bytes have been transferred.
 > 
 > The obvious kludge which comes to mind is to say that it is most
 > unlikely for a target to start disconnecting except on a block
 > boundary and round the estimated number of bytes transferred
 > accordingly.

Any better ideas?

Ian
From: john@starfire.MN.ORG (John Lind)
Newsgroups: comp.sys.nsc.32k
Subject: Re: Pseudo dma.
Summary: poorly-behaved SCSI devices
Date: 31 Aug 92 02:44:18 GMT
Organization: Starfire Consulting Services, Mpls., MN

In article <m0mO0oC-000098C@daver.bungi.com>, dlr@DAVER.BUNGI.COM (Dave Rand) writes:
> 1) SCSI devices will always transfer in block unit sizes (usually 512 bytes)
> before requiring service via an interrupt. Even during disconnect/reconnect,
> it *seems* that this is the case, but is not required by the standard. A
> duff's device, with size of 32 (128 bytes), seems to offer the best
> compromise between i-cache usage and speed. Your results may vary. Void
> where prohibited.  Up to 512 could be used, but results are uncertain.

I do some contract work for a company called Ciprico, which manufacturers
high-performance disk, tape, and SCSI controllers for open standard buses.
They have lots of experience with LOTS of SCSI devices.  Let me assure
you that anything that is allowed by the standard, by intent or by
loophole, happens.

Disks are often well-behaved in regard to when they disconnect, but not
always.  Cacheing disks, in particular, may disconnect at any arbitrary
point in a transfer because its internal scheduler has detected that
a desired sector for reading or writing has come up, and the disk needs
to service its internal cache.  Fun, right? Really, REALLY high-performance
cacheing drives that can keep up a SCSI transfer to/from the cache while
doing head-to-cache work MAY become available, but I haven't seen one yet.

Also, tape devices get weird.  For one thing, you could be reading
any arbitrary block size from a 9-track tape, particularly foreign
host tapes (not that a lot of you are going to use 9-track...) BUT
there are DAT and 8mm devices which have ODD SIZED write buffers,
like 250 (NOT 256) bytes.  They suck up that much data, disconnect,
get the tape moving, then reconnect and suck in more data.  Really
sweet, right?

So, I don't know if any of these concerns apply to the current situation,
but felt you ought to know.
-- 
		   John Lind, Starfire Consulting Services
E-mail: john@starfire.MN.ORG		USnail: PO Box 17247, Mpls MN  55417
Newsgroups: comp.sys.nsc.32k
From: DALL@hfrd.dsto.GOV.AU
Subject: Re: Pseudo dma.
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Tue, 1 Sep 1992 08:38:43 GMT

pc532@bungi.com writes:
 > 
 > In article <m0mO0oC-000098C@daver.bungi.com>, dlr@DAVER.BUNGI.COM (Dave Rand) writes:
 > > 1) SCSI devices will always transfer in block unit sizes (usually 512 bytes)
 > > before requiring service via an interrupt. Even during disconnect/reconnect,
 > > it *seems* that this is the case, but is not required by the standard.
 > ...
 > They have lots of experience with LOTS of SCSI devices.  Let me assure
 > you that anything that is allowed by the standard, by intent or by
 > loophole, happens.
 > ...
 > Disks are often well-behaved in regard to when they disconnect, but not
 > always.  Cacheing disks, in particular, may disconnect at any arbitrary
 > point in a transfer because its internal scheduler has detected that
 > a desired sector for reading or writing has come up, and the disk needs
 > to service its internal cache.  Fun, right? Really, REALLY high-performance
 > ...
 > Also, tape devices get weird.  For one thing, you could be reading
 > any arbitrary block size from a 9-track tape, particularly foreign
 > host tapes (not that a lot of you are going to use 9-track...) BUT
 > there are DAT and 8mm devices which have ODD SIZED write buffers,
 > like 250 (NOT 256) bytes.  They suck up that much data, disconnect,
 > get the tape moving, then reconnect and suck in more data.  Really
 > sweet, right?

This is bad news. The driver I am working on has a bit mask which says
whether a target is allowed to disconnect. I guess my first approach will
be to assume that targets are "well behaved" and disable disconnection
on any that aren't.

It looks like adding the hardware counter is the only real solution,
although I think I will forget about it until I meet a target that
doesn't work with the "integral number of blocks" assumption.

Thanks for the info.

Ian
Newsgroups: comp.sys.nsc.32k
From: DALL@hfrd.dsto.GOV.AU
Subject: Pseudo dma.
Organization: Association for the Prevention of Polar Bears and Kangaroos
Date: Wed, 26 Aug 1992 01:47:27 GMT

I've been trying to make pseudo-dma work for scsi device drivers for
mach.

I have had limited success. I find that I can do reads in small chunks
mostly successfully, but with reads of over 3k, I loose the (3k + 1)th
byte. This looks very much like it arises from an interrupt occuring
and a re-read occuring from the dma buffer.

It is odd that this seems to be repeatably (at least with the same
command) the (3k + 1)th byte, I wouldn't have expected this degree of
synchronization (of clock interrupts?)!  Anyway, all comes good if I
raise spl before the read. Which tends to point the finger pretty
definitely at the pre-fetched operands being discarded on interrupt
problem.

However, this is not an adequate final solution since disabling
interrupts does not allow the correct determination of the number of
bytes copied (needed for disconnect support).

I am currently using "movsb". The string instructions support "partial
completion". A pending interrupt is only serviced when the instruction
is at a point where r0, r1 and r2 have been adjusted and the
instruction can be restarted. However, I can't find any documentation
to say whether the next operand might have been fetched. Can anyone
with intimate knowledge of 32532 internals (Dave? George?) comment?

I can go to an unrolled loop of "movb"s but it is more difficult to
work out how many bytes have been copied.

A second problem with this "pseudo dma" business is on writes? In the
presence of the 532 write buffer, how does one know how many bytes
have successfully been copied to the dma buffer at the point where a
scsi interrupt (for disconnection (*)) occurs. It seems the number of
bytes could be over-estimated by up to two (or 8 if doing movd/movsd
rather than movb/movsb).

The aic chip has dma count registers on it which may solve the
problem.  With the dp chip, however, one seems forced to rely on the
cpu to know how many bytes have been transferred.

The obvious kludge which comes to mind is to say that it is most
unlikely for a target to start disconnecting except on a block
boundary and round the estimated number of bytes transferred
accordingly. If this is indeed the case, then a) one could just
disable interrupts and re-enable them momentarilly after every
blocksize bytes have been transferred and b) use movd or movsd instead
of movb or movsb.

It seems like this must have all been solved before for minix (unless
the minix drivers are as simple as the current mach drivers and don't
support disconnection) and I would just as sooner not re-invent the
wheel.

Ian

* Technically, the number of bytes isn't needed if the target abruptly
  disconnects. If the target wants to reconnect, is should send a
  save-pointers message, so the interrupt which is actually relevant is
  the phase change interrupt.
From: MAILER-DAEMON@uunet.uu.NET
Newsgroups: comp.sys.nsc.32k
Subject: Waiting Mail
Date: 1 Sep 92 13:20:53 GMT
Organization: Association for the Prevention of Polar Bears and Kangaroos

After 3 days (95 hours), your message to the following people:

	tous!manatee!johnc  (host=tarpit)

has not yet been delivered. Attempts to deliver the message will
continue for 26 more days. No further action is required by you.

   ----- Queued message begins -----   
From: uunet!daver.bungi.com!dlr (Dave Rand)
To: bungi.com!pc532
Subject: Re: Pseudo dma.
Date: Fri, 28 Aug 1992 00:31:51 PDT

[In the message entitled "Pseudo dma." on Aug 27, 22:46, idall@eleceng.adelaide.edu.au writes:]
> I believe the discrepency is explained as follows. The 532 is faster
> than the peripheral. When the last byte of the tape file is read, the
> 532 goes on to the next instruction. The way the pal logic seems to
> be, the next instruction completes when the byte is ready *or* an
.....
From: aistmain@vntic.msk.su (Dispatcher of AIST-EuroAIST-RELCOM Boris I. Tarakanov)
Subject: NEW CIPHER-SYSTEM
Summary: NEW CIPHER-SYSTEM
Keywords: NEW CIPHER-SYSTEM
Reply-To: aistmain@vntic.msk.su
Organization: AIST-VNTIC INFORMATION NETWORK
Date: Mon, 31 Aug 92 01:19:34 +0300

              New cipher-system

 1. When the original information is euciphered every bit is
    treaded and redundancy of this information is absent
 2. The amount of variants of eucipher may be so much great,
    for example n=10**91
 3. The quantity of encipher operations for 1 bit are <=22,
    but decipher operations are <= 9 for case n=10**91
 4. Ecodered file is deciphered in turn bit from the end  of
    the text.

    This new cipher-system may be  used  for  protection  of
    information  from   unauthorized  access  and  for  data
    communications by communication chanels.

    Relation by electronic mail.



Newsgroups: comp.sys.handhelds
From: jeff@eng.umd.edu (Jeffrey Frey)
Subject: ZEOS Pocket Review (Comment)
Date: Mon, 31 Aug 92 15:14:55 GMT
Organization: College of Engineering, University of Maryland, College Park

Thanks for the comments on the Zeos Pocket PC.  I hope it doesn't take too long
for the manufacturers to understand that there's a demand for a real 
NOTEBOOK-sized computer with a reasonable keyboard that nevertheless
uses PCMCIA cards and runs on 2 AA cells?

After all, 4" X 9" is too big to fit in any (reasonable) pocket, but also
too small for a reasonable keyboard and screen.

We need a 1# NOTEBOOK-sized computer!  (As I've said before, Fujitsu
already makes one, but it only speaks Japanese.  But then again, Poqet
just changed its name to Fujitsu Computer Systems....)

Jeff

Newsgroups: comp.sys.handhelds
From: bright@sctc.com (David A. Bright)
Subject: Information on TRS-80 Pocket Computer wanted
Organization: SCTC
Date: Wed, 26 Aug 1992 14:58:40 GMT

I have an old TRS-80 Pocket Computer (the first model Radio Shack came out
with in about 1980).  I'd love to have some information on this little gem.
In particular, I'm wondering what processor is used and whether I can get
directly to the CPU, bypassing the built-in BASIC interpreter.  If so, I'd
also like to know how to drive the speaker, LCD display, and output port
(used to connect to a cassette mass storage system!).  I've popped open the
case and found several fairly large surface mount chips labelled SC43178 OJ 15,
SC43177 OH 35, and SC43125 OG 33 (three of them).  I can't find these in the
1991 IC Master, so I'm at a bit of a loss.  Am I right in suspecting that
the processor is some bit-slice thing?

Anyway, any information you can supply would be greatly appreciated.
-- 
David A. Bright			dab@Bright.MN.ORG	(home)
Secure Computing		bright@SCTC.COM		(work)
From: Frank_Murray@mindlink.bc.ca (Frank Murray)
Newsgroups: comp.sys.handhelds
Subject: HP95LX Developement Tools ?
Date: 3 Sep 92 23:39:15 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

I recently purchased an HP95LX and have started developing "Solver" formulas
specifically for Steel Engineering and Drafting.  Outside of the "Developer's
kit (Which is "C") are there any other languages for developing HP95LX specific
applications?

Any references would be greatly appreciated.

Frank Murray

--
Frank Murray   |  a523@Mindlink.UUCP
Vancouver, BC  |  Canada
               |  Night-time sharpens, heightens each sensation...
               |  Darkness stirs and wakes imagination...
               |  Silently the senses abandon their defences...
               |  O.G. --- The Opera Ghost, The Phantom of the Opera.
Newsgroups: comp.sys.handhelds
From: comet@us.oracle.com
Subject: Re: Information on TRS-80 Pocket Computer wanted
Organization: Oracle Corporation, USA
Date: Thu, 3 Sep 1992 09:25:14 GMT
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <1992Aug26.145840.198@sctc.com>, bright@sctc.com (David A. Bright) writes:
> I have an old TRS-80 Pocket Computer (the first model Radio Shack came out
> with in about 1980).  I'd love to have some information on this little gem.
> In particular, I'm wondering what processor is used and whether I can get
> directly to the CPU, bypassing the built-in BASIC interpreter.  If so, I'd
> also like to know how to drive the speaker, LCD display, and output port
> (used to connect to a cassette mass storage system!).  I've popped open the
> case and found several fairly large surface mount chips labelled SC43178 OJ 15,
> SC43177 OH 35, and SC43125 OG 33 (three of them).  I can't find these in the
> 1991 IC Master, so I'm at a bit of a loss.  Am I right in suspecting that
> the processor is some bit-slice thing?
>
> Anyway, any information you can supply would be greatly appreciated.

Hi!  I got my TRS-80 Pocket Computer (Sharp PC-1211) in June of 1981.
It has 1920 bytes.  1424b is for the user, the rest is taken up by the transfer
buffer, input buffer, fixed memories and reserve keys.
I think the "SC" stands for "Sharp Corporation" in the chips you listed.
The computer uses two 4-bit microcprocessors.  Here's what they do:

           Microprocessor 1            |          Micro processor 2
---------------------------------------+----------------------------------------
Key input routine                      |   Display processing routine
Acknowledgement of the remaining       |      Input buffer
   program                             |      Computational result
One instruction to one program step    |      Error
   incorporation                       |
Interpreter:                           |   Arithmetic routine
      Program execute statement        |   Character generator
      Cassette control statement       |   Cassette routine
      Command statement                |   Print routine
      Printer control (reserved)       |   Recognition of printer (reserved)
Execution of manual operations         |   Buzzer
Power shut-off control                 |   Power off
Clock stop control                     |   Clock stop

The above information comes from the book "Programming the TRS-80 Pocket
Computer" by Donald D. Spencer.
From: phr@soda.berkeley.edu (Paul Rubin)
Newsgroups: comp.sys.handhelds
Subject: Re: Opinions on HP42S/HP32S2/28S wanted...
Date: 3 Sep 92 15:57:57
Organization: CSUA/UCB
Distribution: inet
NNTP-Posting-Host: soda.berkeley.edu
In-reply-to: bwc34920@uxa.cso.uiuc.edu's message of Sat, 29 Aug 1992 22:15:34 GMT

The 42s is strictly an RPN calculator, it can't understand formulas
like 3*sin(3x)+5 or whatever.  However, it's solver is quite a bit
more numerically sophisticated than those found in other brands of
calculators.

I still don't like the 42s very much.  It has plenty of functions
but the user interface is very clumsy.  You have to scroll through
a long catalog or else use a painful process to get to any function
that is not directly on the keyboard (or pre-programmed on a key).
I think they did a quick and sloppy job in designing this one.
With used 48's not much more expensive, the only thing the 42s
has going for it is its smaller size.
From: jeff@eng.umd.edu (Jeffrey Frey)
Newsgroups: comp.sys.handhelds
Subject: comp.sys.laptops
Date: 28 Aug 92 13:05:58 GMT
Organization: College of Engineering, University of Maryland, College Park


 good source of SRAM cards for computers that will take them
(HP95LX, POQET, ZEOS Pocket, etc.) is

Tote-A-Lap  at 800-9-LAPTOP or 415-578-1901.  

They are charging $162 for a 1M PCMCIA Card and $351 for a 2M card.

The latest T-A-L price sheet gives some hints on new computers
that will use these cards, such as:

Gridpad Palmtop
DEC Palmtop
IBM PC Radio
Momenta Pentop

Presumably those of these not yet introduced will be seen at Comdex in the
Fall.  Question is, which of these computers will be able to handle the new
20M Flash Cards that are HDD equivalents (i.e., the computer must be
able to write the card and have the software to do so--not only read/write
an SRAM card)?

Jeff
From: akcs.mage@hpcvbbs.cv.hp.com (William H. Blohm)
Date: Thu, 27 Aug 1992 15:40:02 GMT
Subject: Re: Information on TRS-80 Pocket Computer wanted
Message-ID: <2a9cf560.4787.1comp.sys.handhelds.1@hpcvbbs.cv.hp.com>
Newsgroups: comp.sys.handhelds

If you can provide a manufacturer's logo or some such identifier to
show who the manufacturer of the chip set is, you should be able to
look it up in their catalog.  Might have to look under the replacement
for column, though.  It is NOT likely to be a bit-slice processor, 
though.  That machine was not that high performance a machine.  If I
had to guess, I would guess the SC43125 OG 33 were memory.

Xref: sparky comp.sys.handhelds:1948 comp.sys.laptops:3390