The Status Register


CHAMPAIGN-URBANA COMMODORE USERS GROUP INC.


This newsletter will never appear on Prairienet BEFORE the monthly CUCUG meeting it is intended to announce. This is in deference to actual CUCUG members. It is, after all, THEIR newsletter. For advance notification of CUCUG's meeting, look in the "Information About CUCUG" section.

March 1995


To move quickly to an article of your choice, use the search feature of your Reader. Just type "/" ie., a backslash, and enough of your choice to ensure a successfull search. Enjoy.

March News:

The March Meeting Site is in a New Location

"Break out the blood hounds! You'll need 'em to track down CUCUG's new meeting site." No, not really. As all of you are aware (thanks to your trusty Board members calling each and every one of you), the next CUCUG meeting will be held on our regular third Thursday of the month: Thursday, March 16, at 7:00 pm, but it will be held in a new location: the Electrician's Hall, located at 2901 Research Road in the Interstate Research Park in northwest Champaign. To get there you take Mattis north over I-74 and turn right at the second stop light onto Interstate Drive. (Lincoln Trails Library has a building there on the north side of the street.) You then take the first "real" left (not the Libraries drive way) at Research Road. The Electrician's hall (Local 601) is the third building on your left. There's a big flag pole right out front and it's directly across the street from one of Hobbico's signs. You really can't miss it.

The reason for the move is that we are in need of a phone line that we can use for modem/Internet demonstrations. Since the Bresnan Center revamped their phone system to a digital set up, we have been stifled in this regard. We are doing this as a test and we want everyone to come and check this place out and tell us what you think. If the feedback is positive, we may make this move permanent, so come and make your voice heard.

The March 16th meeting will be one of our split SIG meetings. For the C64/128 SIG, Rich Hall will be giving the Introduction to the Internet demo that he attempted to do last October. The phone will be in order this time. For the Amiga SIG, President Jim Huls will be showing his EGS-Spectrum graphics card. He will be showing what this 24-bit powerhouse can and can't do along with demonstrating the software available that takes advantage of its features. Come see the benefits of the higher resolution and color variations. Jim says, "I've got a lot to learn with this card and the software but so far...WOW!!! It adds a whole new life to my Amiga!"

ToC

Amiga World Ceases Publication

from Kevin Hisel and Jim Huls of CUCUG

Kevin Hisel: The nets have been carrying this rumor for the last couple of days so I called the Amiga World WATS line (1-800-827-0877) and their sales rep confirmed it. The April issue will be the last. Since I was signed up through October of 1996, I requested a refund. She did not try to talk me into other IDG titles as others have reported and simply advised that I'd get a refund for my May '95 through October '96 issues. Luckily this is a case where the publisher has many titles and not a case of a lone mag (like .info) going under and therefore no chance of getting the cash back.

I think I'll just sign the check over to Amazing Computing when I get it.

Jim Huls: I've heard (been told by Jason Compton) that IDG will offer AmigaWorld subscribers that chance to transfer their subscription to Amiga Computing. This is one of the Euro Amiga mags. With all of the Euro Amiga mags I can't remember if that is one of the better ones or not. :/

Although things are looking grimmer than ever with AmigaWorld on their way out, I have learned from Doug Cotton of CMD that they are investigating starting up their own Amiga magazine. This is still in the early stages but I'm hoping that they can pull it off. CMD has made a name for itself in the Commodore 8 bit world with their products and their "Commodore World" magazine so I can't help but feel hopeful that they enter the Amiga market and do the same fantastic job that they have done on the C64 side.

ToC

Welcome New Members

We would like to welcome back returning members Bob Bohn, B.J. Anderson, Paul Lassa, and Paul Neubauer, and give a special welcome to our newest member Paul Stackhouse - all joining in February.

ToC

German deal imperils a sale of Commodore

By Dan Stets, Inquirer Staff Writer

New York - The bankruptcy trustee of Commodore International's German subsidiary has independently sold off a key company trademark, potentially undermining efforts to sell all of the company's assets and get Commodore computers back into production.

Trustee Bernard Hembach of Frankfurt sold the Commodore logo to Escom Aktiengessellschaft, a German computer company, last month for $1.4 million in apparent defiance of the U.S. Bankruptcy Court in New York, which tried to block the sale with a temporary restraining order.

The action is another setback to efforts by liquidators of Commodore's parent corporation and the company's American creditors to resolve the complex liquidation.

Sale of the company's technology will be delayed at least for several more weeks, postponing any restart of production of Commodore's Amiga and other computer products.

Frank Wilson, one of two Bahamian liquidators responsible for selling the assets of Commodore's parent company, is afraid that the German sale might make it impossible to sell the company's technology to another buyer.

U.S. Bankruptcy Judge James L. Garrity Jr. conducted a hearing here yesterday on whether Hembach and Commodore's Germany subsidiary, Commodore Bueromaschinen GmbH, should be held in civil contempt for selling the logo.

Garrity postponed a decision until March 20 to give Hembach time to reply to allegations brought by Wilson's attorneys, who say Hembach rushed the sale to duck a pending restraining order.

The judge is weighing whether to fine Hembach and the Germany subsidiary $5,000 each per day until the sale to Escom is reversed. Under the proposed order before the judge, Commodore's parent company would get the money.

Hembach says the American court had no jurisdiction to block the sale, arguing that the logo was owned by the subsidiary, not the parent company. Hembach sold to Escom a logo that includes the word Commodore and the "C=:" trademark. Wilson says all trademarks belonged to the parent company.

Commodore International filed for voluntary liquidation in the Bahamas in May. The company was based in the Bahamas and had its North American headquarters in West Chester.

Hembach sold the Commodore trademark to Escom on Feb. 16, the same day Garrity issued a temporary restraining order against the sale.

Wilson's attorneys say they notified Hembach on Feb. 15 that a motion for the restraining order had been filed in the New York court. According to Wilson, Hembach and Escom executives worked all through the night of Feb. 15 to conclude the sale by the morning of Feb. 16.

Wilson did not learn of the sale until March 1, when he met in New York with Escom representatives to discuss sale of all Commodore assets to the company, which is one of three active suitors for Commodore's remains.

Wilson had hoped to complete a tentative sale of Commodore's technology to Escom last week and then allow others to try to outbid the company at an auction expected to take place in a few weeks.

