HDTenEightyP/NetNews huggingface dataset:
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: Re: Is MC6809 microcoded ?
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Mon, 14 Dec 1992 13:33:25 GMT

ritter@cactus.org (Terry Ritter) writes:

> While I do not normally monitor this group, a friend asked me to
> look in, because, a decade-and-a-half ago, I was involved in the
> design of the 6809.

> As noted in another post, the 6809 was not microcoded.  But the
> structure was not a horribly-complex sort of centralized-state-
> machine either.

> Essentially, each group of instructions started a "timing chain"
> or sequencer which was really just a simple shift-register.  As
> a bit propagated down a chain, fully-decoded timing was provided
> for one group of instructions.  For us breadboard people, this
> was an advantage because we could work on one well-separated
> instruction group at a time.

> A timing-chain structure provides a close relationship between
> a group of instructions and the equations for that group, which
> to some extent provides a reduction of complexity.  Equation
> minimization becomes somewhat more obvious and direct.  This sort
> of structure is probably easier to understand than a centralized
> state machine.  It need not be slower.

> However, the 6809 did in fact use a huge amount of random logic
> in addition to the simple timing-chains and probably was not very
> efficient in its use of silicon.  We certainly did not have any
> research which addressed the issue at the time; this was just
> the way microprocessors were designed.  From the perspective of
> hindsight, however, I think the single-level random-logic
> structure was overtaxed, and could have been greatly minimized
> with additional decoding levels.   Another cost of a timing-chain
> design is the need to test each chain, but that is probably
> implicit in the need to test every instruction anyway.

> The timing-chain design was not a new innovation for the 6809;
> rather, it was the way that the original 6800 (in Phoenix), the
> depletion load re-do 6800 (in Austin), and other processors were
> done (in Austin).  The 6809 was intended to be expanded from the
> 6800 core (similar registers, ALU, etc.).  The 68000 was done
> differently because it was done by a completely separate (new)
> team assembled from the outside and they had different design
> experience.

> ---
> Terry Ritter   ritter@cactus.org

Finally, I get the answer (I am the question's originator).
The conclusion is 6809 is not micro-coded (at least the original
design).

Thanks for everybody answered and read this topic.  Thanks.

Mr.Sai-Kee WONG
Newsgroups: comp.sys.m6809
From: rg9538@eehp5 (Ronald E Garnett)
Subject: Re: S-record format needed
Organization: University of Illinois at Urbana
Date: Mon, 14 Dec 1992 16:42:04 GMT
Keywords: motorola, s-records



The S-Record format is explained very well in the documentation
which comes with the EVB and the EVBU boards.  I'm surprised 
that your assembler documentation does not have a description.


It's all very simple.  The HC11 recognizes 2 types of S record.
I am recalling them from memory, so I hope they are correct!


S1 <# OF DATA BYTES> <ADDRESS OF DATA BYTES(2)> <DATA BYTES (X)> <CHECKSUM (1)>

S9 <# OF DATA BYTES> <ADDRESS TO JUMP TO (2)> <CHECKSUM(1)>


THE <# OF DATA BYTES> FIELD INCLUDES ONLY THE NUMBER OF BYTES WHICH WILL
GO INTO THE MEMORY STARTING AT THE <ADDRESS OF DATA BYTES> FIELD.

tHE CHECKSUM IS THE COMPLEMENT OF THE MODULO 256 SUM OF ALL THE BYTES IN THE

Note that the <# of data bytes> field has a length of one byte, the <address
....> field has 2 bytes, and the <checksum...> field has 1 byte.

Also note that the <address to jump to> field is probably not used and will  
usually be zero.



The S9 record is considered the end of the file.


S1026000123457
S10260025678CD
s9000000FF


result:

6000: 12
6001: 34
6002: 45
6003  67


There may be errors in my description, but at least you get the idea!


Good Luck!


Ron Garnett
.

 
Newsgroups: comp.sys.m6809
From: rrhoades@cs.umr.edu (Ron Rhoades)
Subject: os-9
Date: Sat, 12 Dec 1992 22:20:17 GMT
Distribution: usa
Organization: University of Missouri - Rolla
Originator: rrhoades@mcs213j.cs.umr.edu

I've been seeing alot of postings on os-9 but what is it exactly and where can
I get a copy of it to use on my coco2.



~r end
From: avalon@coombs.anu.edu.au (Darren Reed)
Newsgroups: comp.sys.m6809
Subject: Re: 6809 & parallel processing & os-9
Date: 20 Dec 92 12:36:52 GMT
Organization: Australian National University
NNTP-Posting-Host: 150.203.76.2

joberreu@sumax.seattleu.edu (Jesse Oberreuter) writes:
[...]
>compares.  In many ways, I would still rather run OS9 Level I on a 64k
>CoCo, than MS-Windows on a 486. 

Well said :-)  OS9 on my cocoIII multitasks better than any dos program
(or windows :) that I've seen...

