HDTenEightyP/NetNews huggingface dataset:
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: Re: The 68B09 in SMD package..if not.. why not!
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Sat, 9 Jan 1993 14:03:10 GMT

steveh@tasman.cc.utas.edu.au (Steve Howell) writes:

>Have i looked or what!.. i cant find a SMD version, of the most powerful 8
>bit processor i have ever come across.. the 6809. anywhere!.

>there are heaps of HC11, 6303 etc etc.. but nothing in the full blown 6809
>in a SMD package... I have tried Motorola, Hitachi and SGS-Thomson (ST) and
>all fail to manufacture a SMD version of their 6809's...

>My request is.. does anyone know anyone who makes a SMD version of the 68B09P
>(not E)... as i dearly need it for a new design...

>if it results in the fact that a 6809 is not avail, what are your suggestions
>on changing the code somewhat and going with a 68008?

I love 6809 as well as 68008.  We cannot compare which one is better,
the 6809 has some addressing mode you cannot find in 68000.  The 6809 is
definitely nice.  Programming 68008 is not changing the 6809's code
somewhat, it shall be a different thing.  But if you really need a
surface mount CPU, I think you do not have much choice -- use 68008
instead of 6809.

What is your new design?  I had designed and routed a 6"X4"(Europe card
profile) 68008 CPU board 2 years ago.  It has 2 serial ports, battery
backed static RAM and a 8bit address + 8bit data bus + 7 interrupt lines
to outside world.  With 8 sockets for 256K/1M bits SRAM/EPROM.  It is
intended for use on a 10 slots (8bit A & D bus) backplane.

Currently, I am soldering the second card (also designed and routed by
me) -- a graphics card used with the 68008 CPU.  It employs the TMS34010
as graphics processor, 512KB VRAM, 2MB DRAM, a 16/4096 palette and a
keyboard interface to IBM PC keyboard.

Mr.Sai-Kee WONG

>thanks

>Steve Howell
Newsgroups: comp.sys.m6809
From: steveh@tasman.cc.utas.edu.au (Steve Howell)
Subject: 68008 address demultiplers?.is it this simple?
Organization: University of Tasmania, Australia.
Date: Mon, 11 Jan 1993 01:29:08 GMT



ok.. its been somewhat confirmed that a 6809 is not avail in a SMD package, so
i guess the time has come to go 68k at long last.

just a few questions before i dive in...
can i do the following with a mc68008?

1) can i use the upper address lines thru say a 74ls138 (3-to-8) decoder
to create the enable signal for each pheripherial?.. or do i need some
complex PAL or something (like everone elses uses that ive seen!)

2) the E timing signal on the 68000. is it on the 68008?

3) what is the base address for RAM ($0000 is what a 6809 is at, but i hear its
not this simple with 68k devices?.. is this right)

4) Can i put ROM anywhere i like in the address map? (as long as its big enough)


Thanks

Steve H

Newsgroups: comp.sys.m6809
From: ulan@ee.ualberta.ca (Dale Ulan)
Subject: Re: What is an MC68HCP11A1FN?
Organization: University Of Alberta, Edmonton Canada
Date: Tue, 5 Jan 1993 02:39:55 GMT

sr3745@dean1.usma.edu (Roeber Rodney MAJ) writes:

>Active Electronics sells the MC68HC11A1FN (I know what this one is) and
>the MC68HCP11A1FN.  What is the difference between the HC and the HCP?
>Active shows the difference is $1.00 but how about funtionality or packaging?

The MC68HC11A1FN is listed as having $0D in the config register,
where the MC68HCP11A1FN has $09 in the config register. 
The difference simply turns on the COP timer in the P11 version.
Since you can enable it by re-programming the config register
(refer to the manuals for how to do this.... it's a bit different
from doing normal EEPROM programs), get the cheaper of the two,
probably the HC11A1 (no P). Because of the COP timer, the various
monitors (like Buffalo) won't run on the P long enough to re-program
the config register, although you could write a program that would do
it and burn it into an EEPROM.