However, Wilson now contends that at least one potential bidder said he would drop out if the Commodore trademark in Germany was not up for sale. Germany accounted for 32 percent of Commodore's sales in 1992.

ToC

A sale in Germany may stall U.S. work

By Dan Stets, Inquirer Staff Writer
from the Thursday, March 9, Philadelphia Inquirer

For $1.4 million, Trustee Bernard Hembach of Frankfurt sold the Commodore logo which includes the word Commodore and the C= trademark to Escom on February 16, the same day that U.S. bankruptcy judge James L. Garrity Jr. issued a temporary restraining order against the sale.

Mr. Franklyn Wilson, one of the Bahamian liquidators, hoped to complete a tentative sale to Escom last week. The other interested parties (the Commodore UK buyout team, and CEI) would then have an opportunity to outbid Escom at an auction in a few weeks. The Judge now states that one of the interested parties stated that they would drop out of the bidding if the Commodore trademark was not part of the sale.

At a hearing in New York City yesterday, March 8th, on whether Mr. Hembach and Commodore's German subsidiary should be held in civil contempt, Judge Garrity has given them (Mr. Hembach and Commodore's German subsidiary) time to reply to allegations brought by Wilson's attorneys. The Judge may fine Hembach and the German subsidiary $5,000 per day until the sale to Escom is reversed.

Mr. Hembach states that the Commodore logo belonged to the German subsidiary. One of the Bahamian liquidators, Mr. Franklyn Wilson, states that all trademarks belonged to the parent company.

ToC

Pioneer to build Macintosh-compatible PCs

from the Champaign-Urbana News-Gazette, 2/13/95

TOKYO (N.Y. Times) - Pioneer Electronic Corp. will become the first Japanese company to make a personal computer compatible with Apple Computer's Macintosh, industry officials said Friday.

Pioneer scheduled a news conference for Wednesday to announce the development of a personal computer with the "cooperation" of Apple.

Known for its laser videodisc system and for audio equipment, Pioneer does not make personal computers. But it believes it needs to move into that industry to compete in the so-called multimedia age, when computers will be used to mix and manipulate video and audio information.

The Macintosh clone it manufactures is expected to include audio and video playback. It is expected the machine will be sold mainly in Japan, at least to start. Pioneer would be the third company to license the Macintosh operating system, following two Silicon Valley companies, Power Computing and Radius Inc.

Apple, based in Cupertino, Calif., once closely guarded the basic Macintosh software. But in a change in strategy, it said in September that it would license the operating system and permit Macintosh clones to be made.

ToC

Space shuttle Endeavor connects with Internet

from the Daily Illini, Monday, March 6, 1995

CAPE CANAVERAL, Fla. (AP) - It was bound to happen: Cyberspace meets outer space.

For the first time, NASA is providing public computer access to virtually all aspects of a space shuttle flight via the Internet, including occasional exchanges with Endeavor's seven astronauts and continuous updates on their astronomical observations.

Computer users can even "Come Aboard," and receive pictures and audio tapes of the crew.

It's causing a cyberspace stampede.

More than 350,000 requests for mission information have poured in since Endeavor blasted off Thursday (3/2/95).

Becky Bray, a payload activity controller at Marshall Space Flight Center in Huntsville, Ala., is leading the "Welcome to Astro-2" effort. Astro is the National Aeronautics and Space Administration's name for the three ultraviolet telescopes aboard Endeavor; this is their second space flight.

"We're pretty out there in the realm of my wildest dreams," Bray said Sunday.

An engineer in Bray's software branch tapped into the Internet at work last summer, about the time NASA's public affairs office went on-line with news releases.

The next thing Bray knew she was organizing NASA's first on-line shuttle mission.

Among the information available on the World Wide Web: Endeavor's exact location over Earth, stellar observations by the Astro telescopes and sky charts, crew and ground control team photographs, snapshots of the cockpit, taped conversations from four of the astronauts, even NASA-TV broadcasts of the mission that appear in a one-inch square.

Note: Internet users can access "Welcome to Astro-2" on the World Wide Web by typing: http://astro-2.msfc.nasa.gov

ToC

REVIEW: Liquidation of Commodore International

From: Bo Najdrovsky, bn@okcforum.osrhe.edu

PRODUCT NAME

Liquidation of Commodore International, Ltd.

BRIEF DESCRIPTION

A product that everyone feared would eventually come, and it finally came upon us mercilessly.

AUTHOR/COMPANY INFORMATION

Name: Bahamian Courts, with some help from various legal eagles

LIST PRICE

Anywhere from $19 million to about $100 million (US), depending on whom you ask.

SPECIAL REQUIREMENTS

COPY PROTECTION

This product is protected from successfully operating by a couple of fools named Mehdi Ali and Irving Gould. I would rate this copy protection as unacceptable.

MACHINE USED FOR TESTING

This product has been in extensive testing on over 4 million Amigas worldwide. Many users were so exhausted from testing that they just decided to sell their machine and migrate to a different platform.

INSTALLATION

I never installed this on my system, honest. It just somehow made its way there. I suppose you could describe its installation as simple as, say, a computer virus.

REVIEW

Well, what can I say. For at least a year before it actually happened, I anticipated this product's hitting the Amiga market. During this time, I almost began regarding it as another one of those vaporware products that we Amiga users have become so accustomed to.

When the liquidation finally hit the market, I must say that I was quite disappointed. The whole thing was full of bugs, and hardly ran at all. In fact, now, about 9 revisions and updates later, it still doesn't seem to deliver what was originally promised, which of course was the possibility of a capable company manufacturing and marketing the Amiga line of personal computers.

Though the developers of this product still seem relatively enthusiastic about its possibilities, I am beginning to seriously doubt the liquidation's viability in the current Amiga market. In fact, I would go as far as suggesting that the market might have been better off without such a product being available in the first place.

DOCUMENTATION

Documentation is extremely poor. If it weren't for a few good supplements, such as Amiga Report, there wouldn't be any documentation at all. (Kudos to the editors.)

LIKES

I can't say that I like anything about this product.

DISLIKES AND SUGGESTIONS

I dislike the lengthy, seemingly endless proceedings that never seem to end, and that every time there seems to be the proverbial light at the end of the tunnel, it just turns out to be an oncoming locomotive.

COMPARISON TO OTHER SIMILAR PRODUCTS