darren
Xref: sparky comp.sys.m6809:551 comp.sys.m68k:1488 comp.os.os9:1538
From: spam@ccwf.cc.utexas.edu (Charles E. Watson)
Newsgroups: comp.sys.m6809,comp.sys.m68k,comp.os.os9
Subject: m68HC11
Date: 19 Dec 92 23:53:41 GMT
Followup-To: comp.sys.m6809
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139

I am looking for a ftp site where I can get m68HC11 stuff.  Also,
I thought gcc had m68HC11 cross compiling but I was unable to
find it.  Also, what is the phone number to the Motorola BBS.
Please email and I will summerize.

Ciao!
From: mcarr@austin.onu.edu (Michael Carr (x1723))
Newsgroups: comp.sys.m6809
Subject: Looking for help...
Summary: cannot find documentation for smallc
Keywords: 68HC11 HC11 SMALLC MOTOROLA
Date: 15 Dec 92 18:19:04 GMT
Organization: Ohio Northern University


	This is your typical "Help me, I'm lost" message. I am desperately
trying to locate the documentation, helpful tips, or example source code for
the smallC compiler for the Motorola 68HC11 microcontroller. I have checked
out the archives on red.cs..., but there is no documentation contained
on that site or with the smallc.zip file archive.
	If anyone has successfully used this compiler, or used the 
microcontroller to design a "university project," I would love to talk
to you about some "tricks of the trade." 

		Thanks a lot,
		Michael Carr
		m-carr@onu.edu
Newsgroups: comp.sys.m6809
From: ritter@cactus.org (Terry Ritter)
Subject: Re: Is MC6809 microcoded ?
Summary: No, but . . . .
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Sun, 13 Dec 1992 06:36:48 GMT


 While I do not normally monitor this group, a friend asked me to
 look in, because, a decade-and-a-half ago, I was involved in the
 design of the 6809.

 As noted in another post, the 6809 was not microcoded.  But the
 structure was not a horribly-complex sort of centralized-state-
 machine either.

 Essentially, each group of instructions started a "timing chain"
 or sequencer which was really just a simple shift-register.  As
 a bit propagated down a chain, fully-decoded timing was provided
 for one group of instructions.  For us breadboard people, this
 was an advantage because we could work on one well-separated
 instruction group at a time.

 A timing-chain structure provides a close relationship between
 a group of instructions and the equations for that group, which
 to some extent provides a reduction of complexity.  Equation
 minimization becomes somewhat more obvious and direct.  This sort
 of structure is probably easier to understand than a centralized
 state machine.  It need not be slower.

 However, the 6809 did in fact use a huge amount of random logic
 in addition to the simple timing-chains and probably was not very
 efficient in its use of silicon.  We certainly did not have any
 research which addressed the issue at the time; this was just
 the way microprocessors were designed.  From the perspective of
 hindsight, however, I think the single-level random-logic
 structure was overtaxed, and could have been greatly minimized
 with additional decoding levels.   Another cost of a timing-chain
 design is the need to test each chain, but that is probably
 implicit in the need to test every instruction anyway.

 The timing-chain design was not a new innovation for the 6809;
 rather, it was the way that the original 6800 (in Phoenix), the
 depletion load re-do 6800 (in Austin), and other processors were
 done (in Austin).  The 6809 was intended to be expanded from the
 6800 core (similar registers, ALU, etc.).  The 68000 was done
 differently because it was done by a completely separate (new)
 team assembled from the outside and they had different design
 experience.

 ---
 Terry Ritter   ritter@cactus.org

