#: 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 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 . 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 !>