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
Copyright © 1988, 1994, 1996 Timothy V. Rue