Newsgroups: comp.sys.m6809
From: kindred@telesciences.com (David L Kindred (Dave))
Subject: Re: Stack problem.. is it a hardware or software fault?
Organization: Telesciences CO Systems, Inc.
Date: Thu, 17 Dec 1992 02:14:35 GMT

In article <steveh.723856598@tasman> steveh@tasman.cc.utas.edu.au (Steve Howell) writes:

	   Hello peoples.. ive run into a major problem with one of our 6809
   designs, and cannot figure what exactly is going on... we have a 6809 that
   crashes if an interupt occurs (of either firq and irq), and that it fails
   to maintain its stack correctly.. to reproduce the error, if we push the B
   register with a value, then push a 16 bit X on top, then pull X off, then B off,
   then B will be corrupt!.. is it RAM.. nope.. Ram works and passes every test!
   Is it the IRQ hardware line or a device interupting?.. nope. using a clean
   tight, as well as know good devices, the interupt receives a cleanly shaped
   high to low pulse. Blam!.. still dies...
   Is it ROM?.. why? everything  else works fine.. including a full on 16k
   sized program (which is IRQless and B register less) it has no problems....

One thing to remember is that the stacking operations perform multiple
consecutive memory accesses.  Normal instruction processing will
provide many, many dead cycles, and of course the alternation
between RAM and ROM.  I have seen memory designs (although they were
usually using dynamic RAMs) that would not function properly for more
than one or two consecutive cycles.  This could easily be checked with
the following code:

        pshs    a,b,cc,dp,x,y,u
        puls    a,b,cc,dp,x,y,u

and check the register contents.


						- Dave
--

EMail: kindred@telesciences.com
CI$: 72456,3226 (72456.3226@compuserve.com)
Phone: +1 609 866 1000 x222
Snail: TeleSciences C O Systems, 351 New Albany Rd, Moorestown, NJ 08057-1177
Newsgroups: comp.sys.m6809
From: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
Subject: Re: 6309 extra op codes
Reply-To: zambotti@wpowz.wpo.dec.com (Walter Zambotti)
Organization: Digital Equipment Corporation
Date: Wed, 16 Dec 1992 03:01:42 GMT


In article <1992Nov25.155509.18053@mintaka.lcs.mit.edu>, mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
|>Newsgroups: comp.sys.m6809
|>Path: tkou02.enet.dec.com!jrdzzz.jrd.dec.com!e2big.mko.dec.com!nntpd.lkg.dec.com!news.crl.dec.com!deccrl!enterpoop.mit.edu!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!think.com!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!mikc
|>From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
|>Subject: 6309 extra op codes
|>Message-ID: <1992Nov25.155509.18053@mintaka.lcs.mit.edu>
|>Summary: More new secret 6309 instructions
|>Sender: news@mintaka.lcs.mit.edu
|>Organization: /etc/organization
|>Date: Wed, 25 Nov 92 23:55:09 WST
|>Lines: 128
|>
|>
|>  The following was posted to fidonet's Os-9 conference and I didn't see
|>it posted here. It was also on Delphi, Compuserve, GEnie. Please post 
|>in other appropriate places and save in the archives.
|>  For those who might have missed previous articles, the 6309 processor
|>is not only a copy of the 6809 but has a native mode with many new 
|>instructions that were never published. The following adds to the list.
|>
|>From:    Curtis Boyle 
|>To:      All                                      Msg #129, 31-Oct-92 00:37EST
|>Subject: 6309 info 
|>
|>                        6309 Information Addendum 
|>                        ------------------------- 
|> 
|>                            By L. Curtis Boyle 
|>                               Oct. 30, 1992 
|> 
|>     1st, a correction to Chet Simpson's HD63B09EP Technical Reference Guide: 
|>When an interrupt occurs in native mode, the order of the register stacking
|>he had is wrong (as was discovered in the writing of Gale Force's NITROS9
|>package). The proper sequence is as follows: 
|>
From: lylec@westminster.ac.uk (Jiri Kantor)
Newsgroups: comp.sys.transputer
Subject: need: boo4 or compatible to work with my PC (cheap)
Date: 17 Dec 92 13:49:11 GMT
Distribution: uk
Organization: University of Westminster

