Dear DDJ,
Please help me with the necessary information to write a device driver for my Apple CP/M system. I have the Softcard and the ALDS system. Since I am using Elite Two double-sided 5.25-inch drives made by now defunct Rana Systems, the system has been modified to recognize these drives. The Ultraterm card by Videx gives the system an 80-column display. The Prometheus Versacard gives the system other capabilities.
I have recently acquired a Universal Disk Controller Card and 3.5-inch drive, both made by Central Point Software. I need to write a device driver or get one from Microsoft to use the 3.5-inch drive from my Apple CP/M V2.2 56K TPA system running on an Apple II +.
With six years experience in Z80 assembly language and some in 6502 assembly language, your help should be all that I need to get the 3.5-inch drive on-line with Apple CP/M.
Gayle Lee Fairless
Huntsville, Ala.
CompuServe 71571,321
Dear DDJ,
I was a little upset when I read the editorial in the June issue about the lack of good programmers. I believe the key word in the editorial is "experienced" programmers, not "good" programmers. Many of the companies that I have talked to will not even look at a programmer unless he or she has at least two years of experience.
I graduated from a small college with a BS in computer science in 1987 and have spent over a year so far looking for a position in the programming field. I have had about 10 to 15 interviews but have always found out that another person was hired because he or she had more experience. I always figured that if I became fluent in a few languages (C, Cobol, Basic, Pascal), that I could easily move from one system to another. After all, there are many similarities between computers and their operating systems; it's all a matter of semantics.
My response to those companies who are looking for people with two years of experience is: look harder at the entry level candidates. College work is experience! A college teacher told me that there was a certificate available from some computing society (ACM?) after four years of experience. He also stated that a degree in the computer science field could be substituted for two years of that experience. If this is true, why are recently graduated college students considered as having no experience? I am sure that they all worked hard to earn their degrees.
Entry level people trying to get into the business may cost the company less in salaries and will probably benefit the company if they stay for a few years. Not only do they gain experience but they will know the company and its systems better. It would also help the present staff: what better way is there to test your knowledge and your experience than to answer the ad hoc questions that an eager trainee can come up with?
Start a training or intern program that brings in entry level people. An intern program would be a great way to test the abilities of the candidates for the training program. This would benefit the students by giving them a few months of hands on experience that everyone is looking for. Many entry level people may not need all the training you think they will. Some will catch on to the company's policies and the computer systems in a very short time. Those are the people who will benefit the company the most. A rigorous training class may not be needed. Simply assigning an employee to a trainee as a mentor would be more than adequate for most. The reduced salary that these trainees collect over an experienced candidate will save the company some money.
I am still looking for a position in the computer field. I did not spend four years of my life and over ten thousand dollars to give up and go to work the rest of my life as a laborer. I consider myself a good programmer and try to keep up with what the industry wants. Your magazine has been a great help. Get the companies to hire entry level people right out of school.
Gary Krone
Kansas City, Mo.
Dear DDJ,
My company manufactures a PC compatible data-base software product. We are familiar with the PC environment at the user level. The vast majority of the work we do is microprocessor development in embedded control applications. The hardware we build is not PC compatible, however, so what I am anxious to find are resources for algorithms in general terms that can solve problems we often encounter.
There are many functions that are taken for granted in a high-level language that do not exist in machine code. For instance, floating-point routines, sine, cosine, square root, graphics, and ASCII to binary routines are becoming much more important to our needs. Where can the fundamental algorithms be found to implement these functions?
The ideal solution for me would be a reference book (or books) that describes at a flow chart level how to code these algorithms independent of a specific processor. The chart below shows some of the algorithms I would like to have in my bag of tricks.
If your readers could suggest places to look or publications that answer some of these questions, I would appreciate it very much. I think this need is shared by a great many engineers in addition to myself.
Alan Clark
Dynatech Nevada
Carson City, Nev.
floating point add, subtract, multiply, divide
trig sine, cosine, tangent
square root integer and floating
integer to floating conversion
floating to integer conversion
graphic show to model a bit mapped plane and
draw lines from point to point, circles,
and other shapes
ascii to integer convert an ascii string to
signed/unsigned integer
ascii to floating pt. convert ascii string to signed/unsigned
floating pt.
Dear DDJ,
The Turbo C versus Quick C debate eventually comes down to whether you like the Turbo or Quick interface better. I think that given time, the compilers will be about equal. At the moment, however, TC seems to have the edge as being a more complete, general purpose package than QC. TC provides about the same capability and performance as MSC 5.0 and QC together (minus CV, of course). The main problem with QC is that I think it was shipped much too early as a response to TC. When I received QC as part of my MSC 5.0 update, I had already been using TC for several months. I quickly discovered several things about QC 1.0.
Where TC 1.0 had bugs, QC 1.0 had BUGS. It crashed, it didn't like TSRs, it couldn't handle large or even medium size programs, and it was a memory hog. it apparently interacted closely enough with the hardware to cause damage to hard disk FATs if you had a certain model controller. I was not amused.
The integrated environment provided no control over anything. You were stuck with the medium model (I usually only keep large and small model libraries installed). Coprocessor support wasn't available. Trying to find the limitations of the integrated environment was not easy. I thought that the QC documentation was rather sketchy in this regard.
Unfortunately neither TC nor QC comes with an acceptable editor. Most people consider multiple file capability a minimum requirement. (The Microsoft ME editor shipped with the MASM 5.0 also seems to be a klunker.)
At present I use TC for prototyping and MSC 5.0 for production code. For now this seems to be the optimal development environment. Perhaps I will try QC again in the future, but really don't see anything in particular to recommend it. CV compatibility is nice, but source-level debuggers are only useful in certain situations and CV's size and lack of speed somewhat handicap it for larger programs. I do hope Borland will ship a source level debugger or provide CV support, but i can always switch to MSC 5.0 and use CV.
Michael W. Jeorms
Westmont, Ill.
Dear DDJ,
God preserve us from language standard committees.
The beauty and power of C has always been that, within very broad limits, it left the decisions up to you, and did not constrict your possibilities within the bounds of what other people thought appropriate. If you substituted your own routine for a standard one, and it worked, all well and good. if it didn't--on your head be it.
In other words, you were supposed to be adult enough to make your own decisions and to accept the responsibility if they went wrong, even if only because of unforeseen, possibly undocumented side-effects.
So, will the ANSI C committee (and any other language standardization committees that may be listening) please note--RESERVED WORDS ARE A BAD THING. Although a necessary evil, they are bad in themselves for psychological reasons, but particularly bad for C, both for the reasons given by Mr. Linke (see DDJ "Letters," January 1988) and the fact that existing programs are suddenly liable to stop working--I've had that problem often enough with "improvements" to other languages.
Interested though I am to produce programs which run faster and more efficiently, and which can be ported to other machines more easily, I am most interested in writing programs which work-and everything I have seen so far makes me suspect that that will be more difficult, not less.
C.J. Price
Dortmund 1, W. Germany
We welcome your comments (and suggestions). Mail your letters to DDJ, 501 Galveston Dr., Redwood City, CA 94063, or send them electronically to CompuServe 76704,50 or MCI Mail c/o DDJ. Please include your name, city, and state. We reserve the right to edit letters.