Not much to compare this thing to; but if you're interested, go to your local library and look up "Pan American Airlines." They were also a once-great company that didn't quite make it.

BUGS

Full of bugs. Simply doesn't work.

VENDOR SUPPORT

None.

WARRANTY

None - expressed nor implied.

CONCLUSIONS

I would not recommend this liquidation to anyone. It doesn't perform as promised, doesn't even work, and it costs too much. It also causes many of your fellow Amiga owners leave you for little-endian pastures. Stay away!

COPYRIGHT NOTICE

This review is Copyright 1995 Bo Najdrovsky. It is freeware. Do what you want with it but if you republish it in your newsletter, just let me now. My address is bn@okcforum.osrhe.edu. Thanks.

Bo Najdrovsky // AmigaOS 3.1/Mac Sys7.1/BSD 4.4
bn@gnu.ai.mit.edu \X/ - Courtesy of my A3000

- join the EGS list: listproc@okcforum.osrhe.edu -

bn@okcforum.osrhe.edu

"Who are you, who's so wise in the ways of science?"

Daniel Barrett, Moderator, comp.sys.amiga.reviews
Send reviews to: amiga-reviews-submissions@math.uh.edu
Request information: amiga-reviews-requests@math.uh.edu
Moderator mail: amiga-reviews@math.uh.edu
Anonymous ftp site: math.uh.edu, in /pub/Amiga/comp.sys.amiga.reviews

ToC

Protocols

by Kevin Hisel, Sysop of the Starship CUCUG

Bill Gentry: I am having trouble in deciphering the difference in the protocol settings as for ascii, xmodem/checksum, xmodem/crc, xmodem/1k, ymodem batch, and the rest... I ran in to this situtation that called for ymodem batch and I complied with my prog setting it to ymodem batch and it worked. But my default setting on the bbs is xmodem/crc and the modem I use is an xmodem I think. It's an Aprotek 2400/baud minimodem C24. Tell me about protocol?

Kevin Hisel: Sure! The kind of "protocol" you are asking about only relates to file transfers, i.e., downloading. One thing to remember is that all of the different downloading protocols are software-only--your Aprotek modem has nothing specifically to do with it. In other words, all of the work being done to download or upload a file is between your terminal program and the BBS software.

A "protocol" is simply a "method to get something done". It's a set of rules that both sender and receiver follow to transfer the file. The reason that there are so many confusing protocol options for downloading is that over time there have been many improvements to the process.

The first file-transfer "protocol" wasn't really a protocol at all. ASCII transfer simply would type a text file to the screen continuously, requiring the user to somehow capture and save the text to their system. Since this only works for text (and not really well, by the way), it was useless to tranfer "binary" or "program" files.

The earliest semi-reliable method of transfering program-type files was Xmodem (now referred to as "Xmodem-Checksum"). Its reliability was soon improved and called Xmodem-CRC. That was later improved further and called Xmodem-1K (it transferred data in 1,024-byte blocks instead of 128-byte blocks which made it faster). Xmodem-1K is often confused with Ymodem which is similar but added "batch" capabilities (the ability to send more than one file at a time). A similar protocol was invented around that time for Commodore computers by Steve Punter called Punter-C1 that used 254-byte blocks (the size of a CBM disk sector). Then came Zmodem which was even more reliable and faster.

The trick to selecting a usable protocol is sometimes just trial-and-error. Just keep trying different protocols from those available on both the BBS and your terminal program. If none seem to work right, get a new terminal program. Ask others with your same computer which protocols and termial programs they use and try that.

Another tip specifically for this BBS: once you find a protocol you are happy with, use the T command from the main menu to set that as the default protocol. The BBS will remember that setting and use it every time you download.

Good luck!

ToC

Multitasking - The Switch Is On!

by Mark Vitale, Mark_Vitale@sterling.com

What is multitasking? And why should I care about it? What's the difference between pre-emptive and cooperative multitasking? Is only one of these "true" multitasking, or both, or neither? What does multiprocessing mean, and how does it relate to multitasking?

These are just a few of the questions I've seen discussed on our BBS in the last few months. And whenever these questions pop up, confusion and misconceptions are bound to follow. After all, multitasking is a technical and poorly-understood subject. So why even bother to tackle it? One big reason is that one of the Amiga's best advantages has always been the excellent implementation of multitasking found in AmigaDOS.

So whether your interest is morbid curiosity, desperate confusion, or an insatiable desire to embarrass a Windows Weenie with your new-found expertise, this article's for you! I'd like to share with you a little of what I've learned about multitasking in my 20 years of experience with many different computer platforms. If you find any mistakes, it MUST be because Paul rushed me to finish this; it couldn't POSSIBLY be because I don't know what I'm talking about! (Just kidding, Paul. Now put down the hammer, gently).

To save space, I'll usually use the following abbreviations: "mt" for multitasking and "o.s." for operating system.

What Is It?

