textfiles/messages/ALANWESTON/1994/CIS01_19.txt

#: 19617 S1/General Interest
    17-Jan-94  07:13:03
Sb: #19601-NEW member
Fm: Steve Wegert 76703,4255
To: M. Raabe 100327,1526

 > I'm new inhere and I'm interrested in OS-9/680x0.
 > Especially am I starting migrating the OS-9-Port of
 > 030/040/060/302/340-mashines from V2.4.5 to V3.0.
 > Is anybody here interrested in non-COCO-stuff?
 > If possible contact me by internet under 'mraabe@eltec.de', because
 > I'm seldom polling Compuserve, but I read EMail on Internet daily!


There's quite a bit of interest in non-CoCo stuff. There are a number of us
using the MM/1 computer running a 68070 processor (68000).

How are you using your system? Industrial? Personal?

*- Steve -*


#: 19624 S1/General Interest
    18-Jan-94  22:11:38
Sb: Microware in WSJ
Fm: Frank Hogg of FHL 70310,317
To: All

Microware in WSJ

There is a very interesting article about Microware in The Wall Street Journal
no less! It is on page B1 of the Tuesday January 18, 1994 issue. The title is:
"Little Microware Aims to Be a Multimedia Giant" Even has one of those WSJ dot
ink pictures of Ken Kaplan. He looks good in the pic too. Talks about the CoCo
and lots of other very interesting things. Check it out.

Frank

#: 19613 S10/OS9/6809 (CoCo)
    16-Jan-94  18:52:49
Sb: scribe
Fm: Bob van der Poel 76510,2203
To: All

Can someone post the source or just binary to the program 'scribe' here or to
my cis mailbox. Scribe is a program which expands compressed fidonet messages.
Thanks.

#: 19612 S12/OS9/68000 (OSK)
    16-Jan-94  17:03:02
Sb: #19599-Printing problems
Fm: ole hansen 100016,3417
To: keith bauer 71102,317

Hello Keith

I will be out on the road from Monday through Wednesday. Hopefully you have it
running before Thursday.


regards

ole@danelec.dk

#: 19614 S12/OS9/68000 (OSK)
    16-Jan-94  18:52:59
Sb: #19609-#CDI Computer News
Fm: Bob van der Poel 76510,2203
To: Eric Crichlow 71051,3516 (X)

> but as I understand it, the "memcpy ()" call in C copies data one > byte at a
time.

Nope, you are not going to get a speedup here. memcpy() is written is assembler
and is pretty well optimized (and complicated). BTW, memcpy() and memmove() are
the same functions. There are no assembler block move commands for the 68xxx.
And I don't think you can use the DMA for this either. Don't know about using
the gfx cmds on the 68070 though? Someone else might jump in on this one. I
don't think that Kevin used any of those in his Kwindows code to keep it
portable (ie, for the 68340). I have no idea what you code does or looks like,
but in most cases you can achive better speedup results by improving
algorithms....

> is KVED being advertised anywhere?

Well, not really. I've added it to my ad copy for the OS9 Underground. However,
stay tuned to you mailbox. I hope to have an upgrade announcment out to all
registered uses in the next 2 to 3 weeks. The upgrade will include Kved at no
additional cost (as does the current regular version).

We all look forward to the game! Some more graphics games are sorely needed for
the mm/1!

There is 1 Reply.

#: 19621 S12/OS9/68000 (OSK)
    18-Jan-94  04:33:15
Sb: #19614-#CDI Computer News
Fm: Eric Crichlow 71051,3516
To: Bob van der Poel 76510,2203 (X)

Bob,

  > ... but in most cases you can achive better speedup results by improving
  > algorithms...

    That is true in most cases, but in this one, the vital code segment is so
small I don't know what kind of optimizing I can do. See for yourself:

Display_Screen (rtop, sy, x) register int rtop, x;      /* Don't know if using
"reg" makes a difference  */ char *sy;                          /* Where sy
points to the start of screen memory */ {

   register int y;

   for (y=0;y<SCRNHITE;y++)             /* SCRNHITE defined as 192 */
      memcpy (&sy[yoff[y]],&brdmem[rtop + y][x],SCRNWID); /* SCRNWID = 320 */ }

"yoff[y]" references a set of pre-calculated values for the beginning of screen
lines, i.e. 0, 320, 640, etc..., so that the calculations don't have to be done
at runtime.

The gameboard size is 3 screens by 3 screens. I write the whole board out into
memory, (which admittedly takes up about half a meg of mem,) so as to save the
time that would be needed to decode pixel locations on the fly. Thus,
"&brdmem[rtop + y][x]" referneces the address in the gameboard segment of
memory which is being written to screen memory, where rtop is the position of
the top of the visible area of the gameboard, and x is the postion of the left
side of the visible area of the gameboard.

    Now I don't know where I can do any more optimizing here. In fact, some of
the things I've done in attempting to improve performance may be making no
difference anyway. Got any ideas?

  > There are no assembler block move commands for the 68xxx.

    What I meant there was that, instead of whatever assembly call memcpy()
