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!"
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.
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.
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.
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.
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
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
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
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!
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:
Making A List, Checking It Twice...
Lastly, a multitasking operating system works by maintaining three lists of applications:
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.]
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!
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!
by William F. Maddock
xemRIP12.lha freeware
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.]
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.
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.
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!"
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.
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.
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):
Call our Starship CUCUG BBS at (217) 356-8056, always online, up to
14,400 baud, supporting all CBM computers. Email us at or surf our home page at
Call Prairienet free at (217) 255-9000. Login as "visitor".
Sys-Something-Or-Another of -SKYLINE! SYSTEMS-
Currently using Terminus with the duart.device,0RIP graphics come to the Amiga
xemRIP version 1.2 reviewed
Gateway Amiga Club Newsletter Editor
Stef Rave
Dorpstraat 69
7361 AS Beekbergen, Holland
Internet: srave@sterbbs.nlFebruary General Meeting
reported by Kevin Hopkins
Concluding the Question and Answer Session, Kevin Hisel went into his
presentation of the Library's new Amiga disks for this month.
Quentin said the funny thing about the book is that it only has one U.S.
distributor and that's Periscope Record and CD's here in Champaign. The
guy behind the counter there doesn't know how they got that, but he's been
getting orders from far flung countries al around the world. Go figure.
The Amiga SIG
recorded by Kevin HopkinsThe C64/128 SIG
reported by Craig KummerowFebruary Board Meeting
recorded by Kevin HopkinsThe 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.
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