-----------------------------------------------------------------------------

Dale Ulan		ulan@ee.ualberta.ca  (Computer Eng. Undergrad)
VE6DAU
From: sr3745@dean1.usma.edu (Roeber Rodney MAJ)
Newsgroups: comp.sys.m6809
Subject: What is an MC68HCP11A1FN?
Date: 4 Jan 93 02:05:08 GMT
Organization: US Military Academy, West Point, NY

Active Electronics sells the MC68HC11A1FN (I know what this one is) and
the MC68HCP11A1FN.  What is the difference between the HC and the HCP?
Active shows the difference is $1.00 but how about funtionality or packaging?
Newsgroups: comp.sys.m6809
From: tmorris@bruny.cc.utas.edu.au (Tim Morris)
Subject: Can anyone recommend an editor?
Organization: University of Tasmania, Australia.
Date: Tue, 5 Jan 1993 06:43:31 GMT


I'm going to be writing some large programs in 6809 assembly language and
I need a good editor that runs on an IBM PC 486 under Windows 3.1.  The
feautures I'm looking for:

  1.  Speed (this is important for when I need to page around a lot - I
      guess this means a text-mode editor of some sort).
  2.  Flexible tab stops so I can have long label names (poreferably
      "smart" tabs like most dedicated assemblers have).
  3.  Ability to support a large screen (1024x768).

Up until now I've been using Turbo Pascal 6.0, which scores an "A" on
speed but an "E-" on the other two.  Does anyone have any recommendations?
(Especially the names of any "dedicated" editors, but anything will do).

Thanks in advance,
Tim Morris,
University of Tasmania,
Australia.

Newsgroups: comp.sys.transputer
From: dhd@exnet.co.uk (Damon)
Subject: Re: Transputer Conference
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Fri, 8 Jan 1993 11:05:20 GMT

In article <96119@rphroy.ph.gmr.com> djp@re3sc139h.gmr.com writes:
>
>    Does anyone have knowledge of the Transputer's Users Group
>conference in Vancouver. I would appreciate any information.

From the Parallelogram Diary:

May 10--11

NAUTG6: Transputer---Research and Applications
Vancouver, BC, Canada
Tel: +1 607 273 8664
Fax: +1 607 255 9346
Email: fielding@theory.tc.cornell.edu
(David L Fielding)

Damon
-- 
Damon Hart-Davis        London, UK        Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.36] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.sys.transputer
From: maurro@inf.utfsm.cl (Mauricio Gomez Calderon)
Subject: On-chip Ram: Helios, D7205
Date: Thu, 07 Jan 1993 20:02:47 GMT
Organization: Informatica UTFSM
X-Newsreader: TIN [version 1.1 PL8]

Hi Again...

   I was testing the on-chip RAM for a single Transputer:

   
   In Helios, i tried to accelerate a small test routine, using the
   fast on-chip Ram memory. The code is as follows:

   void cycle(int iterations) {

        int i;
	for(i=0; i<iterations; i++) {
	    /* nothing! */
	    }

   }

   In a normal situation, this takes 14 sec for 10,000,000 iterations.
   Using on-chip Ram, this takes 6 sec for      10,000,000 iterations.


   But in D7205 Occam 2 Toolset, if i try to do the same...

   VAL INT iterations IS 10000000:
   SEQ
     clock ? time1
     i := 0
     WHILE ( i < iterations )
       SEQ
         -- nothing!
	 i := i + 1
     clock ? time2


   In a normal situation, this takes 10 sec for 10,000,000 iterations.
   Using order.code := -1 in the .pgm this takes 14 sec for the same iterations.

   I suppose that this occurs because the occonf try to optimize by default
   the use of the on-chip RAM for small routines...

   But what about the best times? 6 sec in Helios and 10 sec in D7205 for the
   almost 'same' application... Furthermore, the occam process is the only
   process in the transputer...

   Why this difference?         Thanks in Advance...


                                                                       Maurro
								      