uses, I thought that the greatest speed could be achieved by using, (please
excuse my ignorance here, as I've never written a line of assembly code in my
life,):

            move.l (a0)+,(a1)   /* Address Register Indirect Addressing with
                                   Post-Increment using longword operands */

This may make no sense, but, not knowing assembly, it makes perfect sense to
me! :)

    It is my understanding, however, that memcpy() uses "move.b", which moves
data a byte at a time, and is, theoretically, only 1/4 as fast as the method I
want to use. How wrong am I here?

    Thanks for any help or enlightenment you can provide.

..Eric...

There is 1 Reply.

#: 19623 S12/OS9/68000 (OSK)
    18-Jan-94  19:57:36
Sb: #19621-CDI Computer News
Fm: Bob van der Poel 76510,2203
To: Eric Crichlow 71051,3516 (X)

Sure...there is always a way to speed something up <g>. What I would look at in
your loop is to change from an indexed array to a pointer. For example, in your
loop you have:

        &sy[yoff[y]]

it is necessary to do a bunch of math to calcuate the correct offset into 'sy'
each time though the loop. If, instead, you can use a pointer you can save a
bit of time. Maybe you can only get rid of one level of the array--since y is
being incremented by one you could convert y into a pointer pointing to the
yoff array. Course, then you have another chore of determining when to exit.
The same applies to the brdmem[][] thing.

I don't know how much of the overhead is taken up with the math and how much is
actually in the moves...Guess you could do some timing with and without the
call to memcpy() to see if fooling around with this idea is worthwhile.

Also, don't forget that setting up function calls is expensive...so if you can
set up larger blocks for memcpy() to move, you'll get a saving too.

Have you tried using get/put calls instead? I suspect that since they work in
pixels they might be slower than memcpy()....I don't believe that Kevin used
the pixacc in the 68070 for that (or anything else).

Too bad you can't set up the entire board in memory and hardware scroll though
the entire thing. But I don't think the processor supports that.

If you really need speed it is sometimes worthwhile to use the -a switch in the
 compiler to generate assm. code. You can then examine that to see what
variables are being used in registers, etc. Not a bad way to learn some
assembler either....

I have a half-assed disassembly of memcpy() I did awhile ago. If you want, I
can send to your mailbox. You ask if it does a 'move.l (a0)+,(a1)+'. Yup, sure
does. It also does byte and word moves to get into alignment and to transfer
odd byte counts. As I said, the code appears to be very efficient...I wouldn't
spend a lot of time looking there to find any speedups.

Hope some of this helps more than it confuses.

#: 19615 S12/OS9/68000 (OSK)
    16-Jan-94  18:53:01
Sb: #19610-Ghostscript
Fm: Bob van der Poel 76510,2203
To: John R. Wainwright 72517,676 (X)

>  -dNOPAUSE

Thanks!

#: 19618 S12/OS9/68000 (OSK)
    17-Jan-94  19:31:31
Sb: Star Trek Demo??
Fm: KEITH H. MARCH 72733,2173
To: All

Hello:

Where can I get the "Star Trek:The Next Generation" demo as seen on the IMS
Video Tape?

Keith

#: 19619 S12/OS9/68000 (OSK)
    17-Jan-94  21:25:00
Sb: CD-ROM for OSK
Fm: David George 72240,134
To: All

Is anyone using a CD-ROM drive on their OSK machine?

I have an external NEC that I would like to hook up to my
KiX\30.  Anyone have a device driver for CD-ROM?

I would be willing to help debug/test anything that might
be under development.

David George

#: 19620 S12/OS9/68000 (OSK)
    17-Jan-94  21:27:00
Sb: #UUCP for OSK
Fm: David George 72240,134
To: All

Does anyone have a COMPLETE UUCP package that works?

If not, I have the GNU UUCP 1.04 (from Ian Lance Taylor) and
will be porting it.  I have already started, but if someone
has a better alternative I am open to it.

Thanks.
David George

There is 1 Reply.

#: 19622 S12/OS9/68000 (OSK)
    18-Jan-94  13:04:11
Sb: #19620-UUCP for OSK
Fm: Pete Lyall 76703,4230
To: David George 72240,134

David -

Try dropping a note to Mike Haaland. Last I knew he had a relatively complete
implementation.

Pete

#: 19625 S12/OS9/68000 (OSK)
    19-Jan-94  01:38:25
Sb: makpal_fix
Fm: LARRY OLSON 72227,3467
To: all

   For those of you with a 3meg MM/1, and found that the save function didn't
work in the Makpal program that I had uploaded, no it was not a disabled
shareware thing. It was an errant pointer problem that didn't show up on my
9meg MM/1.
   Thanks goes to Colin Mckay for pointing out the problem and finding the fix
for it.

   So for those that are interested, the fixed version should be available in
the downloads, as soon as it is ok'd.

  Thanks again Colin


Larry Olson



Press <CR> !>