or some directions as to where to start looking.

email or phone 071-624 8086 in the evening (ask for Jiri)
Newsgroups: comp.sys.transputer
From: roger@inmos.co.uk (Roger Shepherd)
Subject: Re: REQ: T9000 Status
Organization: Inmos Limited, Bristol
X-Newsreader: TIN [version 1.1 PL8]
Date: Mon, 14 Dec 1992 09:49:52 GMT

I am not commenting on availability, I just wanted to clarify something.

Jacob Hirbawi (jcbhrb@nic.cerf.net) wrote:

:   (1) A fully functional T9000 including the virtual channel capability
:       will be ready around March 1993. This will not be a 50-Mhz part, but
:       will run somewhere around 25-40 MHz. The link speed should still be
:       100 Mbits/sec (this part doesn't make too much sense to me but that's
:       what I was told!). 

On the T9000 the links and processor speeds are determined
indepentdently. There is no reason why a 25 Mhz T9000 should not have
100 Mbit/s links. Remember, all transputers are clocked at 5 Mhz,
whatever the speed of the processor/links. T800 transputers are
available at 20/25 and 30 Mhz, all of which support links running at
5/10/20 Mbit/s.


--
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
Newsgroups: comp.sys.transputer
From: belkacem@funk.ibp.fr (Zerrouk BELKACEM)
Subject: interval routing
Organization: Laboratoire MASI, Paris, France
Date: Tue, 15 Dec 1992 16:09:33 GMT

Reply-to: zerrouk@masi.ibp.fr

Hi, 

I'm working on a VLSI implementation of a message router using interval
 labeling like in the INMOS C104.

I would like to have some contacts with persons working in this field.
And, welcome for informations on the recent advances concerning
 this domain.

 The only refences i have are the following:  

J.Leewen and R.B Tan, "Interval labeling", the computer journal vol30 1987.

N.Santoro and R.Khatib, "Labeling and implicit routing in networks", the
computer journal vol 28 1985. 

If you have e-mails of these authors please send them to me.

Thanks in advance.

Belk.
    
       +---+                          Belkacem ZERROUK
      / \ / \              
     /   /   \                         Equipe CAO&VLSI
    +---+ \   \                       Laboratoire MASI
     \   \ +---+                Institut Blaise Pascal
      \   /   /
       \ / \ /   Couloir 55-65, 2eme etage, Bureau 213
        +---+    Universite Pierre et Marie Curie (P6)
                 4 place Jussieu, 75252 Paris Cedex 05

   Tel: (33.1) 44.27.71.23,   Fax: (33.1) 44.27.62.86
   Telex: UPMCSIX200145F, e-mail: zerrouk@masi.ibp.fr
.
From: teig@autro1.UUCP (Oyvind Teig)
Newsgroups: comp.sys.transputer
Subject: What is an event-driven system?
Date: 16 Dec 92 09:36:41 GMT
Reply-To: teig@autro1.UUCP (Oyvind Teig)
Organization: Autronica A/S, Trondheim, Norway


Event driven systems

I have always thought of occam as "event driven". A single SEQ
occam program may be event driven with the external world, but not
internally. When PARs come into it, isn't occam really VERY
event driven - even more than MS-Windows programs??

Please help me, I have a dispute going :-)

0yvind Teig
Autronica, Trondheim, Norway
From: knut@uni-paderborn.de (Knut Menzel)
Newsgroups: comp.sys.transputer
Subject: PixelPlane machine?
Date: 15 Dec 1992 16:04:57 GMT
Organization: University of Paderborn
Distribution: world
Reply-To: knut@uni-paderborn.de
NNTP-Posting-Host: ruhr.uni-paderborn.de
Keywords: PixelPlanes, parallel, rendering, transputer


