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.

February 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.

February News:

The February Meeting

The February meeting will be held at the Bresnan Meeting Center (Champaign Park District Headquarters) on our regular third Thursday of the month, the 16th, at 7pm. Directions to the Center are on the back of this newsletter.

The February 16th meeting will be one of our split SIG meetings. For the C64/128 SIG, Emil Cobb will be demonstrating the perennial favorite - Newsroom. For the Amiga SIG, it will be a MOD night with the Master of Music, Kevin Hisel. Kevin will be playing some of his favorite MOD and MED files, showing us some of the best players, and how to modify files to better suit your own musical standards. You might want to bring along your favorite MOD tunes; we might have an open stage later!

ToC

Welcome New Members

We would like to express our pleasure at seeing so many of our members renewing their ties with CUCUG in January and February. Welcome B.J. Anderson, Don Berg, Bob Bohn, Tom Cornelius, James Deschene, Paul Froberg, Chris Johns, Eddie Lane, Paul Lassa, Mike Latinovich, Dennis Miller, Garry Morenz, Joe Palmer, Harold Ravlin, Don Shaffer, Corbin Siddall, and Dave Witt.

ToC

Wustl Uses CUCUG's Amiga Web Directory

From: Kevin Hisel, CUCUG, 01-27-95 (08:29)

Aminet in St. Louis (the main site) just replaced the "Amiga Resource" link (the page that has become the defacto Amiga main page) in their main WWW menu with CUCUG's Amiga Web Directory. That means that tens of thousands of Amiga users will now be exposed to our page as the main directory of Amiga links on the Web.

[Editor's Note: I would personally like to extend my congratulations to Mr. Kevin Hisel for the superlative job he has done on CUCUG's WWW page. We derive so much from his efforts. Thanks, Kevin!]

ToC

The "Long March" of the Amiga

by Jason Compton, Amiga Report

(sigh)

Things just keep getting weirder.