Multitasking is a feature of some computer operating systems which allows the computer to run multiple programs ("tasks") virtually at the same time. Read that last sentence again (go ahead, I'll wait). Did you notice that weasel word "virtually"? I had to put that in there because most computers only have one processor, and so can only _really_ execute one program at any given moment. For a uni-processor system, multitasking provides the illusion of multiple programs running simultaneously. But before I explain "How did they do that?", I need to explain...

"Why did they do that?"

"Because I need to do two things at once, you twit!" is the wrong answer, sorry. The real reasons multitasking was invented were expensive mainframes and slow I/O. Let me explain.

Back in the early days of computing, computers were very rare and in very high demand. The law of supply and demand thus made computers (and access to computers) fabulously expensive. The first programmers had to schedule a personal appointment with the "big iron" far in advance. They agonized over every little machine code instruction to squeeze as much work as possible out of their fabulously expensive time slot. And I/O was the worst; it was many times slower than any CPU instruction. Always too soon, the precious time slot was gone... and it was time to wait again for the next appointment.

One day, a weary coder realized that while his program was waiting for a very slow I/O to complete, the fabulously expensive CPU was doing... nothing! What a waste! If only he could figure out a way to use those precious little scraps of idle CPU time... Thus was multitasking born, not of convenience or even efficiency, but of desperation. Programmers soon figured out how to write operating systems which could run other programs while waiting for I/O to complete. Eventually they even figured out how to allow multiple I/O requests to be active simultaneously.

Even today, I/O is still many times slower than CPU, so multitasking is still a big advantage when you've got a lot of work to do.

"How did they do that?"

First, you need hardware support. Asynchronous I/O is a hardware or CPU feature which allows a program to start an I/O and then do something else until the IO completes. Next, you need interrupts; these allow the I/O device to notify the CPU when an I/O is complete. This eliminates the need to use CPU for "polling" the I/O device repeatedly until the I/O is complete. Interrupts can also be used to notify the computer when a given time has elapsed, allowing it to switch from one program to another even if it's not doing any I/O.

Next, you need operating system support. There are many different ways an o.s. can make it look like your computer is running multiple applications simultaneously. Strictly speaking, not all of them are really mt, and this contributes to the confusion. Here's an overview of a few of the techniques:

Task-switching: Although mt operating systems can and do switch between tasks (programs), this term has come to mean manual, user initiated task-switching. By itself, this is not true mt, but rather a method of quickly switching to another application and then returning to where you left off. The "foreground" application is the one you're working with right now, and it's the only one that is ever really running. The "background" applications are in a frozen state, waiting for you to return to them before they can do anything. The background applications can reside in memory or on disk, waiting to be paged into memory when you switch back to them. Examples: Software Carousel and similar programs for early CP/M and MS/DOS systems.

Time-slicing: The operating system uses a hardware timer to interrupt itself occasionally and decide whether the running application has exhausted its pre-assigned interval ("timeslice"). If so, another application is allowed to run for a while. Examples: Windows and AmigaDOS both using timeslicing (but in vastly different ways - more later!).

o.s. extension: A program attaches itself to the operating system by making itself resident in memory, then taking over an interrupt or o.s. service call vector. In this way, it actually becomes an extension of the operating system instead of a traditional application. This can look just like you're running multiple programs, but it's not really mt because nothing can run while you're in the extension. Examples: MS/DOS terminate-and-stay-resident programs (TSRs) and some viruses (what's the difference, heh heh!).

Semaphores: An ingenious method of arbitrating access to shared resources by multiple programs. A semaphore is nothing more than a memory location (anything from a single bit up to 4 bytes or more). Everyone who wants to "serialize" (share orderly access to) a given resource agrees by convention to use the same semaphore. A good real world example of a semaphore is a subway turnstile - it only allows one person at a time to pass through the gate. Another real world example of a semaphore is the lock on a public bathroom stall; as long as everyone uses and respects the lock, it's guaranteed that only one person at a time can use the stall.

More About Semaphores

Let's keep stretching the bathroom stall analogy to learn more about semaphore operation. If someone already has the semaphore, other applications must wait in a queue until the semaphore is released by the first application. When the first application releases the semaphore, the o.s. moves the next application in the queue from the "wait list" to the "eligible list" (see below). And just as with bathroom stalls, if you try to use a resource without getting its semaphore first, "unpredictable results" and embarrassing collisions are sure to follow!

A full discussion of semaphores (and flags and locks) is beyond the scope of this article. For our purposes, you just need to understand three points about semaphores:

  1. The main purpose of semaphores is for resource sharing and inter-process communication.

  2. Semaphores are usually accessed indirectly via o.s. service calls (e.g. Amiga library routines). This is because it is obviously impractical for each application to know the real address of the semaphore.

  3. (Warning - intuitive leap ahead!) Realize that the cpu itself is a resource! An o.s. can be multitasking by merely providing some service calls that either explicitly or implicitly use semaphores. As soon as one application must wait on a semaphore, the o.s. switches to the next application on the "eligible list" (see below). This is how an operating system can switch to another program whenever it executes an IO.

Here's an example of how it works. A word processor initializes and then waits for keyboard input ("think time"). In order to wait in a cooperative way, it just makes a "wait" call to the o.s. for a keyboard event. (Some operating systems have this "wait" built into the IO request logic). When the user hits a key, the event wait is completed and the o.s. puts the word processor back on the eligible list. Hey, what's an eligible list?

Making A List, Checking It Twice...

Lastly, a multitasking operating system works by maintaining three lists of applications:

  1. run list - applications that are actively running RIGHT THIS INSTANT on the cpu(s). This list contains only 1 entry (the "runuser"), unless your system is multiprocessing (that is, your hardware has multiple CPUs and your o.s. supports them).

  2. eligible list - applications whose awaited event (e.g. I/O, timer, voluntary wait) has completed and semaphore has been satisfied. They are "eligible" to run the next time the CPU is ready to dispatch a new program.

  3. wait list - applications which are still waiting for an event (e.g. I/O) to complete.

So there you have a few of the methods used to implement mt. Although there are many methods, and many varieties of using them, the resulting o.s. will usually fall into one of two broad categories: pre-emptive or cooperative.

We Now Pre-empt Our Regularly Scheduled Program...

Pre-emptive and cooperative multitasking are easy to confuse because, despite their considerable internal differences, externally they usually appear to work the same to the end user. Here's an explanation of both.:

Cooperative: The name derives from the fact that it only works well if all the applications cooperate with the operating system and each other. An application is considered "cooperative" or "multi-tasking friendly" if it periodically and voluntarily yields control to the operating system. In other words, when your o.s. uses cooperative mt, it only takes one bad "apple" to spoil the whole bunch!
A cooperative mt o.s. NEVER interrupts a running task; it has no means of doing so. It can only dispatch the next eligible application when the previous application surrenders control.

Pre-emptive: The operating system can switch to another program at any time; it does not have to wait for the program to voluntarily surrender control by directly or indirectly going on the wait list. For this reason, pre-emptive mt is not nearly as sensitive as cooperative mt to poorly-written applications; that's why pre-emptive multitasking is sometimes called "true" multitasking.

Round Up The Usual Suspects

The Macintosh operating system has used cooperative multitasking ever since the multitasking Finder came out many years ago. Therefore, most Mac developers have had plenty of time to make their programs "cooperative", so the Mac multitasks fairly well.

Windows also uses cooperative multitasking, with a little pre-emptive time-slicing thrown in to make sure DOS applications get a fair shake. However, because DOS was never multitasking and Windows used to be merely a task-switcher and not a true multitasker, many clone developers don't know how to write for a multi-tasking environment. There are MANY Windows and DOS applications that are multi-tasking hostile. A "hostile" application may use primitive programming techniques such as polling (for IO) or event loops (for inter-process communication), or it may even disable multitasking altogether! This causes frustrating hangs and lockups while the "hostile" program hogs the CPU. Two examples I use every day are the IrmaLAN 3270 emulator and Microsoft Access database.

