
    This file was put together for an AAi presentation:

    If you like the concept of packaging or the look of the logo then let
    VIScorp know.
                                Thanks,

    By: Timothy Rue

   There are three topics covered.


   1). Incorporating the Amiga "check-mark" into the VIScorp
       logo. Art-work included as well as rendering files.

   2). Hardware considerations that can satisfy the wide
       variety of user and developer interest, applications
       and wants. Yet reducing re-packaging cost to a minimum,
       while increasing versatility and stability of product
       line. And as such, lend to improving sales and support
       by establishing standards with user versatility in mind
       as well as being easier on the support and warranty
       service.

   3). OS considerations that need to be addressed. To the
       point, one bad apple shouldn't spoil the bunch.
       Meaning that in a multi-tasking environment, one
       faulty application program should not crash the whole
       system, but be removed. And this ability should be
       integrated into the OS and not some application
       program. If there is any one thing about the Amiga
       OS that ticks me off, it is this by far. After working
       for hours on something, having the system crash or
       lock up, keeping me from continuing with otherwise
       trouble free applications.

Access Image


 1) - VIScorp LOGO and Amiga check mark.

     Although the artwork was produced using Lightwave, the
 intended out-put media is that print. Using solid colors (blue,
 green, yellow, orange, red, purple, black and gray). Color
 separations files are included (ImageMaster was used to produce
 these). The LightWave files are also included, for better or
 worst - knowing from experience clients, if given the opportunity
 to make changes may never stop making changes with a result of
 nothing happening. On the other hand, flexibility to make changes
 with-in reasonable limits, is also important in client satisfaction.

     Using the LightWave files, you may make the changes you see fit
 (in the event you decide to use this logo). But even if no changes
 are needed you may want to render it out in a higher resolution
 than "2x video/square pixel/limited region on". And this is my
 main reason for including these files. Also, to brighten up the
 colors simple bring the LightWave generated file into ImageMaster,
 ImageFX, or any other such program and use the "Dynamic Range"
 operation on it. Setting the range limits to your desire.

     The general idea of incorporating the Amiga check-mark into
 the VIScorp logo was easy enough. The challange was in making it
 do what a logo is supposed to do, making it "WORK" for the
 company. Getting it to communicate a message people will remember
 while avoiding criticism. I believe I have accomplished this.

     "AMIGA" has well established itself as a foundation. As used
 in the logo it represents not only this foundation but that it is
 a foundation with depth. Done so in a manner to honor the orginal
 company "AMIGA" as well as recognizing the often used concept of
 hiding the computer in the so many ways it has been (from the coin
 operated arcade game to the trade show "under the skirt" system
 to the re-labeling it "Video Toaster System" and selling it to the
 Mac user to control via Mac, from the early "trade secret" of the
 Television/Film industry to the little publicized applications that
 make a difference, etc..) "AMIGA" is intentionally an out-line.
     As used in the VIScorp logo, "AMIGA" is used to give depth and
 foundation to VIScorp, to help "VIScorp" stand out. It also make the
 integrated statement that VIScorp "IS" Amiga. Which I believe is
 the intent of incorporting the check-mark into VIScorp, but makes
 it a bit clearer.

     The color scheme of the check-mark was taken from a very old
 Amiga credit card, there was no purple in it and the five colors
 were well defined. Purple, being the missing color from this set,
 as well as the color of the VIScorp business card, is used to
 balance the logo with it's application in the "O" of "corp".

     I don't know exactly what font was used in the logo on the
 VIScorp business card, but I used "Veracruz" from the Toaster font
 set. Perhaps the font I used would need to be changed to the
 correct font, but then again most people are probably seeing the
 Wed Page font which is nothing like the Business card and won't
 work well with this logo.

     The "IS" of VIScorp is intentionally a thick outline to help
 tie it to the check-mark-V. The check-mark-V is the formost object
 in depth and curves down over the "IS" additionally helping to tie
 the "checkmark-V" to the "IS", then the "corp". And the "corp" has
 it's "o" that ties it to the check-mark-V as well.
     The inner color of "IS" is intentionally gray (darker or
 different than the background) to pull it away from the gray
 background. I would like to suggest this color change, but over
 time. Currently VIScorp is a new owner of the Amiga, as such the
 color is gray to signify the unknown. As time goes by and VIScorp
 establishes itself with outside developers and users to be the
 company to do things right, to produce and support quality Amiga
 based products, this inner "IS" color should change to bronse,
 silver, then gold. Perhaps the "I" for users and developers and
 the "S" for financial Success (thought neither would go to a
 higher quality without both qualifying).

     Versatility/Application of the logo - Being an Eight Color
 logo does mean it's application will be a bit more expensive than
 a two or three color logo. However, this logo can be adjusted for
 single color use or gray scale.
     In addition to this, the logo can be changed in ways that only
 suggest a different application, rather than a different logo.
 Keeping the importance of consistancy of company ID in mind, but
 not limiting versatility. (i.e. remove "amiga" and drop down "IS"
 and "corp" to the same level, perhaps enlarging these to better
 fit the check-mark-V).
     As the logo is here, not only does it work well with the
 Business Card application, but works well with product
 identification. Of note is the free area to the upper right as
 well as the upper left. For the business card, the upper right
 would contain the typical name, title, address, while the upper
 left phone numbers.
     For Product identification, I'll jump ahead of myself here and
 touch on topic #2 mentioned above, but only that #2 lends itself
 to easily using single color (black) line-art icon with a general
 rectangular shape. Such icons may represent unit blocks the user
 may easily add to expand their system (i.e power supply blocks,
 Amiga System block, drive expansion blocks, card expansion blocks,
 3rd party VIScorp approved blocks, Printer/Fax/Copier blocks,
 card-swipe blocks, LCD display block, etc..).  Such a standard
 rectangular icon shape will easily fit into the upper right area
 of the logo. One, two or even three icons may fit in a stacked
 manner (for standard block packages) and such "stacking" would be
 consistant with the block style packaging of products, as mentioned
 in #2. In the logo these Product Icons would have, as their support,
 the "corp" and "AMIGA" as a firm foundation. As well, such a product
 stand can be produced to actually hold product block(s) on display.



 2) - Amiga packaging (Hardware).


         The Amiga seems to be the computer that fits into all the
 cracks, gaps and holes in reguard to the computer industry. As such it
 is difficult to fill the wants and needs of so many when it comes to
 packaging. It does seem that one thing everyone wants is
 expandability.

         I believe there is a workable solutions that most will find
 satisfactory and perhaps as a pleasent suprise. The concept is to
 produce the Amiga into parts or blocks that may be attached and even
 re-configured to fit the packaging needs of many. Such configuring
 abilities certainly would increase the versatility of the system as
 well as allow users to expand their system as they see fit.

         I think from the manufacturing and service perspective, cost
 would be reduced as a result of dealing with standard packaging blocks.
 Electronically, the Amiga seems to have it's Amiga primary board, an
 ability add/enable board and a CPU board. The Amiga primary board would
 be standard in all Amigas where the ability add/enable board is used to
 add or make available additional features of the Amiga. The CPU board
 of course may also contain ram expansion and scsi or IDE interface. The
 variables here would be the ability add/enable board and the CPU board
 and this will allow price differences with the Amiga block.

         The blocks attach to each other through a slot that is
 accessable from both the top and bottom of the right side of the
 block (see dark gray slot panel cover on the units top right side,
 back-side top for the lap-top and hidden in the set top base.) There
 is a "T" pass-thru card the internal boards plug into, which has a card
 edge connector on it's top and bottom edge. The blocks are connected
 using what would be a double sided card edge connector. Securing the
 blocks together is done by removing the light blue rubber molding,
 behind which is the securing screws. This rubber molding also functions
 as the feet so the tower/stacked system, or even the desk-top may be
 layed/sat on it's side (preferably on the right side, due mounting
 direction of the cards that internally plug into the T pass-thru card.)

         The systems in the image:

     Lap-Top - Though not a slim unit but more like a small brief-case,
 uses the standard Amiga Block (bottom), Floppy-plus block (may contain
 up to two hard-drives), Key-board (full size standard), LCD panel (near
 the size of a 13" monitor.) The block on the lower far end is the
 battery pack and external port pass-thru. Additionally the LCD panel may
 contain additional battey power, LCD interface and speakers. Note: the
 LCD panels VIScorp logos - if the LCD panel is mounted to the towers
 top, the LCD panel can fold down the right side of the panel and be
 switched to allow correct viewing/listening.

     Tower/stack - Custom sizable so mini, mid and full don't really
 apply. From the bottom up, Standard Power supply block (this block might
 contain up to three power units (allowing lower cost for those going
 with the basic as well as upgrading as they expand the power requirement
 - while adding another power block is also allowable). Next up is the
 standard Amiga block followed by a card expansion block. The Floppy Plus
 block is next and is followed by a Drive bay block (actually the Card
 expansion block and the drive block could be the same standard block,
 giving the user the option on use). Topping the stack is a standard
 expansion block like the two larger blocks but just small (same heigth
 as the floppy)

     Desk-top - bottom left and clock-wise. Drive/card expansion block
 and Floppy Plus Block. The top is a connector panel that allows stacks
 to be used side-by-side. Then the shorter expansion block followed by
 the Amiga block and finally the Power block.

     Setting on top of the desk-top is the set-top box. This is only
 the Amiga Block with attached (same size as the floppy plus block)
 card swipe block. The base might contain the power supply.

     Personally I think the Set-top box concept is fantastic. It should
 get the Amiga into many homes where it can be expanded as new users are
 introduced to computers and electronic communications. As to third parties
 wanting to license the technology, if the primary Amiga board is versatile
 enough, the boards could be sold in quanity/discount and be used as the
 buyer sees fit or within agreed upon limits. Correct me if I'm wrong, but
 is not the whole idea to generate the finances to payoff debts, improve
 the technology, and earn a nice income for those responsible just the
 business cycle of advancing technology?

     Somewhere is all of this there is a rack-mount and variations of
 portables.

     As you can see, applying some block/modular design to the Amiga
 packaging, it is possible for one to have such a system that may be
 changed around to fit their needs. Such a design has many advantages.
 One of which may be the ability to up-grade the whole system by simple
 upgrading the Amiga block (with newer technology).


     Through standardization and versatility, cost are reduced in areas
 that don't need to be high, for both consumer and manufacture. With the
 price of computer dropping so fast there must be an extra edge and I
 believe this is it. Value added reselling and real Plug-N-Play.

     The casing might well be plastic injection mold, with the back out.
 The electronic slides in from the back and included whatever sheilding
 (thin metal as required). Third party developers no longer need to be
 so concerned with users installing there hardware via real Plug-N-Play.
 And users don't need to be so fearful to expand due installation
 expense or do it yourself fear.

     Ventilation and external connectors are not included in the files
 but I'm sure it's no problem to figure it out. I can easily see it in my
 head.

     All in all there are, given the included files, basicly three
 different heights to the blocks, something a little over 1", 2" and
 4". All with a width of about 8". Of course the keyboard, battery pack
 and perhaps the LCD all break the depth of about 15" and the two stack
 panel connector breaks the standard width, but all these do so in a
 very functional way. See and study the LightWave files which are done
 to scale.

     From the hardware developer perspective, I can see the slot being
 use to plug a development/prototype board directly into while leaving
 accessability to both sides of the prototype board.

     From the software developer perspective (especially the team) I can
 see where there is the ability to directly plug a take along unit into a
 main Amiga to transfer code/application. This does bring up networking
 but to have the ability to directly connect Amiga's to the same bus
 lines (given additional control lines as would be needed) could and
 probably would have worth while advantages. I do recall something
 having been developed for the Amiga along the lines of a transputer/
 parrallel processor system (via add on boards) many years ago.

     Personally, I have an Amiga 1000 and an A4000. The reason I didn't
 up-grade over the years is because I simply didn't see enough of an
 advantage to do so. My purchase of the A4000 was just before Commodore
 went bankrupt and the hardware problems resulted in something of a
 nightmare for me that lasted about a year. Still I'm not completely
 satisfied and sometimes wonder if I'm not still having hardware
 problems but I believe it more an OS and software problems than
 hardware. Had such a modular system existed I have no doubt I would
 have felt more comfortable and probably would have spent more over the
 years to up-grade and expand. Knowing that replacing or adding blocks
 would be a smaller investment than buying a whole new system. And the
 block/modular components would hold value longer due to reusability.

     There is absolutly no doubt in my mind that I'm not the only one
 whom feels this way (or would should others preceive the advantages
 and versatility of a block/modular system). In all the years of the
 Amiga I have only heard a few positive things about the packaging of
 the Amiga, mostly I hear complaints. Of the positive, the one that
 stands out with consistancy is that of the Amiga 2000 having room for
 expandability. What everything I've heard tells me is that people
 don't buy an Amiga for it's looks or small size, but for what they can
 do with it. A block/modular system is much more than any one design
 but that which allows users to create their own design(s) as needed
 and to change the design to fit their current need.



 3) OS and multi-tasking. (warning - this may appear a bit hot
                tempered, but not without cause and clear logic).


     A) - Error catching

         Having a multi-tasking OS is great but to have a multi-tasking
 OS that can be shut down by one faulty application is only a little
 better (if even that) than having a single-tasking OS.
         If there is any one thing about computers that can frustrate
 the user, it has got to be system crashes, lock-up, etc.. And although
 the Amiga has a better multi-tasking environment than the other
 consumer/small business systems, it should and needs to also lead in
 stability. And a smaller OS means less to contend with in reaching
 stability.

         What should be the response of the Amiga OS, when handed a
 faulty application, is a shutdown and removal of the application with
 a file generated giving details. As does Unix based systems. And
 although the Amiga can do this with the help of given application
 software, it should be built into the OS and be more direct about it.

         When software cause problems and failure it should be clear
 it's software and likewise for hardware. I spent far to much energy,
 stress and money in an effort to pin down problems, only to find it
 was the #@@$!@ setpatch program causing all the problems. And the pain
 it was to get ahold of a "better" setpatch program. THIS IS PURE BS
 AND DOES NOT IN ANY WAY HELP SELL THE SYSTEM!!! And the only possible
 excuse for any of this BS to exist in the first place is that of
 laziness and/or stupidity by those whom caused it to exist, probably
 due some constraints given the programmer(s) by management during OS
 development.

         Checking for errors does cost. Checking for user errors in an
 application can result in a rather large portion of the total code of
 an application. Code that could be avoided if all users did things
 right. Checking for errors within an application program or OS is
 totally the responsibility of the programmer(s). For the OS programmer
 the task is to check for their users (application developers) error.
 The application developers job is to check their user (application
 users) error. Both do their best to find and correct their own errors
 as well as check for their user error.

         "So lets leave it up to the Application programmers to do
 things right so we can skip all the error checking and let the
 end-user blame the application programmers when things crash. Besides,
 we can justify this by saying - look at the wonderful OS we've given
 you." If this has been the attitude of those responsible for the OS,
 be it programmer or management, then this attitude has got to change!
 There is not a good enough reason to allow so much frustration for the
 end user and other application developers, whom do things right, that
 justifies avoiding error checking at the OS level.

         To really get the application developers to do things right,
 have the system tell the end user who is breaking the rules, rather
 than letting some rule breaking Application developer BS customers
 into thinking it's someone elses fault. Or causing the end-user to pull
 their hair out in trying to pin the problem down. Who knows, it'll
 probably help expose problems in the OS as well (i.e. setpatch).

         THE ONLY REASON TO NOT BETTER CHECK FOR, CATCH AND REMOVE
 APPLICATIONS IN FALURE, is to support or open the door to the con game
 of pass the buck and blame the other guy. Ultimatly this can only lead
 the end-user into dropping the whole thing, blaming the wrong party or
 blamming everyone, and is an injustice to those doing things right and
 supporting the system.

         The Amiga certainly has the potential to lead in this area of
 error catching and removal at the system level, due it's small OS.


     B) - Multi-tasking

         Once the OS becomes solid and able to protect itself from
 faulty applications, then and only then does the concept of true
 multi-masking become viable and friendly at the consumer level and up.

         The true power of multi-tasking, on the Amiga and with all due
 respects, has been little more than what can and has been done on
 single tasking systems. At best it is an experimental base for those
 who toy with it. The Amiga has multi-tasking potential that is far beyond
 anything currently being done with it on a wide scale consumer level.
         In most cases it is simply the ability to allow applications
 to continue running while the user is interfacing with another
 application. If anything this is just a convience that allows some
 level (a give and take) of increased productivity. There are of course
 such applications that do make strong use of the multi-tasking
 abilities but these are usually dedicated or specifically designed
 configurations of which some programmer(s) have done for a short term
 application.

         Perhaps all this is due the evolution from single-tasking to
 multi-tasking, that is the single-tasking mentality of doing things in a
 multi-tasking environment via single-tasking methods. Clearly the
 hurdle to get over is that of changing tasking mentality. Education of
 multi-tasking mentality is needed.

         In all honesty, the true power of multi-tasking has only been
 toyed with in the form of running several single-tasking application
 with perhaps a communication port between them.

         Imagine for a moment the construction of a house. Using a
 single-tasking mentality either one of two things will happen. At best
 it will take a long time for the house to be built. At worst the house
 will not get built due to deterioration of what has been completed
 while waiting for enough progress to happen to protect it from such.
 As a real example, visit a construction site of a house over the
 progress of it's construction. At times you will find many and various
 craft-people all working at the same time and at times in
 co-ordination with each other. Complete houses (from foundation to
 handing the key over to the tenant) the have been built in less than a
 day.
         The Amiga accomplishes much of its power due the co-processing
 abilities of it's different processors. And it also has a robust
 Multi-tasking OS on top of it. Yet and for the most part it has
 those with single-tasking mentality using it.

         What is missing from the Amiga, that would help educate users
 and developers alike, is really nothing more than built-in system tools.
 Simple tools that would both remind and allows users/developers to
 better evolve their tasking mentality towards multi-tasking. Tools
 that may be used for single-tasking application concepts yet open to
 combining single-tasking parts into a multi-tasking capable
 application. It really is not so complicated or complex to define and
 make available such tools or use of.

         Much like so many whom have discovered the multi-tasking
 advantages of the Amiga vs. other consumer/small business systems,
 true multi-tasking power, once experienced, will be seen as something
 that is hard to imagine we were doing without. As it is difficult to
 imagine how we once input data via holes punched in cards.

         The first step towards true multi-tasking mentality is, of
 course, removing the mental block of the single-tasking mentality.
 Recognizing the importance of the single-tasking mental process of
 co-ordinating many processes/applications to function at or near the
 same time in order to accomplish a common goal. To define the various
 processes/applications is something to be done one by one, single-
 tasking. To apply the multi-tasking functionality is to co-ordinate all
 the processes/applications so that they may work together for a common
 goal. The co-ordinator itself is single-tasking in it's assignments and
 data passing to the processes or application but what is important is
 that the co-ordinator allows for and functions alongside the many
 running processes/applications. The co-ordinator, or any process/
 application may be or become the current user interface awaiting user
 input.

         As an example of applying true multi-tasking, imagine
 application programs that represent the various craft-persons involved
 in the construction of a house. Also consider you will have more than
 one of any one type of craft-person. Now you are the main contractor
 program, now co-ordinate the construction. Answer the numerious
 questions the crafts-persons will have, obtain information from those
 who have the answers and give it to those who need it, etc.. As the
 main contractor you do not need to know all the details but do need to
 have an understanding of what the goal is in order to make proper
 decisions. If you are the buyer and are having the house built to meet
 your specs., you only need to know what the end goal is and have
 ability/user-interface to communicate it to the main contractor.

         If you can imagine how even some of this can happen then you
 will begin to see the true power of multi-tasking.

         To make this example a bit more intune with what the Amiga is
 known for, consider yourself a buyer of an animation of the
 construction of a house. You define the goal and true multi-tasking
 makes it happen. Instead of going into LightWave and creating a wall
 or installing the lights or painting the walls, you simply define the
 goal and answer questions to refine the goal. The crafts-persons/
 applications already know their trained/programmed tasks.

         So where does all of this knowledge these crafts-persons/
 applications come from? It comes from those whom have it. But it is
 thru the use of common system/OS tools that allow such various
 knowledge bases to be pulled together into a goal directed true
 multi-tasking application.

         Now here is the hard part, at least for me. Like the four
 minute mile, nobody could break it because nobody believed it could
 be broken. The individual whom had the most difficulty in breaking
 this barrier was the one whom broke it. Difficulty was not in doing
 it, for others quickly followed, but in overcomming the mental
 programming or belief the four minute mile could not be broken. Not
 only was it a personal mental challenge but a challenge of addressing
 the mentality of other runners and even the competition event.
         Likewise, I may know what the system/OS tools are or can be to
 accomplish the above but I also know I could spend a lifetime or two
 trying to convince others, addressing the insistant single-tasking
 mentality of so many. Even just addressing the question of weither or
 not I know what a bit is could take several lifetimes so long as those
 asking insist on having limitation of mentality (be it for what ever
 reason, perhaps something along the concept of con BS. The con BS of
 which is very very real and rather wide spread, otherwise the Amiga
 would certainly be alot further along than it is).

         Hot-tempered and/or negitive is not my intent. My effort is
 in honesty about reality. And with this, I know what the tools are,
 how they can be used, and the reality of knowing these tools are
 easily within our current technology.

     **** The following is one possibility, perhaps there are other
 configurations that will also work. Keep in mind there is always
 more than one way to skin a cat, but until one decides which way to
 do it, it'll not get done. I've spent alot of time with this and I
 have clear vision about it. But I don't want to come off as though
 I have an ego problem or any other such thing which may be use as
 a BS excuse for someone else intent on fabricating a con.
          I am open, as I always have been, to any productive direction
 (communication, development, etc..) towards creating and applying what
 follows.  ****

 The following are clips from a much larger work:
************************************************************************

These clips are not included here. Refer to the web pages about the V.I.C.


************************************************************************
Email: timrue@mindspring.com