Commodore UK is "making noises" (as Amiga Format's Web page puts it) that they've got the highest bid. In the meantime, CEI is all set (so they say) to submit a new, cash-and-carry bid with a full letter of credit.

In the midst of all of this, the US courts, Bahamanian courts, and Commodore creditors FINALLY agreed on a protocol-that is, a concrete method to handle the liquidation. The decision was to proceed to the auction phase as soon as possible, and to allow examination up to 12 months into Commodore's history for mismanagement.

In response, Irving Gould and Medhi Ali have filed a motion to block on the grounds that they filed for liquidation under Bahamanian law and insist that it be followed to the letter. Between the lines, though, is the fact that Bahamanian law only allows examination 3 months into the past of the company...and last I checked, Gould and Ali didn't win any "Business Executive Of the Year" awards.

Aaargh.

A rumor also claimed that Commodore Canada was refurbishing machines and selling them to dealers, promising a 1 year warranty and new machines within two months.

Well, a representative of Commodore Canada unilaterally denied those rumors this morning.

So, to sum up, nothing particularly new...unfortunately.

ToC

The Major Points:

Commodore Sale Could be Delayed by Legal Question

Philadelphia Inquirer, Monday, February 6, 1995

by Dan Stets, Inquirer Staff Writer

  1. The Bahamian liquidators fear that Msrs. Gould and Ali (former top Commodore executives) "may try to block a legal agreement that cleared the way for the company's assets to be sold."
  2. CEI and Commodore UK are the two key suitors for Commodore's assets.
  3. "... it is unclear whether the sale could be finalized until the new controversy involving Gould and Ali is resolved."
  4. Under the terms reached between the liquidators and the U.S. creditors, Commodore executives "could be held legally accountable for any actions they took 12 months prior to the liquidation filing in May 1994. The protocol reached between the liquidators and the U.S. creditors is 13 pages long.
  5. An attorney for the liquidators "doubts whether Ali and Gould would have legal standing to file an objection to the agreement."
  6. "Under the terms of the agreement, the liquidator will be allowed to use whichever provisions of U.S. or Bahamian law that 'are in the best interest of the estate'".
  7. The accord has been approved by a U.S. bankruptcy judge "and is scheduled for a hearing before the Bahamian Supreme Court on Thursday."
  8. "Under the agreement, it would be possible for the liquidators to sue Gould, Ali or other officers of Commodore for any responsibility they bore for the company's bankruptcy or the manipulation of its assets 12 months prior to the sale. Bahamian law would allow a review of their actions for only three months prior to liquidation."
  9. "The protocol does not spell out what suspicions the liquidators have about Gould and Ali's conduct."
  10. Gould and Ali's Bahamian attorney "has not filed a formal objection to the protocol and does not have plans to do so". "He intends to appear before the Bahamian Supreme Court on Thursday to make known his client's concerns..."
  11. CEI's Alex Amor, stated that he doesn't think that it will hold up the sale. "This is something that is going to benefit the creditors, Amor said. "It is not going to affect the sale of the assets."
ToC

At Commodore, Taking Care of No. 1

Philadelphia Inquirer, Friday, Feb 10, 1995 by Dan Stets, Inquirer Staff Writer
  1. "Less than a week before beginning the liquidation of Commodore Computer last May, the company's directors paid $2.6 million to extend their liability insurance for three years...".
  2. This policy "shields their personal assets from negative legal judgments".
  3. "Chief beneficiaries [...] are Irving Gould and Mehdi R. Ali".
  4. The $2.6 million premium "came out of company assets, so it is money denied Commodore creditors and stockholders".
  5. Two new potential suitors for Commodore emerged. "One of the potential bidders is Escom AG, the largest distributor and marketer of computers in Germany. [...] Another individual, Louis Ulysses of Seattle, also appeared, saying he represented a major American technology company, the name of which he declined to disclose."
  6. Last September, Escom was willing to pay $12 million for Commodore. "Escom is still interested, but would probably no longer be willing to pay that amount, because the sale has been delayed so long".
  7. Neither CEI nor the Commodore UK management buyout team have made their bids public. "[S]ources have said their initial proposals were higher than Escom's."
  8. Both Gould and Ali intend "to oppose the agreement, which would allow the sale of Commodore's assets to proceed."
  9. "The hearing was delayed: The judge scheduled to take the case went on emergency leave because of a death in the family. Lawyers expect the hearing to be rescheduled within two weeks".
ToC

A Discussion of the Issues

Bradley Ross - sg93m3tj@dunx1.ocs.drexel.edu

If a letter was to be sent [to the Bahamian court], it would of course be polite and respectful and should offer a suggestion that will forward the course of justice and fairness for the world at large. Perhaps a suggestion that the two leading bidders be allowed to manage a temporary production line to get A4000, A1200, and CD32 along with spare parts back in supply. The bidders would manage the temporary company for the court with the view that it would prevent the value of the property from decreasing, provide more money for the creditors, and enhance the reputation of all concerned. Any thoughts?

Jason Compton - jcompton@cup.portal.com and @bbs.xnet.com

Aside from the fact that I find it highly unlikely that CEI and C= UK would ever consent to work together -

Hewlett Packard offered to operate Commodore during its liquidation. Their offer was turned down. Whether it was turned down by the court or by the trustee, I'm not certain, but you can bet that if HP is rejected, a CEI/C= UK consortium would be, too.

Add to that the fact that this liquidation is a morass of confused law as it is (case in point: Ali and Gould's court motion), such an idea would probably only complicate things further.

Good thought, though.

Jason Compton - jcompton@cup.portal.com and @bbs.xnet.com

Well, it seems that the US courts, the Bahamian courts, and the creditors finally came to an agreement on a set of law to use for the liquidation: a hybrid of US and Bahamian law.

The significant portions of US law being brought in are the notorious "auction" which we have yet to see, and the investigation 12 months into company financial history. Bahamanian law only allows 3.

Now, who knows what was going on at Commodore in those extra 9 months? Gould and Ali do. Apparently, they don't want the courts to.

Matt Pierce - mpierce@vcd.hp.com

What was Ali and Goulds' court motion?

Maxwell Daymon - mdaymon@rmii.com

Basically, the lawyers set it up so that they would use the law that protects the creditors most (US AND Bahamian).

Gould and Ali are protesting because under US law, they will have to pay back the millions of $$$'s they took just before the liquidation. Under US law, what they did is illegal (they paid themselves off, and left the rest of the creditors to fight over the remains). Not exactly insider trading, but similar and against the law in a bankruptcy.

Under Bahamian law, they (their money) are protected. I see this as a major conflict of interests and they should be excluded on those grounds alone!

... What *IS* likely (if things go this direction) is that the court will reverse the large payments Irving and Mehdi made to themselves prior to the liquidation. This is standard operating procedure for a liquidation, but Mehdi and Irving were outside the Bahamian limit of three months so under THAT law their decisions are "in the past".

Under US law (which was proposed, passed, and the particular item they are contesting), their decisions can be examined up to 12 months prior, and that IS when they paid themselves some of the debt. Creditors are all supposed to get an equal share in the liquidation.

Jason Compton - jcompton@cup.portal.com and @bbs.xnet.com

Actually, based on the information I've been able to accumulate, the Great CD32 Payoff, at least, was well within the 3 month period and may have even been AFTER the filing.

I think this move is "damage control", not "damage elimination"...

Maxwell Daymon - mdaymon@rmii.com

That was stupid. I suppose I shouldn't have given them even THAT much credit for business-sense. ;-)

The bottom line is that it *shouldn't* effect the sale. After all, this won't change the bids any and the company is only going down in value. This is between the creditors and the management INDEPENDENT of any sale.

There's no way a bidder would come up with an extra 50 million just to cover ex-management - it's not the bidders responsibility.

If they are wise, they'll sell the company ASAP.

ToC

Why Should 8-bitters Care Who Gets Commodore?

Why should C64 or C128 owners care what happens to the sale of Commodore's carcass? Here is an excerpt from a conference held on GEnie December 22 with Alex Amor of CEI, one of the contenders for Commodore's assets, which might whet any 8-bitters appetite.

Jason-AR: How about the chips, chipsets, designs, etc. that Commodore has in closets that wouldn't be a priority to the new Amiga company? How seriously would you pursue licensing or selling off those technologies?

CEI-ALEX: C= had a number of projects on the drawing board, unfortunately many of these projects were in early stages. Our first goal is to produce the existing machines which there is a huge demand for, next the different technologies need to be analyzed and a direction determined. Is the future AAA or 3D RISC or maybe even something else? As far as licensing the technology the answer is YES.. Some of our partners want to utilize the technologies in other applications and we have agreed.

Jason-AR: What I was really driving at was the past technology - things that were never even Amigas - i.e. licensing/selling off the 64 technology.

CEI-ALEX: I don't believe there is a lot of demand for the C64 technologies. If someone is willing to pay us for it then FAB!:)

Doug Cotton @ CMD: Following up on Jason's question on the older (64/128) technology: Someone is indeed interested. Who should they contact at CEI to discuss that further?

CEI-ALEX: If you are interested in purchasing the 64 technology call Dave Defelici at (305)266-2800 ext 108. Tell me it's true PLEASE ; )

Doug Cotton @ CMD It is.

CMD is Creative Micro Designs, the bulwark of remaining C64/128 support.

ToC

NCSA enters Microsoft world

Software deal: Company brings University prestige through the use of Mosaic

by Sarah Farr, Daily Illini reporter

A program developed at the University's National Center for Supercomputing Applications is getting people's attention after a recent agreement with Microsoft.

Microsoft, the largest software company in the world, signed an agreement to incorporate NCSA's Mosaic software into its own Microsoft products, including Windows 95, said June Peters, a spokesperson for Microsoft.

The agreement was made in cooperation with Spyglass Inc., which has developed its own commercially version, Spyglass Enhanced Mosaic. Spyglass, which was founded in Champaign and now with offices in Savoy and Naperville, signed a multi-million dollar agreement with NCSA and the University in August.

Although the terms of the Microsoft agreement cannot be discussed, it is very favorable for the University, said Randy Pitzer, Spyglass director of marketing and communications.

"In term of visibility it says alot about the University and the NCSA to be connected to the largest software company in the world," Pitzer said.

The Mosaic program allows people to look for information on the Internet's World Wide Web. Once it is integrated with Microsoft programs, it will "greatly accelerate the move toward an open, global approach to browsing the Internet," said NCSA Director Larry Smarr in a press release.

Microsoft will be working closely with the University in developing protocols for future Internet technology, according to Peters.

As with most new software, Mosaic was not expected to be the success it is today, said George F. Badger Jr., University associate vice chancellor for computing and communications.

"People usually don't know how successful a program will be when it is first developed," Badger said.

Mosaic is now the most successful software program we have developed at the University and the licencing of it has been very important to us," Badger said.

The enhanced Mosaic program has been getting attention from companies other than Microsoft. Spyglass signed licensing agreements totaling more than 12 million copies with such companies as Firefox, FTP Software, IBM's Networking Software Division, O'Reilly and Associates and Digital Equipment, said Tim Krauskopf, company co-founder and current vice president of research and development at Spyglass.

Krauskopf said having the University nearby makes the area "a great place to grow a technical company." About 75 percent of Spyglass' engineers have degrees from the University and its entire development effort is in the Champaign area, Krauskopf said.

Krauskopf said the agreement with Microsoft will mean that a lot of attention will be focused on the University and NCSA.

"It (the agreement) opens the door when you get the reputation they have for doing technology that people want to use. This is when you get noticed," Krauskopf said.

[Source: The Daily Illini, Tuesday, January 17, 1995, with minor additions from the News Gazette, Sunday, February 5, 1995.]

ToC

C64 Emulator for MS-DOS

C64 Emulator allows original C64 software to run on PC

KIRKLAND, Wash.--(BUSINESS WIRE)--Feb. 2, 1995--Seattle Lab, primarily a provider of system and data administration tools for Microsoft's Windows NT is enjoying an ever increasing shipment rate of its Commodore 64 Emulator (C64S).

Being their only departure from tools to "toys," the DOS based product is extending the popularity of games designed for the Commodore 64. The quantity of games available for the C64 continues to be the largest of any computer. User comments include: "I played Paradroids on my laptop this afternoon while parked in my car. Now that's living! ... Got to go, time to play Lode Runner. (I am so happy you can't begin to comprehend it.)" and "I am just thrilled that someone took the time and effort to write a true C64 emulator for the PC ... how I've missed by old faithful C64."

Seattle Lab's C64S is a full featured C64 Emulator that allows software, particularly games, originally written for the Commodore 64 to run on a PC. Impossible Mission, Out Run, Chop Lifter, Ghost Busters, Go for the Gold and Bungling Bay represent but a few of the many popular games enjoyed by C64 users for years. The software is shipped with a 1541/71 diskette adapter cable and software manual.

Minimum system requirements are a 486 (500K RAM), VGA display (register compatible), DOS 3.0 or newer. Commodore features supported include: sound cards such as Gravis UltraSound, Sound Blaster, ProAudio Spectrum and Covox or compatible DAC; PC joystick (1 or 2); tape/floppy interface.

A single user demo version of C64S is available on Seattle Lab's World Wide Web site (http://www.seattlelab.com), FTP site (ftp.seattlelab.com) and its Bulletin Board at 206/827-5580. The price is $69.95 (US). This includes the emulator software, a 4 ft diskette adapter cable, manual and North American postage. Mail checks or money orders to Seattle Lab, 214 1st Street, Kirkland, WA 98033. Call 206/828-9001 for Visa/MC orders. Add $5 (US) for orders outside North America.

Seattle Lab is a software development firm specializing in system software, data administration tools for Windows NT and is a leader in porting applications to the Windows NT platform.

ToC

OutraGEOS!

A column by Randy Harris, SWRAP President

geoFAX

If it seems I like to mention Maurice Randall's name alot, you're right! But I can't help it! The guy is just unbelievable! His latest creation is geoFAX! Yes, now you can send and receive faxes on your Commodore!

What will you need? The basic requirements are:

  1. GEOS v2.0 (64 or 128 40 col. mode. 80 column version in the works)
  2. Class 2 fax/modem
  3. geoFAX (available later this month [1/95] for $39 + $4 S&H from CMD)
  4. CMD Swiftlink Cartridge
For more details, there are several text files on the DOM [Disk Of the Month] which give info concerning this soon to be released program. Also included on the DOM is a transcript of the Maurice Randall Conference on GEnie from December 20, 1994. The main focus of this conference was geoFAX, so get the disk and READ ALL ABOUT IT! The text (SEQuential) file reader on the DOM will let you read or print the various text files from the disk in 64 mode. Or just use JiffyDOS to read the files!

Thankfully, Maurice created a stripped down demo version to show how EASY geoFAX is! This demo version is on this month's DOM!

As you will read in the text files, Maurice has created many new drivers, and a new CONFIGURE file for GEOS, to help us get the most out of our CMD devices when used with GEOS! Thanks to Maurice, our Commodores and GEOS will continue to prove useful and cost effective for several years to come!

Creative Micro Designs, Inc.
P.O. Box 646, 15 Benton Drive
East Longmeadow, MA 01028
Phone: 800-638-3263 or 413-525-0023

[Source: From the Southwest Regional Association of Programmers / 64-128 newsletter "Comm-Adore", January, 1995. SWRAP's address is P.O. Box 342, Bedford Park, Illinois 60499-0342.]

ToC

What's new with GEOS?

by Craig Kummerow, CUCUG

One of our club members asked me if I could write an article about what's new with GEOS. I initially said yes, thinking that it would be no problem, but there is so much that is new with GEOS that it is hard to narrow it down to just a few things. Nonetheless, I decided to give it a shot. What's new in GEOS? Well, in addition to a terrific WYSIWYG word processor with tons of fonts available, a superb paint program, mail merge, a publishing program, a programming program, an excellent datatbase, a spell checker, laser printer drivers, calculator, alarm clock, and note pad, there is now a FAX program called geoFAX. Yes, Maurice Randall of geoSHELL fame has written this program to allow you to send or receive faxes at up to 9600 baud by attaching a fax/modem connected to your system by the Swiftlink cartridge. Yes, that is 9600 baud! Those faxes you receive can either be sent directly to your printer, saved as a geoPAINT file, or as a fax file. It was slated for a January release at $39.95 from Click Here Software.

If you are as excited as I am about GEOS, you really want to keep up on what is happening. Besides the new geoFAX program mentioned, Commodore World's 5th issue has GEOS 101, 102, and 103 for beginners who think they might want to dabble or even just jump into GEOS. dieHard magazine also contains plenty on GEOS every month. LOADSTAR, the monthly disk magazine, has fonts, art, and programs for GEOS quite often. For the people who are online (what, you haven't made the leap, yet!), check out GEnie. There is extensive help and advice relating to programs available and tips to help you with those you already have. I have come to love the point and click (I know the CLI people just HATE this) and have found that it does everything I need it to do. I use geoPublish constantly, and aside from the speed (which actually is pretty quick with RAMLink) it does everything I ask of it. geoFile is nice database that I use fairly often, and although I don't use geoCalc very often, it proves to be an easy to use and powerful tool when I do need it.

There are many other additions to the GEOS world that make life easier. geoWizard, by Jim Collette, allows you to switch from application to application instantly, without closing to desktop. To use it you need a REU of some kind,the larger the better. It basically makes your 64/128 act as if it is multitasking. In reality, the program you move from is swapped and frozen in memory until you return to it. It has several other really handy features, including a screen dump, and it's a very effective program. For those who like the CLI world, GEOS does offer a version for you called geoSHELL (mentioned above). It replaces the standard desktop with more of a CLI based desktop. People who use it swear it's the greatest, but I personally haven't tried it.

To get any of these offerings, start by contacting CMD. They handle all of the GEOS programs now available, with the exception of third party applications. Contact CMD at 1-800-638-3263 for orders, 1-413-525-0023 for info, and 1-413-525-0147 for faxes. GEOS. A great environment in which to operate!

ToC

The Effects of Sample Rate and Sample Width in Digital Audio Recording

or

How to Digitize "Beavis and Butthead" Gooder

by Clete Baker, AUoH

(ed note: The subtitle is mine, don't blame it on Clete -- Greg)

At the risk of "going over the top" this month, I'm going to make the assumption that by now nearly everyone who A) owns an Amiga and B) is interested in creating audio samples already knows essentially how to do that. I can sum it up in one sentence: buy a good audio digitizer such as those from Perfect Sound, AMAS, or GVP for around a hundred bucks, and follow the instructions provided.

This will result in acceptably good sound samples which can be played back on any Amiga, or translated via SOX or other sound conversion software to .wav or .snd or other formats for playback on other platforms.

There. I'm done. Or almost, anyway.

What I'd like to do here and at this month's meeting is to delve a little further into the theory of digitizing audio in an effort to give those of you who are trying this at home a chance to maximize the quality of your samples. Hold onto your hip waders, this'll only take a minute.

Digitizing an analog signal such as the electrical waveform created by audio information requires high sample rates and sample widths if the waveform is to be reproduced accurately. These examples illustrate the effects of increased sample rate (greater resolution along the time domain) and increased sample width (greater resolution along the voltage domain).

waveform1.gif waveform2.gif

waveform3.gif

Waveform 1 is coarse in both sample rate and sample width. Waveform 2 doubles both to smooth the digitized representation somewhat. Waveform 3 is greatly improved by at least a tenfold increase in both, and clearly describes the original analog waveform much more accurately.

In fairness, when the analog sound is recreated in the digital-to-analog conversion process, the resulting analog waveform will be smoothed until it looks similar to Waveform 3, however it's clear that much of the subtlety of the original will be lost when recreating Waveforms 1 and 2.

Sample rates in common use in professional audio include 32khz, 44.056 khz, 44.1 khz, and 48 khz. Compact Disc masters are always sampled at 44.1 kzh, and data must be converted to that rate if it was originally sampled at any other rate. 32 kzh is used in multimedia applications, while 44.056 and 48 kzh are used in video. When sampling on my Amiga I commonly end up with samples at or near 11 khz. I find that this results in the best compromise between audio quality and storage overhead for my purposes.

Sample widths in common usage range from 8 or 12 bits in some computer multimedia applications and in early electronic keyboard samplers, to 18 or 20 bits in professional digital audio recorders. Compact Disc employs 16 bits and likewise requires that 18- or 20-bit recordings be down-converted (actively, using a dithering algorithm) to 16 bits.

Sample width has a direct correlation to the noise floor of the recording medium. There is a theoretical increase in signal-to-noise ratio of 6dB for each additional bit. An 8-bit sample offers 255 discrete measurement levels which can be represented for any one sample, and a 48dB dynamic range. A 16-bit sample offers 65,535 discrete levels and a 96dB dynamic range. An 18-bit sample offers 262,143 levels, and a 20-bit sample, 1,048,575 levels with a theoretical increase in dynamic range to 120dB. This represents an obviously huge increase in the density of information from which to recover the original signal.

There. That wasn't so bad, was it? Now, if you read the hyperbole in the manuals for most of the modern audio digitizing hardware available for the Amiga you'll invariably see phrases like "CD quality" or even "better than CD quality", referring to the digitizer's capability to record at sample rates higher than the 44.1 khz of a Compact Disc. This might lead one to believe that the internal sound production mechanism of the Amiga beats that of the CD player you have hooked up to your stereo system. But in practice, you notice, while it's good all right, it ain't that good.

Why is it that your "better than CD quality" audio digitizer doesn't stand up to critical comparison with a garden variety Compact Disc? It's because the sample rate is only one of two major parameters of a digital sample which determine the quality of the recovered audio information. The other is sample width.

Yes, modern sound digitizers for the Amiga can record samples at rates up to 56 khz ... an increase in sample rate resolution of nearly 30% over that of CDs. But CDs employ a 16-bit word for each sample, whereas the Amiga is limited to an 8-bit word. CDs enjoy two hundred and fifty six times the sample width resolution available from an Amiga sample, from 255 possible discrete values on the Amiga to 65,535 possible values on a CD to represent a single sample. To draw a terribly rough analogy, touting "VGA resolution" in the number of pixels on a monitor screen along the horizontal axis is relatively pointless if you must suffer with only a few pixels of resolution along the vertical axis. Understatement alert: the overall level of detail is surely not what you'd expect after seeing a real VGA monitor.

So it is with digitized audio on the Amiga. Regardless of the sample rate, the 8-bit sample word length manifests itself in two nasty and unavoidable ways: 1) it raises the noise floor significantly, and 2) it causes modest distortion of the signal.

Does it sound bad? No, actually it can sound quite good. As long as you are aware of these limitations and are careful to work around them, you'll get excellent results from your audio digitizing. It's more realistic to compare Amiga sound samples, though, to the quality of AM radio than to that of Compact Discs. As to what tricks you can use to wring the most out of your audio digitizing ... see me at the meeting, and bring your questions.

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

ToC

One User's A-Max Upgrade Experience

by Tyronne Smith

I've had an A-MAX II+ card in my Amiga 3000 for about two years. I had a Macintosh Plus, but when it started to die, I decided to try the A-MAX. Since I liked the Amiga better than the Mac, I didn't use the Mac except for Word by Microsoft and PageMaker by Aldus. So, it seemed cheaper, more logical, and I could expand the utility of my Amiga in one step by simply adding an A-MAX card to my Amiga.

I used the hard drive from my slowly dying Mac Plus, and abducted the ROMs to make my Amiga A-MAX card come alive. As I remember, the installation went rather smoothly, but that was two years ago. When the hard drive on the A-MAX II+ started getting flaky, I added a Syquest 44 MB drive. The rationale for this addition was that the Syquest drive with its removable cartridges could serve double duty as a system drive for the Mac, and extra storage for my Amiga. That has worked very well.

Prompted by the recent comparison in AmigaWorld of the new A-MAX IV with the EMPLANT card, I decided to update my A-MAX II+. Besides, Apple has made such a big deal about System 7, their new operating system, I thought it would be worth the effort. A graphical user interface in color...what a concept!

The update cost $119.95, plus $5 shipping and handling. Why don't they just charge you $124.95, or better yet $125.00, and be done with it? Oh well, I guess it's a business thing. When I called to order my update, my name couldn't be found on the registered customers' database, so I had to FAX the cover and first page of my A-MAX II+ manual to prove that I, at least, owned or could borrow a manual. I only mention this because what I received as an update was a 3 1/2" Amiga formatted floppy disk, an A-MAX IV manual, and a twenty-pin dual in-line plug (DIP) chip. The DIP chip replaces a chip that is on the A-MAX II+ board. Therefore, in order to make use of the update, I had to have an A-MAX II+ board, and if I had an A-MAX II+ board - why would I have to prove I was an A-MAX II+ owner? The answer to this question may never be known. Corporate decisions know no logic, take it from one who has been there and back!

Obviously, in order to install the DIP chip, I first needed to open my Amiga and swap the chips. Since the DIPs on the A-MAX board are socketed, exchanging the chips was fairly simple. I didn't have to replace the Mac ROM chips that were already on the board. These were the very same Mac ROMs that I removed from the Mac Plus. I find this interesting - emulating the new color Macs and using System 7 with Mac Plus ROMs.

Installation of the software onto the hard drive was straightforward and simple. So, I immediately started the software and attempted to get A-MAX IV to work. Three hours later, I decided to read the manual, or at least scan through the manual, to see what I was doing wrong. First of all, I discovered the minimum requirements for A-MAX IV were: AmigaDOS 2.1 or higher; a 68020 or higher Amiga with Zorro expansion slots (no floating point math coprocessor or Memory Management Unit was required); at least four megabytes of Fast RAM, with a minimum of two megabytes available when starting A-MAX IV; an Amiga hard drive; Apple 128K boot ROMs (from a Mac 512K E or a Mac Plus), and Macintosh System Disks, Version 7.0 or higher (System 7.1 is recommended).

A-MAX IV can directly read only Macintosh high-density disks under Mac emulation, so, it is recommended that you also have a high-density floppy drive, but there are ways around that - it essentially entails having to special order 800K disks from Apple (all Apple software is now sold on high-density floppies), move the disk image to an A-MAX IV partition on your Amiga hard drive, and have A-MAX IV read the information from there.

The A-MAX IV manual is about sixty 5 1/2" x 8" pages. Half of the manual is devoted to installing and configuring A-MAX IV, and the other half discusses using the Mac side. I would have rather they spent the whole sixty pages detailing the operation of the A-MAX IV, because the descriptions are so short that you have to read them several times to understand what they are driving at. There is nothing in the manual that tells you what to do if something goes wrong.

Since I had a CD-ROM connected to my Amiga, and not a high-density floppy drive, I decided to buy Apple's System 7.5 on CD-ROM. That way I could get around having to buy an internal high-density floppy drive - WRONG!!! After a full day (10 hours) of fiddling, I couldn't get the Mac side to recognize my CD-ROM. Apple no longer supports the 800K (low density) floppy, so everything I could get my hands on (including the Mac disk image files on Compuserve) was in high-density (1.44K) format.

One of the things that has always amused me is the complaints that I hear from Amiga users about the difficulty of installing software, and the problems with software bugs. But, if you've ever used a Mac or PC for any length of time, you would know that software installation and bugs on the Amiga are nothing in comparison.

So, I decided to order an internal high-density drive for my Amiga. I had already invested a little under $225 and it was kiss that money goodbye or get a high-density drive for $132.35. The internal drive arrived in two weeks (it was back ordered). I installed the drive and once again tried the Disk Tools disk I got with the System 7.5 installation pack. NOTHING!

The total investment was now about $357, the A-MAX IV wasn't working, and there was only one thing to do - throw some more money at it. I called a few Mac vendors and finally found one who had the Mac System 7.1. Apple has now moved to System 7.5, so System 7.1 is actually not easy to find. I received System 7.1 the next day, and was able to use the Disk Tools disk to finally get A-MAX IV to work. By the way, that cost another $57.98.

Let's recap - it took me three weeks, $124.95 for the A-MAX IV chip, $99.95 for System 7.5, $132.35 for the Amiga internal high-density floppy drive, and $57.98 for System 7.1. That's a grand total of $415.23 for the A-MAX IV upgrade. One could argue that I really didn't need to buy System 7.5, but in my defense, it was the current operating system, and one should reasonably expect it to work. There's that word again - reasonably. I've got to stop using that word.

When A-MAX IV first starts up, it is in black and white. You use the Monitors program to add color. I have a stock Amiga 3000 (no accelerator or 24-bit color boards), so, the most colors I can get from A-MAX IV is 16. The About This Macintosh window says I have a Macintosh Quadra 950. When I changed from black and white to 19 colors, the A-MAX IV response slowed visibly. The response was just on the edge of being annoying. Exiting programs on the Amiga side didn't seem to make a difference. Changing the task priority of A-MAX IV from 0 to 10 (15 is the suggested maximum) improved the Mac response considerably, but at this priority, the A-MAX IV failed to recognize any disk that was inserted into the floppy drive - one step forward, two steps back!

I still couldn't get the CD-ROM that I have connected to my Amiga SCSI bus to mount onto the Mac Desktop. I'd tried a few SCSI mounting utilities, but none seemed to work. The only solution I had found was to copy the Mac files to an Amiga Drive and mount them as Desktop files. Not elegant, but it works. This was a little disappointing because more and more software is being released on CD-ROM. So if I needed to run something directly from CD-ROM - no luck!

Yes, the Amiga side runs in the background, and you can flip between A-MAX IV and the Amiga because A-MAX IV is just another screen. I use Microsoft Windows quite a bit because of my work, and when I return to the Amiga, I always marvel at how much better the Amiga multitasking is over that of Windows. Can you imagine what it would have been like if Bill Gates and Company had been involved in the Amiga?

You can also have multiple Mac screens (these are called Virtual Monitors). Each Mac screen can be a different resolution and number of colors. The screens are positioned next to each other, and not on top of one another like in the Amiga. So, you move from screen to screen by moving the pointer to the edge of the current screen. You can also drag windows from screen to screen.

The things I liked least about this installation were the hidden costs, the inability to run my CD-ROM from the Mac Desktop, and the fact that A-MAX IV doesn't run System 7.5. The thing that I liked most was being able to run a Mac without actually paying the big bucks it takes to get one. I guess when you look at it that way, $450 isn't really that much to pay for a Macintosh Quadra 950.

Some warnings - there are always hidden costs in updating. You have to have a high-density floppy drive as DF0: to run A-MAX IV. ReadySoft lists this as a recommendation, but I would classify it as a requirement. As in all emulations, don't expect this setup to equal a real Mac, but considering the price benefit ratio, it is worth the money if you occasionally need to use a Mac. Since A-MAX IV can't run System 7.5, one can assume that there are some fundamental changes that have to happen with A-MAX IV to accommodate System 7.5. When you use an emulator, you can always expect to be somewhat less than current. After all, the company developing the emulator will always require time to respond to changes in the system that it is emulating.

Would I do this again? Probably not. The update costs were a little more than I wanted to spend. A-MAX IV seems to be dead-ended at System 7.1. I spent a significant amount of time getting things to work, and every time I called ReadySoft's technical service, I got a recorded message to leave my name and phone number (I don't want you to call me back - I've got a problem NOW!!!). And, I don't have to have a Mac. So, if you require a Mac, and you value your money more than your time, A-MAX IV is a solution. But, if your time is more valuable than your money, just go out - buy a Mac - set it next to your Amiga, and be done with it.

So, now I have a color Mac, sort of. The Mac software that I had, ran well on System 6, but that was black and white. I guess I have to go out and spend a few thousand dollars on software for my new Mac.

By the way, I finally did get the Mac to recognize my CD-ROM. I had to buy a CD-ROM driver. You guessed it - that was another $49.74!

[Source: New Orleans Commodore Klub, Amiga Group, newsletter, "N.O.C.K Notes" December, 1994. NOCK Amiga Group's address is P.O. Box 8307, Metairie, LA 70011-8307.]

ToC

Emulation Issues:

Subject: Apple CD-Rom with Emplant or the Amiga

Pete Gerken - pgerken@css.tayloru.edu

I have access to an Apple CD-Rom external drive and was wondering if it would work with Emplant's Deluxe model (which should be coming any day now!!). The cable from the CD-Rom plugs into the Mac with a 25 pin cable which I'm assuming is SCSI.

Would it also be possible to use the Apple CD-Rom on the Amiga side with the appropriate drivers? If it is SCSI, then I should be able to simply plug it into the SCSI port on the back of my 3000T(UX), right?

Jim Drew - CEO/Product Engineer - Utilities Unlimited, Inc. - jdrew@cryo.rain.com

Yes, it works just fine.

Ottmar Roehrig - or@silicon.hanse.de

I am using an Apple CD300 on the SCSI-port of an A3000 and on Emplant's SCSI-port without problems. You have to make sure though that you use at least v3.1 of Emplant because the CD-ROM-driver uses blind reads.

Michael van de Kamp - michaelk@stack.urc.tue.nl

Does anyone use the AppleCD300 on the Amiga? It is a SCSI isn't it? Is it compatible with the external connector of the GVP-controller? Can I use CD^32 CD's or do I need KS3.1?

Nico Francois - nico@augfl.be

I have an Apple CD300 connected to a Supra SCSI controller in my A4000 (although I'll be switching to a 4091 soon). It works perfectly. Can't say anything about it working with the GVP controller though.

The only CD-32 title I've been able to experiment with was Liberation. Seemed to work just fine apart from the missing CD audio (there is no cd.device to play the tracks on the CD).

Michael van de Kamp - michaelk@stack.urc.tue.nl

What CD-Filesystems are available/working?

Nico Francois - nico@augfl.be

AmiCDROM works fine with it.

Stephan Feinen - feinen@kaa.informatik.rwth-aachen.de

It is a SCSI-drive, capable of using synchronous transfers. I am using it with the Fastlane Z3 SCSI-host adaptor and I am very content with it. There is a CDROM-driver package included with the hostadaptor, however the AmiCDROM-package is also working quite well with it. SCSI-speed says that the drive has a reading speed of about 330 kByte/sec. There is a firmware bug that can cause diskchange problems with several drivers. The Fastlane CD-driver is OK as long as you have a CD inserted on booting whereas the AmiCD-driver prevents errors by starting a separate scan-task.

ToC

Subject: Emplant and Quadra ROMS???

violator@grumpy.cc.utexas.edu (MVH)

Can Emplant make use of Quadra Roms, if not how long before it will be able to?

Jim Drew - jdrew@cryo.rain.com

No, we don't need to. We are able to run 040 specific software with 040'd Amigas at the same speed as the equivalent 040 MAC....and all with 256K ROMs. I don't think we need 419K of GIF pictures (of 3 Apple engineers) as part of our ROM code. :-)

Suraj Gulrajanai - suraj@nwg.nectec.or.th

At least the guys at Apple should have JPEG'ed them.. (sigh!)

Evan Kirchhoff - kirchh@ccu.umanitoba.ca

What?!? GIFs in the Quadra ROMs? How can I display these (next time I encounter a Quadra, I mean)?

Jim Drew - jdrew@cryo.rain.com

There is a program located in the Macintosh RoundTable on GEnie that let's you view the pictures.

Tommy Hwang - thwang@mentor.cc.purdue.edu

What is the purpose of the 2 gif-pics?

Jim Drew - jdrew@cryo.rain.com

Who knows? Just to fill up the ROM, I suppose.

Jay Rymal - jayrymal@gpu.utcc.utoronto.ca

OK, Fine. But we are having a lot of trouble getting certain MacOS fn's to work, since we can't turn on 32bit addressing cause the OS knows we have MacIIcx ROMs which don't support 32bit addressing.

I would like to put in IIci or Centris 650 8/230 roms in so the OS and other apps know that I'm using a superior machine....

Jim Drew - jdrew@cryo.rain.com

This is incorrect. MAC 256K ROMs are not 'the reason' why the 24/32 bit switch is not available... it is just a flag in the OS that allows this to happen. The Gestalt knows that the 256K ROMs at boot time are not capable of running in 32 bit mode, but they can be.

You must understand that the 512K and 256K ROMs are NO different once System 7.x is running... all of the code added into the 512K ROMs gets patched out by System 7.x when it loads, leaving you with the original 256K ROM code running.

Nicholas Merrill - nimhc@cunyvm.cuny.edu

Jim Drew - I don't mean to be antagonistic because I love my Emplant, but if there's no reason to use the Quadra ROM's then why does the ad say "Mac Quadra" as planned for the near future?

Jim Drew - jdrew@cryo.rain.com

Because ads are placed months in advance. None of our new ads (coming out) state this...in fact, our new ads claim that the emulation is 'all MACs made'.

Tommy Hwang - thwang@mentor.cc.purdue.edu

The Quadras and IIci are more widely available. Besides, in my case, my sister wants a Mac and she wants something more powerful, so she wants either Quadra or Performa. I'll just get ROM from her. I think that is okay, but then..?

Jim Drew - jdrew@cryo.rain.com

The 256K ROMs were the first COLOR ROM'd MACs. 512k ROMs made the earlier ROMs 32 bit clean (you could have more than 8 megs of memory in your machine), added 32 bit color Quickdraw in ROM, and changed a menu bar definition. The Quadra ROM (1 meg) has nearly the same ROM code as the 512K ROMs (same ROM ID even!) and just a few thousand bytes of code to handle the 040's copyback mode...the rest (419K worth) are 3 GIF pics of Apple engineers.

When System 7.x loads, ALL of the additional code added to the 512K (and 1 meg) ROMs, except the 32 bit clean code, gets patched out....leaving you with the original 256K ROM code.

You can easily buy MAC II/x/cx ROMs. You can not easily buy 512K ROMs, and that is the reason why we did not choose these ROMs for our emulation.

Tommy Hwang - thwang@mentor.cc.purdue.edu

I can tell you that Mac dealers here sure have a problem with selling me 256K roms.

Jim Drew - jdrew@cryo.rain.com

Yes, authorized MAC service centers are not suppose to sell ROMs. You can thumb through 'Computer Shopper' and find more than a dozen MAC service centers (non-authorized) that are more than happy to get rid of their ROMs (which they thought they never would before!).

violator@grumpy.cc.utexas.edu

Well, I figured 32 bit clean roms would be important, not to mention an addressing scheme for the memory that would be able to take advantage of the Amiga's memory. Right now, Emplant has trouble accessing memory and who knows, maybe the 32 bit Quickdraw routines are kinda nice to have.

Jim Drew - jdrew@cryo.rain.com

The next release of the MAC emulation software for EMPLANT makes it completely 32 bit clean, allowing up to 1.76 gigabytes of memory to be used with the emulation. 32 bit color Quickdraw is built into ROM on all MAC II and higher machines.

Dale Adams - Dale_Adams@gateway.qm.apple.com

Well, sort of.

It is true that 'color QuickDraw' is in the ROM of all Mac II and later (with at least a 68020 processor) machines. However, don't confuse this with "32-bit QuickDraw", as these are separate entities. 32-bit QuickDraw was a later evolution of color QuickDraw which added, among other things, real support for 24-bits/pixel frame buffers. The first Mac which had 32-bit QD in ROM was the IIci. 32-bit QD was not in the ROMs of the Mac II, IIx, or IIcx. Apple provided a system software extension which gave these machines 32-bit QD capability.

Jim Drew - jdrew@cryo.rain.com

Yep, you're right. I did not mean to add the '32 bit'. V1.0 of 'QuickDraw' is built into the 256K ROMs. 32bit color QD v1.2 is the INIT you are referring to.

Tommy Hwang - thwang@mentor.cc.purdue.edu

One thing I forgot to ask. I have 10 Megs, with planed to go up to over 100Megs of RAM in my A4000. Would this cause problems with Emplant?

Jim Drew - jdrew@cryo.rain.com

No, with v3.2 and later, you could have up to 1.76 gigabytes... interestingly enough, real MACs limit their memory to 1 gigabyte maximum, in fact there is a system warning message telling you that you have 'too much memory installed, reduce memory to 1,000,000K'.

ToC

Subject: Re: Emplant & 42% of CPU time?

Nicholas Merrill - nimhc@cunyvm.cuny.edu

Jim - I am wondering about the statistic that you have repeatedly quoted about how Emplant's Mac II emulation only uses 42% of the CPU time and is still faster than the equivalent machines. Well mine, according to Xoper, SysSpy, etc., all say the Mac II is using a minimum of 88% more like 98% depending on what I'm doing... but even so, not only is it not as fast, it's like half as fast, I think, at least, with CPU time.. I can finally see what is running and what percent of the CPU time is being used.. damn there are 203 I/O Interrupts per second.. more even when I'm typing fast... Oh well, I have NoisePlayer and Xoper in the background. That probably doesn't help.. Anyway, Jim, what's the answer. I haven't seen the have II task go under 88 percent so far even when still..

Jim Drew - jdrew@cryo.rain.com

XOPER, on all of my machines (and other customers's machines that I have played with) shows an average of 42% CPU usage...peaks to 65%, dips to 19%. Are you using an 040? If so, are you using caches and CopyBack mode?? I demonstrated this at WOC because quite a few people did not believe this could be true.

Another interesting thing... as we get close to releasing 32 bit clean support, we are learning more and more about the internals of the MAC and various programs (what they do, how they work, etc.). Because of the 'cleaning' we did on the original emulation (pre-32 bit clean support), every single benchmark program/System information display shows that the MAC is 'accelerated'. 25Mhz machines show as 28Mhz (either 030 or 040), and my VXL*30/40Mhz shows as 'unknown'...looking through the code of the program displaying this message told me that 'everything faster than an FX is unknown'. :-)

Also, another nifty that we ran into... the MAC's have their version of 'Arexx'. It is called the Apple Event Stream. It will be possible for us to patch this so that MAC programs supporting the AES could be controlled by ARexx on the Amiga side.

ToC

MagicUserInterface

A biased look at one of the best things you can put into your Amiga

by Colin Thompson, colin@cts.com

The Amiga, by definition, is a Graphics Computer. We use the graphics ability of the Amiga every time we turn on the machine. This should not come as a big surprise.

As computer users, we use programs written by programmers. These creative folks, by their very nature, are a disturbingly different class of humans. They view the world in ways that a normal person (like you and me) would find alarming.

It's a matter of style

If you hand three programmers a specification for a new program, you will get back three different programs. The programs might actually do what you wanted, but one thing is for sure. The programs will all look different.

The most anti-social of programmers will write programs that can only be operated from the Shell. They write programs for other programmers. They usually live in a van, down by the river.

More socially advanced programmers understand the concept of the Amiga WorkBench. They write programs that can be launched by double clicking an Icon. You may not see anything happen, or know when the program has finished, but at least the programmer didn't expect you to type something arcane in the Shell.

Programmers of the highest rank actually want you to use their programs. They provide you with a "GRAPHICAL USER INTERFACE", or GUI to help you use the program. The GUI has buttons, gadgets, pull down menus, and docs to read. Mind you, these high level programmers are two rungs below the evolutionary scale of musicians, but at least they give you a fighting chance to use the programs they scribble.

Back in the early days of computing, all interaction with the computer was done with the keyboard. Next came the joystick, and finally the trackball gave way to the modern two button rodent we call a mouse. (Yes, I know there are three button Mice, but Commodore hasn't heard about it yet).

Now that we are all armed with Mice, we need something to click. Enter the GUI. They usually have too many buttons, but at least we don't have to use the Shell.

What's a GUI and why should I have one?

GUIs come in three basic flavors. The home-grown variety are the product of hundreds of hours of custom programming. You rarely see these any more. They take longer to write than the program they control.

A few years ago, a smart fellow named Jan Van Den Baard decided to improve the lives of his fellow programmers by making GUIs easier to write. He wrote a Toolbox, loaded with standard objects that a programmer could use to assemble a GUI. GadToolsBox has become the standard GUI tool for Amiga programmers. You have seen GadTools GUIs. You probably didn't recognize them.

From the programmer's point of view, GadTools is a two edged sword. It is very easy to design the GUI, but difficult to integrate it with the source code of the program. On the plus side, a GadTools GUI is compiled along with the program and can be distributed to users without the need of a special library. On the down side, the GUI is a fixed window, unchangeable by the user.

Since GadTools was released, several other GUI generators have been written to get around some of the problems with GadTools. Visual Arts, triton, guienv, and Designer are some of the newcomers.

All things change. Nowadays the 500 pound gorilla of GUI designers is MUI, the MagicUserInterface, written by Stephan Stuntz. 1994 saw an explosion of programs written with a MUI GUI. If you scan the latest AmiNet INDEX, you will find over one hundred MUI-based programs. That means there a lot of programmers out there who have mastered MUI and are writing programs that take advantage of MUI's unique features.

So what are these unique features?

The most obvious property of a MUI GUI is that you can change it's size. It stretches out to the size you want. Just click on the size gadget in the lower right of the window and drag out the window to the size you like.

There is a new gadget in the title bar that lets you iconify the window to an icon on the WorkBench screen. This lets you close the window, then reopen it later by clicking it's icon.

Registered owners of MUI can customize the look of every MUI program they use with a Prefs program. You can change the look of any part of the window and its gadgets. "So you don't like square buttons?" Make them oval.

Why MUI is getting popular with programmers

Several different file requesters are available. The programmer can take his pick of custom requesters, box frames, text windows, listviews, and many other gadgets. This makes for an interesting GUI that completely matches the needs of the program.

Much of the drudgery of GUI-making is relieved by MUI. Font sensitivity is handled with ease. MUI offers one feature that nothing else can match. You can include a gadget, or group of gadgets in a box that overlays another box of other gadgets. This lets you, the user, click a button and have a whole new group of buttons, or other gadgets, appear in its place.

The programmer has a tool to use that you will never see. It's a "MUI GUI MAKER" called MUIBuilder. The GUI is actually constructed with this tool.

So just exactly what is MUI?

From the user's point of view, MUI is just another library. It's 192K. Once MUI is installed on your system, you can run any program that uses the MUIMASTER library. Without MUI, you can't run these programs. The current version of MUI is called mui22usr.lha. It's a $20 shareware program, available on AmiNet in the dev/gui directory. MUI is distributed in the AMITCP/IP package, so you might already have it installed!

MUI comes with a wealth of demo programs that will knock your socks off. It's very easy to install and doesn't require you to change your startup-sequence manually. Registration couldn't be easier. Just click on the "Register" icon and fill out a form. Then press the "Print" button and the form prints to the printer. When you register, you will receive the latest version of MUI, including a KEY.FILE that has your name and address in it, thus making the program "registered" to you.

MUI runs on all Amigas using 2.0 and up. It needs about 3 Megs of disk space and about 2 Megs of Ram to work well. As a user, you don't even have to read the extensive documentation. Just install it and start trying all those programs you couldn't use before.

Is there a down side?

Yup. MUI is slower than molasses in January when used on my 7 Mzh 600. My 10 Mhz 1000 displays MUI GUIs MUCH faster. My 14 Mhz 1200 works great with MUI. My 40 Mhz 1200 displays the GUIs in a flash. Some of the purists that lurk in the shadows of the net complain that the library is too big. Tough. MUI actually drives Intuition, not the other way around. This is powerful magic. You should expect a miracle like MUI to use up some of your Fast Ram.

Is it worth it?

Two thumbs up. Register your copy, or Santa will bring you ANOTHER lump of coal.

[Editor's Note: Colin Thompson has been programming Commodore computers since 1980. He is currently working on a project that allows MUI GUIs to be generated and controlled by DOS, instead of C, E, or Assembler. Direct your hate mail to colin@cts.com.

Colin is also the Editor of "The NotePad", the newsletter of the San Diego Amiga Users Group. SDAUG's address is P.O. Box 81801, San Diego, CA 92138-1801.]

ToC

January General Meeting

reported by Kevin Hopkins

The January 20th meeting was opened with a brand new President at the helm. Jim Huls, in his first act as CUCUG's new President, continued the continuity which has marked our group over its eleven plus years. Beginning with a little hesitancy as a first time President, Jim soon warmed to the task and deftly handled our now traditional introduction of CUCUG's officers.

He then called on Kevin Hisel to present the changes to the By-Laws to the membership for a vote. In a show of hands, the proposed change of the dues structure from a quarterly to a half-year tier passed with only one vote in dissention. Again, with a show of hands, the proposed addition to the By-Laws to define grounds for rescinding membership in CUCUG was passed unanimously.

That business being dispensed with, President Huls opened the floor for our Question and Answer Session.

Following the Question and Answer Session, Jim Huls turned the floor over to Kevin Hisel for the presentation of the Library's new Amiga disks for this month.

CUCUGAMI #137: Aktris (a Tetris clone which uses the falling pieces of well known actresses as the falling blocks, accompanied by maniacal laughter), Charr (a clone of the old VIC game Artillery. We spent quite a while watching this game run in automatic mode. Kevin got roundly booed for turning it off before the finish), and TypeIt (a Commodity to be run under WB2.0 or greater that will complete a word you are typing, from a lookup list you can tailor yourself, just by pressing shift-space.)

CUCUGAMI #138: GfxCon (a utility to load in images and convert them to any of a number of formats), Rockslide (another Tetris-like game), WReadFiles (PROPERLY reads text files by ignoring unspeakable codes and correctly pronouncing words most commonly mispronounced by the Amiga SPEAK: device), and HydroZone (a game where you fly down a 3D obstacle course).

After Kevin's presentation, President Jim Huls announced that he has arranged for Jason Compton of Amiga Reports fame to come speak to our group in June. Jason might bring along his C65. On the heels of that impressive news, Jim reported we had eleven members renew their memberships at this meeting.

ToC

The Amiga SIG

recorded by Kevin Hopkins

After the break, the Amiga SIG was treated to a working demonstration of WReadFiles. The demo during Kevin's main disk presentation faltered due to a missing library, which was subsequently installed on the club machine.

Turning to the scheduled activity of the evening, the floor was opened to specific Amiga related questions and problems members might be having. Kevin Hopkins posed the first question. His sister has recently purchased a clone machine and has asked his help in converting an eight year library of text files from the C64 to her new platform. Having nearly 2000 files to convert from the 64's PETSCII to the DOS world's ASCII, Kevin asked if there was a way to write a script that would repeatedly call a conversion program he has (named P2A), for each of the files on a disk, without having to do it manually for each file. Kevin Hisel offered a solution utilizing the LFORMAT function of the LIST command.

First you would use simple redirection to send the output of the LIST command to a file. In its simplest form it looks like this:

list >RAM:cucug

Working on the fly Kevin Hisel (KH1) wrote a script that handled the basic requirements of the task. It looked like this:

pcd RAM:
list lformat="P2A %s%s RAM:%s" files >RAM:XXX
execute RAM:XXX

The PCD command in the first line is itself a script and can be found in your System:S directory. It comes with your Amiga. It is a CD script that remembers the previous directory you were in. Issuing PCD again, by itself, will return you to the directory you came from.

The LFORMAT option has two pages of explanation in my manual, so if you're interested in learning more, I suggest you refer to your manual. For our discussion here, the %s in the second line is telling the LIST command to just list the filenames. The double %s is telling the LIST command to output the path of the file as well as its filename. The manual says, "The format for the output specification string is LFORMAT=<string>. To include the output of LIST in this string, use the substitution operator %S." So, the second line is the one that builds the script file using my provided command name, then the path/filename of the files it finds in the current directory as the source files, and giving the destination of the conversion process as RAM: with the same filename. The FILES option to LIST specifies files only, no directories. Then, we have our redirect command for the output of the LIST to a file named XXX in RAM:. In the third line, we execute our resultant script file to get our job done. Simple, right? That's why I asked.

Being another of our resident script writers, Jim Lewis was asked to post some of his scripts to the BBS, as examples of using the LFORMAT option, for others to study. Jim said he would.

The next question came from Vice President Dave Witt. He has some Macintosh sound files and wanted to know how to convert them to the Amiga. Kevin Hopkins said he has done this and thought he had used AmiMacTools-1.0a to do it. Upon further research, Kevin (KH2) has discovered he used MacResourcer1.0.a off of Aminet in the mus/misc directory. Jim Lewis said he needed a binhex dearchiver for the Amiga; that is in AmiMacTools in Aminet's misc/emu directory and on the club BBS as well.

Someone asked about "the no name file" on the club disks. KH1 said, with a wry smile, "Don't play with the file named 'space'."

Kevin Hisel then asked' "What's up with the Fonts directory?" This sparked a general discussion about fonts. In the case of a font like diamond. The directory named "diamond" contains the bitmaps for the screen. The file "diamond.font" contains the basic information about the font and the sizes available. The program FixFonts corrects these definitions should something change, like one of the sizes gets deleted.

A Compugraphic Font, like CGTimes, had no "directory". Its .font file contains the font definition for this scalable font. The program Fountain creates a bitmap rendering from an outline font for faster screen printing.

On another topic, Bill Zwicky reported that RTPatch for ReqTools caused his Amiga to crash when accessing the phonebook in the VLT terminal program. Others believed the problem lies in the VLT phonebook itself, as there have been reports of similar problems using it. However, VLT comes highly recommended, as it is very fast.

Someone asked how to create a hidden directory. If I understood correctly, there are no "hidden" directories or files on the Amiga, like in MSDOS. However, there are ways to keep inexperienced yet prying eyes away from certain material you wish to keep less visible. The simplest is to have your Workbench SHOW ICONS ONLY under the WINDOW menu and then make sure the directory you wish to protect has no icon (.info) file. Under WB1.3 and lower this pretty much happened automatically - you didn't have a SHOW ALL FILES where Workbench would provide you with an icon to work with if there wasn't one. No icon; no access. In the above cases, you are relying on your snooper not knowing about the CLI or how to operate Workbench's menu system. Not always a good bet.

Other suggestions as how to hide a directory from unwanted access were to bury it deeply in an unrelated directory tree, or use something like MultiDOS and mess with the format.

A final suggestion was to make the directory with an unusual key combination, as in:

makedir (ALT-Amiga-S)

I suppose how the directory name appears would depend upon which font you had as your System Font, but you could be fairly certain someone prying into your machine would have real trouble coming up with the proper key combination. Of course, our CLI pros promptly said that if you used the DIR INTER command (for DIRectory INTERactive) someone in the know could still gain access to your directory's contents. And, of course, there's CD ? or our good old friend SNAP. But all of these possibilities imply a pretty strong working knowledge of the Amiga

Jim Huls posed the next question. He asked about ENV:. It was pointed out that this is where certain settings and variables are stored by the Amiga for programs' and its use. Your Preferences are stored in ENV:Sys. You can usually find ENV: in RAM:. In order that you can maintain some continuity, these settings are also stored in the ENVARC directory in your System's Preferences directory and read from there into ENV: when you turn on your Amiga. So, if you want a program's settings to be maintained from session to session and it stores those settings in ENV:, make sure a copy also gets put in the ENVARC directory.

As a final bit of information for the night someone mentioned that mouse.prefs will screw up your WB3.x upgrade. Be sure to delete this file before you upgrade and reset it to your preference once your upgrade is complete.

ToC

The C64/128 SIG

reported by Craig Kummerow

The 64/128 SIG attendance was very light, to say the least. But then, that's to be expected on a Friday night in January. The three of us who did brave the cold that night had a nice discussion of the 64/128 world.

We discussed the upcoming year's events, with no real determinations being made regarding specific programs, but we did reach some general conclusions. We felt that most people were very interested in telecommunications. We also felt that very few were extremely interested in programming. (There may be members in the club who are, but we focused on the people who are fairly regular attendees of the meetings.)

We talked about other programs that we did over the years and the response to them. I felt that I was probably the only serious GEOS user, and that the general membership wasn't too interested in any more programs devoted to it. Emil said that he might consider blowing the dust off of NewsRoom and doing a demo on it in February.

During the discussion, I was playing music on Stereo SID Player by Mark Dickerson using the Stereo SID cartridge that CMD has resurrected. I also had a pair of small KOSS speakers in place of a full stereo system. This led to a discussion of other things that were new in the 64/128 world. Don asked if there might be an article in a future newsletter regarding the new (and older) developments regarding the venerable 64. I said I would try to put something together in the near future.

If anyone who was not at the meeting has a request or idea for a program, give me a call or post a message on STARSHIP or Prairienet. We still need suggestions!

ToC

January Board Meeting

recorded by Kevin Hopkins

The January meeting of the CUCUG executive board was held on Wednesday, January 25th at 7PM at Kevin Hisel's house (address and phone number, both in the book). Present at the meeting were: Jim Huls, Dave Witt, Mark Landman, Emil Cobb, Richard Rollins, Craig Kummerow, Fred Cline, Kevin Hopkins, Mike Latinovich, Kevin Hisel, Jon Sago, and Jim Lewis. President Huls opened the meeting by calling on his Vice President.

Dave Witt: Reviewing the General Meeting, Dave said, "The meeting was pretty good."

Mark Landman: Mark said he had talked to the IRS in order to expedite our tax exempt status. He discussed our financial records and our current balance. He finished his report noting we had twelve reups at the meeting and two mail-in renewals.

Emil Cobb: Emil reported that there were 33 people at the January meeting.

Richard Rollins: Richard reported that Vic Serbe will be doing MIDI in a few months. He said he thought Jim Huls did a good job of conducting the meeting.

Craig Kummerow: Craig said he was pleased that in the introduction of officers Jim pronounced his name right. Craig then turned in the money to Treasurer Mark Landman that he'd received for the C64 donation items.

Craig said the January get together was a good meeting. He was disappointed that only three 64 people showed up, so they tabled their plan to discuss the future direction the SIG will take.

Next month, Emil will do Newsroom revisited. Craig says there is real interest in telecommunications and hopes we can resolve the modem problem at the Bresnan Center.

Craig reported that Paul Neubauer said he'll rejoin the group next month. Paul gave Craig a run down on the SX64 repair he's doing for CUCUG. We are in need of a keyboard cable for an SX64.

Finally, Craig reported he does now have a net address. If you'd like to contact Craig you can email him at cwkummer@prairienet.org.

Fred Cline: Fred thought the January meeting was good. Fred calls himself a "User". That's why he's in a Users Group. Speaking generally about the group and what he is seeking from it, he said, "The CLI is over my head, but I enjoy whatever you put on." "I really enjoyed the Gateway trip and the class on DPaint was great."

Kevin Hopkins: Kevin distributed the mail and passed around the exchange newsletters. He brought up the topic of Microsoft's interest in NCSA's Mosaic (see article in this newsletter), which prompted a discussion about the future of Windows and OS/2.

Kevin reported he'd been working this last month on learning HTML (HyperText Markup Language) and exploring Lynx. He brought a version of the January newsletter that can be accessed through Mosaic and Netscape on the WWW. (This version is now online.)

Kevin brought up for discussion a message Jim Huls had put on the BBS about the reception he received from a member of the Bresnan Center staff when he went to renew our room commitment for the new year. KH2 was not the least amused. Others were not so effected. The discussion branched into the possibility of seeking a new meeting site. One recommended was the Electricians Union Hall - Local 601 - in the Industrial Park on north Matthis. It is located adjacent to a building used by Jim Lewis, so we could store our equipment in Jim's facility and just walk it over to the meeting site. The hall is obviously set up for group meetings, as that is its sole purpose. Access to a phone line is also a plus. And, it just so happens that Fred Cline is a retired electrician out of that local and knows the people there. Fred said he would explore the possibilities of using the hall. The group might test the waters with a special telecommunications night later this year.

Kevin reported on the opening of an Office Depot in the building Phar-Mor used to be in out at Market Place Mall. Besides selling computers, they also have a large photocopying center. Kevin said he explored the possibility of printing our newsletter there and we may be able to cut the printing cost even farther than the move to Office One Superstore had gained us.

Finally, Kevin wanted to thank Kevin Hisel for answering his question at meeting and the script he wrote over the weekend has vastly simplified the daunting task of converting those C64 files to MSDOS format.

Mike Latinovich: Mike said, "Good meeting." "Congrats to the new officers." "The new meeting place should be looked at and considered." Mike feels we need to line up some more programs for this upcoming year. Concluding his remarks, Mike told Kevin Hisel he has some of the greatest games on the club disks. He's had great fun playing them.

Kevin Hisel: Kevin said, "We should never ever do a Question and Answer session without seed questions."

Kevin asked how do we stand membership-wise. KH2 reported back that although we are down a little in numbers, we are right about even with where we were last year at this time. KH1 went over his BBS statistics which showed similar overall numbers, but he was concerned that the biggest drop in BBS users was in Amiga using non-members. As this has traditionally been the group we've recruited new members from, Kevin felt that this was not good for club growth.

There was discussion of the preparation and mailing of our annual "Lost Souls" letter for those people we have lost over the last year. This task will be tended to in March.

Kevin reported BBS usage has been up, at 20%.

Disk sales this month were good.

Kevin reported that he had renewed the subscription to the BBS support line.

The BBS is running out of storage space again. We figured we would run out last August, so technically we are ahead of the game. There was discussion of purchasing another hard drive. There was also related talk about a CDROM drive and linking the BBS to Prairienet and all that would entail.

Jon Sago: Jon discussed some of the topics raised at the last meeting. He offered the club a hard drive at a good price if its impending sale didn't go through.

Jim Lewis: Jim said he felt the January meeting went surprisingly well. As to other topics, he said the ones he had meant to discussed had already come up so he would pass on further comment.

Jim Huls: Jim thanked Jim Lewis and Kevin Hisel for their help in the Amiga SIG. He said he thought the second half went well. He was quite pleased that we had no recurring topics from previous Q&A sessions we've held, so we seem to be remaining fresh.

Jim then opened the floor for suggestions for a program at the February meeting. Kevin Hopkins suggested that with all the musicians and gamers we have in the group, why don't we do a night of MOD music. Richard Rollins suggested that we do an evening of how to handle various graphics formats: .gif, .jpeg, etc. Any other suggestions from the members will be gratefully accepted.

ToC

For what it's worth.....

On the subject of sex and violence in video games:

Well, I think violence is the easiest way to express a life and death situation and get the adrenaline pumping. I think it is inevitable to have conflict there. And, I think sex is there because it expresses relationships in a quick way of telegraphing ultimate concern.

Johnny Wilson, Editor-in-Chief of Computer Gaming World

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