AmigaDOS is a pre-emptive multitasking operating system; for that reason it can smoothly run many programs at once. The only way an application can screw it up is by misusing the "forbid" service; it is intended only for the rare times when a program must disable multitasking temporarily. Most "hostile" AmigaDOS programs were weeded out long ago by natural selection; Amigans are used to multitasking and will quickly reject programs which don't do it well. One exception is high-performance games, which always run faster if they take over the CPU by disabling multitasking.

Conclusion (finally!)

I hope this article dispels some confusion and misconceptions about multitasking. If you have any questions or comments (or corrections!), please send me an email; I'd love to hear from you!

[Source: Amiga Users of the Heartland "Chronicles" December, 1994. AUOH's address is P.O. Box 1432, DTS, Omaha, Nebraska 68101-1432.]

ToC

Multi-Serialism

Jim Huls:

I've tried Skyline a couple times this week but get busy signals. I'll keep trying!

You might want to give it a try now. Mike only had one line going because of a problem with what he thought was one of his other serial ports. He seems to have narrowed down the problem now so more than one can get online now. The board has been *VERY* busy lately.

*I* even have trouble getting on. ;-)

Mike Latinovich:

Everthing seems to be fixed now... What I thought was a serial card problem turns out to have been a serial CABLE problem.

I'm happy to say though, that in my quest to solve the problem, I've picked up a second serial card, a BSC/Alfa Data MultiFaceCard III (MFC3)... This is a pretty nice board!! It's *VERY* comparable to the GVP ioExtender (the older ones with the 2 serial ports), and has pretty much everything the GVP card does.

Here's how they stand:

GVP's ioExtender (old ioExtender): 2 *VERY* high speed serial ports, with 16-byte FIFO (First In, First Out) buffers on each port. This gives a theoretical maximum throughput of around 614,400 bits-per-second per port (at least according to their software and literature). I have only personally locked the ports at 115,200 bps with my 2 US Robotics v.32terbo modems, as they are the only modems available to me that can lock at a rate that high. I have heard that it will run with 2 of the new Hayes v.FC modems with locked-port rates of 230,400 bps, but I can't actually say I've seen it.

The GVP card also has a standard 25-pin Parallel port that supposedly supports all of the bi-directional functions that the internal Amiga parallel port does. (I have no way of testing this port, as I have no printer, nor another machine to ParNet with.)

Also included is a MIDI port, for GVP's "Midi Expansion Unit"... Alas, GVP never released this product, and have ticked off a whole slew of ioExtender owners.

The 44-page manual is quite complete in it's description of how to install the board in a variety of systems, mainly the A2000 and A3000. I had no problems adapting the A3000 installation instructions to my Amiga 4000, and the card worked flawlessly after installation.

The ioExtender requires that you install a device driver to be able to use the board once it is installed in your system. GVP provides this software on 1 disk, and everything is a snap to install because GVP chose to use Commodore's standard Installer program to take care of everything. The software includes 2 "Prefs"-style programs which allow you to configure the board without having to mess with any hardware jumpers. One of the Prefs programs allows you to re-direct input/output functions of your Amiga's built-in serial & parallel ports to any of the ioExtender's ports.

Overall, this is a very good product if you need the high-speed multi-serial abilities like I do when running a multi-line BBS. It is a product I would, and will, recommend to people looking for such an item.

BSC/Alfa Data's MultiFaceCard III (MFC3): Again, 2 high-speed serial ports that I would assume also have FIFO buffering, but I haven't been able to find much technical information available about this board yet. The manual states that this board will allow up to a maximum of 115,200 bps per port, and again, I have verified this with my modems. This board seems to take up less of the CPU while operating at high speeds than the GVP board does. This may be attributed to the board using on-board processors to move the data rather than using buffers like the GVP card does. However, I cannot verify whether this is the case or not, since I'm no engineer, and I have no idea what all those little numbers on the chips mean.

The MFC3 also has one 25-pin Parallel port on board, and it is of the bi-directional nature also. The manual and installation software state that the ports on the MFC3 can be used for "ParNetting" two Amigas together, and again, I cannot verify this because of the lack of printer or other Amigas). The manual also states that you can add a second Parallel port to the card if needed, but doesn't really go into detail of how or where to purchase this add-on (I would assume you could get it through Alfa Data here in the USA).

The manual has some blurb about not being able to handle MIDI data rates, so I don't think this card has the MIDI capabilities (?!?) of the GVP board.

The manual is quite nice. Almost 200 pages in length, it covers the installation of the board and the software in both English (92 pages) and German (95 pages). The manual describes how to install a variety of BSC's cards (all the MultiFace series boards) into various different Amigas. It also includes pinout references for all the ports on board, which is something GVP neglected to do. The manual seems to be a very complete and accurate source of information considering this product was created for an overseas market (UK & Germany).

BSC includes a disk that also has a very complete installation package provided throught the Commodore Installer. I had no problems installing the board or the software onto my machine, and it has worked 100% flawlessly since installed. The installation script also provides for removing the installed programs, which is a very nice provision for the software.

Overall, a very professional package, which would suit the needs of any BBS sysops that I know. I would also recommend this fine piece of hardware to anyone that needed it's abilities. It would be their place to decide between the GVP or the BSC/Alfa Data board.

Both of the boards have a similar price. I paid $119 for the GVP board at my local dealer (Micro Resales, when they supported the Amiga), and I paid $95 for the BSC board from a local Amiga mail order firm (Select Solutions). Both are very good buys for what they provide!

Hope this wasn't too long... I will probably revise this thing a bit later to make it 100% correct, etc... Otherwise, enjoy reading!

Mike Latinovich of -SKYLINE! SYSTEMS- @ (217) 359-1189!
Sys-Something-Or-Another of -SKYLINE! SYSTEMS-

Tim Urbin:

Hi, Mike! I've seen ads for these boards and have a question. How does the Amiga know which port to access? Is there some sort of polling by the software to see what's on the other end like some MS-DOS boards do? Or are there settings like Serial 1 and Serial 2 similar to an LPT1 and LPT2 setup? If the software is managing the ports, how large of a program is it? Any indications on how well it will coexist with other software? Thanks for any info!

