<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Tue, 26 Jan 1988 19:23:51 GMT
From   : oliveb!intelca!mipos3!cadev4!dbraun@AMES.ARC.NASA.GOV (Doug Braun ~)
Subject: Anybody heard of a company called High Tech Research? (Also Z280)

About 10 months ago someone in this newsgroup mentioned a product
called the "Ultraboard" that was being developed for Kaypro computers.
It was being worked on by a company called "High Tech Research",
which announced it at last year's West Coast Computer Faire.
It is a replacement for the Kaypro main board that uses the Zilog
Z280 CPU.

I just read in Ted Silveira's CP/M column, in the latest issue
of Bay Area Computer Currents, that the company encountered some
"bugs in the Z280" and still hasn't finished the product.
Since I am working on my own Z280 board, I would be very interested
in talking to someone at High Tech about their experiences
with the Z280.  Does anyone have any more information about them
(address, phone, etc.)?  Zilog hasn't issued any application
notes, etc. on the Z280, so it would be really useful for me
to talk to someone who has some experience with the part.

Actually, my Z280 board is coming along very well.
It will run my floppy version of CP/M, but I have
to modify my hard disk BIOS to use the Z280's on-chip
DMA controller.  Also, my floppy BIOS needs a timing
problem fixed before it will work with the cache turned on.

The board has the following parts:

Z280 CPU
2 2732 EPROMS
2 32Kx8 static RAM chips
2 Address latches
2 16L8 PALs
2 TTL glue chips
1 6850 ACIA serial chip (included for software compatibility)

The disk controllers and many other things are on seperate boards.
Sometime I plan to add 512k of memory in the form of 4 256Kx4 
dynamic RAM chips, which will let it run in burst mode with a 10 MHz
bus clock.

Some preliminary benchmarks:

The classic Sieve program, compiled with the Software Toolworks C
compiler (I think):

Original 4 MHz Z80:                            34 sec.
9.8 MHz Z280, no cache:                                45 sec.  (!!!)
Z280, instructions cached, no burst mode:      16 sec.  (whew!)
Z280, data and instructions cached:            13 sec.

Basically, we get a 2.5x speedup on the same .COM files.
Having burst mode memory would not affect this benchmark much since
its inner loops probably fit entirely in the cache, and few external
memory accesses are needed.

An off the cuff analysis tells me that a simple modification of
the compiler to substitute new Z280 instructions for subroutine
calls would speed it up another 50%, and a fancier compiler would
give another 25% speedup, giving an ultimate time of about 5 sec.
for the Sieve benchmark.  (BTW, the sieve runs in 3 seconds
on a 8 MHz V-30 with Turbo C 1.5).

If you can tell me something about High Tech Research,
or are curious about my project, send me mail.

Doug Braun                             Intel Corp CAD
                                       408 496-5939

 / decwrl \
 | hplabs |
-| oliveb |- !intelca!mipos3!cadev4!dbraun
 | amd    |
 \ qantel /


Date: Friday, 29 January 1988  08:42-MST
From: jdb@NCSC.ARPA (Brown)
Subject: Modified 'undigestify.c' available from SIMTEL20

I have modified the undigestify.c program mentioned in a previous
message to correctly figure out the VOL and NUM of the Info-CPM
digest.  (also tested with Info-IBM and Info-Kermit digests).

The new version of undigestify.c is now available via standard
anonymous FTP from SIMTEL20 as:

Filename                       Type     Bytes   CRC

Directory PD2:<UNIX.MAIL>
UNDIGESTIFY.C.2                        ASCII     5139  3DA1H

If compiled as is, the default output file names will be vv.nn.  If
LONGNAME is defined, (on Unix, at least 4.3BSD, this can be done as
cc -DLONGNAME undigestify.c), the default name will be of the form
<digest-name>.vv.nn.

I don't think it does anything special that would prevent it from
compiling with any reasonable 'c' compiler.  The mods didn't add any
new constructs that weren't already in the original except a #ifndef
directive. The original had a #ifdef.  Too bad there are so many
flavors of unix/c/etc.

David

<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>