Newsgroups: comp.sys.transputer
From: maurro@inf.utfsm.cl (Mauricio Gomez Calderon)
Subject: On-chip RAM using D7205.- Help!
Date: Wed, 06 Jan 1993 19:05:26 GMT
Organization: Informatica UTFSM
X-Newsreader: TIN [version 1.1 PL8]



Hi...
      In order to accelerate a numerical calculation, I'm trying to put
      small code in the fast on-chip RAM, using

          SET processor (order.code := -1)
	  MAP logical.processor ONTO processor

      and the corresponding /RE option on the occonf.

      It works... but don't increases the speed!!!

      The small code is a small program that perform 1000000 iterations
      changing only 5 REAL64 variables. This code is put into five transputers
      connected like a ring. Communications take place only 3 times over the
      network.



      What's wrong???



                                                            Maurro
From: conor@lion.inmos.co.uk (Conor O'Neill)
Subject: Re: On-chip RAM using D7205.- Help!
Organization: INMOS Limited, Bristol, UK
Date: Thu, 7 Jan 1993 12:18:50 GMT

In article <1993Jan06.190526.42203@dcc.uchile.cl> maurro@inf.utfsm.cl (Mauricio Gomez Calderon) writes:
>Hi...
>      In order to accelerate a numerical calculation, I'm trying to put
>      small code in the fast on-chip RAM, using
>
>          SET processor (order.code := -1)
>	  MAP logical.processor ONTO processor
>
>      and the corresponding /RE option on the occonf.
>
>      It works... but don't increases the speed!!!
>
>      The small code is a small program that perform 1000000 iterations
>      changing only 5 REAL64 variables. This code is put into five transputers
>      connected like a ring. Communications take place only 3 times over the
>      network.
>
>      What's wrong???

Try looking at the file produced by the collector's -p option.
This tells you where the code and data etc has been placed for each processor.
This will show you exactly what effect the various changes you make are
having to the memory layout.
In general, it is better to place workspace on-chip, because transputers
make more accesses to data than to code. This is why this is the
default behaviour of the configurer.

If your example really is as simple as you describe, you will probably   
find that both code and data are already on-chip, so changing their order
will have no effect.

Hope this helps.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
From: butenuth@i30fs1.ira.uka.de (Roger Butenuth)
Newsgroups: comp.sys.transputer
Subject: Inmos C, file format: .rsc
Date: 6 Jan 1993 15:55:12 GMT
Organization: University of Karlsruhe (Germany)
Distribution: world
NNTP-Posting-Host: i30s20.ira.uka.de

The Inmos Toolset has the ability to produce `.rsc' files, which are
dynamic loadable. Does anybody know, how to load these files?
What is the format of the files? First comes a 10 word header, following
the code of the first compiled function. What happens before `main' is 
called? Which values in W are expected?

Roger Butenuth,
Universitaet Karlsruhe,
Institut fuer Betriebs- und Dialogsysteme



Newsgroups: comp.sys.transputer
From: droux@hei.unige.ch
Subject: Simulating procedure call
Organization: University of Geneva, Switzerland
Date: Thu, 7 Jan 1993 16:27:11 GMT


I am currently writing an occam program that uses a mathematical 
library. The functions provided by this library typically gets 
two-dimensional open arrays and vectors of real number, as well 
as atomic types and channels. 

The calculations that are involved can get very large matrices 
using megabytes of memory. As the size of these matrices is not 
known at compile time, I have opted for a "dynamical" allocation 
method where a memory pool is shared among various data. With 
this method, a vector can be allocated as follows:

  allocate.memory(memory.pool, size, vector.ptr) -- alloc size words
  [] REAL64 vector RETYPES [memory.pool FROM vector.ptr FOR size * 2] :
  
A problem is that the same method does not work with more than one 
dimensions, as only one dimension can be omitted, for example:

  [][] REAL64 matrix RETYPES [memory....         -- allowed
  [100][] REAL64 matrix RETYPES [memory...       -- not allowed
  
To bypass this problem, a solution is to define a "flat" matrix, 
stored as a one dimensional vector. The index of the elements in 
this vector are then calculated using the known dimensions of the 
matrix. For example:
  
  [] REAL64 flat.matrix RETYPES [memory.pool FROM matrix.ptr FOR
                                 size * size * 2] :
				 
This matrix should be then given as parameter to the calculation 
routine. Unfortunately, due to the strong type checking of occam, 
this is not possible simply by calling the function with flat.matrix 
as argument. As I have seen in the Inmos manuals, a two dimensional 
array is passed to a procedure as three values: a pointer to the 
array, the first dimension and the second dimension of the array. 

My idea would be to simulate a call to the procedure by passing 
these three information. A possibilty to do this should be the use 
of the ASM construct to build the workspace containing the correct 
parameters and calling the function. Unfortunately, I have no 
experience writing Transputer assembler and I don't know how the 
arguments are passed to a procedure. Does anybody can tell me if 
this solution is realistic, and how I can simulate a such call ?

Nicolas Droux, droux@cs.isbiel.ch
Engineering College of Biel, Switzerland
Computer Science Dpt.
From: dca@dcs.exeter.ac.uk (Duncan Campbell)
Newsgroups: comp.sys.transputer
Subject: Distributed Shared Memory
Date: 5 Jan 93 11:01:52 GMT
Organization: Computer Science Dept. - University of Exeter. UK

Does anybody out there have any information on any work that has been
performed on the implementation of Distributed Shared Memory (DSM)
over Transputer networks?  Please e-mail me if you do.

I will post the replies if I receive sufficient response.

	Duncan

*******************************************************************************
Duncan Campbell                * The views expressed above are not my own, they
Department of Computer Science * are those of my employer, and I am just a pawn
University of Exeter,          * acting as a mouth-piece for my employer :-)
Prince of Wales Road,          ************************************************
Exeter  EX4 4PT              Tel:  +44 392 264063  Telex:  42894 EXUNIV G
United Kingdom               Fax:  +44 392 264067  e-mail: dca@dcs.exeter.ac.uk
*******************************************************************************


-- 
*******************************************************************************
Duncan Campbell                * The views expressed above are not my own, they
Department of Computer Science * are those of my employer, and I am just a pawn
University of Exeter,          * acting as a mouth-piece for my employer :-)
Newsgroups: comp.sys.transputer
From: conor@lion.inmos.co.uk (Conor O'Neill)
Subject: Re: On-chip Ram: Helios, D7205
Organization: INMOS Limited, Bristol, UK
Date: Fri, 8 Jan 1993 17:57:06 GMT

In article <1993Jan07.200247.37029@dcc.uchile.cl> maurro@inf.utfsm.cl (Mauricio Gomez Calderon) writes:
>   But what about the best times? 6 sec in Helios and 10 sec in D7205 for the
>   almost 'same' application... Furthermore, the occam process is the only
>   process in the transputer...
>
>   Why this difference?         Thanks in Advance...

I can perhaps offer one suggestion; you are not comparing similar programs.
 
I know it sounds trivial, but in C you are using:

>   void cycle(int iterations) {
>
>        int i;
>       for(i=0; i<iterations; i++) {
>           /* nothing! */
>           }
>
>   }

whereas in occam you have:
      
>   VAL INT iterations IS 10000000:
>   SEQ
>     clock ? time1
>     i := 0
>     WHILE ( i < iterations )
>       SEQ
>         -- nothing!
>        i := i + 1
>     clock ? time2
       
The C version holds `iterations' as a variable, whereas the occam program
has a constant. Large constants are (relatively) expensive on a transputer;
it is faster to load a local variable than to generate the
constant '10000000'.
       
Try changing the occam to something equivalent to the C:

  PROC cycle(VAL INT iterations)
    INT i :
    SEQ
      i := 0
      WHILE i < iterations
        i := i + 1
  :
  
You will find that this is the entire reason for the change.

The D4205A compiler produces this for the version with the constant
value for `iterations':

       0: 20 20 20                pfix    0
       3: 60 BF                   ajw     -1
       5: 40                      ldc     0
       6: D0                      stl     0
       7: 29 28 29 26 28 40       ldc     10000000
      13: 70                      ldl     0
      14: F9                      gt
      15: A5                      cj      5
      16: 70                      ldl     0
      17: 81                      adc     1
      18: D0                      stl     0
      19: 60 02                   j       -14
      21: B1                      ajw     1
      22: 22 F0                   ret

and this for the version where it is a formal parameter:

       0: 60 BF                   ajw     -1
       2: 40                      ldc     0
       3: D0                      stl     0
       4: 72                      ldl     2
       5: 70                      ldl     0
       6: F9                      gt
       7: A5                      cj      5
       8: 70                      ldl     0
       9: 81                      adc     1
      10: D0                      stl     0
      11: 60 07                   j       -9
      13: B1                      ajw     1
      14: 22 F0                   ret

The same problem would occur in C if you used the constant in the for loop.

---
Conor O'Neill, Software Group, INMOS Ltd., UK.
UK: conor@inmos.co.uk		US: conor@inmos.com
"It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
Newsgroups: comp.sys.transputer,comp.realtime,comp.specification,comp.specification.z
From: bergman@cyklop.nada.kth.se (Magnus Bergman)
Newsgroups: comp.sys.transputer
Subject: REQUEST FOR PARALLEL APPLICATIONS
Date: 8 Jan 93 20:11:16 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden



          REQUEST FOR PARALLEL APPLICATIONS

In the search for partners in the area of applied parallel
computing we would like to create a list of applications
available on (or suitable for) parallel platforms.

The programming models might be data-, control-parallel or a
combination of both. Machine architectures of interest are
SIMD, MIMD, clusters of Workstation or a combination of those
three.

If this list becomes interesting I will post it to this news group.

Please post to: bergman@nada.kth.se

Dr. C.M. Bergman
Center for Computational Mathematics and Mechanics
Department of Numerical Analysis and Computing Science
Royal Institute of Technology
S-100 44 Stockholm

Tel: +46 8 790 6267 * Fax: +46 8 790 0930 * Mobile: +46 10 228 02 91
Newsgroups: comp.sys.transputer
From: jipping@cs.hope.edu (Mike Jipping)
Subject: OS Project for Transputers
Organization: Hope College Dept of CS
Date: Thu, 7 Jan 1993 12:33:04 GMT

I'm searching for a platform to teach an operating system class -- with a
good OS writing project.  We have this nifty Transputer network just
waiting for software....

Has anyone taught an OS class or designed an OS for a Transputer?  I'm
looking for a contained project, doable in a semester, for 1 or more
Transputers.  

Hey, I'll take any ideas you want to float to me.  Many Thanks!

      Mike Jipping
      Hope College Department of Computer Science
      jipping@cs.hope.edu  (BITNET: JIPPING@HOPE)

      "It was a marketing coup ... to rename SunOS 4.1.X to 
       Solaris 1.0.  That way, Solaris 2.X could be called 
       an upgrade..."
                                    -- Rob Kolstad, SUG '92
From: djp@re3sc139h.gmr.com
Newsgroups: comp.sys.transputer
Subject: Transputer Conference
Date: 7 Jan 93 21:53:22 GMT
Organization: GM


    Does anyone have knowledge of the Transputer's Users Group
conference in Vancouver. I would appreciate any information.

    Thanks,

    Doug Priemer
    General Motors Research Laboratories
    E3 Department
    30500 Mound Round
    Warren, MI
    48090-9055
    djp@re3sc139h.gmr.com
From: a909937@tiuk.ti.com (Graham Barr          (0004 bodg))
Subject: Re: Grab Keys
Reply-To: a909937@tiuk.ti.com
Organization: Texas Instruments Ltd.
Date: Tue, 12 Jan 1993 19:26:34 GMT


In article 1iv2qsINNp76@clover.csv.warwick.ac.uk, cstadge@csv.warwick.ac.uk (Mr G R Douglas) writes:
>In article <1993Jan12.173249.13904@aston.ac.uk> braindl@uhura.aston.ac.uk (David Brain) writes:
>>I was messing around with the resources on an A5000, and I found in the
>>(I think) wimp directory a template for a window with a green border, and
>>yellow title (etc) called Grab Keys ...
>>
>>..What's this for, when does it appear ? 
>>
>You can get that on a normal Archi can't you - there is a odd window you can
>get using the task manager resources on an A3000... Dunno what it's for.
>
>
>Anybody ever tried giving the icon bar sliders and movers - then making the
>desktop green - pseudo ST!
>
>	-Giles


The Task manager uses the 'Grab Keys' window to grab F12, Shift-F12, etc for
the * Commands and Task Window.

Graham Barr
a909937@server1.tiuk.ti.com

You don't get anywhere without Risc's
From: gilbertd@cs.man.ac.uk (David Alan Gilbert)
Newsgroups: comp.sys.acorn
Subject: New version of WinLook
Date: 8 Jan 93 11:40:42 GMT

I've just posted a new version of WinLook
onto uts.mcc.ac.uk - it may not be available
immediatly

The program allows a window to be grabbed forcibly off the
screen - it then displays all information on the window and all
information on the icons in it.  A diagnostic section warns of icons
of the work area/extent etc.

It can then save the window as a template file, or as a textual
description.


The new features are( V1.09 3/1/93):-


1) It can grab a window as a sprite (very useful when writing manuals
and no need to trim down!) - even with pane windows (Ctrl+Shift+F6)

2) The hot keys can be changed.