Mike Latinovich:

When you install the software, it puts a handler for the hardware in your SYS:Expansion directory (Both boards do this. They each have a file in SYS:Expansion), and the files are relatively small (9264 bytes for the GVP board, 15488 for the BSC board). Those get started up in your S:Startup-Sequence when the system hits the command C:BindDrivers. Other than that, the GVP software adds 3 devices to the device list: GS0, GS1, GP0 for Serial 0, Serial 1, and Parallel 0 respectively.

You could, for instance, go into Term or Terminus and change your "Port" parameters to use the boards. The GVP card can be accessed through gvpser.device and whichever unit number for whichever port (ie, 0 for port 0). You can do the same with the BSC card as well. It is accessed through the duart.device and again, the unit number corresponding to the port number.

For parallel devices, you use the gvppar.device for the GVP card, and pit.device for the BSC card.

Both packages come with software to re-map the native Amiga serial or parallel ports to either card, and work quite well. This is a key factor when you've got a device hooked up to one of the parallel ports and your DTP package won't output to anything other than the standard parallel.device.

The BSC board's installation will put a Mountlist file in your DEVS: directory if you are running 2.04, and it will put the correct "DOSDrivers" in place if you are running 2.1 or above.

Other than that, they each have a small Prefs program for configuration of the boards.

Bascially though, you have to tell the software you are using to access these extra ports. They look like standard Amiga devices to the system, the only difference being that these are faster, more efficient, and require almost nil time to set up.

As far as compatability: Well, they are as compatible as system-friendly Amiga devices as you could ask for. In other words, no compatability problems, and I run 2 different boards in one machine.

If ya need any more info, let me know, and I can add some more to this ongoing mini-review (or whatever it is...).

Mike Latinovich of -SKYLINE! SYSTEMS- @ (217) 359-1189!
Currently using Terminus with the duart.device,0

ToC

RIP graphics come to the Amiga

xemRIP version 1.2 reviewed

by William F. Maddock
Gateway Amiga Club Newsletter Editor

xemRIP12.lha freeware
Stef Rave
Dorpstraat 69
7361 AS Beekbergen, Holland
Internet: srave@sterbbs.nl

In the past year we have seen the introduction of several terminal programs that attempt to support Remote Imaging Protocol (RIP) graphics on the Amiga. While this is a very welcome development, as each of these has run into problems of supporting an entire terminal program, we have seen each of them fall well short of their goals.

During this same time there has been one person who decided to do only what needs to be done and not try to engage in overkill. Beginning on August 8, 1994 and continuing through the latest release (version 1.2 on November 20, 1994) Stef Rave has engaged in giving RIP support to already existing terminal programs that support XEM 2.0 libraries. His success has made BBSs the world over far easier for Amigans to use.

The point-and-click style of RIP makes the Amiga user far more at home on-line. On a properly configured BBS, the desired result is now only a mouse-click away. XemRIP has even turned programs like Olaf Barthel's Term into graphics-viewers because of the available RIP pictures that can be viewed off-line with xemRIP and converted to IFF with Term's screensaver command - you see some of these throughout this issue.

In gathering screenshots for this article, including the time taken to enter my name, use Term's project menu option to save the screen as IFF, enter my password, download a qwk packet, look around a bit, return to the main menu, grab another screenshot, logoff, and grab the last screenshot, all of two minutes and a few mouse clicks passed. Just click your mouse on the right button and away you go.

The xemRIP12.lha archive can be found in the AmiNET/comm/misc directory. Enjoy.