Hi colleagues,

does anyone out there know some details about the
PixelPlane architecture used at University of North
Carolina. I think it is transputer based...

Best wishes,
-- Knut Menzel

--------------------------------------------------------------------------
 Knut Menzel                          University of Paderborn
 email:   knut@uni-paderborn.de       Department of Computer Science FB17
          ...!uunet!unido!pbinfo!knut Warburger Str. 100
 Tel:     +49 5251 603325             D-4790 Paderborn
 Telefax: +49 5251 603853
--------------------------------------------------------------------------
From: trivedi@picasso.ocis.temple.edu (Hemang Trivedi)
Newsgroups: comp.sys.transputer
Subject: Re: What is an event-driven system?
Date: 18 Dec 92 20:53:54 GMT
Organization: Temple University
X-Newsreader: TIN [version 1.1 PL8]

I would call anything which is "parallel message-passing" as
event driven.

Hemang
Newsgroups: comp.sys.transputer
From: parsytec@ux2.cso.uiuc.edu (Brian Upper - Invoice)
Subject: Re: REQ: T9000 Status
Organization: University of Illinois at Urbana
Date: Fri, 11 Dec 1992 22:37:57 GMT
Keywords: T9000

wjs@re3sc139h.gmr.com writes:

>Are there any OEMs listening out there who have received or begun
>development of board products using T9000 ?  It's been a while
>since I've heard a reliable status of the chip.  Does it have
>the virtual channel capability yet ? What about the packet routing
>chip availability ? 

>			Walt Stuart

>			GM Research Laboratories
>			Electrical/Electronics Dept. (E3)
>			Warren, Mi.


Parsytec has been developing products around the T9000 for quite some time.
We have under development MPP systems based on the T9 as well as special
equipment for image processing and real time applications.  
The first T9000 beta chips are in our lab and are already working on some
of our boards. 

For specific questions about functional units I would refer you to Inmos.

For questions in regard to our developments give us a call.


Reinhard Rinn
Parsytec Inc
West Chicago,  IL
Tel.: (708) 293 9500
From: fred@wuee1.wustl.edu (Fred U. Rosenberger)
Subject: Re: REQ: T9000 Status
Organization: Washington University, St. Louis Mo.
Date: Sat, 12 Dec 1992 14:51:51 GMT

Seems the T9000 is too late to be very useful.
WHAT IS STATUS OF THE GENERATION AFTER THE T9000?
Almost ready?  4 or 5 years away?  Never?
I have not heard anything about this except for some very preliminary
discussion by David May at a WOTUG conference.

Seems that the decision to invest time/effort/dollars in using the
T9000 depends to a major extent on what follows (and when).


Fred
Newsgroups: comp.sys.transputer
From: 891306r@dragon.acadiau.ca (Ganapathy R.)
Subject: Requesting A Book List for Occam Programming
Organization: Acadia University
Date: Fri, 18 Dec 1992 18:02:17 GMT

Greetings.

I am presently working on a network of four transputers,
implementing concurrent algorithms. My references are the 
manuals which came along with the Education Kit. I would 
like to request for recommendations on books for Occam 2
programming.

Also where can I get posters, pictures or slides on transputers?
This would help me in presenting a seminar in the next few months.


Thank you.

Cheers
Ganapathy
-- 
*******************************************************************************
Ganapathy Ramachandran   ganapathy.r@acadiau.ca	 Believe In Imagination And 
P.O. Box 112, Wolfville  Acadia University	 It Will Bring You To  
N.S. Canada B0P 1X0      Tel : 542-9920		 Never Never Land.........      *******************************************************************************
From: wjs@re3sc139h.gmr.com
Newsgroups: comp.sys.transputer
Subject: REQ: T9000 Status
Keywords: T9000
Date: 11 Dec 92 18:53:47 GMT
Article-I.D.: rphroy.94900
Organization: General Motors/EDS