3) The hot keys work more reliably - there used to be a bug in which
they stopped working - I think they work 99.9% of the time now (at least!!!)

There is one unfortunate problem - the preferences window (for
the hot keys doesnt seem to work on Risc OS 2 - if anyone
out there would tell me why it will get fixed - the template
is OK and it works fine under Risc OS 3.1)

Dave

--
-------------------------------------------------------------------------------
- David Alan Gilbert - gilbertd@cs.man.ac.uk - G7FHJ@GB7CRG                   -
------(Programmers don't sleep - they just park their heads)-------------------
Newsgroups: comp.sys.acorn
Subject: Re: No subject 
From: epoo1@cs.aukuni.ac.nz (Edouard Poor)
Date: Sun, 10 Jan 1993 11:50:42 GMT
Organization: Computer Science Dept. University of Auckland

amclintock@cix.compulink.co.uk ("Cray Communications, Alex McL") writes:

>I have both ZIP and the recently posted infocom,
>but I can't get either to work with my infocom .dat 
>files. I have hitchhik, leatherg, and zork1 from a pc.

>I do have original infocom games from my pcw, but 
>getting them off those funny amstrad disks is a pain 
>in the butt.

>Has anyone a) got them to work.
>           b) not got them to work?

mark me down for a)... I've got about 27 infocom adventures going so far,
(Lost treasures of Infocom [mac version] accounting for most of those) and
the only thing that was nessessary was to ftp the files across to my Arc.

As long as you are transferring the story.dat file OK then I cant see any 
problems... Try transferring the files back onto PC disc and see if they
still go--that should at least eliminate that possibility.

I do recall that some versions of infocom games came on specialy formatted
discs--some of the PC ones I think, as well as other versions like the c64
ones... The PC has a program that allows you to change a PC protected 
infocom adventure into an unprotected one, but I don't have it about
(check local PC BBS though.) I don't think those games had story.dat files
though, so I suspect that this is not your problem.

Edouard