[Source: From the Gateway Amiga Club newsletter, "GAC FLAK" March, 1995. GAC's address is P.O. Box 811, Bridgeton, MO 63044-0811.]

ToC

February General Meeting

reported by Kevin Hopkins

The February 16th meeting began with President Huls giving the traditional introduction of CUCUG's officers. During the proceedings Jim commended the February newsletter as being the "Best yet." He concluded the introductions by saying, "Despite the doom and gloom with the Amiga, the club is doing really good." We couldn't agree more.

That being said, President Huls opened the floor for our Question and Answer Session.

Concluding the Question and Answer Session, Kevin Hisel went into his presentation of the Library's new Amiga disks for this month.

CUCUGAMI #139:

MegaBlock2 (a Tetris-type games in PAL - good for kids), MFormat (a really nice, enhanced replacement for Commodore's Format command), and TouchAMania (kind of like the Simon game on anabolic steroids).

Taking a slight break, Kevin jokingly told how he has been supplying himself with blank disks from America Online. It seems they've asked him to subscribe about fifteen different times and each time they provide their software on a disk. It's high density, to be sure, but formatted it works fine for other applications.

CUCUGAMI #140:

MSPengo (MartinSoft, not those other guys. Actually this was once an arcade game, in the Pac Man vein), The_Game ( a game dedicated to the history of the Amiga created on Shootem Up Construction Set. This thing is hilarious. Jim Lewis was overheard to say, "This is great!" Recommendation enough.), NewMM and Yahtzee (Mastermind and Yahtzee for your Workbench).

After Kevin's presentation, President Jim Huls welcomed the visitors to our meeting. We then recessed for a fifteen minute break.

ToC

The Amiga SIG

recorded by Kevin Hopkins

The subject of the Amiga SIG this month was Music on the Amiga. Kevin Hisel was our guide as we took an excursion into the world of MOD files.

Kevin began by explaining that MOD stands for module files, a compact standard for distributing music among computers. He believes that MODs will be one of the Amiga's lasting contributions to the computer world. With a somewhat superior glint in his eye, Kevin said he like the fact that MODS are created on the Amiga and can only be played on the PC.

On the topic of players, Kevin said that there are as many different kinds of players as there are MODs. He then fired up one called STP, which has an interface that looks exactly like a CD player, and played a song called "Bazaar Love Triangle" by the band New Order. This song can be found on the 3-disk CUCUG Amiga Pro Music Set.

Addressing a little more of the technical aspect, Kevin said the Amiga comes with four channel stereo built in. He then ran MED, a musical editor, and played the same song, but this time we could see the four channels displayed as they worked. Kevin commented that ProTracker/SoundTracker MODs are pretty much the standard in the field. When asked about the different instruments being used and where can you get them, Kevin said the best place to get samples is from other MODs. There are two major kinds of samples: (1) digitized from a real source, and (2) those created on the computer itself. To keep things lively, Kevin then played another MOD called "Lunatic", an award-winning laid back guitar piece available on our BBS as LUNATIC.LZH. Dennis Miller asked how big the files are. Kevin said they run from around 150K up to 400K on average. "Lunatic" is 222,594 bytes long. Kevin said those containing digitized samples are bigger.

Jim Lewis asked if the Amiga will play WAV format. No, Kevin said, you need to convert WAV files to Amiga IFF. During the discussion of various players, Mike Latinovich recommended one called DeliTracker (also available on our BBS - DELITRAC.LZH) noted for its ability to play a variety of formats.

Kevin then played several songs: "TimeWinds", Rainunp", "Hideaway Blues", GuitarSlinger", and "A-T-S-W" just give everyone an inkling of the variety and quality of music available on the Amiga. [See TIMEWIND.LZH, RAINING.LZH, HIDEAWAY.LZH, GUITARSL.LZH, and ATSW.LZH on the BBS.] Kevin referred to the last song (All That She Wants by Ace of Base) as a lame use of the MOD format, since it simply is the sampling of a regular CD and played back. However it is good enough for some of us to check out the real CD.

Some other players mentioned as worthy of examination were EaglePlayer, DeliTracker, and EdPlayer.

Kevin concluded him presentation with a foray of his own into the MOD/MED arena, playing the song "Crane" recorded by They Might Be Giants which he had recreated using the MED editor. He was apologetic about its simplicity, but then you couldn't prove that by most of us. Vic Serbe, our resident MIDI expert, said you can improve on the perceived complexity of a piece by using a sample editor to combine samples thus gaining more apparent channels.

Kevin Hopkins asked to see the exact procedure of swapping samples from one song to another in order to get better sounding instrumentation. Kevin Hisel then used MED to pull an instrument out of GuitarSlinger and put it into Bazaar Love Triangle. Ed Serbe said you can actually change them on the fly.

The question was asked, "Where is the best place to get MODs?" The best place is from our BBS. The selection there is some of the best available.

One final caveat with MODs: sometimes there are problems between PAL timing and NTSC timing when playing MODs.

Turning to a more general Question and Answer Session, Greg Zalucha said he is having trouble with his clock starting up with randomly weird times. He was told to use SETCLOCK RESET. It was theorized that some piece of PD software might be screwing up the clock. Ed Serbe related a problem he had with some PD stuff which caused all of the date stamps on his files to read "Future".

Jim Huls talked a little about his hardware coup purchased off the net. No details are given here since we don't want him to gloat any more than he already has. Jim will be sharing the wealth: he will be showing some of his new toys in the near future.

Kudos and congratulations were passed out to a certain TV personality in our midst. Channel 15's brand new shiny graphics are due to Mr. Mark Landman and his Video Toaster. Mark receive a communal "Cool!"

ToC

The C64/128 SIG

reported by Craig Kummerow

The February 64/128 SIG had some new blood injected this month. David Cooper and Darlene (I didn't catch the last name) visited the ranks of dedicated users. Darlene didn't know that there were so many 64 sources still available, and David already has semi-offered to help with a presentation. Good to have you aboard!

Emil began with an off-the-cuff dissertation of 64 uses, before smoothly slipping into a super (as always) demo of Newsroom. Although Newsroom has been around for a long time, it still is very useful and powerful. When you boot the program, it automatically looks to see if there is a second drive attached. If there is one, it becomes the data disk. The data disk holds photos, banners, panels, and pages. When the program is finished booting, the menu page comes up. Here is where you pick what to do next. The first thing to do is go to banner. You pick a graphic, flip it, move it, and make multiple prints of it on the banner area. You may put several graphics there, if you wish. Next you pick the font (sorry, only 5 choices), and add the text exactly where you want. When you get it done, you save it to your data disk. Next you go to the copy section. This is where you write your copy. Again, you can add graphics or photos as you wish. If you choose to use a photo, you first must take one. This allows you to crop graphics, add text, or edit the graphic pixel by pixel. After you do this, add the photo to your panel. The text you write will wrap around the graphic/photo. You may move the graphic/photo at any time. When you are satisfied, save it to your data disk also.

When all of the panels are done and saved, you go to layout. In layout you choose how to place all of the panels on the page. You can do an 8X11 with or without banner, or a legal size, again with or without banner. When you have the page (or pages) done just the way you want, you must save it to the data disk also. The final step is to go to press. It is here that you print your creation. You have the choice of printing a banner, photo, panel, or whole page. A wide range of printers are supported. For tonight, Emil brought his trusty Okimate 10, which is a thermal printer. David asked where he still found paper for it, to which Emil replied that he simply uses fax paper, and finds it quite adequate. Emil also passed around several assorted samples from some of his previous printings.

All in all, a very enjoyable and informative time was had by all. We hope that a few more of the regulars can rejoin our ranks, so that we can continue to make the 64/128 a viable alternative to the higher priced market available today.

ToC

February Board Meeting

recorded by Kevin Hopkins

The February meeting of the CUCUG executive board was held on Wednesday, February 22nd at 7PM at Kevin Hisel's house (address and phone number, both in the book). Present at the meeting were: Jim Huls, Mike Latinovich, Mark Landman, Emil Cobb, Craig Kummerow, Fred Cline, Kevin Hopkins, Kevin Hisel, Jon Sago, and Jim Lewis.

Jim Huls: Jim opened the meeting by asking if we were sending a complimentary newsletter to former member Don Sisk, who has fallen gravely ill. KH2 answered, "Yes."

Jim announced that the new hard drive for the BBS had arrived and was to be installed after this meeting, but Richard Rollins wasn't here to do the job. KH2 said he got a call from Rich and was to convey his apologies, but Rich's maternal grandfather just passed away and he had to go to California for the funeral.

Jim requested information on the software situation with the former owner of Micro Resales. The consensus of the discussion was that the figures were "a wash" and that the problem seems to have resolved itself.

Jim then inquired about how our membership numbers compared to those of this time last year. KH2 reported that they are running just about equal.

Mike Latinovich: After some gentle reminding what had occurred at the last meeting, Mike said, "Yeah, the mod files were cool." He then discussed some of the mods and various players he's examined.

Mark Landman: Mark reported that we had one reup at the February meeting, the illustrious Mr. Paul Neubauer. This news was met favorably by all.

Mark then reported on the annual state of the treasury. Our balance is down from last year almost exactly the cost of the trip to the Gateway show. There followed a general discussion of financial matters.

Finally, Mark reported that the Champaign Public Library wants to receive our newsletter. KH2 sneered and said he'd offered to put them on the list years ago, but they did want it then. KH1 said they probably have a new person in charge of local affairs and that we ought to go ahead and put them on the list. Mark will provide Kevin with the proper address.

Emil Cobb: Emil reported that there were 32 people at the February meeting. We had one renewal and two visitors.

Craig Kummerow: Craig thanked Mr. Cobb for his presentation at the February meeting. "Emil did a great job, as always, on the 64 side.

Craig stated that if no more than a couple of people show up for the C64 SIG at a meeting, the SIG meeting will be cancelled for that month. This will be decided on a per meeting basis.

The club's SX64's are back and fixed. Big thanks to Paul Neubauer. Jim Huls said he would check into getting some SX64 keyboard cables for one of the club SXs and one for Emil.

KH1 asked Craig for a list of places that repaired C64 equipment for those that request such information from our online services. Craig said he could provide that list.

Jim asked Craig what he had planned for the SIG next month. The discussion that followed was intertwined with the issue of moving the meeting to a location with a phone line. It was decided that both the Amiga SIG and the C64 SIG would focus on telecommunications for the March meeting. To do so we will be meeting at the Electricians Union Hall in the Industrial Park on North Mattis.

Fred Cline: Fred said he looked into the Union Hall and it could be had for $35 a night with no hour restrictions. This is what we pay for the Bresnan Center for three hours. Our contract with the Bresnan Center states that we can cancel our meeting there two days prior to our scheduled date with no penalty. There was a discussion about this impending move. Several Board members are pushing strongly for the change while several others have rather serious reservations. Emil Cobb voiced the opinion that the membership should be the final arbiters of any permanent change in meeting sites. Everyone agreed to that point.

It was decided that a group of Board members would go out and examine the facilities and report back as to the fitness of the hall for our purposes. The final decision will be conducted on the BBS. There followed a discussion of the best way to inform the membership of the change in the March meeting site should that change be made. Both the newsletter and a phoning campaign will be used.

Kevin Hopkins (KH2): Kevin distributed the mail and passed around the exchange newsletters. He reported that he had used Office Depot to print our newsletter this month and that the saving were substantial.

Kevin then voiced a topic brought up by a member on the BBS requesting that we consider upgrading the modem on the BBS to a 28.8K. By selling the two 14.4K modems the club has, the cost of the new modem would be fairly small. KH1 didn't feel there was a pressing need to boost the speed yet and waiting would only improve the price we would eventually have to pay. It was decided we would wait.

President Huls expressed pleasure with the quality of the February newsletter. Several other Board members gave their support as well. Thanks, guys. Kevin let everyone know that the newsletter is now online on Prairienet in HTML format for those users of Mosaic and Netscape.

Kevin Hisel (KH1): Kevin reported overall disk sales were brisk this month.

BBS usage was low, at 15.5%, as it always is in February.

Kevin informed the Board that the letters for the raffle will be going out soon.

Jon Sago: Jon said he had nothing really to say, except that the February meeting had been a good one.

Jim Lewis: Jim said "I.R. Fine. Not much to comment on." Jim said he would like to see us move over to the Union Hall. Rich Rollins' desire to be counted in the "move" column was reported.

Jim Huls: Jim asked Kevin Hisel if the BBS had been crashing recently. KH1 said it had.

Jim asked, "Who is David Terry?" His name appears in the listed of people with access to the Board section of the BBS. KH1 reported he was one of the programmers of the PCBoard software and had been give access for some debugging work.

As mentioned above, the Amiga SIG will be looking at telecommunication in March. Other possible topics for future meetings were discussed, like Jim's new video card.

Finally, Jim reported he is working on a deal to get a Commodore A2091 SCSI card for $10. Good luck, Jim.

ToC

The Back Page

The Champaign-Urbana Commodore Users Group, (CUCUG), a not-for-profit corporation and Authorized Commodore User Group #00251, was organized in 1983 to support and advance the knowledge of area Commodore computer users.

Meetings are held the third Thursday of each month at 7:00 p.m. at the Bresnan Meeting Center in the Champaign Park District Headquarters (398-2591). The Center is located at 706 Kenwood, 1/2 block south of the corner of Kenwood and John Street, in west Champaign. Kenwood is the fourth south-bound street off of John as you are going west, after crossing Mattis. The Center is in the northwest corner of Centennial Park, northwest of Centennial High School.

ASCII text files of all recent Status Register newsletters are available for downloading on our BBS or our WWW site. Other user group newsletter editors may leave a comment to the BBS Sysop to request free access. To initiate a newsletter exchange, just send us your newsletter. As a matter of CUCUG policy, a newsletter exchange partner will be dropped after three months of no contact.

This newsletter was prepared with PageStream 2.22 on an Amiga 3000 25/100 and output to an HP Laserjet IIP plus. Pagestream was donated to CUCUG by Soft-Logik Publishing Corporation.

For further information, please attend the next meeting as our guest, or contact one of our officers(all at area code 217):


President:         Jim Huls         892-8730        jhuls@cucug.org
Vice-President:    David Witt       684-2815         maddog@prairienet.org
Secretary/Editor:  Kevin Hopkins    356-5026     khopkins@ux1.cso.uiuc.edu
Treasurer:         Mark Landman     398-2910       mlandman@prairienet.org
Corporate Agent:   Jim Lewis        359-1342         jlewis@cucug.org
Librarian/Sysop:   Kevin Hisel      352-1002         khisel@cucug.org
C64/128 SIG:       Craig Kummerow   784-5919       cwkummer@prairienet.org
Board Advisor:     Richard Rollins  469-2616             RERollins@aol.com

Call our Starship CUCUG BBS at (217) 356-8056, always online, up to 14,400 baud, supporting all CBM computers. Email us at

cucug@cucug.org

or surf our home page at

http://www.cucug.org/.

Call Prairienet free at (217) 255-9000. Login as "visitor".

ToC