Are there any OEMs listening out there who have received or begun
development of board products using T9000 ?  It's been a while
since I've heard a reliable status of the chip.  Does it have
the virtual channel capability yet ? What about the packet routing
chip availability ? 

			Walt Stuart

			GM Research Laboratories
			Electrical/Electronics Dept. (E3)
			Warren, Mi.
From: jcbhrb@nic.cerf.net (Jacob Hirbawi)
Newsgroups: comp.sys.transputer
Subject: RE: REQ: T9000 Status
Date: 11 Dec 92 23:46:12 GMT
Organization: CERFnet

In comp.sys.transputer <94900@rphroy.ph.gmr.com>
Walt Stuart <wjs@re3sc139h.gmr.com> writes:

> Are there any OEMs listening out there who have received or begun
> development of board products using T9000 ?  It's been a while
> since I've heard a reliable status of the chip.  Does it have
> the virtual channel capability yet ? What about the packet routing
> chip availability ? 

I'm not sure that I would consider myself an OEM; but I have just finished
talking to representatives from Inmos, Parsytec, and Transatec about the
T9000 (and other things) and I can perhaps summarize the impressions I got:

  (1) A fully functional T9000 including the virtual channel capability
      will be ready around March 1993. This will not be a 50-Mhz part, but
      will run somewhere around 25-40 MHz. The link speed should still be
      100 Mbits/sec (this part doesn't make too much sense to me but that's
      what I was told!). The price should be around $600.

  (2) The 50 MHz T9000 should be out around September 1993. The price should
      be around $900.

  (3) The C104 (32x32 multiplexer -- the T9000 equivalent of the C004) won't be
      out until June 1993. In the meantime there is an 8x8 implementation as an
      ASIC (C103) -- this is either available now or soon; I did not pay too
      much attention since I doubt that I will use it.

  (4) The C100 (T9000 link adapter) should also be available early in 1993.

  (5) The software to develop T9000 code will be first available for SUN
      platforms. The IBM-PC/DOS version (the one I'm interested in) should
      be out three weeks after the introduction of the T9000 -- i.e. around 
      April 1993. Unlike the older D705 and D7205 this will (also?) run on the
      host processor (486 for example). Of course you will still need a link 
      adapter card on your PC bus to download the code to the target 
      transputers. A 50 MHz 486 should compile and link OCCAM code a bit 
      faster than a T800.

  (6) Parsytec expects to have deliverable T9000 products by June 1993 --
      the specific item I asked about was a T9000 on a VME bus. Judging
      by the delivery dates above it doesn't look like anyone will have
      any products before this date and even then it will be with the slow
      T9000.

This information is somewhat discouraging and I would be more than glad to
find out that things are not so gloomy. Along with the other Transputer
faithfuls I will probably end up waiting for the T9000 until *whenever* it
comes out; but for now I am forced to use another processor for a contract
that must be completed by August 1993. I will be getting a number of
Transatec's i860-T800 modules ($7500 a pop for an 860 with 16 MByte DRAM,
and a T800 with 4 MByte DRAM). This is definitely not my first choice but
it's the only product that can do the job *now*.

Jacob Hirbawi
JcbHrb@CERF.net
Newsgroups: comp.sys.acorn
From: jmarten@cix.compulink.co.uk (Jonathan Marten)
Subject: Re: Indirected template icons
Reply-To: jmarten@cix.compulink.co.uk
Date: Wed, 16 Dec 1992 20:10:00 +0000

 
  Frank Lancaster (fl@tools.de) writes:
 
  fl> Beware: using resspr_area in the window templates forces you to
  fl> define the sprites for radio buttons etc. in your sprite file. This
  fl> is a waste of space since they are already in the wimp sprite area. 
 
This has been fixed under RiscOS 3.  If a window specifies sprites from a 
user area, but the required sprite is not found in that area, then the 
window manager will look for it in the Wimp sprite pool and use it from 
there if it exists.
 
-- JJM --   Using ReaderS with thread following
            Acorn DTP user... and proud of it!